devopsチームのリーダーになって始めたエモい目標と取り組み
TECH
2022.12.23
2020.12.04
2022.12.27
PLAN-Bに入社して約2年半、自社プロダクト開発におけるアジャイルなあり方を模索・推進してきました。
アジャイルやスクラムは、理解した気になるのは簡単ですが、実践するのはめっっっっっちゃ難しいと言われています(実感の数だけ「っ」を足してみました)。 弊社でも特にこの2年間推進してきてようやく、形になってきたかなと言える状態になりました。 改善は今後も止まることなく続きますが、改めてこの2年間の取り組みをまとめます。 まずは特に最初の半年、アジャイル以前に「チーム開発」を目指した時期の取り組みについてです。
(以前同様の内容をDevLOVE関西で発表しました。「個人からチームへの越境、チームから組織への越境」 この時の内容を再構成し、改めてふりかえったものになります)
前半はやや辛口な内容になっていますが、今や解決できた過去のことです。同様の問題に悩まされている方の役に立てれば嬉しいです。
当時社内には複数のプロダクトがあり、それぞれに複数のエンジニアが所属していました。しかしエンジニア間の連携はあまりなく、同じプロダクトを担当はしていても、仕事は個人で受けるような状態になっていました。ガチガチのウォーターフォールでも、アジャイルやスクラムでもない、ルールやプロセスといったものは定義されていない状態。いわゆる「カウボーイコーディング」の状態とも言えます。
カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うことである。好ましくない状態を指すのに使う言葉であり、特定の開発手法を指す言葉ではない。職人的な個人技に依存するカウボーイコーディングには、明確な手法が欠如している。カウボーイコーディングで開発を行うチームのメンバーは、自分たちがそれぞれ正しいと感じた作業を行う。(Wikipediaより引用)
弊社ではよく「個人商店」と言われていました。
「同じプロダクトに所属しているエンジニアは複数人いるが、お互い何をやっているかは知らず、いつの間にか何らかの対応やリリースが完了している」状態になっていました。アジャイルが〜以前の問題で、チーム開発の体をなしていませんでした。例えばこんなことがよく起こります。
開発プロジェクトとしても問題が発生します。本来は組織的な判断が必要なところを、個人の判断に依存することになります。例えばこんなこともよく起こります。
これによってしわ寄せが来るのが、ビジネスサイドとプロダクトです。
「思っていたのと違う」「リリースしてみたら障害だらけ」「ソースコードが継ぎ接ぎだらけ」 結局作り直しになったり、障害対応時間が増えたり、メンテコストが上がったりと悪いことずくめです。アジャイルではOutputよりもOutcomeと言われますが、Outputさえも上手くできていない状態です。
運用作業についても同様で、こちらはより個人に集中・隠れやすくなります。開発や運用が個人の判断によって行われ、更に個人にタスクが隠れるとどうなるか。以下のようなコンボが決まり、最終的に新規開発や改善にかけられる時間が減ります。プロダクトのROIが悪化し続けます。実際、当時のプロダクトで障害対応にあたる時間が、プロダクト全体に使える時間の数十パーセントに達していたものもありました。(今はほとんどの時間を新規開発あてられるようになりました)
なんとか障害対応をして、いざ新規開発に向かったとしても、技術的負債がたまりにたまったプロダクトです。障害対応や問い合わせも多くなっています。いざ開発を始めてみても、前述した様々な理由により遅れが発生、理想の時間では終われません。
最後にナレッジマネジメント、組織としてのノウハウの蓄積としての観点でもいいことはまるでありません。個人個人で仕事をしているので、よほどのことでなければ情報は共有されません。何か問題が起こると「うわ、またいつものパターンやん」「えっ、それならxxxしたら良かったのに」のような反応が起こります。ノウハウが共有されていれば起こらなかったかもしれないことも、チームで当たれば解決できたかもしれないことも、何度でも「失敗を再発明」します。
アジャイル云々の前に、まずは個人ではなくチームや組織としてプロダクト開発に当たれるようにするところから始めました。個人商店状態の課題を深堀りしていくと以下に分類できました。
それぞれの課題に対して、大きな方針として「役割と責任の明確化」「1枚のカンバンに全てのプロダクトをのせる」「継続的なふりかえり」を行いました。
組織的な面では、プロダクトチームのメンバーを3つの役割に整理しました。(ここにはデザイナーやビジネスサイドのメンバーは含まれていません)
役割 | 責任 |
---|---|
Dev | 新規開発、機能改善、QCDSのトレードオフやリードタイムの改善 |
devops | プロダクトの内部品質やインフラコスト、プロダクト開発を加速させるための業務改善や自動化 (こちらの記事もご参考ください: devopsチームのリーダーになって始めたエモい目標と取り組み) |
プロダクトマネージャー | いわゆるプロダクトマネジメント (こちらの記事もご参考ください: プロダクトマネージャー(PM)のチーム立ち上げ時に参考となった考えや実務を行う上での必要なスキルセットについて) |
まずは役割ごとの責任を果たせるようになるために、組織図としてはこの役割に寄せた上で、プロダクトのチームは役割を横断して入るようにしました。以下の図のような形で、「あるメンバーは組織図上はDevチームに属しており、プロダクトはAを担当」となります。このあたり、プロダクトチームの練度や組織の方針によって変わるところではありますが、「プロダクトチームにのみ所属していて個人商店化していた状態」から反対側に舵を切って「役割と責任が明確にされた状態で、プロダクトチームに所属」に一度変えました。
※おじさんとお姉さんと猫しかいませんが、3人が兼任しているのではなく、それぞれ別の人ですw
しかしここで問題が起こります。「個人商店がいきなりショッピングモールに統合されても認識が全く合わない」状況になりました。タックマンモデルでいうところの「形成期」ではありますが、主義主張、思想が入り乱れます。 この時には積極的にチームビルディング系のワークを行いました。いくつか記事にもしてありますが、以下のようなものです。
並べてみるとコミュニケーションやモチベーション、感情に寄り添ったものが多いです。まずはお互いをちゃんと知るというところに重きをおいていました。
ドラッカー風エクササイズはメンバーが変わるたびや別チームでも何度もしたので、マイナーバージョンアップが行われていました。
当時社内で運用していたプロダクトは4-6つほどでした(新規で起こすプロダクトもあれば、やめるプロダクトもあるので変動は常にあります)。それぞれのプロダクトでカンバンやタスクボード的なものはあったりなかったりでしたが、すべてを1枚のカンバンにまとめることにしました。
まず個人商店状態の問題点として、個人が「隠れタスク」を持っていることがあります。とにかくこれをなくさなければ、プロダクトや組織としての優先順位判断ができないので、タスクマネジメントとタスクの場所を一本化することから始めました。
一見こう見えても
隠れタスクがいっぱいで、実はこういうことがある
このカンバンに込めた思いが強すぎて、詳しく書くと非常に長くなってしまう(いずれ別記事にて)ので、ざっくりまとめるとこんな感じのカンバンです。
めちゃめちゃ具体的なことが書かれているので、ぼかしを入れています
他にも小道具がたくさんありますが、コロナ以降は物理的な小道具を使えていないこともあり省略します。(小道具作成にあたっては、「アジャイルコーチの道具箱」(外部サイト)がとても参考になりました。リモートでもゲーミフィケーション的に楽しめるテクニックはあるので、おすすめです。)
カンバンとしては1つにまとめていますが、プロダクト毎の毎朝のスタンドアップは、別々に5-10分と時間を決めてローテーションして行いました。そこで出た問題かつプロダクトチーム内で解決できないものは、一覧を開発者全体のチャットに流した上でネクストアクションを決めるフローにしていました。
全てのタスクが見える状態で、問題があるものや遅れが発生しているものは小道具でわかるようにした結果、エンジニア同士でのコミュニケーションが増えたり、「組織vs問題」の構図ができたりしやすくなりました。
役割と責任、タスクマネジメントとフローを明確にしたあとは、それらが継続的に改善されるよう、継続的なふりかえりを習慣化することを目指しました。ふりかえりをする際は、事実に基づいたデータがあるとなおヨシです。当時、物理のカンバンも運用しつつ、試験的にデジタルの方でも物理と同期したカンバン運用をしていました。タスク(チケット)ごとの列移動時のタイムスタンプやかけた時間がデータとしてたまるので、Metabaseを使って可視化・継続的に追うなども動きもできました。(こちらの記事も参考に: Metabaseを使って成果の可視化でチームの心を1つにしよう!ツール選定と実際の手順をご紹介!)
またこの時点では「ふりかえりで成果に繋がった」「ふりかえり楽しい」と思ってもらうことを大事にしていました。毎回同じふりかえり手法を使うよりは、その時々のプロダクトやチームの課題にフォーカスして、ふりかえりを設計・実践しました。小さくても成功体験を重ねることで、ふりかえりのモチベーションを高め、ふりかえりの成果がより高まるサイクルにつなげます。
役割とプロダクトでクロスしたチーム構成にした結果、副次的な効果として「プロダクトチームのふりかえりで得た知見を役割のチームに共有」「役割のチームで得た知見をプロダクトチームに共有」の流れが自然とでき、ナレッジの共有が自然と行われるようになりました。以下のような流れです。
個人商店からチーム開発になるためにこれらの方針にのっとって、様々なアクションをしてきました。このレベルで組織的にやり方を変えたことはなかったので、最初は「3ヵ月程度で一定まわるようになるだろう」と楽観していましたが、全然足りませんでした。
以前参加したアジャイル系のイベントで「スクラムを初めて導入する際は、経験者のスクラムマスターと開発者が1人ずついたとしても半年から1年かかる」と聞いたことがありますが、まさにその通りでした。この時点ではスクラムなどのフレームワークを導入したわけではなく、カンバン運用を始めただけではありますが、タスク(チケットやバックログアイテム)の作り方、カンバンの考え方(pushではなくpullする、WIP制限など)、ペアプログラモング/モブプログラミングの実践などなど、一定まわると思えるようになるまで半年から1年弱はかかりました。
今あらためて当時をふりかえって自分にアドバイスするならこの3つです。
(このあたりは「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」(外部サイト)が参考になります。おすすめです)
今回改めて2年前〜1年前あたりの「組織・チームで開発をできるようになる」までの話をまとめました。2020年11月現在、プロダクトの開発は基本的にスクラムでまわるようになっていますが、まずこの「チーム開発を当たり前にする」「組織的な判断ができるようにする」「カンバンでまわせるようにする」ができたことで、この後のスクラム導入の素地ができたかと思います。
実際ここまで変化ができたのは、「今までと違うやり方へ変化」の不安がある中で当時のメンバーが協力し続けてくれたからこそでした。感謝感謝しかありません。何かを変えるには、先立って信頼があると変化が加速することも学びでした。
最後に、個人商店からチームになる過程で変わったこと、できるようになったことを紹介します。
アジャイルやスクラムでは、プラクティス以上にマインドセットやあり方の定義が大事になってきます。昔ながらの階層構造や分業構造が強い組織やチームでは、そもそも「チーム」になれていないところもあるかと思います。これからアジャイルやるぞー!やスクラムやるぞー!という前に、まずは「(個人が抱えるのではなく)自分たちで自分たちの問題を解決できるチーム」を目指す活動から始めてみてはいかがでしょうか。
次回があれば、この後に始めたスクラム導入か、思いを込めたカンバンの話をしようかと思います。お読みいただき、ありがとうございました。