エンジニアの責務範囲を考える
この記事はOptimind Advent Calendar 2024 15日目の記事です。
はじめに
あまり自分の考えを記す系の記事を書くことは多くないのですが、今回はあえてそれをやってみようと考え、エンジニアの責務範囲について自分が最近感じていることを雑記的に記していこうと思います。まとまらないかもしれません。
エンジニアの責務範囲のトレンド
私自身はそういった環境を直接経験していませんが、書籍や伝聞などの知識をベースに語ると比較的伝統的な現場におけるエンジニアは主にプログラミング言語や特定のフレームワーク、OS、データベースなど、担当領域が明確に区切られた「専門職人」として振る舞うことが多く、要件定義や設計は上流工程担当者に任されがちだったようです。
それに対して、現代のエンジニアはよりクロスファンクショナルな責務を持つことを求められる傾向にあると思います。具体的には、サービス全体のビジネス価値やUXを理解した上で、要件定義・アーキテクチャ設計・実装・テスト・運用まで一気通貫で関わることが求められ、「ただの実装者」ではなく、全体最適を目指す「技術的意思決定者」の役割が求められています。
このような流れはAWS, GCP, Azureなどのクラウドプロバイダーの台頭や、それに伴うTerraformなどのIaCツール、CI/CDパイプラインなどの発展の影響が大きいと思います。それらの技術によってエンジニアはインフラ構築やデプロイ作業を安定・高速化できるようになり開発と運用の境界が曖昧になり、その結果今日のDevOps的な文化の流れができているのだと思います。勿論技術の革新によってそれが可能になったからというだけではなく、それをすることによって様々なことをシフトレフトし全体効率を向上させられるという利得がそもそもあるからそういうトレンドが生まれているということなのだろうと思っています。
広がり続ける責務範囲
近年の流れは所謂インフラなどのOpsだけではなくDevSecOpsやDevSecFinOpsなどという考え方に代表されるように、セキュリティやコスト最適化についても開発と同様の文脈で取り組むべきものとされるトレンドにあり、更にエンジニアの責務範囲は広がっています。ただこの辺りの領域も、クラウドプロバイダーやSaaSにおいてカバーされやすい領域であり、それ単体にかける社内での労働力という意味でのコストが低くなってきているということを考えると、開発プロセスに統合していこうという動きは大きな違和感なく受け入れられると思います。しかし、これらはサイロ化されたセクションを統合するという考え方ではありつつも大きな括りでは「開発者」と呼ばれるロールの範疇のものを統合しようという動きだと思います。しかし、近年ではプロダクトエンジニアのようにいわゆる「開発者」ロール外に責務範囲を広げ更により良いプロダクト作りをしていこうという考え方もあるようです。
生産力と生産性
責務範囲がどうあるべきかを考えるためには「生産性」について考える必要があると思います。何故なら、それが事業活動なのであれば、責務範囲というパラメータを変化させることによって最大化したいのは「生産性」であるはずだからです。
いわゆる「生産力」を上げるためだけならば、一人一人にある特定の領域にフォーカスしてもらい、その領域の業務を正しくかつ効率よくこなすためのスキルを身につけてもらうことが良いのだろうと思います。しかし、最終的に事業活動として向上させたいのは生産した出力(=アウトプット)を成果(=アウトカム)に繋げる効率であるところの「生産性」です。これを作れば確実に成果(例えば売り上げ)に繋がるという確信がある状態に事業があれば、いかに「生産力」を上げるかということにフォーカスすべきだと思いますが、弊社も含めた大抵のスタートアップではそのような状態にあることは少ないでしょう。そのため、アウトプットをアウトカムに繋げるための営みがより一層重要になってきます。
この辺りのトピックを考える時に以下の記事が非常に参考になりました。
エンジニアのアウトプットの質を定義するときに、いかに技術負債を最小化し、資産となるようなより良いアウトプットを高速に出せているかということが重要だと思います。何故ならば質の低いアウトプットを出し技術負債を蓄積すると、技術負債を返済するためのアウトプットが必要になり資産をアウトプットするための時間が圧迫されていき、最悪の場合どこかで完全にリプレースをするなどして資産となるようなアウトプットを止めるケースも想定されるためです。そのため、高い技術スキルを駆使してより良いアウトプットを出し続けることはエンジニアにとって重要なミッションの一つであるべきです。
ただ、「より良いアウトプットを出すことがミッション」と書くと「アウトプットを出せばよくて、アウトカムはPdMの責務なんだな」という風に解釈されかねなくもないですが、そうではないと思っていてアウトプットの質を考える時にアウトカムについて考えることは切っても切り離せないと思っています。例えば、アウトプットについてのみフォーカスした場合の弊害としては、エンジニア目線でなければ気づけないより良いソリューション案を取りこぼす機会損失、または既存のソリューションにおける落とし穴にハマるなどのリスクが考えられるでしょう。そのため、PdMから提案されたソリューションに対してある程度エンジニアが影響を与えるということも重要な営みだと思います。またアウトプットにのみフォーカスする弊害とアウトカムを考慮する重要性は前述の記事でも以下のように語られており納得感があると感じました。
生産した結果だけにコミットする開発チームは「外部ベンダー」とあまり変わらないということ。取引コストだけ社内の方がコストカット出来ますが、コストセンターになります。機能提供チームと割り切ればそれもひとつの戦略ですが、コアとなるシステムを開発し続けているチームには生産性の指標も入れて、事業全体のROIに効果をもたらすようなゴール設定をしていくことが強い技術組織を作る要素となるでしょう
オプティマインドにおける体制を考える
では、弊社オプティマインドではどのような体制になっているのかというと、いわゆるPdMやデザイナー、デリバリマネージャが所属するプロダクトチームと、機能毎に分割した各種開発チームで分かれています。基本的に顧客のどの問題をなぜ解くのかを定義するのはPdMに委ねられていますが、ソリューションがトップダウン的にプロダクトチームから開発チームに下されそれをそのまま開発するという構造ではなく、基本的にプロダクトチームのPdMには各機能開発系チームに兼務してもらい、チームとよくコミュニケーションを取ってもらいつつ開発を進めています。
これ自体は、現時点では弊社の事業領域においてはそこまで間違った方向ではないと思っています。物流領域は非常にステークホルダーが多く、一つの機能を開発するとしても、どのステークホルダーにフォーカスするのかで方向性が変わってくることがあり得ます。そのため、顧客の課題を深掘りしどの課題を、誰に向けて解くと全体として素早くアウトカムへ繋げることができるのかということを考えるのはコストのかかる業務であり、そこには専門ポジションを置くべきだと考えています。勿論、一つのポジションの責務に抑えるメリットというのも十分に理解はできます。どうしてもポジションを分けると抜け落ちるコンテキストが発生しますが、同じポジションにその責務を納めてしまえばそのリスクは低減されるでしょう。ただし、複雑な事業領域では全部できるスーパーマンを探すのは実態として困難であり、事業をスケールするにはある程度の分業を受け入れた組織構造にしつつ、その分業の境目をどのようなコミュニケーションパスで効率的に繋ぐのかを考えたほうが良さそうだなと今のところは思っています。(来年はわかりませんが。)
まとめ
なんだかまとまらない文章を書いてしまった気がしますが、この辺りのトピックについては社内に熱い思いを持った面々がたくさんいるので、改めて社内の国士無双な各位と議論してみたいなと思いました。
最後に
オプティマインドという組織について興味を持っていただけた方は、弊社採用資料もぜひご覧ください。また、カジュアル面談も大歓迎ですので気軽にお声がけください。