技術選定の下ごしらえ - asken テックブログ

はじめに
ターゲット
伝えたいこと
下ごしらえとして何をしたのか？
おわりに
参考リンク (先人たちに感謝)

はじめに

今年、スマホアプリのクロスプラットフォーム技術の選定を行う機会がありました*1。

わくわく感が大きかったのですが、初めての割と大きな技術選定ということもあり、「はて。どう進めるか？どうすると良さそうか？」というのが正直なところでした。また、自身がバックエンドエンジニアという背景から、スマホアプリにそこまで詳しくはないということも手伝い、「何を検証するか」という部分も自信があまりないスタートでした。

そんなゆるふわな状況とはいえ、やると決めたからには技術選定を進めていく必要があります。今回の記事では、料理における下ごしらえのように、技術選定をする前の「準備段階」にフォーカスして、私が実際にどんな行動をしたのかを共有できればと思います。

ターゲット

この記事は以下のような人たちの参考になればと思っています。

これから初めて技術選定をする人
新しい技術の導入をしたいと考えている人
何から手をつけていいかわからない人

伝えたいこと

この記事を通して、以下のことが伝わればと思っています。

下ごしらえは地味だが役に立つ
- 事前に不確実性の高い部分が見えてくる
- 何か起きても下ごしらえしたものをベースに修正できる
目的に立ちかえることが大切
- 目的がわかるとゴールが見える
- ゴールが共有できると一緒に進みやすい

下ごしらえとして何をしたのか？

冒頭で触れた通り、何からはじめれば良いか悩ましいというところが本音でした。また、どう着地させると技術選定ができたと言えるのかも自分の中で曖昧でした。いわゆる「完了の定義」がない状態です。そして、そこに至るための道筋にも霧がかかっている状態です。

そのため、まずはこの霧を晴らし、進む方向とゴールを組み立てに行くことにしました。

先人たちの知恵を借りる

困った時は先人たちの知恵や経験を頼りにすることも1つの手だと思います。「技術選定やり方」「技術選定方法」などのキーワードで検索し、片っ端から記事を読み漁りました。個人的には読むだけでは理解した気になるだけであるため、ざっと斜め読みをしたのちに、今の自分の状況に合いそうな記事をいくつかピックアップし、balus というモデリングツールにポイントを整理していきました。

今見返すと右上だけ力尽きたのか(苦笑)空っぽではあるのですが、どの先人の記事達も本当に参考になりました。ありがとうございます。こうしてポイントを整理した結果、どの先人の記事にも以下のような共通点があることが見えてきました。なるほど。ここを足がかりとして組み立てれば下ごしらえを進められそうです。

目的の明確化
- どのような課題を解決したいのか？
プロダクトを理解する
- プロダクトを意識して独りよがりな選択にならないようにする
ゴールを定めて分解すること
- 説明責任が果たせるように観点や基準を事前に決めておく

上の3つに加え、今回の場合は「体制」や「スケジュール」についても事前に考えておくことにしました。これは検証期間が限られていることから、事前に体制やスケジュールを考えておくことで、当たり前ではありますが見通しを立てやすくしておきたいと考えたためです。

ということで、先人たちの知恵と経験のおかげで下ごしらえとしてやるべき方向性が見えてきました。

目的を明らかにする

まずは今回の検証の目的を明らかにするために、下図のように整理*2を進めていきました。

図内にも記載しているのですが、今回は「ただ新しい技術を試す」ということは目的ではないと定めました。より明確な目的意識を持つことで、事業として必要な技術選定であることを改めて意識することができました。

詳細は「僕たちはどう Flutter で価値を届けるのか？」内の「僕たちはなぜ技術選定をしたのか篇」に譲るのですが、今回の大きな目的は「素早く価値を実現することが難しい」という課題を技術的に解決する、であることが見えてきました。

プロダクトについて考える

目的が明らかになったところで、次に今回のプロダクトの性質について考えました。視点としてはさまざまあるとは思いますが、私としては以下の3点にフォーカスして考えることにしました。

フィットジャーニーのどこに位置するか？
何が強く求められるのか？
何はそこまで重要ではないのか？

例えば、フィットジャーニーにおける PMF 以前と以後に分けて考えた場合、前者の場合は「開発速度 > 安定性」となるかもしれませんし、後者の場合は「開発速度 < 安定性」となるかもしれません。つまり、技術側に求められる優先度が異なります。この優先度を考えずに選択した場合、安定度が求められるものが必要であったのにそうでないものを選択してしまったり、その逆の選択をしてしまうことがあります。

また、プロダクトとして何が強く求められ、何がそこまで重要ではないかも大切な点だと思います。今回のようなアプリ開発系であれば、例えば以下のような要望があるのかを事前に知っておくことで、選択した技術とプロダクトでやりたいことにズレがなくなります。

