はじめに
TRIAL＆RetailAI Advent Calendar 2024 の 5日目の記事です。
昨日は @Mikey さんの『第五次産業革命』という記事でした。
「第四次産業革命」について考え始めたばかりでしたが、すでに「第五次産業革命」も議論されているようですね。
特に「人間中心の技術」というテーマが非常に印象的でした。これから発表される内容も、きっとその一部なのだろうと思います。
前回の記事
本題
IT業界の進化と普及に伴い、ビジネスの世界でも激しい変化が起きています。DX（デジタル・トランスフォーメーション）の重要性はさまざまな業態に浸透し、単なる部分的な自動化や効率化にとどまらず、競争優位性を生み出す取り組みへと進化しています。ガートナー・ジャパン（2023年1月）の調査では、企業の内製化の方向性が54％に達しているとのデータも示されています。
しかし、IT専門家を採用しエンジニアリング組織を構築するだけでは、DXが成功するとは限りません。従来のSlerのように、単にタスクを依頼して進めてもらうだけでは何も変わらないのです。DXを成功に導くために、いくつかの観点からエンジニアリング組織の成長について考察してみます。
プロダクト目標（エンジニアチームとビジネスチームの関係）
現在では、様々な競争製品や競合サービスのある中から、「目まぐるしく変化する市場環境や顧客ニーズに答えていく」という要求に答えていく必要が出てきたいのです。このようなソフトウェア開発を巡る前提の変化が、プロジェクト方開発からプロダクト開発へと導いていくことになります。
プロダクトマネジメントに置いては、プロダクトの価値を継続的に向上させるためのチームをどのように作るかということについて、自覚的に取り組むことになります。逆にプロダクトマネジメントにおいて、この点を無視してしまうと早晩チームは崩壊し、プロダクト次第の存続可能性に非常に大きな負のインパクトをもたらすことになってしまいます。
（《エンジニアリング組織論への招待》より引用）
プロダクト目標に関して、これまで主流だったSler型開発では、ビジネスサイドが目標を策定し、エンジニアリングチームは受け手として計画に基づいて開発を進めるという形式が一般的でした。しかし、マーケットの不確実性が高まる現在、何を作れば効果があるのか明確でない状況では、計画駆動型の開発は適応しづらくなっています。
プロジェクト型開発は特定のタスクを期限内に完遂することを目的とする一方、プロダクト型開発は市場や顧客ニーズの変化に迅速に対応し、継続的に価値を提供することを目的としています。このような開発モデルの転換により、エンジニアチームとビジネスチームの関係はより密接で協調的であることが求められるようになりました。
具体的には、ビジネスチームが市場や顧客ニーズを深く理解し、エンジニアチームと共通の言語でビジョンを共有することが重要です。また、エンジニアも単なる「技術者」に留まらず、プロダクトの全体像やビジネス目標を理解し、自発的に価値創出に寄与する姿勢が求められます。
プロダクト開発を成功させるには、透明性のあるコミュニケーションを促進し、ビジョンを共有する文化を醸成することが不可欠です。逆にこれを怠ると、チーム内で認識のズレが生じ、分裂や生産性の低下、さらにはプロダクトの失敗に繋がるリスクが高まります。特に、表面的なビジョン共有に留まり、一つのチームであると言いながらも、実際には異なる認識で動く場面が頻発することは避けなければなりません。
学習する組織（エンジニアとチームとの関係）
個人マスタリーとは、人生において自分が本当に求めている結果を生み出すために、自身の能力と意識を絶えず伸ばし続けることです。「マスタリー」とは、自らエネルギーを注ぐ分野で熟達し、自分を磨き続けることです。自分が職業人生を通じて従事し、磨き続ける「道」を指しています。
共有ビジョンとは、組織のメンバーが共有して抱く未来への憧憬です。「私達は何を作るのか」「私達はどうありたいのか」という問いへの答えとなるものです。
（《マンガでやさしくわかる学習する組織》より引用）
学習は多くの場合、個人の責任と捉えられることが一般的ですが、実際には共有ビジョンは個人のビジョンから生まれるものだと言われています。個人の成長（個人マスタリー）においては、エンジニア一人ひとりが自分自身の強みや弱みを認識し、目標を設定しながら成長を続けることが求められます。これには、自己学習だけでなく、チームや組織の積極的なサポートが欠かせません。
一方、共有ビジョンは、組織全体が目指すべき未来を描き、それに向けてメンバー全員が結束するための重要な指針となります。この実現には、継続的なコミュニケーションとフィードバックの場を設け、個人の目標とチームの目標を結び付ける取り組みが不可欠です。
ゴールの達成は、既存の方法を着実に実行することで可能ですが、プロダクトが継続的に発展し続ける場合には、学習を通じてより良い方法を模索することが求められます。こうした取り組みは、個人の成長を促すだけでなく、チーム全体の目標達成を加速させる原動力にもなります。
学習は単なる「個人の責任」にとどまらず、組織全体の文化として根付かせることが重要です。たとえば、ペアプログラミングやコードレビュー、社内勉強会などの仕組みを導入することで、自然と知識の共有や学びの促進が図れるでしょう。このような文化を育むことで、組織全体の成長と成功が期待できます。
評価（マネジャーとエンジニアとの関係）
評価とは年に１〜２回の人事考課だけをさすのではありません。給与やボーナスなどの報酬を込めることだけがマネジャーの役割ではないからです。
評価とは部下が成長していくための気付きを与える行為です。定期的に人事考課の季節を待つのではなく、常に適切なタイミングでフィードバックをしなければなりません。そのためには、部下の能力を理解して、その能力を活かしたパフォーマンスを発揮しているか把握しておくことが大切です。
（《ソフトウェア・ファースト》 より引用）
書籍の中で、外資系のマネージャーと日本で一般的に呼ばれる管理職を比較した際、「ある程度の年齢に達してから管理職に昇進する」という日本の慣習とは異なり、「マネジメントも一つの専門職として扱われ、評価や昇進は特定の領域における専門性を基に判断される」と説明されています。この領域は、人や組織、特定の顧客、プロダクトなど多岐にわたり、それぞれの対象に対する専門性があって初めて、その領域における「マネージャー」という職位を得られる仕組みです。
つまり、年齢に関係なく、たとえばエンジニアリング組織のマネージャーであれば、エンジニアやエンジニア組織に対する知識や専門性を持つ役割であると言えるでしょう。
評価について具体例を挙げて説明されていますが、日々の業務においても、エンジニア自身が自分の強みや改善点を認識できるよう、1on1ミーティングやメンタリングなどの制度を導入し、成果や努力に対するフィードバックや改善点の指摘を行うことが重要です。このような取り組みによって、エンジニアの成長を促進し、モチベーションの維持と向上を図ることができます。
まとめ
DXを成功させ、時代の流れに乗るために、多くの企業がIT専門家を採用し、エンジニア組織を構築する動きを加速させています。しかし、Slerで培われた「仕事を丸投げする習慣」や、納期に縛られた契約が生み出す対立構造から抜け出せていない現状も依然として存在しています。
本稿ではエンジニアの視点からまとめましたが、プロジェクト全体を統括するPM、市場を切り開くビジネスサイドのメンバー、そしてエンジニアリングチームのいずれかが機能不全に陥れば、良いプロダクトを生み出すことは難しいと言えるでしょう。
プロダクト目標の共有、学習文化の醸成、適切な評価制度の構築などを通じて、組織全体が一体となり、持続的な成長を目指すことが重要です。こうした取り組みこそが、継続的な競争優位性を実現する鍵となります。
参照
《ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略》
《エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング》
《マンガでやさしくわかる学習する組織》
※ ChatGPTより日本語訂正
最後に
次回は、@nakayama_ryuseiRAI さんによる「LT大会を企画してみた！運営のコツと学び」という記事です
組織内のイベントを開催したりする場合、きっとヒントになる内容と思います。
お楽しみに！！
RetailAIとTRIALではエンジニアを募集しています！
興味がある方はご連絡ください！
一緒に働けることを楽しみにしています！