前回、計画駆動型開発手法（通称ウォーターフォールモデル型開発手法）の問題点を説明した。そして「将来を予測できなくても良い」「欲しいものが最初からわからなくても良い」「開発者の厳密な開発能力がわからなくても良い」というなんだか夢のような開発手法を目指したのがアジャイル開発手法である、という旨の期待を煽った形で締め括った。
なんだか一見、「何にも分からなくても良い」とも受け取れてしまいそうであるが、逆に「何を分かっていなくてはならないのか？」について答える形でアジャイル／スクラム開発を成功させるための考え方について説明してみようと思う。
それは
『システム思考』+『デザイン思考』+『認知科学』
というものである。
システム思考
まずは『システム思考』という考え方について分かっておくととても役に立つ。
『システム・ダイナミクス』という経済・社会・自然環境などの複雑なフィードバックをもつシステムを解析し望ましい変化を創り出すための理論から、コンピュータを使用する複雑な数学の部分を省いたものが『システム思考』である。
『システム思考』とは、「様々な事象を相互に関連したシステムとして捉える概念」であり、物事を単体として見るのではなく、相互の関連や関係性に着目し、静止的ではなく動的に、断片的ではなく全体的に、そして変化を捉える見方である。
単純な原因と結果という見方ではなく、構造や変化のパターンを捉えることによって、システム全体に大きな影響を及ぼす、（通常は隠れている）レバレッジポイントを探り、現実に対応するモデルを描いてシステムの構造の修正を試みる。
スクラム開発において特に参考にできるものは「挙動は構造に従う」というものである。システム思考においては構造が重要であり、見えやすい出来事や結果を単独で表層的に捉えるのではなく、全体像をさまざまな要素のつながりをもつ構造として理解するのである。スクラムでは「スプリント」という期間単位で開発をしていく。これはループを作っているのであり、開発し出荷した製品増加分に対するユーザーレビューが次のスプリントの開発の判断に影響を及ぼす。スクラム開発の構造について言えば、例えば、1スプリントにかける設定期間を長くするほど、ユーザーからのフィードバックは遅れることになり、現実に起こっている問題と、製品の問題解決にズレが生じやすくなり、そのズレが取り戻せないほどに累積してしまう事態を生み出す可能性は高まる。
そして開発するプロダクトの機能を考える時も、システム思考は役に立つ。インクリメンタルに開発をし、どんどん機能を追加してリリースしていくことを目指すが、システムとしての全体性を考えながら、そのシステムとしての最も重要な機能から開発しリリースすることを狙う。この場合、システム全体を単に分解しバラバラに切り離した部分として考えるのではなく、あくまでそれら機能も全体性をもった小システムとして捉えて設計・開発を行い、リリースしていく。
システムとしての全体性を何も考えずにただ機能を追加することしか考えなかった場合、全体性を損ねてしまう事態を招く可能性が高い。リリース後（あるいはユーザーレビュー時）にシステムとしての全体性を損ねていることが分かった場合は、次のスプリント以降でシステムとしての全体性を実現できるように修正をする。システムとしての全体性を維持・強化しながら段階的に機能追加をしていくので直線的な機能追加をするのではなく、蛇行運転しながら回りくどく開発していくような感覚に陥ってしまい非効率な開発になってしまっているのではと感じる場合もあるかもしれないが、システムの全体性が損なわれた場合は大きなタイムラグの後に挙動となって現れる場合がありその場合は修正が大幅に遅れるので、やはりシステムの全体性を捉え維持しながら機能追加した方が結果的には効率が良い。
デザイン思考
次にデザイン思考でスクラム開発に役に立つのは以下の段階的な考え方である。
(1) 共感 (Empathise) - ユーザーの行動を理解し、寄り添い、何が問題なのかを見つける
(2) 定義 (Define) - ユーザーのニーズや問題点、みずからが考えることをはっきりさせる
(3) 概念化 (Ideate) - 仮説を立て、新しい解決方法となるアイデアを生み出す
(4) 試作 (Prototype) - 問題に取組み始める
(5) テスト (Test) - 検証こそが解決方法これら(1)から順番に連続的になされるのではなく、5つの段階は同時に行われたり、互いに影響したり、行ったり来たり、繰り返したりするのであって、順番にプロセスをたどらなければならないということではない。連続した手順ではなく、問題を解決するための包括的な考え方である。ユーザーの行動の観察によって新しい解決方法を見出し、試作（プロトタイピング）し、検証するのである。
つづく