アニメーションを多用したい/しなくともよい
OS部分の機能を積極的に活用したい/しなくともよい
レイアウトはOSごとに分けたい/統一したい

それぞれのプロダクトにより、考えた方が良い要素はさまざまかと思います。重要なポイントは、技術部分に近視眼的にならないようにすることだと考えています。「プロダクト」と「技術」とが切り離された状態にならないように考え続けることが大切です。個人的には、他社の事例に憧れた選択や、自分自身の趣味に寄りすぎた選択にならないためにも、プロダクトについて考えることを意識し続けるようにしていました。

ゴールを定めて分解する

次にゴールを定め、検証を進めやすくするためにそのゴールを分解しました。

まずはゴールですが、目的がわかっていることで言語化はあまり悩むことなく進めることができました。今回で言えば、前提として Flutter を第一候補として考えていたこともあり、また課題も明確であったため、次のように定めました。

アプリ開発課題を「技術」で解決すること
- ※ 「ただ新しい技術を試すこと」が目的とゴールではない点は注意
第一候補である「Flutter」の選択によって課題が解決可能か検証すること

次に、ゴールまでの道筋を考えるために「課題が解決可能か検証」の部分を分解しました。検証要素が場当たり的な状態では、検証を進めてもゴールに到達できるか不確実性が高いままです。ここで、プロダクトについて考えたことが活きてきます。下図の「機能(プロダクト要件)」や「将来性」の部分に落とし込まれています。プロダクトについて意識しなければ、こうした視点は抜けていたかもしれません。

さらに事前に調べた先人たちの知恵を加え、自身の経験値から必要だと考えるものを加えていきました。こうしてゴールを分解することで、検証の解像度があがっていきました。また具体的な項目が見えてくることで、動き出しのイメージもついてきました。

壁打ちをしてもらう

自身がバックエンドエンジニアである背景を考えると、アプリエンジニアであれば経験則として自明であるような視点が抜けていることもあり得ます。不確実な部分や不安は早めに潰しておくが吉です。そのため、ここまでの情報をもとにアプリエンジニアに壁打ちをしてもらうことにしました。

1つの前の図は、実はアプリエンジニア壁打ち後の完成系のものになります。壁打ち前の図を載せたかったのですが、流石に残ってませんでした。ですが、「アプリサイズの増大」や「ネイティブ部分の記載」、「KMM」や開発者体験系の多くの部分は、壁打ちの結果出てきた項目だと記憶しています。ありがたいことに、私ひとりでは見えていない部分に気づくことができました。

個人的には、壁打ちをしてもらうことは地味にとても重要な点だと考えています。ひとりの視点では限界があることはもちろんですが、異なる経験を持つ人からのフィードバックにより、思わぬ気づきを得ることができます。また、1つ1つの繋がりの悪い部分や、自分の中で腹落ちしていない状態の部分が、人に説明して質問に答えることでより明確になります。

下ごしらえの完了

目的とゴールが明らかになり、壁打ちを通して自分以外の視点も取り入れることができ、下ごしらえとしてはまずまずなところまで来ることができました。あとは「スケジュール」と「体制」を加えること*3ができれば、ある程度の着地点が分かった状態で技術選定を進めることができそうです。また、技術選定を進めていく中で何か起きた場合も、準備したものを下地に軌道修正ができそうです。

最後に下ごしらえで何をしたのかを簡単に振り返っておきます。

先人たちがどう進めたのかを分析する
なぜやるのか目的を明確にする
何ができればゴールかを明確にする
ゴールまでの道筋がわかるように分解する
「2~4」の情報をもとに壁打ちしてもらう
壁打ちで得たフィードバックをもとに修正する
スケジュールや体制など進める上で必要な要素を加える

おわりに

「はて。どう進めるか？どうすると良さそうか？」という五里霧中なスタートから、先人たちの知恵を分析することで、進め方について具体的なイメージを持つことができるようになりました。

すでに技術選定を終えた今現在からふりかえると、事前に下準備をして進めたことで助けられた点が多かったです。例えば、他のメンバーとゴールや目的の意思疎通が取りやすくなり、認識齟齬が減りました。また、節目節目ごとに行った経過の説明についても場当たり感がなくなり納得感が出ました。現在どの地点まで進んでいるか把握しやすくなったことも大きかったです。

最後に、この記事が今後はじめて技術選定をすることになった方々の手助けになれば幸いです。

asken では、プロダクトを加速するために技術を発揮することが好きなエンジニアを募集しています。

www.asken.inc

本文執筆 : バックエンドエンジニアの羽鳥