「リーダーシップ」を育み、次世代へと引き継ぐために
そしてもう1つ、「リーダーシップのトランスファー」も新たな取り組みだという。チームは、システムサービスの要求に対する解決策を自らの能力を活かして提案し（要件定義）、実現（設計・実装）する状態が望ましい。そのためには、各メンバーが役割や能力に応じてリーダーシップを発揮し、チーム全体でプロジェクトの課題に対処する必要がある。
このときに発揮される「リーダーシップ」は、課題解決やタスクを進める際に活動の状況を把握し、有識者を巻き込み、必要に応じて作業の移譲を行う能力である。総じていえば、「チームが協力して課題を解決するための旗を振る」役割と言えよう。
しかし、リーダーシップは本を読めばすぐに身につく類いのものではなく、もともと力を持っている人ばかりでもない。そこで、若手を中心に組織内でリーダーシップを育む必要があった。そこで、コーディングやプログラミングのようなテクニカルスキルのトランスファーでもよく使われる、経験豊かなシニアエンジニアとジュニアエンジニアを組ませて課題解決のプロセスを見せながら学習させる施策を実施した。その際、ジュニアエンジニアに「学んでほしい部分」を明示することで、より効果が上がるという。
この取り組みの結果、ジュニアエンジニアは作業予定や成果の発信について「要点を簡潔にまとめる力」を向上させ、シニアエンジニアの力量やスキルを把握しやすくなった。また、コミュニケーションの心理的なハードルを下げて巻き込みやすくなる効果もあったという。なお、注意すべき点としては、サブチーム内での知識のサイロ化や、ジュニアエンジニアとシニアエンジニアとの交流を促すためにサブチームはスプリントごとに組み直すことなどがあげられる。
理想のアジャイル開発へ、TISが現在取り組む、新たな課題とは？
こうした施策によってチームの状態はかなり改善してきたが、現在はさらに新しい課題が生じ、それに向かって取り組んでいるところだという。まず、プロダクトオーナーに要件が委ねられすぎていることへの懸念がある。チームはビジネスの目標や要求を理解して、プロダクト開発に落とし込む責任をもつとしているが、エンジニアがプロダクトオーナーにもなったことで、ビジネスの要求をシステムの要件に変換する部分を担えるようになった。その結果、チーム全体がプロダクトオーナーに依存する傾向が見られるという。
髙谷氏は、「画面の詳細な作りや遷移先、情報の処理やイン・アウトまでプロダクトオーナーに決めてもらう状態となっていた。システムを通してやりたいことを言語化するのはプロダクトオーナーでも、やりたいことをどう実現するかまで事細かく決めるのは頼りすぎ」と語り、「プロダクトオーナーが疲弊・パンクする恐れがある。またシステムに一番くわしい開発チームがシステムへの落とし込みを主導しないのは勿体ないこと」と懸念を示した。
また、チームが開発に習熟するとシステムを作る速度は上がるが、要件定義部分を担うプロダクトオーナーは1人で大幅な加速は見込めない。結果、ボトルネック化する可能性も生じてくる。そこで、ゴールとしては、要求の言語化をプロダクトオーナーが行い、それに対応する要件は開発チームから提案。プロダクトオーナーが判断を下し、実装されていくという流れが望ましい。
これを実現するために、現在は開発チームが要件を定めるよう、開発プロセスに取り込み、トライしているところだという。要件を定めるために必要な情報をプロダクトオーナーに聞きにいく、要件のための要求を引き出す場をスクラムマスターが設けるという2つの動線についてトライを重ねている最中だ。
髙谷氏は、「あるべき綺麗なスクラム・アジャイル開発の状態に最初からなれない、上手く行かないなかで、エンジニアがプロダクトオーナーになることで開発チームとビジネスサイドのコミュニケーションの橋渡しをしてきた。次はプロダクトオーナーに寄りかかっている要件定義をちゃんと開発チームに戻していくことに取り組んでいきたい。そして、コツコツと理想的なスクラムや開発体制にしていきたい」と語り、セッションのまとめとした。
