はじめに

delyに来てマネジメントに関わるようになってから２年が経ちました。エンジニアの成長について色々考えさせられることがあるのですが、プロダクト開発においてエンジニアがやるべきことはシステムの設計と実装だけではなくなってきたなと、最近になってより強く感じるようになりました。環境や携わっているプロダクトの特性やフェーズによってももちろん変わると思うのですが、この流れは今後加速していくだろうと感じるので、この機会に整理しておこうと思います。

インターネット技術の進化によって、世の中の色々なものがIT技術に置き換えられていっています。プロダクトやサービスの数も急速に増えていますが、WEBサービス開発における技術的な実現方法はどのプロダクトもそこまで大きな違いはないと思います。というのも、どのプロダクトでも共通に課題だと認識しているコアな技術的要素はクラウドやSaaSが生まれ、それらに置き換えられていってるからです。数年前までは技術的な実現手段についてエンジニアが頭を悩ませていましたが、今ではサービスを組み合わせることで、比較的簡単に実現できてしまう世の中になってきました。この流れは今後落ち着いていくことはなく、より一層加速してくと考えています。技術的な実現方法がコモディティ化していくこの時代において、プロダクト開発に携わるエンジニアは今後何をしていくべきなのかを考えてみました。

考えを整理するにあたって下記の記事を参考にさせて頂きました。

エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド

プロダクト開発における技術選定の捉え方

エンジニアなら誰しも課題に対して適切な手段を選定して、ビシバシ解消していきたいですよね。ただこの「技術選定」という言葉、"技術"という言葉が入っているが故に若干ミスリードしているのではないかなと最近思っています。「技術選定」という言葉を使うと何か特別感が出てしまうのですが、プロダクト開発においては「意思決定の一種」として捉えた方が自然ではないかなと思っています。

プロダクト開発における意思決定って何

プロダクト開発においては大小様々な意思決定が行われます。

例えば、「何の機能を作るか」、「どの機能から作るか」、「いつまでに作るか」、「誰が作るか」、「どうやって作るか」、などなど上げればキリがないですが、これらはプロダクト開発において決めないと何も進まない要素であり、意思決定すべき項目になります。例に上げた抽象度の高いものだけではなく、実装において何のライブラリを使うのかやどういったデータ構造にするのかといった具体性の高いものも意思決定の一つになります。

ちなみにdelyではスクアッドという組織構成を作っていて、スピード感を持った意思決定ができるようにしています。

https://speakerdeck.com/tsubotax/dely?slide=29

f:id:gomesuit:20201207095547p:plain

意思決定はどのように行われるか

意思決定を行うためには、決定を下すために必要な情報を整理する必要があります。意思決定の不確実性が高ければ高いほど、広範囲に渡る情報を集める必要があり、それぞれの分野の有識者を巻き込む必要が出てきます。情報を整理することで選択肢とメリデメを洗い出し、各ステークホルダーの合意を形成を行った後、責任者が決定を下すことで意思決定は行われます。

意思決定において必要な情報とは

意思決定に必要な情報は、意思決定しようとしている範囲によっても変わりますが、例えば「何の機能を作るか」でいくと、その機能が会社のビジョンや事業計画に沿っているのかやどうかといった情報が必要になります。「どの機能から作るか」であれば、要件定義や予算が必要になり、「いつまでに作るか」であれば見積もりやスケジュールが、「誰が作るか」であれば開発リソース、「どうやって作るか」であれば機能要件や非機能要件、現状のシステムのアーキテクチャが必要になります。その他のところではマーケティングやセールスとの関連がないかなど、上げればキリがないですが、精度の高い決定を下そうとすればするほど、多くの情報が必要になります。

プロダクト開発における情報のマネジメント

前項では、意思決定に必要な情報は何かという話をしましたが、それらの情報を得るための知識は４分類できます。そして、エンジニアとしての成長のために避けては通れない４つの領域もこちらになります。

f:id:gomesuit:20201207110700p:plain

https://qiita.com/hirokidaichi/items/95678bb1cef32629c317#各種スキルと読書ガイドを元に画像を作成しました。

