アジャイルとスクラムについて
ソフトウェア開発に限らずアジャイルを組織やプロジェクトのマネジメントに活用している会社が多くなってきている。
変化を前提としていないと時流に対応できないという一般的なビジネスの流れに対して、不確実性の高い複雑な領域であるソフトウェア開発やプロジェクトマネジメントに用いられてきたアジャイルプロセスが経営的なプロセスでも実践されてきているらしい。
日本でもそのような企業は存在するのだろうか？
アジャイル、そしてその中の一つの手法であるスクラムについて説明をしてみたい。
個人的な観点のため、偏った説明になるのはご容赦いただきたい。
アジャイルソフトウェア開発宣言
ソフトウェア開発に関するベストプラクティスを、旧来の開発の問題点を様々な方法で改善しようと取り組んでいる有名エンジニアが集まって考えた。
「このやり方がいい、あのやり方がいい。」
結論は出ず、宣言だけが採択された。
宣言とその背景にある原則を忠実に読み込めば、最終的に顧客がほしい「有益なプロダクト」をつくるためには、「動くプロダクトを見ながら常に顧客と対話して、その時々に発生する必要な変化に向けて一緒に戦う。」ということが書かれていることがわかる。
アジャイルソフトウェア開発宣言の「左と右」
アジャイルソフトウェア開発宣言では左に旧来のやり方の特徴、そして右にアジャイルで実現したい特徴が書かれている。
旧来のやり方を否定するのではなく、目的のために最速な手段を右側に書かれているもので見つけてやっていこうという感じになっている。
左に書かれていることを疎かにするとアジャイルに詳しい人に怒られる。
左：プロセスやツールよりも 右：個人と対話を
取り決めやマニュアルに書かれている手順通りツール、プロセス、プロトコルを守る、ということよりも何か変化が必要なのだったら直接対話しましょう。
ただし対話はSlackなどのチャットツールのこともあるのだから、ツールを重視しないというわけではない。
左：包括的なドキュメントよりも 右：動くソフトウェアを
プロダクトについての全ての内容をドキュメントとして起こすと（例えばExcelでつくってそれをプリントアウトする）、キングジムのバインダーに途方もない量の紙が挟まれたものが何冊か用意される。
そしてそれは、殺人バインダーとよばれる。
ちょっとしたカイゼンの修正をするたびに、そのドキュメントを書き直すというのが本当にほしい価値だろうか？
ただし、ドキュメントを書かないというわけではない。
検索性のあるツールを使って、開発の段階から必要な内容を書いていくのが普通。
必要であればマニュアルなどを後追いででもつくる。
左：契約交渉よりも 右：顧客との協調を
有益なコントラクトはとても大事。ただし、本当にいいコントラクトならば顧客と協調できるはず。
プロダクトをつくることに対して顧客を巻き込めるかどうかが、本当にいいプロダクトを作れるかどうかの分岐点になる。
左：計画に従うことよりも 右：変化への対応を
反例として「分析・設計・開発・テストと３ヶ月ごとなど長期的なスパンで計画を区切って、テストの段階で分析が問題だったことがわかったけど計画にはないのでもどれない」みたいな状況を作らないということ。
変化が常に発生する前提のフィードバックループが大事である。
ただし、計画を立てないとそもそも目標がどこにあるのかわからないのでループを回して進む方向がわからなくなる。
スクラムについて
アジャイルソフトウェア開発宣言の前後の流れとして生まれたものの一つがスクラム
スクラムは軽量な開発プロセスのフレームワーク。基本的にはチーム開発のためのもの。
アジャイルソフトウェア宣言に則しており、シンプルで「特定領域にしか当てはまらない」ということがないため、アジャイルの主流になってきた。
スクラムの特徴
リリースなどの価値提供を短いスパンで行い続ける、フィードバックループが基本
大きな計画を立てて最後に一斉にアウトプットするのではなく、常にアウトプットし、「フィードバックループ」で軌道修正し続けながら価値提供を行う。
スクラムの原則
スクラムの原則は、透明性・検査・適応の3本柱に支えられている。
透明性
フィードバックループで重要なのは透明化・つまり見える化されていること。
特に結果責任を持っている人、要するにお金を出す決定をする(執行役員などの)責任者に対して見える化されていること。
スクラムは透明化に対する【仕組み】が組み込まれているチーミングフレームワークである
検査
フィードバックするためには、作成物や進捗を検査し、「カイゼン」が必要なものを見つけないといけない
ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。
あくまでチーム単位で行い、最大限の効果のある改善ポイントを見つけ出す。
適応
検査で見つけた不備について、「カイゼン」が必要な場合にはプロセスやプロダクトの構成要素を調整する必要がある。
「カイゼン」はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
スクラムは検査と適応に対する【イベント】が組み込まれているチーミングフレームワークである。
アジャイルやスクラムで何が生まれるか？
素早い価値提供・素早い学習
ただし、開発プロセスが高速化してもインプットするものがだめだと、高速にゴミが量産されることになる。
というのが売り文句なんだけど、副作用としてチームでの働きやすさを提供してくれる。
働き方ディバイドやコミュニケーションのロスがイベントや仕組みで軽減される。
チームがチームとして透明性やカイゼンを考える頭を持つようになれば、お金出す人としては権限委譲がしやすい。
（IT系の）エンジニアは尖っていたり、コミュニケーション嫌いだったりすることが多いわけだが、結果としてこっちのほうがうまく行くと納得するルールであれば守りやすい。
こうしたことはエンジニアに限らずチームやプロジェクトの進め方の問題だし、構成員の複雑性や多様性が増す社会の中では経営的な視点でも活用できる。
