個人からチームへ。アジャイル開発への最初の半年間の取り組み

PLAN-Bに入社して約2年半、自社プロダクト開発におけるアジャイルなあり方を模索・推進してきました。
アジャイルやスクラムは、理解した気になるのは簡単ですが、実践するのはめっっっっっちゃ難しいと言われています(実感の数だけ「っ」を足してみました)。 弊社でも特にこの2年間推進してきてようやく、形になってきたかなと言える状態になりました。 改善は今後も止まることなく続きますが、改めてこの2年間の取り組みをまとめます。 まずは特に最初の半年、アジャイル以前に「チーム開発」を目指した時期の取り組みについてです。

(以前同様の内容をDevLOVE関西で発表しました。「個人からチームへの越境、チームから組織への越境」 この時の内容を再構成し、改めてふりかえったものになります)

前半はやや辛口な内容になっていますが、今や解決できた過去のことです。同様の問題に悩まされている方の役に立てれば嬉しいです。

チームに入っていてもチームじゃない、エンジニアの個人商店

当時社内には複数のプロダクトがあり、それぞれに複数のエンジニアが所属していました。しかしエンジニア間の連携はあまりなく、同じプロダクトを担当はしていても、仕事は個人で受けるような状態になっていました。ガチガチのウォーターフォールでも、アジャイルやスクラムでもない、ルールやプロセスといったものは定義されていない状態。いわゆる「カウボーイコーディング」の状態とも言えます。

カウボーイコーディングは、各々の開発者が「自分が良いと思うプログラミング」をバラバラに行うことである。好ましくない状態を指すのに使う言葉であり、特定の開発手法を指す言葉ではない。職人的な個人技に依存するカウボーイコーディングには、明確な手法が欠如している。カウボーイコーディングで開発を行うチームのメンバーは、自分たちがそれぞれ正しいと感じた作業を行う。(Wikipediaより引用)

弊社ではよく「個人商店」と言われていました。

• チームでタスクを持つのではなく、ビジネスサイドからエンジニア個人への依頼が来る
• タスクの完了も、エンジニア個人とビジネスサイドの当人同士の確認によってのみ行われる

「同じプロダクトに所属しているエンジニアは複数人いるが、お互い何をやっているかは知らず、いつの間にか何らかの対応やリリースが完了している」状態になっていました。アジャイルが〜以前の問題で、チーム開発の体をなしていませんでした。例えばこんなことがよく起こります。

• 運用や問い合わせが特定の個人に集中する(しかも依頼は個人チャットで行われ、他のメンバーは知らない)
• 個人でタスクを行っているので、何か問題が起きた時の「対応が遅い」「対応ができない」になり、結局依頼者からの期待値からはずれる
• サービスがいい個人商店(エンジニア)だと、目の前のお客さん(ビジネスサイド)のために何時間でも作業しちゃう。他の組織的なタスクよりも優先順位を個人で勝手にあげちゃう

個人の判断でしわ寄せをする

開発プロジェクトとしても問題が発生します。本来は組織的な判断が必要なところを、個人の判断に依存することになります。例えばこんなこともよく起こります。

• お客さん(ビジネスサイド)から言われた納期が絶対(と個人で判断)なので…
  • 納期が来たらスコープを独自に変更
  • 納期が迫ってきたらテスト終了
• 品質担保も個人の裁量なので…
  • 設計・テストをそもそもやらない、ドキュメントを残さない
  • 結果的に独自の実装や仕組みが増え、メンテナンスコストがあがる
  • コードレビューはしていたが、他のメンバーは何をしているのか具体的には知らないので「コードの書き方」程度のレビューにとどまる

これによってしわ寄せが来るのが、ビジネスサイドとプロダクトです。
「思っていたのと違う」「リリースしてみたら障害だらけ」「ソースコードが継ぎ接ぎだらけ」 結局作り直しになったり、障害対応時間が増えたり、メンテコストが上がったりと悪いことずくめです。アジャイルではOutputよりもOutcomeと言われますが、Outputさえも上手くできていない状態です。

障害・運用が増え、新規開発にかけられる時間が減る

