学びの整理 vol.03(LayerX社、Speee社、Algomatic社、ハコベル社)
学びを整理するための投稿、第3段です。
ビジネスに活かしていけるよう、整理しておきます。
生成AIでシステム開発はどう変わるか
キャッチアップは非常に重要で、今後また更に変化が起き、エンジニア界隈でも差が広がりそうだと感じます。
エンジニアとして事業に貢献するとは「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」である
事業の解像度が上がる、事業のフェーズが変わるにつれて、解くべき課題 (What)やその解き方 (How)が変わっていくということです。そして、チームで「どのようにWhy-What-Howを一貫させていくか」という共通認識を持つための道標が「事業戦略」だという理解をしています。
エンジニアとしてプロダクト開発に従事する上で、以下のような制約条件を考慮する必要があるでしょう。
・事業解像度が上がるほど、Why-What-Howを一貫させるための事業戦略や、プロダクトとして解くべき課題 (注力すべき施策)が変わっていく
事業戦略や解くべき課題 (注力すべき施策)が変わると、最適なソフトウェアのアーキテクチャが変わっていく
→コンウェイの法則に則り、同時に最適な組織アーキテクチャも変わっていく
・施策の試行回数が積み重なるほど、ソフトウェアが複雑になり、施策を試行するための開発コストが上がっていく
→いわゆる技術的負債、そしてチーム内のコミュニケーション複雑性も増していく
エンジニアはそのような制約条件下で以下のようなテーマと向き合うべきだと私は考えています。
・常に目的思考を持って、「その施策を通じてどのような価値を提供したいのか」、「その施策を通じて、事業としてどのような学びを得たいのか」を理解した上で、最適なHowをチームで意思決定し続けること
・事業戦略に追従しながら、大小様々な施策を試行可能なソフトウェアや組織のアーキテクチャをデザインし続けること
これらのテーマに向き合い続けることが、冒頭でも述べた「Why-What-Howの一貫性を保ちながら、技術意思決定を積み重ねること」だと考えています。エンジニアリングの面白いポイントとも言えますね。
立ち上げ期から開発メンバー全員が集う週次の定例MTG (スクラムのリファインメントです)の場で、PdMやPMMから以下のような情報や考察を共有してもらう取り組みを続けています。
・施策リリース後にユーザから得られたフィードバックやKPIの変化
それに対するPdM、PMM視点での考察
・(ある場合は) ロードマップのアップデート
・それらを踏まえて、目下取り組む施策の目的、背景、内容
前提が揃った状態で皆が議論を繰り返すことで、エンジニアメンバーも施策の目的を見失わず、目的思考で最適なHowについて考えることができます。
特にHowはエンジニアの得意領域なので、「より開発コストを抑えつつ、インパクトが生み出せるソリューションの提案」はエンジニア起点で生まれることも多いです。
Housiiのプロダクトチームでは「あ、今の意思決定、ドキュメントにまとめておきますね」といった会話が日常的に飛び交っています。徹底的に言語化することを大切にしています。
オーナーシップを持った優秀なメンバーが集まってくれたというのもありますが、そのような言語化文化を作りたいという私の想いもあります。理由は以下の2点です。
・未来の開発生産性への先行投資のため
・個々人の技術意思決定力の向上のため
未来の開発生産性への先行投資のため
「初期メンバーのみで半永久的にプロダクトを成長させていく」という戦略は、あまり現実的ではありません。やはりチームや組織も事業とともに成長、拡大、変化していくと思います。
そこで開発生産性を落とさずにチームをスケールさせていきたいわけですが、チーム内が暗黙的なルールやコードから読み解けない情報 (意思決定の背景など)に溢れかえっていると、それは難しいでしょう。新しいメンバーが早期に成功体験を積むことも困難になります。
そういった将来起こり得る組織課題をなるべく減らすために、Housiiチームでは「今なぜこの仕様にしたのか」、「今なぜこの設計にしたのか」といった仕様や設計、意思決定を徹底的に言語化し、ドキュメントに残すようにしています。
「ソースコードには残らないが、重要な意思決定プロセス」もチームの資産として蓄積していきたいという想いから取り組んでいます。
設計力とは、これまで繰り返し述べてきた「技術意思決定力」のようなものだと捉えています。「事業上の課題を将来起こり得る技術的なリスクも考慮した上で、今どう解決するかを決める力」のような理解をしています。
エンジニアの責任は「技術を使って、事業上インパクトのある課題を解決すること」だと考えています。そのためには事業を多面的に捉え、Why-What-Howが整合しているかを常にチェックしながらプロダクト開発に向き合う必要があります。
Whyからの言語化が重要、ということがわかる投稿です。
初期から様々な可能性を考慮し、プロダクトを成長させるための土台が作られていることがわかります。
目指すは「打席に立ちまくる」企業。20億円調達生成AIスタートアップが考える事業の勝ち筋
2023年3月に、私はX（旧・Twitter）で生成AIにコードを書かせたことについての投稿をしたんですよ。
私が同じ品質のコードを書くなら30〜60分ほどかかると思うんですが、これを生成AIは1分足らずで出力してきました。これほどのレベルで開発の生産性が変わったことは、これまでの人生で初めてでした。
成功する事業はひと握り。最初から共通化を考えても意味がない
あえて言うならば、私自身が決めているのは「自分が技術的な意思決定に携わらないこと」です。事業部ごとに置かれているコンテキストや事業ドメインが全く違うので、それぞれに任せています。基本的には、事業ドメインに合わせた技術選定をするべきです。
その技術を提供している企業や組織、団体が向かっている方向性ですね。例を挙げると、私はキャリアのなかでわりと早い時期からFlutterを使い始めました。このとき、Flutterの提供元であるGoogleがこの技術にどれくらい注力するつもりなのか、動向を見ていたんですね。
すると、レンダリングエンジンライブラリのSkiaをGoogleが買収したんですよ。これはFlutterで採用されていたレンダリングエンジンで、この動きがあったので「Googleは少なくとも数年はFlutterに投資し続ける予定なんだな」と思えました。
エンジニアの採用コスト。「Flutterをやりたい」というエンジニアは多かったので、採用活動にもプラスに働きました。それから、他の技術からのスイッチングコストが低いこと。
Androidアプリを開発している人がFlutterを学ぶのは簡単ですし、iOSアプリを開発している人もFlutterのDartはキャッチアップしやすい。FlutterはReactを踏襲している部分も多く、フロントエンドエンジニアにもとっつきやすいので、学習コストが低いです。
他にも、ビジネスドメインに合っているかも重視します。かつてFlutterは「UIがあまり滑らかではなく、動きがカクカクしている」と言われていたんです。でも、本当に滑らかなUIが必要かどうかは、アプリの種類によって違うじゃないですか。
たとえば、単に「何かの施設の予約をするだけ」のアプリであれば、動きがカクカクしていてもあまり影響はないですよね。その逆に、リアルタイム性が問われるライブ配信などでFlutterを採択するのは、さすがにユーザー体験が悪いのでダメだろうと過去には考えていました*。ビジネスドメインによって要求されるものは違うので、「何がエンジニアリングに求められているか」を考えることが大切ということですね。
*…南里さん曰く「Flutterの性能改善が行われてきたため、現在はライブ配信などでも使用できるかもしれないと考えている」とのこと。
「いまAI界隈はすべてを機械学習で解決しようとし過ぎているけれど、実際にはもっと多様なアプローチがあるはず」という旨のことを話しました。
たとえば、（テーブルにある飲み物の入ったペットボトルを手に取りながら）ふたの開け方をみんなが知っているのは、（機械学習のように）ふたを開ける動画を100万回見たからではないわけです。私たちは物理法則を理解しているので、「たぶん、こうやったら開くだろうな」という推測ができるんですよね。
この事例で何を言いたいかというと、つまり私たちは「いままで当たり前とされてきた手法」にとらわれ過ぎているんじゃないかという話があって。本当の意味で社会の課題を解決するには、いろいろな技術を複合的に扱っていかなければならないと思っています。
スタートアップはマーケットの不確実性と技術の不確実性の両方に取り組むわけですが、どちらもあまりに不確実だとプロジェクトが失敗する可能性が高くなります。
そこで、このプロジェクトでは市場の不確実性には取り組まず、技術的な不確実性と徹底的に取り組むことを目的としていますね。とにかく、新しい技術を試してPoCを作りまくるという。この組織が技術的な不確実性を解消していくことで、ビジネスサイドのメンバーたちがマーケットの不確実性に取り組める状態に、なるべく早くたどり着けるようにします。
技術選定について、その技術を提供している会社や組織の動向まで意識することや、市場ではなく技術の不確実性に取り組む点など、新たな学びに繋がりました。
未来は予測不能！技術選定の意思決定において一番大切なこと
技術選定の意思決定において一番大切なことは、「技術選定の意思決定を言語化して属人化を防ぎ、透明性を高めること」だと考えています。
数年後を見据えた正解を出すことは難しく時間の経過や外部環境の変化によって最適な技術選定は変わっていくので後からの軌道修正をできるようにしたい。そのためには、判断材料として当時の意思決定をいつでも振り返ることができる状態にしておくのが重要だという考え方です。
技術選定の意思決定を言語化していくことで、型にしていくことができます。
過去の型を捨てやすくすることで、仕組み化をし続けやすくなります。
コミットやプルリクエストはWHATだけではなくWHY
何をしただけでなく、何故したのかを残すことで、背景や文脈が形式知化されます。
実装後にコミットやプルリクエストを作成する際にも、意思決定を言語化する取り組みをします。プルリクエスト、コミットは、「何をした」ではなく、「何故した」のかを残すことが重要です。
例えば、お客様からの要望を受けて機能を修正したとしたとき、「何々のデザイン修正」ではなく、「何々は何々の課題があったので、何々できるように修正」といったようなものを残しましょう。
こちらも言語化の重要性、また他の投稿と同じように、Whyについて語られていて、学びになりました。
前回投稿したvol.01~02も載せておきます。
この記事が気に入ったらサポートをしてみませんか？