形だけスクラムを導入してもうまくいかず、そのまま形骸化してしまうケースをよく見かけます。
スクラムが生まれた背景や過去のソフトウェア開発との違いを知っておくことでスクラムイベントの意味をより深く理解できると考え、個人的に抑えておきたいことをまとめてみました。
アジャイルマニュフェスト
アジャイルマニュフェスト1は、ケント・ベックを始めとして当時アジャイル型開発において権威のあった17人が集まり、それぞれの開発手法の中で重要な原則を文書としてまとめたものです。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
特に有名なのは上記の文章ですが、大事なのは左側の価値も認めた上で右側のことがらを重視するということです。
最近はあまり聞かなくなりましたが、アジャイル開発ではドキュメントを書かなくても良いという誤解はここから来たものと考えられます。
予測主義と経験主義
予測主義とは、未来は知識に基づいて予測可能であるという考え方です。
ウォーターフォール型の開発プロセスは予測主義に基づいており、予め立てた見積もりや計画に沿ってプロジェクトが進むことを前提としています。
経験主義とは、実際に経験した事実(以後経験的事実と呼ぶ)と既知の事実による判断によって知識が獲得できる。逆に言えば未来は経験に基づいてしか予測できないという考え方です。(ここで言う経験とは、チームでの成功失敗の実体験や仮説検証における実験観察の結果などを指す)
アジャイル型の開発は経験主義に基づいており、反復的・漸進的なプロセスを繰り返すことによって予測可能性をコントロールします。
スクラムでは、特にチームとしての経験的事実を重視します。2
たとえメンバーの誰かが特定の知識や技能を持っていたとしても、チーム構成が変わればベロシティはリセットされるし、新しいメンバーが増えれば学習コストが発生します。
ある機能を作るためにどのような工程が必要で、どれくらいの期間がかかるのか、作ったものがユーザにどのように受け入れられるのかは、スクラムのセレモニー(スプリントプランニングやスプリントレトロスペクティブ等のスクラムイベント)を通じてスクラムチームとしての経験的事実を蓄積することが重要です。
不確実性マネジメント
「エンジニアリング組織論への招待」3でも触れられているように、ソフトウェア開発を成功させる重要な要素として不確実性のマネジメントがあります。
不確実性と一口に言っても、マーケット不確実性や技術的不確実性など様々なものがあり、エンジニアリング組織論への招待では不確実性を以下の3種類に分類しています。
- 通信不確実性
- 目的不確実性
- 方法不確実性
ウォーターフォール型の開発は方法不確実性にフォーカスしたアプローチで、要件定義や基本設計、詳細設計、変更プロセスを厳密に定義することで不確実性をコントロールしようとしています。
これに対してスクラムは通信不確実性や目的不確実性にフォーカスしており、デイリースクラムやカンバンによる見える化、スプリントプランニング等を通じてこれらの不確実性をコントロールしようとしています。
通信不確実性
通信不確実性(コミュニケーション不確実性)は、ある情報が別の人・組織に正しく伝わるかどうかの不確実さを表します。
通信不確実性は、用語やプロセスを定義することである程度減らすことができます。
例えばスクラムであれば、いつまでに誰が何をやるのかはストーリー、カンバンといったツールで定型化できる他、受け入れ条件やDoneの定義を用いることで達成基準を満たしていることを保証することができます。
目的不確実性
目的不確実性は、ある成果がマーケットやユーザのニーズを満たすかどうかの不確実さを表します。
目的不確実性は仮説検証を繰り返すことでしか減らすことができませんが、ユーザーインタビューやユーザーペルソナの作成などでスモールに始めることは可能です。
また、計画段階(スプリントプランニング)であれば、Why/Whatにフォーカスして本当にユーザが必要としているものを明確にすることで、目的不確実性が高いものを作るリスクを小さくすることができます。
方法不確実性
方法不確実性は、目的を達成する手段が適切かどうか、実現可能かどうかの不確実さを表します。
例えばユーザの行動データをバッチ処理でDBに保存しようとしたときに、いざ実装を始めてみるとバッチサーバとDB間の通信で問題があったり、運用を続けたときにDBのキャパシティの問題が発生したりします。
これらの不確実性をどのタイミングでどれだけ減らすかは議論の余地がありますが、不確実性が存在することをチームが認識することと、どこまで不確実性を許容するかをチームが合意してることが重要です。
仮説思考
「仮説」とは読んで字のごとく仮の答えであり、「まだ証明はしていないが、現在もっとも答えに近いと思われる答え」のことを指します。4
経験主義や目的不確実性の項でも述べたように、ある機能やプロダクトがマーケットやユーザのニーズを満たすかどうかは、仮説検証を積み重ね、経験的事実に基づいて判断するしかありません。
仮説思考は、プロダクト開発初期のような限定的な情報しか持たない状況において、最も確からしい「仮の答え」を導き出す考え方を指します。
経験主義と仮説思考を活かすためには、具体的な経験的事実を得ることが重要です。
Google Analyticsやユーザインサイト等のツールを使い、数値化された事実を元に新たな仮説を構築することで、より精度の高い仮説検証を行うことができます。
リーン思考
3つのM
トヨタ生産方式で知られる3M(またはダラリ)として「ムダ」「ムラ」「ムリ」があります。
- ムダ
- 目的 < 手段、または負荷 < 能力である状態
- 付加価値を高めない現象や結果
- ムラ
- 目的/負荷が手段/能力より大きかったり小さかったりする状態
- 仕事の品質が一定でない
- ムリ
- 目的 > 手段、または負荷 > 能力である状態
- 生産性の低下、欠陥の発生につながる
トヨタ生産方式では更にムダを7つのムダ(作りすぎのムダ、在庫のムダ、加工のムダ、動作のムダ等)に分類し、ムダを徹底的に排除することで生産性を改善します。
リーン生産方式
リーン生産方式/リーンソフトウェア開発はトヨタ生産方式を研究して生み出された考え方で、トヨタ生産方式と同じく「ムダの徹底排除」を根底に「ジャスト・イン・タイム(必要になるまで作らない)」「自動化(自働化)」を大きな柱としています。
MVP
MVPとはMinimum Viable Productの略で、顧客に価値を提供できる最小限のプロダクトのことを指します。
リーンソフトウェア開発ではMVPを利用することで、最小限に素早くビジネス価値を検証することができます。
リーンソフトウェア開発における考え方はアジャイルと重複する部分もありますが、スモールスタートや小さく失敗するという考え方は現代のソフトウェア開発では特に重要なため、抑えておいて損はないと思います。
心理的安全
Google re:Work5によれば心理的安全は以下のように定義されています。
心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。心理的安全性の高いチームのメンバーは、他のメンバーに対してリスクを取ることに不安を感じていません。自分の過ちを認めたり、質問をしたり、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余地があります。
スクラムの5つの価値基準に取り入れられている、確約（commitment）・勇気（courage）・集中（focus）・公開（openness）・尊敬（respect）の中でも、公開や尊敬として心理的安全な振る舞いが重要であることが伺えます。
馴れ合いと心理的安全は混同されがちですが似て非なるものです。
必ずしも和気あいあいとしている必要はなく、プロフェッショナルとして互いに意見しあったり助け合ったりすることができることが重要です。
「チームの心理的安全性」という概念を最初に提唱したエイミー・エドモンソン氏は、心理的安全を高めるために今すぐ始められる取り組みとして以下の3つを上げています。
- 仕事を実行の機会ではなく学習の機会と捉える。
- 自分が間違うということを認める。
- 好奇心を形にし、積極的に質問する。
アジャイルと設計
「Inspired: 顧客の心を捉える製品の創り方」6によると、アジャイルの源流は顧客向けの特注ソフトウェアを開発するために生まれたとあります。
そのため、既に完成したソフトウェアをカスタマイズして如何に顧客のニーズを満たすかという点にフォーカスしており、ユーザエクスペリエンスデザインやアーキテクチャデザインをアジャイルの中でどのように運用するかについては深く言及されていません。
実際にスクラムを運用してみても、アーキテクチャデザインを行うためにスプリントゼロやスパイクスプリントといった特殊なスプリントを設けたり、デザイナと協調してプロトタイプやインタラクションデザインを行う際は独自のルールを考える必要があります。
スクラムを導入する際には自分たちのメンバー構成や開発フェイズも踏まえてこれらをどう運用するかを慎重に検討しましょう。
まとめ
今まで色々なチームでスクラムを導入した経験を踏まえて、最低限これだけは抑えておきたいという点をリストアップしてみました。
まだまだ粗いところがあるので、今後もブラッシュアップしていきたいと思います。
予測主義・経験主義のあたりは原典が見当たらなかったりふわっとしてたりするので、ご意見・ご指摘あればよろしくお願いしますm(_ _)m