はじめに
こちらは技術的ポエム Advent Calendar 2018の22日目の記事です。
今回はここ最近、感じている 『アーキテクチャの選定の難しさ』 について書いていきたいと思います。
アーキテクチャ選定について
新規プロダクトの開発をする時に、当然、アーキテクチャを選定する必要があります。
では、アーキテクチャはどのように選定すべきなのでしょうか？
筆者が振り返って今感じる、選定時に考えるべきポイントを紹介したいと思います。
個人的に大事だと思うポイントは下記の4つになります。
【ポイント】
- プロダクトの規模感
- 単発的なサービスか長期的に育てていくサービスか
- チームメンバーのスキルセットの把握とマインドの統一
- QCDの優先順位
順を追って1つずつ説明していきましょう。
プロダクトの規模感
例えば、画面数が3〜4個でロジックが簡易なアプリに Clean Architecture を適用するのが本当に正しいのかという話です。
とは言え、『 Testability を高めた設計にしたい』という想いや、『新しい設計思想で開発したい』という想いも技術者なら持ち合わせて然るべきです。
なので、筆者個人としては、他ポイントと合わせた上で、結論を出すべきだと思っています。
単発的なサービスか長期的に育てていくサービスか
CM用の一時的なサービスであれば、そこまで運用を考えすぎずに、技術者の裁量で決めてしまっても良いように思えます。
もちろん、CMを打つタイミングでサービスが完成していないといった状況は避けるべきではありますが…
一方で長期的に育てていくサービスはどうすべきなのでしょうか？
筆者個人としては、下記理由から、現状よりも一段階上のレベルの挑戦をするのが適切だと思っています。
① 現時点でレガシーすぎる技術を使うと、 今後の採用に響く 可能性がある
② 早くサービスを世に出す ということも事業として大切である
③ 挑戦が メンバーやチームを成長させる
①は技術者であれば割と受け入れやすい、わかりやすい理由ではないかと思います。
②は技術への興味が強すぎると忘れ去られがちなこともありますが、
これを軽視してしまうと『誰の/何のためにサービスを作っているのか』などのゴールを見失う可能性があると思っています。
とは言え、③の観点は非常に重要だと思っています。
ただし、既に開発プロセスや利用ツールや、何らかのルールなど多分に新しい挑戦が組み込まれている場合は注意が必要です。
なぜなら、それらも 異なる側面での挑戦である ことに他ならないからです。
挑戦は楽しい一方で、それなりに負担でもあるため、一度に多くの挑戦を組み込むと、デスマーチに近づく可能性が高くなることでしょう。
チームメンバーのスキルセットの把握とマインドの統一
アーキテクチャを選考するにあたって切っても切り離せないのが、チームメンバーのスキルセットとマインドだと筆者は考えています。
どういうことかと言うと、
もし、納期の厳しいスピードを最優先とされるプロジェクトにアサインされたとして、
誰も利用経験のないアーキテクチャを採用するかどうか
ということです。
基本的には、 チームを先導できるレベルの技術者がいない状況 では、ハードルが高いなと思っています。
ただし、『利用経験のない』とは必ずしも、業務での利用経験とイコールと捉えなくとも良い気はしています。
なぜなら、これを許容しないと、誰も新しいことに挑戦できない世の中になるからです。
(世の中から挑戦が一切なくなると、創造性もなくなり…みたいな話にもなるのかもしれませんね。)
そして開発を始める前に必ずやらなければならないことが『マインドの統一』です。
事前にこれをしておかないと、技術的な問題にぶつかった際に、チームが崩壊するリスクも備えています。
筆者としては、チームメンバーに方針を納得してもらった上で一緒に開発を進めたいと思っています。
最低でも 『なぜ / 今回 / このアーキテクチャを採用するのか』 は説明し、納得してもらう必要があるでしょう。
欲を言えば、チームで意見交換をした上でアーキテクチャを選定したくはありますが、
チームのスキルセットや外部要因に影響されることでもあるため、次のレベルかなと思ったりします。
QCDの優先順位
プロジェクトを進める上で業務上設定される QCD の優先順位が存在するかと思います。
これはアーキテクチャを選定する上で最も影響のあるポイントと言っても過言ではないかもしれません。
他のポイントを説明する際にも「納期の厳しいスピードを最優先とされる」といった形で引用しましたが、特に技術者が気にするポイントはDelivery(納期)ではないでしょうか。
基本的に、サービスを世に送り出すことにおいて、Deliveryが軽視されることは稀かと思います。
大抵の場合、Quality(品質)と同等かそれ以上に優先度が設定されることがあります。
また、Quality > Delivery > Cost の順番で優先度を設定したプロジェクトだったとしても、
途中で Quality を優先するために Delivery を変更することは至難の業である場合が多いと思います。
(何のための優先順位決めなのかと議論になることもありますが、ここでは論点がずれるため触れないこととします。)
筆者も上記のような経験を何度かしてきました。
その結果、アーキテクチャを決める上で厳しくシビアに判定しなければいけないポイントだと思うようになりました。
つまり、誤解を恐れずに言えば、
圧倒的に Delivery が優先される現場においては、他のポイントを考えるまでもなくアーキテクチャが決まると言うことです。
しかしながら、この Delivery の MUST 性はもう少し分解することが可能です。
極端な例で言えば、
『毎年決まった時期にリリースしているサービス』で『特定の層のほとんどが認知して利用しているサービス』
と
『今回初めてリリースするため、リリース後に徐々に広告を増やしてアピールしていくサービス』
では、Delivery 最優先と設定されたとしても、遅れた場合に生じる企業へのダメージは明らかに異なるでしょう。
よって、 Delivery が優先度高であるとは言っても、 本当に最上なのか はきちんと判断すると良いかと思います。
まとめ
さて、今回は、筆者がアーキテクチャ選定する時に大事だと思う4つの観点について説明しました。
文章で書くのは簡単ですが、実践は相当に難しいと思います。
何が難しいかで言うと、多面的かつ複合的に考える必要がある上に経験に頼る部分も大きくなるからです。
筆者も正直、上記4点から最良のアーキテクチャ選定ができたなと思える経験はなかなかありません。
失敗の方が圧倒的に多いです。
それでも、アーキテクチャ選定は今後も逃れることのできない、技術者が考えなくてはならない事柄だと思います。
そして恐らく完璧な答えなどない世界なんだと思います。
でも、だからこそ、責任のある重要な仕事であり、やりがいのある仕事なのではないでしょうか。
筆者自身も今後の経験で考え方が変わる可能性も十分にありますし、
この記事が最良だとも思っていませんが、
自身がまたアーキテクチャ設計に関わる時に思い出したり、誰かの役に少しでも立つのであれば幸いかなと思います。
と言ったところで本日はここまで。
ポエムでした。