内製組織に待っていた4つのハードルと取り組んだプラクティス
開発組織の発足後、メンバーは目の前に立ちふさがる4つのハードルを次々と乗り越えていった。
第1のハードルは、依頼者と開発チームの合意形成の場を設けることだ。これまでは開発組織外のユーザーが運用も考えずに「欲しいな」と思ったことを要望として開発に投げる状態だった。そこで、河内氏たちはヒアリングシートを作成し、事業（プロダクト）のビジネスインパクトやイグジットプラン、改廃判断ができる責任者などが明確でない案件は開発しない方針を出した。ヒアリングで開発不要の案件を半数近く洗い出すことができたことは、大きな成果だ。
第2のハードルは、ガントチャートの呪縛から解放されることだ。「ガントチャートは、夜更け過ぎにノルマに変わる。例えばビッグリリースの開発で佳境に入ったとき、日単位で機能開発のスケジュールを管理する場面で有用。でも、不確実性が残された状態では機能を開発するだけのノルマに変わりやすく、チームを圧迫する」。そう述べた河内氏は、ガントチャートをビジネスサイドとのコミュニケーションツールとして捉え、機能ではなく事業価値や解決すべき課題に粒度を変更。これにより、機能視点では見えなかった、よりシンプルな開発方法を発見するなどの効果があった。
第3のハードルは、優先度の設定だ。以前は多数のステークホルダーが自分たちの事情だけで依頼や納期を設定していたため、不満を言われることも多かった。そこで、河内氏たちは事案ごとのステークホルダーが参加する事務局を設置。ステークホルダー同士で開発の優先度を話し合える場を作った。
そして最後の第4のハードルは、経済合理性のみで外部委託と内製開発が比べられる問題だ。これは、技術的ノウハウの蓄積が必須ではない案件についてはパートナー企業に発注し、内製と切り分けることで乗り越えた。
ハードルを乗り越えながら、河内氏はこれらに共通する、ある重要なテーマを痛感した。それは、エンジニアの組織はエンジニアリングが主要事業ではない企業にとって、圧倒的にマイノリティーであるという課題だ。そのため、例えばエンジニアを新規雇用したくても、人事や広報にとっては主要事業の人材と異なる採用の動線や人材プール、評価スキームとなり、戸惑いが発生する。
そこで河内氏たちは、「既存の企業文化に開発組織の文化や価値観をトッピング」して社内での異文化形成を測った。具体的には、エンジニアオリエンテッドなプラクティスを導入し、エンジニア文化の独自性を示しながら、主体的に提案していくことだ。これは開発者にとっても、独自の生態系を作って頑張るよりは精神的負担は少なく、心理的安全性を確保できる方法でもあったと河内氏は説明する。
河内氏が採用した、エンジニアオリエンテッドなプラクティスの1つは、スクラム開発だ。エンジニアにとっては一般的だが、社内においてはエンジニアらしさが際立つ同プラクティスは、エンジニアと非エンジニアの顔を合わせの機会を増やし、レトロスペクティブ（振り返り）を通じて新鮮な気づきや学び、相互理解を促進した。
「我々のレトロスペクティブでは、チームのパフォーマンス向上を目的に設定し、1つ以上の問題点を1週間後のスプリントまでに解消できるよう取り組むようにした」。そう述べる河内氏は、ビジネスサイドを巻き込んだスクラム勉強会も開催し、今ではスクラムが企業文化にまで昇華したと明かす。
また、ドキュメント駆動開発も通常業務に取り入れた。参考にしたのは、GitLab社の「GitLab Handbook」だ。河内氏は同社のハンドブックを見て、テストコードを書いてからプログラミングするテスト駆動開発を応用した手法ではないかと分析。部のビジョンやミッション、大事にしている価値観、コミュニケーションルール、オンボーディングプロセスなどのドキュメントを先にまとめた上で業務に着手するワークスタイルを作っていった。ドキュメントは、誰もが必要に応じてメンテナンスする。「これはいわば、開発チームの青写真を体系立てて精緻化する作業で、業務の精緻化にもつながった」（河内氏）
このほか、技術者用キャリアパスを社の評価ステップにマッピングする、個人の学びや主業務外のアウトプットをする場として週次の技術共有会や個人QDR（Quarter Development Review）発表会などを開催する、採用イベントへの参加や内定前インターン制度の開始など人事や広報活動へ積極的に参加するなど、さまざまな取り組みを実践している。
現在は、事業部門の社員との距離をさらに近づけるべく、開発チームを事業部門内に設置すべく計画を進めていると河内氏。今後も挑戦は続いていく。