運用作業についても同様で、こちらはより個人に集中・隠れやすくなります。開発や運用が個人の判断によって行われ、更に個人にタスクが隠れるとどうなるか。以下のようなコンボが決まり、最終的に新規開発や改善にかけられる時間が減ります。プロダクトのROIが悪化し続けます。実際、当時のプロダクトで障害対応にあたる時間が、プロダクト全体に使える時間の数十パーセントに達していたものもありました。(今はほとんどの時間を新規開発あてられるようになりました)

ねんがんの新規開発でも困る

なんとか障害対応をして、いざ新規開発に向かったとしても、技術的負債がたまりにたまったプロダクトです。障害対応や問い合わせも多くなっています。いざ開発を始めてみても、前述した様々な理由により遅れが発生、理想の時間では終われません。

そして失敗を再発明する

最後にナレッジマネジメント、組織としてのノウハウの蓄積としての観点でもいいことはまるでありません。個人個人で仕事をしているので、よほどのことでなければ情報は共有されません。何か問題が起こると「うわ、またいつものパターンやん」「えっ、それならxxxしたら良かったのに」のような反応が起こります。ノウハウが共有されていれば起こらなかったかもしれないことも、チームで当たれば解決できたかもしれないことも、何度でも「失敗を再発明」します。

個人からチームへ、何から始めたか

アジャイル云々の前に、まずは個人ではなくチームや組織としてプロダクト開発に当たれるようにするところから始めました。個人商店状態の課題を深堀りしていくと以下に分類できました。

1. 責任が曖昧: 特に、プロダクトの品質(外部、内部)について責任者が不在
2. 組織的な判断ができていない: 個人では難しい判断や、プロダクト間の問題を解決する仕組みが弱い
3. 改善活動ができていない: チームやプロダクトの状態を俯瞰的に改善する場や仕組みが弱い

それぞれの課題に対して、大きな方針として「役割と責任の明確化」「1枚のカンバンに全てのプロダクトをのせる」「継続的なふりかえり」を行いました。

組織変更で役割と責任を明確化

組織的な面では、プロダクトチームのメンバーを3つの役割に整理しました。(ここにはデザイナーやビジネスサイドのメンバーは含まれていません)

まずは役割ごとの責任を果たせるようになるために、組織図としてはこの役割に寄せた上で、プロダクトのチームは役割を横断して入るようにしました。以下の図のような形で、「あるメンバーは組織図上はDevチームに属しており、プロダクトはAを担当」となります。このあたり、プロダクトチームの練度や組織の方針によって変わるところではありますが、「プロダクトチームにのみ所属していて個人商店化していた状態」から反対側に舵を切って「役割と責任が明確にされた状態で、プロダクトチームに所属」に一度変えました。

※おじさんとお姉さんと猫しかいませんが、3人が兼任しているのではなく、それぞれ別の人ですｗ

しかしここで問題が起こります。「個人商店がいきなりショッピングモールに統合されても認識が全く合わない」状況になりました。タックマンモデルでいうところの「形成期」ではありますが、主義主張、思想が入り乱れます。 この時には積極的にチームビルディング系のワークを行いました。いくつか記事にもしてありますが、以下のようなものです。

• ドラッカー風エクササイズ: お互いを知る、期待をすりあわせる。
  

  先輩に本音を言えてますか？遠慮があったら始まらない「ドラッカー風エクササイズ」で作る良いチーム

  組織変更があった、新しいチームができた、チームメンバーが変わったなど、チームやメンバーが変わると色々な不安がありますよね。あの人はどういう考えや価値観を持っているんだろう？自分をどれくらい出しても良いんだろう？など、多く…
• 爆弾解除ゲーム: コミュニケーションは難しいものだと改めて体感する。
  

  伝えたいことが伝わってない！？チームビルディングをゲームで楽しく

  「アレをアレして、次にコレを…違う違う！アレをコレするんじゃなくて、アレをアレ…」エンジニアとプランナー、開発と運用、身近なところでは自分と実家の母とのパソコンが動かなくなった系の相談など、お互いの持っているスキルや情報…
• 心理的安全性ゲーム: 言葉ひとつで感情がどう動くのか体験する。(心理的安全性ゲーム(外部サイト))

