外注依存で生まれた3つの課題
デジタルマーケティングの全ての領域に対する、コンサルティング、開発・実装、運用・実行の提供を行う電通デジタルは2018年、広告プロダクトの運用支援ツール開発に向けて内製開発組織を設置した。これまでも広告配信実績データの可視化基盤の運用で、エンジニアが数名割り当てられていた。しかし、ベンダーコントロールや社内調整に手いっぱいで、開発の大半は外部パートナー企業任せだった。そのため、同社の技術スタックはパートナー企業の技術スタックとほぼイコールの状態でその技術戦略はなかった。
当時はコンサルティング業務に従事しており、後の内製開発組織の発足でメンバーとして合流することになる技術畑出身の河内修氏は、彼らが抱えていた課題を3つ挙げる。
1つは、初期の要件（依頼内容）でそのままデリバリー・リリースされる点だ。パートナー企業は依頼どおりに開発しているだけなので、それ自体は問題ない。しかし、当該スコープの課題の範囲内で設計され、そのまま進んでしまう。結果、実は存在するシステム間の依存関係を見落としたり、将来の戦略を考慮せずに進んでしまうことが多かった。実際、なぜか不定期に落ちるバッチAがあり、Aが落ちるとまったく関係ないはずのバッチBも落ちるという現象もあり、「原因を特定する仕組みもなかったので、しばらく悩まされた」と河内氏は振り返る。
2つめは、運用側が使い方を把握できないようなものが発注、設計されがちな点だ。例えば、ある外部システムのデータを取り込みたいとの依頼を受けて、それがどんな使われ方をするか分からないままにパートナー企業はデータを取り込むデータベースを設計。しかし、用途が明確でないシステムはほぼブラックボックス状態で、仕様が分からないと利用も運用もできないといった状況が発生していた。
3つめは、外部システムの障害を天災として扱う以外の手段がない点だ。開発の知見が内部エンジニアにほとんど蓄積されていないため、障害が発生したら「アンコントローラブルだからしかたがない」とか、あとは起きないように祈るだけになってしまっていた。「技術スタックが弊社側に蓄積されていれば、『天災』が起きる度に技術的備えを増やしていき、より強固なシステムを構築できるはずだ」（河内氏）
こうした課題を解消し、顧客向けのデータ活用プラットフォームの開発や、社内の戦略プロダクトの開発を内製で主導できるよう、内製組織が発足された。メンバーは、広告配信プラットフォームに関わっていたメンバーに加えて、河内氏含むエンジニア経験者や中途採用のエンジニアが合流する形で構成された。
だが、課題に取り組む前に、やるべきことがあった。それは、内製開発組織の存在意義を共有することだ。
同氏たちは、なぜ内製組織が必要なのかを定期的にコアメンバーでブレーンストーミングし、働きたい組織像を明確化。そして、その組織像をさまざまな形で部内外と共有するようにした。
「開発組織の本来あるべき姿を開発メンバーで共有できていないと、各所で開発依頼の要求を代案や優先順位も考えずに開発するだけの『脳死した生産工場』に陥ってしまう。そうすると以前作ったものと似たようなものを再生産してしまうなどの悪循環も発生しがちだ」。こういったあるべき姿など重要なことほど露出回数を増やすべきと考える河内氏は、例えば開発組織のすべてが分かるハンドブックを作成して公開する、期初の活動計画発表で部内外に開発組織のあるべき姿を発信するといった活動を、今でも積極的に行っている。
内製組織に待っていた4つのハードルと取り組んだプラクティス
開発組織の発足後、メンバーは目の前に立ちふさがる4つのハードルを次々と乗り越えていった。
第1のハードルは、依頼者と開発チームの合意形成の場を設けることだ。これまでは開発組織外のユーザーが運用も考えずに「欲しいな」と思ったことを要望として開発に投げる状態だった。そこで、河内氏たちはヒアリングシートを作成し、事業（プロダクト）のビジネスインパクトやイグジットプラン、改廃判断ができる責任者などが明確でない案件は開発しない方針を出した。ヒアリングで開発不要の案件を半数近く洗い出すことができたことは、大きな成果だ。
第2のハードルは、ガントチャートの呪縛から解放されることだ。「ガントチャートは、夜更け過ぎにノルマに変わる。例えばビッグリリースの開発で佳境に入ったとき、日単位で機能開発のスケジュールを管理する場面で有用。でも、不確実性が残された状態では機能を開発するだけのノルマに変わりやすく、チームを圧迫する」。そう述べた河内氏は、ガントチャートをビジネスサイドとのコミュニケーションツールとして捉え、機能ではなく事業価値や解決すべき課題に粒度を変更。これにより、機能視点では見えなかった、よりシンプルな開発方法を発見するなどの効果があった。
第3のハードルは、優先度の設定だ。以前は多数のステークホルダーが自分たちの事情だけで依頼や納期を設定していたため、不満を言われることも多かった。そこで、河内氏たちは事案ごとのステークホルダーが参加する事務局を設置。ステークホルダー同士で開発の優先度を話し合える場を作った。
そして最後の第4のハードルは、経済合理性のみで外部委託と内製開発が比べられる問題だ。これは、技術的ノウハウの蓄積が必須ではない案件についてはパートナー企業に発注し、内製と切り分けることで乗り越えた。
ハードルを乗り越えながら、河内氏はこれらに共通する、ある重要なテーマを痛感した。それは、エンジニアの組織はエンジニアリングが主要事業ではない企業にとって、圧倒的にマイノリティーであるという課題だ。そのため、例えばエンジニアを新規雇用したくても、人事や広報にとっては主要事業の人材と異なる採用の動線や人材プール、評価スキームとなり、戸惑いが発生する。
そこで河内氏たちは、「既存の企業文化に開発組織の文化や価値観をトッピング」して社内での異文化形成を測った。具体的には、エンジニアオリエンテッドなプラクティスを導入し、エンジニア文化の独自性を示しながら、主体的に提案していくことだ。これは開発者にとっても、独自の生態系を作って頑張るよりは精神的負担は少なく、心理的安全性を確保できる方法でもあったと河内氏は説明する。
河内氏が採用した、エンジニアオリエンテッドなプラクティスの1つは、スクラム開発だ。エンジニアにとっては一般的だが、社内においてはエンジニアらしさが際立つ同プラクティスは、エンジニアと非エンジニアの顔を合わせの機会を増やし、レトロスペクティブ（振り返り）を通じて新鮮な気づきや学び、相互理解を促進した。
「我々のレトロスペクティブでは、チームのパフォーマンス向上を目的に設定し、1つ以上の問題点を1週間後のスプリントまでに解消できるよう取り組むようにした」。そう述べる河内氏は、ビジネスサイドを巻き込んだスクラム勉強会も開催し、今ではスクラムが企業文化にまで昇華したと明かす。
また、ドキュメント駆動開発も通常業務に取り入れた。参考にしたのは、GitLab社の「GitLab Handbook」だ。河内氏は同社のハンドブックを見て、テストコードを書いてからプログラミングするテスト駆動開発を応用した手法ではないかと分析。部のビジョンやミッション、大事にしている価値観、コミュニケーションルール、オンボーディングプロセスなどのドキュメントを先にまとめた上で業務に着手するワークスタイルを作っていった。ドキュメントは、誰もが必要に応じてメンテナンスする。「これはいわば、開発チームの青写真を体系立てて精緻化する作業で、業務の精緻化にもつながった」（河内氏）
このほか、技術者用キャリアパスを社の評価ステップにマッピングする、個人の学びや主業務外のアウトプットをする場として週次の技術共有会や個人QDR（Quarter Development Review）発表会などを開催する、採用イベントへの参加や内定前インターン制度の開始など人事や広報活動へ積極的に参加するなど、さまざまな取り組みを実践している。
現在は、事業部門の社員との距離をさらに近づけるべく、開発チームを事業部門内に設置すべく計画を進めていると河内氏。今後も挑戦は続いていく。
