未来は予測不能！技術選定の意思決定において一番大切なこと
持続可能なプロダクト開発において、技術選定の意思決定は重要な要素です。
この記事では、技術選定の意思決定において一番大切なことと、それを実現するための6つの取り組みを紹介します。
サクッと読みたい方はこちらのスライドもどうぞ。
対象読者
- チーム開発で技術選定に携わっている
- 技術選定の意思決定に悩んでいる
- プロダクトの持続性を向上させたい
はじめに
筆者は、5年以上の長年に渡り運用されているプロダクトでの開発から、0 → 1の立ち上げまで、様々なプロダクト開発に携わってきました。
長年運用されているプロダクトを開発する際には、保守性が低く、どうしてこんな技術選定になっているのか？なぜこのような実装になっているのか？と不満に感じることがありました。しかし、当時の背景や状況を知ることができないため、すでに動いているものが絶対視され、そのままになってしまうことが多かったです。
一方で、新プロジェクトの立ち上げに際して、技術選定にとても苦慮しました。数年後もプロダクトがスケールし続け、保守性が低下しない基盤を築くためには、どの技術を選ぶべきなのか？ という問いに答えることが難しかったです。
技術選定の意思決定において一番大切なこと
両方の立場の経験から、技術選定の意思決定において一番大切なことは、「技術選定の意思決定を言語化して属人化を防ぎ、透明性を高めること」だと考えています。
つまり、数年後を見据えた正解を出すことは難しく時間の経過や外部環境の変化によって最適な技術選定は変わっていくので後からの軌道修正をできるようにしたい。そのためには、判断材料として当時の意思決定をいつでも振り返ることができる状態にしておくのが重要だという考え方です。
この記事では、この考え方を実践するための6つの取り組みを紹介します。
意思決定の透明性を高めるための6つの取り組み
1. チームの壁を超えた広い視野で議論する
チームの壁を超えて議論をし、広い視野で技術選定ができます。
手っ取り早く行える方法としては、普段からチーム横断の技術Meetupを定例で開催するのがおすすめです。具体的には、技術領域に特化してフロントエンド会、サーバーサイド会、インフラ会のようなものを週次で開催します。
このMeetupの中で、技術選定について共有や相談するコーナーを設けることで、他チームのメンバーにも知見を共有したり、相談したりできます。また、インターンや業務委託メンバーにも参加してもらうことで、社外からの視点も得られます。
また、副次的な効果として、技術選定の議論について社内で多くのメンバーに知ることが出来るため、暗黙知を減らすことができ、チームの異動や入退職があっても引き継ぎがしやすくなります。
この取り組みによって、広い視野で議論ができ、議論の質が向上します。
2. 会社の壁を超えた広い視野で議論する
技術選定の過程や結果をテックブログや登壇などで社外に公開することで、世界中からのフィードバックを得ることができます。
テックブログなどの媒体を活用し、技術選定の過程や結果を公開するのがおすすめです。私も勤務先のテックブログで技術選定に関して何本か記事を上げています。
記事化するにあたり言語化されるメリットがあります。社外でも見せられる文章にしないといけないので、誰でも理解しやすい意思決定の説明を世の中に残すことができます。
さらに、社外公開されることで、支持を可視化できます。いいね数などから、現時点で正しい選択をしているのかどうか定量的に証明できます。また、世界中からフィードバックコメントを得ることもできます。
この取り組みによって、さらに情報が集まり意思決定を洗練できます。
(テックブログにコメントしてくださった例)
3. ADR (Architecture Decision Record) を記録する
技術選定の意思決定を言語化していくことで、型にしていくことができます。
次に、技術選定が決まったら、技術選定に関する意思決定を言語化して記録していくことが重要です。ADRとはアーキテクチャ、デシジョン・レコードの略で、技術選定に関する意思決定を言語した文章です。
このドキュメントを作る利点なのですが、ドキュメントを作る過程で、技術選定の意思決定が型化されていくところにあります。さらに、技術選定の意思決定が言語化されることで、技術選定の背景や理由を後から振り返ることができます。
なお、作成したADRはチームでレビューするようにしましょう。レビューを通じて自分ごと化され、チーム全体の共通認識となります。
この取り組みによって、意思決定の透明性が高まり、属人性の解消に貢献します。
4. いつでも切り離せるようにする
過去の型を捨てやすくすることで、仕組み化をし続けやすくなります。
技術選定の議論が終わり、ADRを記録して型化しても、それで技術選定は終わりません。当時は最適だった技術選定も、時間が経ったり環境が変わっていくにつれて改善していく必要があります。
改善しやすくするためには、環境や人に依存しない技術選定をすることが重要です。記憶、勘、人に頼った技術は、短期的にはパフォーマンスが出ますが、それに頼れなくなると崩壊してしまいます。
そのため、定期的に振り返える機会を設け、時には捨てる勇気を持つようにします。さらに、過去の型を改善していって、環境や人に依存しない仕組み化をし続けていきます。
このようなマインドを持ち、型を改善する姿勢を持ち続けることで、プロダクトの持続性が向上します。
5. アノテーションコメントをする
実装時の温度感(WHY NOT)をコメントで残すことで、後から過去の実装を変える勇気を得られやすくなります。
いざ実装に入った後も、意思決定を言語化する取り組みは続きます。実装時には実装時の温度感をコメントで残すことが重要です。いわゆる、TODOコメントやFIXMEコメントをしようという話です[1]。
例えば、早くお客様に価値提供したいということを優先し、適当な実装になってしまった。あとでまとめてリファクタしたいなという温度感、実装中に起こったことはないでしょうか。
どうしてベストを尽くさなかったのか。それは技術的には可能だけど、他を優先したという歴史的経緯があったのではないでしょうか。しかし、その温度感は、1ヶ月後には消えていることが多いです。
「TODO: ◯様向けのデリバリーを優先して仮で実装した。後でリファクタする」「FIXME: ここ辛いけどAに依存している。Aをリファクタした後こっちも直す」などといったコメントを残すことで、後から振り返り直しやすくなります。また、アノテーションコメントを検出するツールを用いて抽出することで、可視化もできます。
アノテーションコメントを通じて温度感を残すことで、後から意思決定を振り返り、軌道修正しやすくなります。
(アノテーションコメントを検出するツールの例)
6. コミットやプルリクエストはWHATだけではなくWHYで
何をしただけでなく、何故したのかを残すことで、背景や文脈が形式知化されます。
最後に、実装後にコミットやプルリクエストを作成する際にも、意思決定を言語化する取り組みをします。プルリクエスト、コミットは、「何をした」ではなく、「何故した」のかを残すことが重要です。
例えば、お客様からの要望を受けて機能を修正したとしたとき、「何々のデザイン修正」ではなく、「何々は何々の課題があったので、何々できるように修正」といったようなものを残しましょう。
なお、ドキュメントのURLを貼って省力化もできますが、将来的にリンク切れになってしまうことも考えられるので、メッセージやプルリクエストの説明のみでも判断できるようにしておくのがおすすめです。 (筆者はリンク切れで何度も苦しめられました)
しかし、コミットメッセージやプルリクエストのコメントは疎かになりがちです。そのため、ワーキングアグリーメントなどでテンプレートを定めたり、CIやGit hooksなどを活用して仕組み化することが有効です。
コミットメッセージを通じて説明責任を果たすことで、将来の意思決定を支えることができます。
まとめ
時間の経過や外部環境の変化によって最適な技術選定は変わっていきます。そのため、技術選定の意思決定において一番大切なことは、「技術選定の意思決定を言語化して属人化を防ぎ、透明性を高めること」だと考えています。
この記事では意思決定の透明性を高めるための6つの取り組みを紹介しました。これらの取り組みを実践することで、将来の軌道修正を支え、プロダクトの持続性を向上させることができます。
技術選定の意思決定に悩んでいる方は、ぜひこの取り組みを試してみてください。
-
アノテーションコメント苦手な方もいらっしゃるのは承知しているのですが、技術選定の意思決定を支えるという観点からは必要だと考えています。 ↩︎
Discussion