並べてみるとコミュニケーションやモチベーション、感情に寄り添ったものが多いです。まずはお互いをちゃんと知るというところに重きをおいていました。

ドラッカー風エクササイズはメンバーが変わるたびや別チームでも何度もしたので、マイナーバージョンアップが行われていました。

1枚のカンバンに全てのプロダクトをのせる

当時社内で運用していたプロダクトは4-6つほどでした(新規で起こすプロダクトもあれば、やめるプロダクトもあるので変動は常にあります)。それぞれのプロダクトでカンバンやタスクボード的なものはあったりなかったりでしたが、すべてを1枚のカンバンにまとめることにしました。
まず個人商店状態の問題点として、個人が「隠れタスク」を持っていることがあります。とにかくこれをなくさなければ、プロダクトや組織としての優先順位判断ができないので、タスクマネジメントとタスクの場所を一本化することから始めました。

一見こう見えても

隠れタスクがいっぱいで、実はこういうことがある

このカンバンに込めた思いが強すぎて、詳しく書くと非常に長くなってしまう(いずれ別記事にて)ので、ざっくりまとめるとこんな感じのカンバンです。

めちゃめちゃ具体的なことが書かれているので、ぼかしを入れています

• 全てのプロダクトのタスクをここにのせる
• 付箋にはったシールの色でプロダクトを区別する
• 3色の付箋でタスクの種類を区別
  • 黄: 新規開発や機能改善
  • 青: 保守や問い合わせなど運用に関わるもの
  • 赤: 障害対応
• アバター(自家製の担当者マグネット)は1人1枚で、最優先で取り掛かっているものにだけのせる
• 列を共通にし、列ごとにどの役割が責任を持つのかを明確にした
  • とにかく「カタ」がない状態なので、まずは統一したルールで共通認識作りに重きを置きました

他にも小道具がたくさんありますが、コロナ以降は物理的な小道具を使えていないこともあり省略します。(小道具作成にあたっては、「アジャイルコーチの道具箱」(外部サイト)がとても参考になりました。リモートでもゲーミフィケーション的に楽しめるテクニックはあるので、おすすめです。)

カンバンとしては1つにまとめていますが、プロダクト毎の毎朝のスタンドアップは、別々に5-10分と時間を決めてローテーションして行いました。そこで出た問題かつプロダクトチーム内で解決できないものは、一覧を開発者全体のチャットに流した上でネクストアクションを決めるフローにしていました。
全てのタスクが見える状態で、問題があるものや遅れが発生しているものは小道具でわかるようにした結果、エンジニア同士でのコミュニケーションが増えたり、「組織vs問題」の構図ができたりしやすくなりました。

状況の可視化と継続的なふりかえり

役割と責任、タスクマネジメントとフローを明確にしたあとは、それらが継続的に改善されるよう、継続的なふりかえりを習慣化することを目指しました。ふりかえりをする際は、事実に基づいたデータがあるとなおヨシです。当時、物理のカンバンも運用しつつ、試験的にデジタルの方でも物理と同期したカンバン運用をしていました。タスク(チケット)ごとの列移動時のタイムスタンプやかけた時間がデータとしてたまるので、Metabaseを使って可視化・継続的に追うなども動きもできました。(こちらの記事も参考に: Metabaseを使って成果の可視化でチームの心を1つにしよう！ツール選定と実際の手順をご紹介！)

またこの時点では「ふりかえりで成果に繋がった」「ふりかえり楽しい」と思ってもらうことを大事にしていました。毎回同じふりかえり手法を使うよりは、その時々のプロダクトやチームの課題にフォーカスして、ふりかえりを設計・実践しました。小さくても成功体験を重ねることで、ふりかえりのモチベーションを高め、ふりかえりの成果がより高まるサイクルにつなげます。

役割とプロダクトでクロスしたチーム構成にした結果、副次的な効果として「プロダクトチームのふりかえりで得た知見を役割のチームに共有」「役割のチームで得た知見をプロダクトチームに共有」の流れが自然とでき、ナレッジの共有が自然と行われるようになりました。以下のような流れです。

1. プロダクトチームAでふりかえり
2. 1の結果をDevチームで共有
3. Devチームの他のメンバーがプロダクトチームBで共有・実践

