先日、『技術を的に当てる技術について』という話をした。これに関連して、影響範囲のある技術を途中から導入するときにこのあたりは一定抑えるのが大事かなあと思ってるポイントがあるので、現状認識のスナップショットとしてちょっとまとめておく1。
- 最初に確認したいこと2
- その技術はどのような課題を解決しようとしているか？それはどのように要素分解できるか？
- その技術を入れることで確実に解決される “重要な課題” はあるか？
- 初動
- その価値が利用の増大に応じて複利的に利くようなものである場合、最初の根を張る必要がある
- 早い段階で価値を感じられるように、具体性の高い問題解決を行うのが定石
- 技術を整備したり使う人が理解するのには一定のコストがかかる
- このコストをリターンがちょっとでも上回るようになることを最短で設計するということが重要
- 初動を終えた後
- そこまでの手応えを振り返り、進むか撤退するかを決める
- 定常的なワークフローに自然に組み込む、それに困った時に自然と使うように仕向けるなど拡大するようにする
- ここまで来るとこのリターンとコストの差分であるプラスが増えていく状態になる
- 経過を観察しながら、ボトルネックがあれば対処し、またさらに技術を使いやすくするなどの再投資を適宜行い、開発を加速させていく
競合技術がある場合
競合技術がある場合はそれと比較すると良い。これは、より良い選択肢を選ぶという意味ももちろんあるが、比較することで元の技術がより良く理解できるというになるためである。
- その技術の競合技術はあるか？その競合技術はどのように要素分解できるか？
- 要素のうち重複する部分と、そうでない部分を明確にする
- それらの要素はなぜ重複して、なぜ重複しないのかを明らかにする
- 特にエコシステムの発展度合いに起因する要素と、そうではない固定的な要素の違いに注意を払う
- この検討の過程で、それぞれの技術がどのような問題設定を敷いており、どのようなスコープの問題解決を行おうとしているのかの理解が深まる
- そのような問題設定はある程度、一般的に存在する問題であることが期待される
- その一般的な問題が自分たちの組織・ビジネス・プロダクトの状況にどの程度適合しているかを検討する
- 適合するのであれば、その技術が現在提供している価値だけでなく、発展することにより将来的に提供される価値も享受できることが期待できる
- 一般的に、技術の仕様と実装だけでなく、その技術が解決しようとしている問題の方を正しく捉えることが非常に重要
- 性質を理解した上で複数の技術を使いたい場合はポジショニングを明確にする
耐用年数
時間の観点についても触れておく。技術の価値は、それが適切に機能している限りにおいて、入れてから使い終えるまでのトータルの時間積分になる。
このため、外的変化と内的変化のそれぞれについて粗くても良いので見立てを持っておく方が良い。
- その技術の耐用年数はどの程度か？より良い選択肢が市場に生まれるのにどのくらいかかるか？
- 導入前：代替となる強力な選択肢の当たりをつけて、その状況を調べてみる
- 導入後：その選択肢がどの程度、力を持つかを継続的にモニタリングしておくことで、状況が変化した場合に早い段階でキャッチする
- その技術の問題設定が自分たちの状況に適合しなくなるとしたらどのような要因がありうるか？
- よくある観点：開発者の人数、ビジネスのモデル、サービスの性質、ソフトウェアの複雑性
これらを見立てると次のようなことを考えることになる。
- 技術の耐用年数があまりにも短ければ、モノとしてそっちの方が良いとしてもスルーした方が良い可能性がある
- 一方で、耐用年数内に導入コストを回収できるかは、いかに早く技術を立ち上げられるかでもある
- 立ち上げが早ければ、耐用年数が短くても使った方が良い可能性がある
おまけ：
こうやって見ただけでも事は複雑に絡み合っているわけだが、そういう中で一定のバランスを見てやっていくという動的性質がソフトウェアエンジニアリングの奥深いところなのではないかと思う。また、その意味ではここに書いたことも（あるいは世の中にある重厚な技術選定のフレームワークですら）、ルールではなく一つの目安でしかないので注意したい。