不確実性の高い意思決定を下す際は、基本的に複数の分野の情報が必要になります。１人が全ての知識を持っていることは稀なので、基本的には複数人で情報を集める必要があります。ただし、必要な人数が増えれば増えるほどコミュニケーションコストが増えるとともに、それ相応の対話スキルが求められるようになります。そのため複数領域の知識を持つ人は必然的に意思決定に巻き込まれやすくなります。

f:id:gomesuit:20201207095647p:plain

https://qiita.com/hirokidaichi/items/95678bb1cef32629c317#弱めのem定義と強めのem定義を元に画像を作成しました。

意思決定の一種である技術選定においても、不確実性の高いものはテクノロジー領域の知識だけでは決定を下すための情報が足りないということが言えると思います。

テクノロジー領域の知識だけでは精度の高い技術選定はできない例

２つほど具体例を考えてみました。

例１：マイクロサービス化

最近話題に上がりやすい「マイクロサービス」を題材にしてみます。プロダクトが成長し組織が大きくなったタイミングで、システムの構造をマイクロサービス化しようという話が上がったとします。当然マイクロサービス化する「目的」にもよると思いますが、一旦そこは無視した上でそういった状況になった場合、技術的な観点以外で必要になりそうな情報は下記の通りです。

今後の事業計画や組織体制
サービスの粒度の決め方やサービス間の循環依存を防止する仕組み

仮にテクノロジー領域の知識だけで意思決定を行った場合、アーキテクチャと組織構造のズレが発生したり、ルールやガイドラインなしでマイクロサービス化を行った結果、横断的な視点が失われてより一層課題が大きくなるといったことが考えられそうです。テクノロジー領域だけの情報で決めるのではなく、将来的な事業方針や組織体制を踏まえた上で決めていく事柄ではないかなと思います。

例２：プログラミング言語・フレームワークの採用

クラウドやコンテナ技術の浸透によって、プログラミング言語やフレームワークの流行は大きく影響を受けました。周りの技術が進歩・浸透することによって、その環境前提のプログラミング言語やフレームワークが新しく生まれたり、流行ったりします。現在のプロダクトがレガシーなプログラミング言語やフレームワークで開発されていた場合、新しい機能は別のプログラミング言語・フレームワークで開発しようという話が上がることもあると思います。そういった状況になった場合、技術的な観点以外で必要になりそうな情報は下記の通りです。

採用計画
既存メンバーの学習コスト
既存システムの移管プロジェクト
エンジニアのモチベーション

仮にテクノロジー領域の知識だけで意思決定を行った場合、採用計画への影響や既存システムをどうするのかのプロジェクト観点が抜け落ち、別の課題が新たに生まれることは間違いないでしょう。テクノロジー領域の情報だけで決めるのではなく、採用計画を含めた長期の視点も含めて決めていく必要がある領域であると思います。

まとめ

この記事を通して自分が伝えたかったことは下記になります。

プロダクト開発において、より不確実性の大きい技術選定をするためには、テクノロジー領域の知識だけでは足りない
テクノロジー領域の知識をつけることだけがエンジニアの成長ではない。プロダクト、プロジェクト、ピープル領域のマネジメントスキルを身につければ、より不確実性の大きい領域に対して技術選定ができるようになる
エンジニアが各領域のマネジメントを行う経験は、エンジニアとしての成長にとっても大きな要素になる

エンジニアでありながら、プロダクトマネジメント、プロジェクトマネジメント、ピープルマネジメントの役割を担っている方がいると思いますが、コードを書かないことを不安に思う必要は全くないと思います。プロダクト開発において、エンジニアがやるべきことの中で「コードを書く」ということの割合は少しずつ減っていきます。今自分がやるべきことをやり、物事を成し遂げて行くことが重要であり、その結果プロダクトが成長していけば、自ずと自身もエンジニアとして成長するはずだと思います。

さいごに

また、dely ではエンジニアを絶賛募集中です！ご興味ある方はこちらのリンクからお気軽にエントリーください！

join-us.dely.jp

さらに、定期的に TechTalk というイベントを通じて、クラシルで利用している技術や開発手法、組織に関する情報も発信しております。ノウハウの共有だけでなく、クラシルで働くエンジニアがどんな想いを持って働いているのかや、働く人の雰囲気を感じていただけるイベントになっていますので、ぜひお気軽にご参加ください！

bethesun.connpass.com