chap-shimazaki.re

= 思考と組織を変えてくれたアジャイル

//flushright{
島崎純一@junsora
//}


「これ、いつまでにできますか？」


仕事を進める上で、よく聞くひとこと。この質問に対し、皆さんはどのように回答しますか？


開発者であれば、設計して、実装して、テストして…このように全てのタスクを元に工数を出し、妥当性を出した上で、期日を決める。そんな経験あるのではないでしょうか。


私も、開発者時代同じように見積もりを出していた記憶があります。


この章では、このような、従来から重要視されていた流れるような一気通貫スタイルと、小さくカイゼンしながら進める学習スタイルについて、2018年頃から私が経験した組織を変えるまでの物語についてお伝えします。

== 一気通貫スタイルでの経験


「これ、いつまでにできますか？」


ビジネス側から要求が上がってくると、要求に対し、要件を考え、簡単な技術要素も含め、実現可能な要件をビジネス側に伝える。ビジネス側と認識が合うと、プロジェクトマネージャーであれば、アサインを決め、メンバーに工数を確認し、WBS(Work Breakdown Structure)などを作成する。開発者であれば、依頼された要件を元に、実現するために必要な工数を洗い出す。  


一気通貫スタイルであれば、大体こんな形ではないでしょうか？


私も請負でプロジェクトマネージャーやっていた時、出来上がった内容を元に開発完了時期の共有、毎週のように進捗報告を実施しながら、自分自身も開発していました。では、上手くいったか？と言うとそうでも無かったのが現実です。


なにが上手くいかなかったのか？


不確実な技術要素による遅延、横やりタスクによる遅延、コミュニケーションや設計ミスによる手戻り、そもそも的外れな見積もり…これらの遅延を取り戻すために、月80時間と言う果てしない残業が始まります。そして、頑張ってリリースしたところで、顧客の課題に紐づいていないことが原因で使われないモノが誕生します。


当時の私も、BtoC(Business to Consumer)サービスの開発でプロジェクトリーダーとしてなんとかやっていました。作ったモノは最終的に使われているかは分かりません。

== スクラムとの出会い


転機は別チームが始めたスクラムでした。最初は情報がなかったため、スクラムは一気通貫スタイルの繰り返しで、今までとの差は正直わかりませんでした。


「これ、いつまでにできますか？」


お馴染みの言葉もよく聞こえてた事もあり、余計に差が分かりませんでした。


数ヶ月すると話は変わってきます。


「これ、次のスプリントで対応できますか？」


「バーンダウンチャートがうまく下がってないですね。スプリントレトロスペクティブで見直しましょう」


使っている言葉が違う。バーンダウンチャート？スプリントレトロスペクティブ？


初めてスクラムに興味が湧き、本や勉強会に参加し始めました。スクラムの進め方、スクラムを通し仮説検証し不確実性なモノを確かなモノにするという考えを複数の本や勉強会で学びました。


ある程度スクラムを学んだ結果、スクラムは開発フレームワークではあるものの、単なるフレームワークではなく、組織論として扱うことが重要であると理解しました。


なぜ組織論にたどり着いたのか？理由は自己組織化にあります。


当時のスクラムガイド@<fn>{scrumguide2017}では、スクラムチームの構成は、下記のように表現されていました。

//footnote[scrumguide2017][スクラムガイド 2017年 @<href>{https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf, https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf}]


//quote{
    プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための 最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。
//}

チーム構成や機能横断型については容易にイメージできます。しかし、自己組織化はイメージすることが難しく、スクラムガイド内で7回も使われていましたが、どのような状態かわかりませんでした。自己組織化とはなんなのか？どのような状態なのか？Wikipedia@<fn>{wiki_selfmanagement}上では下記のように記載されています。


//quote{
    物質や個体が、系全体を俯瞰する能力を持たないのに関わらず、個々の自律的な振る舞いの結果として、秩序を持つ大きな構造を作り出す現象のこと。
//}

//footnote[wiki_selfmanagement][@<href>{https://ja.wikipedia.org/wiki/自己組織化, https://ja.wikipedia.org/wiki/自己組織化}]


どちらかと言うと物質などで用いられることの方が多いようで、スクラムに定義されている組織に置き換えるのは難しいです。しばらく自己組織化について調べると、「ティール組織」@<fn>{teal}に出会いました。特にこの中でも、ティール組織になるためのブレイクスルーが重要でした。

//footnote[teal][@<href>{https://www.amazon.co.jp/dp/B078YJV9ZW/, https://www.amazon.co.jp/dp/B078YJV9ZW/}]


ティール組織のブレイクスルーには、進化する目的、セルフマネジメント、ホールネスが重要になります。これらは、必要に応じて目指すビジョンを見直し、上下関係がなく、自身の強みを活かし、自分で考えて行動するというものです。


ティール組織のブレイクスルーが、スクラムガイドに書かれているスクラムチームに紐づいたのです。なので、私は、スクラムをすると言う事は、個で何かするのではなく、ティール組織のような状態にチームを育てる事だと言うことに繋がりました。


では、当時の状況はどうだったのか？所属組織はヒエラルキーの中、個々が機械のように動く組織だったため、ティールには程遠い状態だった為、何らかの形で変化させることが必要でした。

=== カイゼンから見直すチーム


「毎週ふりかえりしましょう」


