ビジネスの価値創造にむけて自走する組織が持つ三要素
SIerとして、多くの企業のシステムインテグレーションやアウトソーシングなどを手掛けるTIS。髙谷氏が所属する新規事業開発チームでは、名前の通り「TISで新規事業を成功させる」ことをミッションとし、社内で生まれてきた新しいビジネス・事業に対し、エンジニアリングを提供している。
しかし、TISは基本的に受託型の事業を展開してきたこともあり、「新しい価値を生み出す」よりも、「確定したものを早く安く正確につくる」ことに主眼が置かれてきた。そこで、新規事業開発に取り組むにあたり、まずは「マインド」を変える必要があった。そして、新規事業についてスピーディーに手続きを行うためSI前提だった「手続き」を変えること、さらにジュニアエンジニアも含めた「チーム編成」によって、学習・成長を支えながら開発のミッションに挑む必要があった。
そうした課題の一方、各ジャンルの専門家から技術面やビジネス・法務面で大きなサポートと知見を得られ、既存顧客との関係を活かした事業開発の可能性が考えられることなど、TISは大規模な会社ゆえの「強み」も有している。社内手続きも必ずしも硬直しているわけではなく、新規事業開発の実態や課題感を社内に共有することで変えられる余地はあり、髙谷氏のチームでも働きかけを積極的に行っているという。
そうした新規事業チーム内では、「ビジネスの価値づくりに向かって自走する状態」を実現するために必要なものについて話し合い、次の三要素が重要という結論に至った。
①ビジネスの理解と責任
自分たちが作ろうとしているもののビジネスへの「貢献性・価値」を理解した上で、何をどうプロダクトに落とし込めば実現できるか理解ができており、実際に開発に落とし込む責任を認識し、実行できること。
②状態・課題の透明性
チーム内はもちろん、プロダクトオーナーやビジネスオーナーなどステークホルダーとコミュニケーションを行い、ビジネス／・プロダクトの知識・状態・課題を明確に共有する。それによって、課題解決ができる人が問題を検知し、解決に向けたアクションや決定を下したり、状態に応じて協力体制を整えたりすることができる。
③主体的な問題解決ができること
各メンバーが役割や能力に応じてリーダーシップを発揮し、チーム全体で開発の課題に対処する状態。“自走する”上での重要ポイントとなる。
この3つの要素を踏まえ、さまざまな取り組みを実施し、現在は徐々に自走できる形になりつつあるという。その取り組みの1つとして「エンジニアがプロダクトオーナーを務める」までの経緯について紹介された。
エンジニアがプロダクトオーナーに！？ 新開発体制でコミュニケーションがスムーズに
もともとの開発体制は、市場を調査・理解して事業の戦略を立案する「事業オーナー」がプロダクトオーナーを務めていた。どちらかといえば、営業・ビジネスサイド寄りであり、背景には「プロダクト価値の最大化は事業オーナーにしか担えない」という“無意識”に抱いていた前提があったという。しかしながら、オーナーとエンジニアの間に齟齬が生じ、分断が深まることとなる。その理由について、髙谷氏は3つの課題があったと語る。
1）スクラムに関する理解の壁
ビジネス側ではスクラム開発に馴染みがなく、学ぶことから始まった。しかし、プロダクトバックログから開発チームに伝えるべきことについての理解がなかなか進まず、たとえばアイテムの目的や背景についてシステムに落とし込める“粒度感”や、PBIの受け入れ条件についての内容や確度など、習熟には時間がかかるものも多かった。
2）システム開発に関する基本知識の壁
稼働率や不正データの際のシステムの挙動など、システムの細かい判断について、開発チームがプロダクトオーナーに求めても十分な対応が難しかった。
3）事業オーナー／POに求めるものが多すぎる
事業オーナーへの要望が多く、細かな事項に忙殺されるようになった。事業戦略など、本来担うべき重要なミッションに関わる時間が圧迫され始めた。
その結果、プロダクトオーナーである事業オーナーとエンジニアのコミュニケーションがうまく取れず、理想とする「ビジネスの理解と責任」および「状態・課題の透明性」が担保できない状態になってきたことから、「エンジニア側がプロダクトオーナーを担う」判断がなされた。
しかしながら、エンジニアがプロダクトオーナーを担うとなれば、事業オーナーはエンジニア側のプロダクトオーナーを信頼し、仕様の最終決定権を委ねる覚悟を決める必要がある。プロダクトオーナーを担ったエンジニア側も、ビジネス知識やニーズを把握して、ビジネスにかなう仕様を生み出すことに集中する必要がある。そこで、エンジニアと兼業とせず、専業とすることとなった。
エンジニアがプロダクトオーナーになることで、開発チーム側にとってのメリットとしては、まず「データモデル設計について開発者とコミュニケーションできるようになったこと」があるという。
髙谷氏は「ビジネスを言語化・モデル化したデータモデル上で、システムについてコミュニケーションが取れるようになると、ビジネスプロセスやビジネス内で登場するイベントの構造や関係でも認識齟齬を大きく減らせる感触があった。また、ビジネス活動のうち、どのような履歴を残せば今後も活用できるのか、プロダクトオーナーと目線が合わせられるのはよかった」と語る。
そして、髙谷氏は2つめに良かったこととして、「要求→要件の過程で認識の齟齬が生まれなくなってきたこと」をあげる。プロダクトオーナーが、ビジネスの要求を伝えることと、その要求を叶えるためのシステム要件を定義・決定する人物が同一人物になったことで、システムの要件をしっかりと把握し定義できるようになった。
そして3つめには、「仕様に関するコミュニケーションで非エンジニアのための翻訳が不要になる」ことが大きかったという。技術的な問題点やサービスの選定などで、細かな説明やコンテキストのすり合わせをせずともダイレクトに通じるようになった。
話すだけでは伝わらない？ ドキュメント化の文化で形成する組織の共通認識
ここまでは、2023年2月のデブサミでも発表された内容だが、そこで取り上げられなかったこと、そして、それ以降に実施された取り組みについて紹介された。
まず1つめに、髙谷氏は「言語化と情報のストック化の徹底」をあげた。以前は、コミュニケーションにおいて口頭でのコミュニケーションの比率が非常に高かったため、実際に各自の開発・実装作業をした後に認識が合っていないということがあった。特にビジネスの要求やシステム要件での認識がずれると、大きく手戻りすることになりダメージが大きい。
また、コミュニケーションでのやりとりや結果をストックする文化が根付いていなかったため、後から参画したエンジニアへの情報提供や、新領域の開発に関する情報共有がうまくできていなかった。そこで、改善に向けてさまざまな本やドキュメントを読み返す中で、髙谷氏は「アジャイルソフトウェア開発宣言（Manifesto for Agile Software Development）」の中の「ドキュメントを作成しなくてもいいというのは誤解」という記述に気づき、言語化の徹底を決意したという。
「話せば伝わるという幻想を捨て、言語化と情報のストックを徹底しよう。アジャイルであっても残すべきドキュメントは残そう。そういい続け、これをチームのコアな文化として掲げ、実践し続けてきた。その結果、明確に共通理解を築けるというメリットが確実に得られた」と髙谷氏は語る。
もちろん文字で書かれている場合でも認識齟齬は発生するが、同じ文言を読み返し咀嚼することができるため、曖昧な表現に気づいて確認したり、認識齟齬を減らしたりする効果が高く、後から確認する時間は大きく削減された。また、コードレビューの際にも実装に至った背景情報がすぐに参照できるため、時短につながった。髙谷氏は、「文字をタイピングする時間はかかっても、間違いなくメリットが大きい」と語る。
実際のドキュメント作成にはwikiを活用した。プロダクトバックログアイテムにまつわる情報やユーザーストーリー、受け入れ条件、さらに、ユーザーストーリーの上位になるエピックもしっかり文字情報で記述している。また、システム機能の概要についても、複雑な処理が行われる場合に処理概要を言語化したり、図に起こしたりして残すことを徹底している。
髙谷氏は、「コードを読む認知負荷が高そうな場所は、とにかく言語で表現することを徹底した。言語で表現できないことは実装できないとして、まず言語で表現できる処理なのかを確認する意味合いもあった。最後に認証やトランザクションといった考慮が必要不可欠な処理についても一旦書き出しておき、チェックリスト的に活用していた」と説明した。
また、必ずしも全てをドキュメント化するわけではなく、議論や意見交換などはむしろ口頭の方が早い場合も多い。そこで得られた結論やそこに至るまでの経緯などは記録が望ましい。そして、内容的にも、たとえばビジネスの目的や希望、夢などはテキストコミュニケーションよりも、顔を突き合わせて話すことが向いているといえるだろう。
「リーダーシップ」を育み、次世代へと引き継ぐために
そしてもう1つ、「リーダーシップのトランスファー」も新たな取り組みだという。チームは、システムサービスの要求に対する解決策を自らの能力を活かして提案し（要件定義）、実現（設計・実装）する状態が望ましい。そのためには、各メンバーが役割や能力に応じてリーダーシップを発揮し、チーム全体でプロジェクトの課題に対処する必要がある。
このときに発揮される「リーダーシップ」は、課題解決やタスクを進める際に活動の状況を把握し、有識者を巻き込み、必要に応じて作業の移譲を行う能力である。総じていえば、「チームが協力して課題を解決するための旗を振る」役割と言えよう。
しかし、リーダーシップは本を読めばすぐに身につく類いのものではなく、もともと力を持っている人ばかりでもない。そこで、若手を中心に組織内でリーダーシップを育む必要があった。そこで、コーディングやプログラミングのようなテクニカルスキルのトランスファーでもよく使われる、経験豊かなシニアエンジニアとジュニアエンジニアを組ませて課題解決のプロセスを見せながら学習させる施策を実施した。その際、ジュニアエンジニアに「学んでほしい部分」を明示することで、より効果が上がるという。
この取り組みの結果、ジュニアエンジニアは作業予定や成果の発信について「要点を簡潔にまとめる力」を向上させ、シニアエンジニアの力量やスキルを把握しやすくなった。また、コミュニケーションの心理的なハードルを下げて巻き込みやすくなる効果もあったという。なお、注意すべき点としては、サブチーム内での知識のサイロ化や、ジュニアエンジニアとシニアエンジニアとの交流を促すためにサブチームはスプリントごとに組み直すことなどがあげられる。
理想のアジャイル開発へ、TISが現在取り組む、新たな課題とは？
こうした施策によってチームの状態はかなり改善してきたが、現在はさらに新しい課題が生じ、それに向かって取り組んでいるところだという。まず、プロダクトオーナーに要件が委ねられすぎていることへの懸念がある。チームはビジネスの目標や要求を理解して、プロダクト開発に落とし込む責任をもつとしているが、エンジニアがプロダクトオーナーにもなったことで、ビジネスの要求をシステムの要件に変換する部分を担えるようになった。その結果、チーム全体がプロダクトオーナーに依存する傾向が見られるという。
髙谷氏は、「画面の詳細な作りや遷移先、情報の処理やイン・アウトまでプロダクトオーナーに決めてもらう状態となっていた。システムを通してやりたいことを言語化するのはプロダクトオーナーでも、やりたいことをどう実現するかまで事細かく決めるのは頼りすぎ」と語り、「プロダクトオーナーが疲弊・パンクする恐れがある。またシステムに一番くわしい開発チームがシステムへの落とし込みを主導しないのは勿体ないこと」と懸念を示した。
また、チームが開発に習熟するとシステムを作る速度は上がるが、要件定義部分を担うプロダクトオーナーは1人で大幅な加速は見込めない。結果、ボトルネック化する可能性も生じてくる。そこで、ゴールとしては、要求の言語化をプロダクトオーナーが行い、それに対応する要件は開発チームから提案。プロダクトオーナーが判断を下し、実装されていくという流れが望ましい。
これを実現するために、現在は開発チームが要件を定めるよう、開発プロセスに取り込み、トライしているところだという。要件を定めるために必要な情報をプロダクトオーナーに聞きにいく、要件のための要求を引き出す場をスクラムマスターが設けるという2つの動線についてトライを重ねている最中だ。
髙谷氏は、「あるべき綺麗なスクラム・アジャイル開発の状態に最初からなれない、上手く行かないなかで、エンジニアがプロダクトオーナーになることで開発チームとビジネスサイドのコミュニケーションの橋渡しをしてきた。次はプロダクトオーナーに寄りかかっている要件定義をちゃんと開発チームに戻していくことに取り組んでいきたい。そして、コツコツと理想的なスクラムや開発体制にしていきたい」と語り、セッションのまとめとした。
