ふっとしたタイミングで技術選定のことが話題になって、そういえばその辺の考えって感覚的になっていて言語化したことなかったので、今回それを言語化してみようと思う。
技術選定のステップ
自分が技術選定するとき、大きく分けると以下のステップで物事を考えています。
- 目的を明確にする（やりたいことは何か）
- どういう選択肢が取れるか（技術のリストアップ）
- 技術検証
- その技術を使いこなせるか
- 説明する（合意を取る）
目的を明確にする
まずはやりたいことファーストです。顧客自身もやりたいことを理解しきれていないことがあるので、ここはいろいろなアプローチをとり、情報を集めます。
顧客から「これをやりたい」みたいなことを言われたら、
- その背景は何なんだろう？
- なぜそれがやりたいんだろう？
- それをやることによって何が解決するんだろう？
- 誰が使うんだろう？
というのを自分がわからなければ確認します。
特に誰が使うかは結構気にしています。エンジニアよりの人なのか、非エンジニアなのか。
ここで重要なのは「自分が理解し、目的を明確にする」ことです。
どういう選択肢が取れるか
目的が明確になったら、そこから目的を実現するためにはどういう選択肢があるのかを検討していきます。
ここで言う選択肢というのは、アーキテクチャも含めています。機能系であれば「このサービス導入すれば終わりじゃね？」という結論の場合もあるし、「それ実現するにはスクラッチで作らないといかんなぁ」とか「ミドルウェアと組み合わせれば出来るんじゃないか？」などなど。
そのへんをひたすらリストアップします。
リストアップした後は、それのメリットデメリットを比較表にして、比較をします。
比較表の項目としてはフロントエンド、バックエンド、インフラとレイヤーが違うと項目も変えていますが、例えばインフラレイヤーでの比較表だと、メンテナンス性の良さ、安定性、拡張性、将来性、情報の多さなどを項目に入れます。
このときに絶対にも落とさないように注意しているのは、「出来ないことがないかどうか」です。別の言い方をすると「制限事項がないかどうか」です。
まずは目先の目的を達成するのが最初ですが、作成したものをベースに成長させていくケースがあると思うので、最初に選定の時に出来ないことを把握しておいて、その情報を展開しておくことは必要なことだと思っています。
技術検証
リストアップした技術で、目的が何となく達成できそうだから選んだと思うのですが、当然不安な場合もあります。
本当にできるのだろうか？とか、使用感がよくわからないなとかあれば、それは技術検証をします。
その技術検証がすごい工数がかかる場合は相談して「PoCのフェーズをもうけさせてください」といった打診をする場合もあります。
簡単なプログラムを作って、動作確認をし、使用感を確認して、目的が達成できるかどうかを確認します。
そしてその結果をドキュメントとして残します。これが重要。
その技術を使いこなせるか
技術検証等でだいぶクリアーになってきたら、今度は「自分も含めてこの技術を使いこなせるか？」ということを検討します。
開発項目を一人でやることもありますが、大体の場合はチームでやることが多いと思います。ということは、自分一人だけが使えてもダメで、そこはバランスを考える必要があります。
よくある、「技術決めた人が退職してどうすればいいのかわからん」事態を防ぐ意味も兼ねていますし、目的は達成できるけど情報源が少なくてトライアンドエラーを常にしなくてめちゃくちゃ開発に時間かかるとか、それだと本末転倒になってしまうので。
自分の最低ラインとしては、
- 自分が説明することができるか
- 情報源がどのぐらいあるのか
は気にしています。
説明
下準備が完了したら、関係各所に合意を取りに行きます。
技術選定というのは「これから進む道を示す」ことでもあると思うので、一人で勝手に決めてはいけなくて、皆の同意が必須です。
説明内容もステークホルダーによって使い分けないといけないと思っています。
PO向けに説明する際は「将来性」「安定性」「情報源の多さ」「制限事項」などが重要だと考えています。
せっかく作り終えたものを一定期間たったら全部作り直さなきゃいけないとか、俗人化しちゃってチーム解散後にもう一度作ろうと思ったら再度以前のチームを招集しなきゃいけないとかそうなるとだいぶプロダクト運営がきつくなるので、その辺はだいたい聞かれます。
メンバー向けに説明する場合は、選定した技術を使う立場なので「技術への理解」「使用感」「どういう風に進めるのか」などが重要だと考えています。
例えば、未知の技術でもサポート体制としてプロフェッショナルを入れるから大丈夫だよとか、トレーニングの期間を設けてからやるとか、使ったことないメンバーが多い場合はそういったフォローをしたりもします。
逆に、メンバーにそこまで負荷をかけるわけにはいかないとなったら、多少手間がかかっても、本人たちがある程度自立して動けるものを選ぶ場合もあります。
まとめ
つらつらと思ったものを書いてみました。
技術選定について言語化するのは難しいなと改めて思いました。
これが基本っていうだけで、プロジェクトの規模や体制に応じて思考もちょっとずつカスタマイズしてたりするのでなかなかテンプレート化するは難しいのかなと今回書いていて思いました。
技術選定で選んだものが正解だったかどうかはプロジェクトが終わったときにはじめて確認ができるものだと思うので、重要なのは「なぜその技術を選んだのかの理由を明確に説明出来て、その上で方向性を示して、皆で（納得するのは必須ではなく）納得感がある状態で進められるようにする」ことだと思っています。
今回のこの記事、本当は図に落としたかったのですがちょっと難しかったので全部文章になってしまいました。
プロジェクト終盤で「なんでこの技術採用したの・・・」という意見を聞くと選定した立場からすると結構悲しいものがあるので、選定する側もそういうことが起こらないようにしたいですね。
まぁ・・・・
結果、使いづらかったら、作り直しちゃえばいいじゃん？
って思っているのは秘密です。
ではではー。