この提案からカイゼンが始まりました。ふりかえりと言えばKPT(Keep Problem Try)が定番かもしれませんが、私自身がKPTでふりかえれる自信がなかった事もあり、最初はgood/badを挙げる事から始めました。


実際に始めてみると、goodが少なく、badに本番で「不具合が出た」などネガティブな内容が多かったです。しかし、チームメンバーそれぞれが持っている「仕様がわからない」などの疑問や困りごとが可視化され、課題を洗い出すことができたのです。


ここからは、少しづつカイゼンが始まります。


まずは、モヤっとボードを作成し、困ったことがすぐ共有できるようにしました。何かわからない事や気になったことがあった時に、付箋で貼り付け、朝会で確認するという内容です。


モヤっとボードにより、それぞれの持っている悩みが共有され、俗人化していた仕様などが共有されるようになりました。それだけではなく、毎週のふりかえり、モヤっとボードにより、コミュニケーションが生まれた事で、タスク状況の可視化が不足していることがわかりました。


そこで導入したのが物理カンバンです。タスク毎の付箋を用意し、Todo、Doing、Doneのステータス上に並べ、タスク状況を見えるようにしました。


朝会も物理カンバンの前に集まり、現在進行中のタスク共有をするようにしました。結果、実施すべきタスクの優先順位、割り込みタスク状況、課題点が確認し合えるようにようになりました。


そして、物理カンバンの効果としては、開発チーム以外にも良い影響がありました。それは、開発チームの実施しているタスク状況を、他のステークホルダー（サポートデスク、営業）にも理解していただける点です。


今までは、サポートデスクや営業からすると、お客様に説明しなくてはならないが、開発状況が見えないため、余計に質問する必要があったのです。
タスク状況が見えることで、余計な質問が減り、状況がわからないからこそイライラしてしまう状況が緩和されました。状況が見える事で、協力体制も生まれ、組織としてはとても良い結果となりました。

== 理想のプロダクトチームを目指しスクラムマスターに


カイゼンが進んだ結果、チームもスクラムを取り入れることになります。私はスクラムマスターに任命され、チームの支援を任されました。


チームがスクラムの流れを理解している状況だったため、チームメンバーがそれぞれが自己組織化されるように支援することと、CS（カスタマーサクセス）や営業メンバーなども巻き込み、プロダクトチームにする事がミッションでした。では、どのようにすれば、理想のプロダクトチームになるのでしょうか。様々な勉強会やチームビルディングを調べ、様々な施策を行います。


私が今まで実施してきた開発チーム向けの施策は下記の通りです。

 * スクラムイベントの設計と運用
 * スパイダーウェブ討論と1on1で会話と個人の強みを可視化
 * WorkingAgreementの策定によるチームルールの統一



そして、プロダクトチーム向けには、以下の施策を実施しました。

 * ワールドカフェ形式のディスカッション
 * 各チームのふりかえりミーティングの構築



結果、どうなったか？
施策それぞれの効果は小さかったと思いますが、何度も繰り返し実施した事で、責任が曖昧なチケットが生まれがちだったチームは、チームメンバーでしっかり拾えるようになり、ふりかえりでの発言も増え、自らカイゼンまでできるチームに成長しました。


プロダクトチームとしても、開発チームとCSや営業と繋げた事で、それぞれの状況理解が進み、開発チームが責められることが目立っていたプロダクトチームでしたが、同じ目的に向かって共に動くことができるプロダクトチームに成長しました。


スクラムを通して、透明性・検査・適応が進み、開発チームだけでなく、プロダクトチームが、個人との対話、ビジネスと開発の協調、変化への対応とアジャイルな形に近づけたと感じています。

== アジャイルのススメと注意点


「これ、いつ頃対応できるんでしたっけ？」


「優先度とベロシティ的には、2スプリント後ですね。優先順位変える必要ありますか？」


「そうですね、結構お客様の温度感高くて。」


「お客様の温度感高いんですね。プロダクトオーナーに相談してみます。」


スクラムであれ、お客様からすると要望がいつ叶うのかは重要な情報です。しかし、アジャイルなチームになった事で、対話が増え、相互理解も深まったため、内容が顧客思考に変わりました。


一つ追加でお伝えすると、うまくいったのはプロダクトチームとして組織改善できたからだと思っています。今、プロダクトマネージャとして、新しくアジャイルでない環境に入って感じているのが、開発チームだけがアジャイルになったとしても、ステークホルダーがアジャイルを理解できていないと、溝が生まれ、その溝を埋めることで忙しくなり、最終的に厳しくなります。


アジャイルなチームになることはとても素晴らしいと思いますし、不確実なプロダクト開発であれば必須だと思います。プロセスだけでなく、組織の考えを、少しずつで良いので変えることが重要だと思います。

　

//embed{
    \begin{minipage}{.1\linewidth}
        \centering
        \includegraphics[width=.75\linewidth]{images/chap-shimazaki/junsora.jpg}
    \end{minipage}
    \begin{minipage}{.89\linewidth}
        島崎純一 @junsora https://twitter.com/JuKoA453\\
        \end{minipage}
    \hspace{1ex}
//}

プロダクトマネージャ&スクラムマスター ◀︎ スクラムマスター ◀︎ DevOps 人を知り、チームでプロダクトを作る中、社内企画を通し、組織を作る人。