株式会社ギガスリート大垣です
これから何回かに分けてこのアジャイル開発について解説をする動画をアップしていきたいと思います
私がなぜこのアジャイル開発について解説をする動画をアップしようと思ったと言いますと 非常に誤解の多いこの開発プロセスで、ただ導入するだけではすぐにうまくいくという事例がなかなかないのが現状でして、私は最近では開発をうまく成功させたいというそういったニーズに対してコンサルティング、コーチングをプロジェクトに参画するという形で支援するというお仕事を引き受けてきました。
その中でたくさんのことがわかったんですけれど、そうしたわかったことをこの動画を通じて皆さんにお届けすることでもし皆さんが今アジャイル開発をやっていて何か悩まれている、あるいはスクラム開発をやっていて「もっとうまくやれるんじゃないか」っていうそうした期待、そういったことがこの動画の中で、何か得られたことを皆さんのプロジェクトの成功と助けになればと思いますので、ぜひこの動画の中で得られたことを現場で活かしていただければと思います。
早速ですけれども「計画駆動」と「アジャイル」と何が違うかといいますと細かなことを言いますと本当にありとあらゆる事が違うので、これだけに絞って一つだけ 何か重要な点方を挙げろと言われますと、私は「予測に対する態度」、ここが一番違うと考えています。
ウォーターフォールモデルではこの予測というのは絶対的なもので、予測を基に計画を立てます。
そしてこの計画を予測に対して確実に結果を得られるように入念に練り上げた計画を作るんですけれども、それをそのまま計画通りに実行するということを考えます。
そしてその計画通り実行した結果、そのソフトウェアがユーザーに価値をもたらすであろうということを着たりした流れになっています。
これらはすべて次のステップにパスし続けますので、基本的に前のステップに戻るということは原則的に認めてません。
ただまぁ実際の現場では戻るということもまぁ妥協としてあり得ますので、あくまでもウォーターフォールモデルが考えている 流れとしては一方向しか認めていないという意味で、これはウォーターフォールモデルに対しての解説になります。
この場合のこの予測はかなり特殊な予測なんですね。私はこれを まるで天気予報みたいですので、『天気予報型』と呼んでいます。
いわばその予測が、その結果に対して予測をすることあるいは予測によって得られた何かしらの情報、わかったことを何かに使ってとしても結果を変えることはないというスタンスですね。
例えば天気予報だと雨を予報したとして、じゃあ「明日雨になります」となってですね皆さんが一斉に傘を準備して、で実際雨が降りそうだっていう時に傘を持ち出したとしますね。
街を見ると誰が傘を持っている状態ですけれども、それだったとしても天気が晴れるかというと晴れないですね。天気は変更されません。これが天気予報型です。
予測をすることと結果に関しては影響はない、と考えるのは天気予報型なんですけれども、実際私たちが生きているこの世界は、ほとんどがこの天気予報型を使う形で予測できるものではないんですね。
ほとんどが実は、予測をしてその予測後に得られた情報を何かに持ちようとした時点で実は結果に影響を与えてしまうという、そういったものなんです。
このアジャイルではじゃあどういうものかというとこの予測は『株価予想型』です。
これはどういうことかと言いますと、例えば有名なアナリストが「A社の業績が良かったです」と分析をして影響力のある媒体で A社の業績に対して発表したとします。そしてそこに「A社の株は上がるでしょう」という予測を付け加えます。
するとそれを見た人たちが一斉にA社の株をもし買いに走った場合、実際にA社の株は上がってしまいます。
いわば予測をしてその予測用いたことによって結果が影響を受けてしまう、それがこの『株価予想型』になります。
ソフトウェアビジネスにおいてソフトウェアを作って、それをユーザーが使い始めたときにユーザーの業務が変化します。それはソフトウェアが価値をもたらした結果であって、逆に言えばソフトウェアを導入したことによってユーザーの業務が一切変わらないとしたらそれはそのソフトウェアに価値はないということですから、ソフトウェアに価値がある場合は必ずユーザーの業務は効率化されたり
良い方向に向かうはずです。変化をするわけですね。
するとその変化がユーザのビジネス環境、あるいは業務を行っている、より大きな意味でのシステムは変更されます。
それによって別の箇所に歪みが発生したりあるいは新たなビジネスニーズが生まれたりするわけですね。
するとそれによって当初考えていた予測が外れるということが起こります。あるいは当初の予測が変更を加えられるとなりますので、常に予測というのは結果に対して影響を与えているということを理解する必要があります。
それがアジャイルの基本スタンスです。
ですのでウォーターフォールモデルでは予測からスタートしていきましたけれども、アジャイルの場合は予測からスタートしません。
予測はしますけれども予測を完全に練り切った上で行動しようではなく、まずは『実行』します。『実行』によって『結果』が生まれますから、ユーザーに対する価値が生まれたのか、あるいは業務に変更が入ったのか、その価値を『観察』します。そしてその『観察』によって得られた情報から『学習』します。
このあたりでウォーターフォールモデルとかなり形が変わってきますね。
この『学習』によって得られた情報をもとに『予測』を立てます。その『予測』から『計画』を立てます。そしてまた『実行』して、というループを繰り返すんですけれども、『学習』によって『予測』をした場合、もともとの当初の立てていた『予測』とその後の2度目のループで学習したことによって得られた『予測』というのは変わってきますから、変更を加えるわけですね。いわば変化をここで取り入れます。
実際の予測がどのようだったかに拘らず、結果を重視して「実際にどうなのか」、「現実の世界はどうなのか」に対してフィットせようというのが、アジャイルの考え方です。
ですから、1年後の株価を予想して何かを行動に起こそうというよりは、今この瞬間 現実はどうなのかというのを最重要視して結果、あるいは今残っている現実 、あるいは実績そういったものから開発する予測計画というのを組み立てていく、というのが アジャイルの仕組みになります。
この予測に対する態度が 計画駆動型とアジャイルでは大きく基本スタンスが異なります。
それによって、計画駆動型は天気予報型の予測であるにも関わらず、そうではないソフトウェアビジネスにそれを適用しようとしてしまっている時点で、色んなところに 歪みが生じるんですね。
ですからウォーターフォールモデルが、単にうまくいかない、あるいは失敗する、あるいは納期に間に合わない、あるいは予算内に収まらない、あるいは品質が担保できない 、ビジネス要件の変更に対処できない、というこれらの問題の多くは実はこの予測に対する態度、天気予報型を用いてしまっている、というところにあります。
このアジャイルではこの開発フローだけで対処できるかというと、実は このアジャイルにも欠点があります。
それは何かと言うと『全体性を損ね易い』ということですね。
特にスクラムでは「スプリントという期間に区切って小さく早く作りましょう」「ユーザーがすぐ使えるものを提供しましょう」という基本スタンスですから、作るものは なるべく小さく早く作る、そしてユーザーのフィードバックを受ける、それを第一優先度においてどんどん作り始めるわけですけれども、システムというのは絶対性が重要ですから、部分としては完成して、機能が提供できてユーザー使えるものができたとしても、それらを 組み合わせていく過程で 、あるいは組み合わせた結果、システムとしても全体としては当初期待していた挙動とまったく違う挙動になってしまうとかでですね。 あるいは、ある特定の条件下においてはうまく挙動するんだけれども、少し特殊な状況、あるいは当初想定していなかったパターン、シチュエーションでは全く予測していなかった挙動になってしまうということがシステムというのは往々にしてあります。
逆に言うとそれがシステムの特性でありシステムとしての価値ではあるんですけれども、それらをこのアジャイルでは見失いやすいんですね。
ですからこのアジャイルはさらに組み合わせる必要があります。この全体性をいかに損なわないかという視点が重要になってきます。
それらをどのように全体性を損なわないようにすればいいのか。
私はこのアジャイルをするチームにコーチングする際にいくつかのポイントをレクチャーすることにしています。
まずはシステム思考。
そしてリスク管理。
そして全体性を常に把握し続けるというのはなかなか難しいですから、モデリング。これらで全体性を常に視野に入れておく方法をレクチャーします。
そして認知科学。特に社会心理学ですね。
これらの知識を私はチームに対して教えるようにしています。いきなり全部はさすがに注入しませんけれども、必要なタイミング必要なサイズでうまく適宜 これらも知識を教えるようにしています。実際にそれをどうすれば上手く使えるツールとして形にできるのかというのを手本を見せたりしながらそのプロジェクト、プロジェクトの状況に対して、いろんな形で提供することになりますけれども、こうしたことを行っていきます。
これから何回かに分けて公開するつもりの動画ではこういったことも触れて、その具体的なツールとしてどう用いればいいのかというのも紹介していきたいとおもいます。
次回はスクラムボードについてお話をしたいなと思っています
スクラムボードは一応形式として非常にわかりやすくシンプルなものなんですけれども、うまく使うともっと強力なツールとして用いることができますし、スクラムではですねあのスクラムボードは基本ですから1番目のつくところにあるようになります。
ですからあのスクラムボードをうまく活用することでチームの生産性を上げたり、あるいは システムとしての完成度を高めたり、プロジェクトの成功をより確実にしたり、そういったことを スクラムボードでできるんじゃないかなと思いますので次回はそのスクラムボードについて紹介してきたいと思います。
