はじめに
こんにちは。最近かかりつけの病院で生活習慣病の療養計画書を書かされることになったプランニングのプロこと、sadatoshiです。
社内向けの研究発表会の記念すべき10回目!! にて、3年以上私が携わらせていただいている案件におけるアジャイルチームのビルドアップの軌跡について発表させていただきました。
内容のすべては難しいのですが、簡単にお話しできる範囲でご紹介させていただければと思います。
他社文化に馴染みながらってどういうこと？
大変ありがたいことに弊社はリファラルでお仕事をいただくことが多く、今回もその流れで案件をいただきました。
なぜその流れになったかというと、案件をいただいたクライアントのプロダクトが拡大するにあたって内製のパワーだけだと不足気味であったことから、弊社からアジャイルチームごと参画して欲しいとの要望を受け、私はそのチームのマネジメントを担当しました。
なので、既に内製しているアジャイルチームと並列で弊社のアジャイルチームが開発する流れとなりました。この時に大切にしたのが「まず相手の文化を知ること」でした。
海外旅行に行った際に相手国の文化を尊重したうえで行動したり、そんなイベントごとでなくとも、他人の家に行ったときはその家のルールに従うといったことと同じで、相手の文化を知って、理解した上で自分たちの文化と融合しようと考えました。
とはいえ、文化が正反対だと大変にはなるのですが、幸いにして「クオリティを大切にする」「事業目線だけでなく、エンジニア目線の気付きも大切にする」といった弊社の文化に近しくもあり、文化の融合については透明性を担保しつつ相互交流を積極的に実施することで成し遂げることができました。
その甲斐もあって、現在では意識の相違が生まれることはほとんどなく、お互い同じ方向を向いてプロダクトをより良くしたい！というマインドで動くことが出来ていると感じます。
成長を加速させた「透明性」
それでは、ビルドアップにおいて大切にしたことを3つお伝えしていきたいと思います。 まずは1つ目。
先程、「文化の融合については透明性を担保しつつ〜」と書かせていただきましたが、私たちが相手を知ることと同じくらい、相手に私たちを知ってもらうことが参画初期フェーズにおいての重要事項であると考えました。
特に今回はアジャイルということでチームが成熟すれば「早く良いものを作ることができる」状態となりますが、未熟な状態からのスタートになってしまうので、未熟だからこそ自分たちの現在地を明確に示すことで「この人たちに任せて大丈夫かな？」という不安を払拭させたかったという理由からです。
現在の状況や問題点を過剰なまでに発信することで、余計に信用がなくなるんじゃないか？というネガティブな気持ちになってしまいうこともあるかと思います。が、それ以上に未熟な私たちだけだと気付けない解決法をご提示いただけることもあり、成長速度を上げることに寄与したと思っています。
もちろんこの時にベロシティという生産性を可視化した数値もお見せするのですが、決して個々の生産性としてではなく、あくまでもチームの現状を示し、チームとして問題に取り組み、チームとして成長することにフォーカスさせることにより、個々が自身の問題として捉えて抱え込んでしままわないように、チーム内で可能な限り同じ方向を向くように心がけました。
チームである、ということにこだわった「属人化の防止」
2つ目は、透明性を担保しつつ生産性を上げた後に気を付けたことは属人化を防ぐことでした。
チームとして参画している以上、チーム自体がクライアントに評価されないと意味がないと考えているため、「このチームは〇〇さんがいるから安心できる」ということをなるべく避けたかったからです。（この場合はチームではなく特定の担当者が評価されているだけという話）
そのためにドキュメントの工夫など色々実施していましたが、特に気を付けていたのはプルリクエストのレビューは全員のapproveを必須としたことです。
これにより、自身が現在関わっていない機能についてのキャッチアップが行われ、またリードエンジニアのコードから学びを得ることでスキルの平準化と自分が全く知らない領域がない状態を作りつつ、何より品質の向上に大きく役立たせることができました。
精度高い「計画性」を早期に示す
そして、3つ目。「ウォーターフォール」と「アジャイル」との比較において、よく計画性の有無という極論で語られることがありますが、それは誤りです。もちろん「ウォーターフォール」のようにスタートからゴールまでの道のりをすべて計画立てることはしませんが、いつゴールするのかの算段を付けるのは「アジャイル」であっても重要です。
なぜなら、ソフトウェア開発工程におけるゴールはカスタマサクセスやユーザにとってのスタートでもあるからです。
スタートがいつか直前までわからないソフトウェア開発のプロセスに積極的に携わりたいエンジニアはいないでしょう。
なので、確約はできないまでも確度のあるゴール時期を早期に示す必要があります。
そのためには、不確定要素を早期に潰す必要があるので、不確定要素を洗い出し対処するプロセスを必ず開発案件ごとの冒頭で実施するように心がけました。
その上でプランニングポーカーで簡易見積もりを実施し、チームの生産性に当てはめることで開発着手時により確実なゴール時期を示すことができました。
意志を持ってチームを更に進化させていきたい
今まで述べたことを3年間ひたすら実践してきたことで下記のようなチームを作り上げることができたかなと思っています。
- 相手の文化を尊重しながら自分たちの文化も大切にするチーム
- 透明性があり、皆でプロダクトをより良くしたいと思えるチーム
- 品質保持と計画遂行を高い水準で維持できるチーム
これらのことを保ちつつ、より主体的に開発パートナーという殻を破ってクライアントへの事業貢献ができるよう今も日々奮闘しております。
おわりに
あれだけ計画が大切という話をさせてもらったにも関わらず、療養計画については全く遂行できておりません。。（特に週2回の運動という計画が暑さを言い訳に進まない・・・）
要するに無理のない計画を立てるのが一番大事ってことなのかなと自分の身を持って実感しております。
長々とした駄文にお付き合いいただき、ありがとうございました。
計画ムズカシイ！