変わるには時間がかかる

個人商店からチーム開発になるためにこれらの方針にのっとって、様々なアクションをしてきました。このレベルで組織的にやり方を変えたことはなかったので、最初は「3ヵ月程度で一定まわるようになるだろう」と楽観していましたが、全然足りませんでした。
以前参加したアジャイル系のイベントで「スクラムを初めて導入する際は、経験者のスクラムマスターと開発者が1人ずついたとしても半年から1年かかる」と聞いたことがありますが、まさにその通りでした。この時点ではスクラムなどのフレームワークを導入したわけではなく、カンバン運用を始めただけではありますが、タスク(チケットやバックログアイテム)の作り方、カンバンの考え方(pushではなくpullする、WIP制限など)、ペアプログラモング/モブプログラミングの実践などなど、一定まわると思えるようになるまで半年から1年弱はかかりました。

今あらためて当時をふりかえって自分にアドバイスするならこの3つです。

• 運用がまわるようになるまで何度でも説明をする。個人ではなく、できればチームに対してする
• 人によってコンテキストが違うので、いきなり全員理解するのは無理。1人、2人、3人…と理解しているメンバーを増やしていく
  • チーム単位で説明をすると真逆のようですが、チーム単位で広く浅くカバーはしつつ、深い理解を持つメンバーを増やしていくと、代わりに説明してくれるようになる
• 組織の上司や外部のコーチのパワーを借りるのもあり。組織から任命された正式な担当者であることを周知することも必要

(このあたりは「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」(外部サイト)が参考になります。おすすめです)

そして変わったこと

今回改めて2年前〜1年前あたりの「組織・チームで開発をできるようになる」までの話をまとめました。2020年11月現在、プロダクトの開発は基本的にスクラムでまわるようになっていますが、まずこの「チーム開発を当たり前にする」「組織的な判断ができるようにする」「カンバンでまわせるようにする」ができたことで、この後のスクラム導入の素地ができたかと思います。

実際ここまで変化ができたのは、「今までと違うやり方へ変化」の不安がある中で当時のメンバーが協力し続けてくれたからこそでした。感謝感謝しかありません。何かを変えるには、先立って信頼があると変化が加速することも学びでした。

最後に、個人商店からチームになる過程で変わったこと、できるようになったことを紹介します。

• 個人で仕事を受けるのではなく、共通のカンバンに全てをのせるようになった。何かあった時に納期のみを優先するのではなく、品質やスコープとのトレードオフを組織として判断できるように
  • 結果的に内部品質が向上し、障害対応や運用対応にかかる時間を長期的に減らしていくことができ、新規開発にあてられる時間が増えた
• 共通のタスク(チケット、バックログアイテム)作成ルールが浸透。工数の記録や、「新規開発」「障害対応」「運用対応」にそれぞれどれだけ時間がかかったかがわかるようになったので、定量的にトレンドを追いふりかえることが可能に
  • 合わせて、ユーザーストーリー的なユーザーや顧客から見た時のDONEの定義と、それらを成し遂げるためのシステム開発的なDONEの定義を分離。「ユーザー目線」になるべきものと「システム目線」になるべきものの見分けができるようになった
• 継続的なふりかえりを通して、個人で問題を抱えるのではなく、チームでの自分たちの動き方やカンバン運用などメタ的な改善をできるようになった
• 開発中に問題が発生した場合にチームで気づくことができるので、ペアプログラミングやモブプログラミングなどの問題の早期解決やフローを重視したプラクティスが自然と導入されていった

アジャイルやスクラムでは、プラクティス以上にマインドセットやあり方の定義が大事になってきます。昔ながらの階層構造や分業構造が強い組織やチームでは、そもそも「チーム」になれていないところもあるかと思います。これからアジャイルやるぞー！やスクラムやるぞー！という前に、まずは「(個人が抱えるのではなく)自分たちで自分たちの問題を解決できるチーム」を目指す活動から始めてみてはいかがでしょうか。

次回があれば、この後に始めたスクラム導入か、思いを込めたカンバンの話をしようかと思います。お読みいただき、ありがとうございました。