開発組織を変革するための3つのステップ
国産初のダイナミックスピーカーから始まり、GPS搭載カーナビやカーCDプレーヤーなど数々の「世界初」を送り出してきた老舗メーカーのパイオニア。技術開発力で高い評価を得ていた同社だが、時代の変化に取り残され、2000年代に入ってからは経営が悪化。2019年には東京証券取引所第1部にて上場廃止が決定するという憂き目を見た。
そんな苦境を跳ね返すべく、同社はすぐさま構造改革に着手。2025年に向けた新企業ビジョン「未来の移動体験を創ります」の下、モビリティデータを活用したソリューションサービスの提供など、ソリューションビジネスへと大きく舵を切る決断をした。
同社の挑戦を裏で支えるのが、2021年8月に設立したSTCだ。DevOpsによる開発および運用の効率化、サービス開発および運用の内製化、データ活用の強化などを目標に、人・組織・プロセスを強化して底上げしながら、DevOpsでテクノロジーと品質保証、事業の密な融合を図り、プロダクトの成長を加速させるというミッションを掲げ、開発組織の大改革を推進している。
STCのセンター長を務めるのは、パイオニアの執行役員でCTOの岩田和宏氏だ。同氏は、抜本的な組織改革に即効性のある解決策など存在しないとして、まずは200名近くの社内エンジニアと1on1を実施。新体制へ移行するために乗り越えるべき課題を、文化と技術の2つの切り口から整理した。
結果、浮き彫りになったのは、モノ作り型の開発思考や制度、文化が深く根付いていること。例えば、縦割り組織で社内受発注のようなプロセスが動いており、開発もウォーターフォール型。外部ベンダーへの依存度も高く、インフラを含む開発技術標準がなく、クラウドやWebなどIT技術周りのスペシャリストが圧倒的に不足しているなどの課題もあった。
このモノ作り文化・制度をどのようにしてサービスやソリューション開発の文化・制度へと移行させるのか。「その解答は、逆コンウェイの法則にある」と岩田氏は言う。逆コンウェイの法則では「自分たちの望ましいアーキテクチャ設計を促進するように、チームと組織側を機動的に進化させることを推奨する。理想的には“技術的アーキテクチャ”が“ビジネスアーキテクチャ”の同形写像になるように」という文言がある。これを岩田氏は「組織の構造やチーム間のコミュニケーションパスは、結果的にシステムのアーキテクチャに反映される。そのため、望ましいアーキテクチャと一致するように、またアジャイルなフローを実現するように、組織・チームを逆算して設計することだ」と解釈した。
新たな文化や思想を醸成させるには、まずはソリューションサービスカンパニーへの変革を成功させるためのミッションやビジョンを作り、戦略や全体構成、ロードマップを具体化した上で、その実行部隊となる組織および開発体制を準備する。その組織には、SaaS開発に関わる技術の標準化や設計などを経験したことのある、アジャイルな開発やマインドを持った人材を投入。さらに、モノ作りのスペシャリストであるパイオニア社員を加えて、スキルシフトを図りながらDevOpsの開発思考を身につけてもらう。そして、その融合が進んだ先に新しい文化が醸成される。岩田氏は、この「組織・開発体制の構築」「人材の確保」「文化の醸成」の3つのステップで変革を進める戦略を立てた。
現在は、iOSおよびAndroidエンジニア、Webアプリエンジニア、インフラエンジニア、データサイエンティストなどのスキルセットを持つ人材を、採用チームと連携しながら外部から積極採用中。「社内人材との融合が始まり、良いシナジーが生まれている」と岩田氏は明かす。また、開発についても内製化やSaaS開発に関わる技術の標準化、自動テストやUI/UX系デザイン体制の構築や評価などが進んでいるという。
開発体制の整備とエンジニアに求めるスキルセット
以下の図は、STCが現在構築を目指している、Piomatix（Pioneer Informatics Architecture：パイオニアの技術基盤）をベースとした次世代プラットフォームの全体像だ。IoTデバイスから吸い上げたデータをデータナレッジとして蓄積。行動提案や配送、ナビ、AIなど各種の機能エンジンで処理し、APIからB2CやB2B2C、B2BにSaaSとして利用できるようにするというSaaSプロジェクト構想だ。
プロジェクトを推進するため、岩田氏はPiomatixなどの技術基盤を担当するプラットフォームチーム、SCMやUX、QAなどプロジェクト型チーム、これらチームと横断的に連携してSREやデータインテリジェンスなどを提供する職能横断型チームの、3つのチームタイプを定義。チームの役割を定義し、コミュニケーションパスを明確化した。そして、これらチームが持続的に成果を出せるよう、ハイパフォーマンスの状態に持って行くための「チームファースト思考」を取り入れ、文化的な成熟度や技術的な成熟度、人材の状況を見極めながら推進しているという。
開発プロセスについては、既存のプロセスで改善が必要なもの、まだ存在しないプロセスが何かなどを整理した。例えばプロダクト計画プロセスの場合は、既存のプロセスでは事業部がプロダクト計画を立ててから技術部門に開発見積もりを依頼して開発スタートという流れで、「仕様や見積もりの曖昧さが残る受発注的プロセスだった」と岩田氏は指摘。これを、最初にサービスロードマップを作成してから初期的な体験を設計するチームを組成し、その後に開発チームの規模や構成を検討するという流れを作った。
「事業部の垣根を越えた、ワンチーム開発体制にシフトすることを重視して取り組んだ」（岩田氏）
新規に導入した体験設計プロセスについては、新サービスを設計するプロセスとDevOpsを回すプロセスに分けて、それぞれの詳細を定義。要件定義と仕様の作成を同時に行う仕掛けを作った。
例えば新サービス設計では、ユーザーリテンションやベネフィットトラッキング、価値の分解（ユーザートラッキングで可視化されたユーザー操作からユーザーエクスペリエンスが理想の状態にあるかどうかを判定）、ユーザーストーリーを設計し、MVPを決定する流れを構築。DevOpsのプロセスでは、KPIやモニタリング数値に基づき、分析結果をまとめて、価値提案やアップデートを実施。各種設計をアップデートしてステークホルダーに分析結果をレポートという流れを回す仕組みを作った。
また、チェックリストと必要な作成物を定義し、次のプロセスへ移る前に確認できるようにした。チェックリストでは、例えば「ユーザーが使い続ける仕組みが要件に入っているか」というチェック項目に対して「フックモデル」のアプローチを定義し、その詳細を「説明」に記載。チームが同じ言葉とツールを使って会話できるようにしたという。
プロセスが定義できたところで、岩田氏はサービスに紐付くかたちで開発チームを組んだ。流れとしては、チームごとのインセプションデッキを作成し、PMやエンジニア、デザイナー、QAエンジニアなどとのキックオフを実施し、開発アプローチや各種ツールを選定する。
最後に岩田氏は、信頼できて仕事を任せられるエンジニアの条件を、これまでの経験から思いつく限り挙げた。
「まずは、モノやサービスを生み出すエンジニアリングが本当に好きであること。これは技術への好奇心や熱意の高さの源泉となり、スキルアップのスピードにも関わってくるように感じる。そうした土台を持ち、伝えるべき内容を正確に言語化し、チームと対話しながらプロジェクトを円滑に進めるコミュニケーション力、ビジネスモデルや背景を理解して設計できる要求エンジニアリング力、ユーザーニーズや機能要件などのUXを設計できる体験設計力、アーキテクチャやコンポーネントをコーディングする実装力を備えた 『自走力』のあるエンジニアが、互いを高め合える、一緒に働きたいと思える人材だ」（岩田氏）
パイオニアの公式noteでは、取り組みの最新情報を公開している。「開発組織の変革を考える方にとって、少しでも参考になれば幸い」と岩田氏は述べ、講演を終えた。
