記事一覧

成功するアジャイル開発#1「計画駆動と アジャイル の違い」 ソフトウェア開発 スクラム scrum agile システム開発 kanban agile coach project manager

YouTube 動画
アジャイル開発によってソフトウェア開発プロジェクトの成功確率が向上しました。 しかしその本質を理解しないまま見かけだけのアジャイル開発を始めてしまうとプロジェクトの失敗確率はかえって上がってしまいます。 そうした誤解の多いアジャイル開発について、その本質に迫りながら、具体的な手法の参考を示し、皆さんのアジャイル開発を成功に導く助けになればと思います。 効果的なアジャイル開発によって皆さんのソフトウェア開発を成功させましょう! 「成功するアジャイル」が本になりました!▼ 【フル版】全10章完全収録 https://www.amazon.co.jp/dp/B08X6MR9FP 【エッセン
文字起こし

株式会社ギガスリート大垣ですこれから何回かに分けてこのアジャイル開発について解説をする動画をアップしていきたいと思います私がなぜこのアジャイル開発について解説をする動画をアップしようと思ったと言いますと非常に誤解の多いこの開発プロセスでただ導入するだけではすぐにうまくいくという事例がなかなかないのが現状でして

私は最近では開発をうまく成功させたいというそういったニーズに対してコンサルティング、コーチングをプロジェクトに参画するという形で支援するというお仕事を引き受けてきましたその中でたくさんのことがわかったんですけれど

そうしたわかったことをこの動画を通じて皆さんにお届けすることでもし皆さんが今アジャイル開発をやっていて何か悩まれているあるいはスクラム開発をやっていて「もっとうまくやれるんじゃないか」っていうそうした期待、

そういったことがこの動画の中で、何か得られたことを皆さんのプロジェクトの成功と助けになればと思いますのでぜひこの動画の中で得られたことを現場で活かしていただければと思います早速ですけれども計画駆動とアジャイルと

何が違うかといいますと細かなことを言いますと本当にありとあらゆる事が違うのでこれだけに絞って一つだけ 何か重要な点方を挙げろと言われますと私は後予測に対する態度ここが一番違うと考えていますウォーターフォールモデルではこの予測というのは絶対的なもので

予測を基に計画を立てますそしてこの計画を予測に対して確実に結果を得られるように入念に練り上げた計画を作るんですけれどもそれをそのまま計画通りに実行するということを考えますそしてその計画通り実行した結果

そのソフトウェアがユーザーに価値をもたらすであろうということを着たりした流れになっていますこれらはすべて次のステップにパスし続けますので基本的に、前のステップに戻るということは原則的に認めてませんただまぁ実際の現場では

戻るということもまぁ妥協としてあり得ますのであくまでもウォーターフォールモデルが考えている 流れとしては一方向しか認めていないと言う意味ですこれはウォーターフォールモデルに対しての解説になりますこの場合のこの予測はかなり特殊な予測なんですね私はこれを まるで天気予報みたいですので

天気予報型と呼んでいますいわばその予測がその結果に対して予測をすることあるいは予測によって得られた何かしらの情報、わかったことを何かに使ってとしても

結果を変えることはないというスタンスですね例えば天気予報だと雨を予報したとしてじゃあ「明日雨になります」となってですね皆さんが一斉に傘を準備してで実際雨が降りそうだっていう時に傘を持ち出してもしますね

街を見ると誰が傘を持っている状態ですけれどもそれだったとしても天気が晴れるかというと晴れないですね天気は変更されませんこれが天気予報型です予測をすることと結果に関しては影響はない

と考えるのは天気予報型なんですけれども実際私たちが生きているこの世界はほとんどがこの天気予報型を使う形で予測できるものではない んですねほとんどが実は予測をしてその予測後に得られた情報を何かに持ちようとした時点で実は結果に影響を

与えてしまうと言うそういったものなんですこのアジャイルではじゃあどういうものかというとこの予測は

株価予想型ですこれはどういうことかと言いますと例えば有名なアナリストが「A社の業績が良かったです」と分析をして影響力のある媒体で A社の業績に対して発表しますそしてそこに「A社の株は上がるでしょう」という予測を付け加えます

するとそれを見た人たちが一斉にA社の株をもし買いに走った場合実際にA社の株は上がってしまいますいわば予測をしてその予測用いたことによって結果が影響を受けてしまうそれがこの株価予想型になりますソフトウェアビジネスにおいてソフトウェアをつくってそれをユーザーが使い始めたときにユーザーの業務が変化しますね

それはソフトウェアが価値をもたらした結果であって逆に言えばソフトウェアを導入したことによってユーザーの業務が一切変わらないとしたらそれはそのソフトウェアに価値はないということですからソフトウェアに価値がある場合は必ずユーザーの業務は効率化されたり

いい方向に向かうはずです変化をするわけですねするとその変化がユーザのビジネス環境、あるいは業務を行っている より大きな意味でのシステムは変更されますそれによって別の箇所に歪みが発生したりあるいは新たなビジネスニーズが生まれたり するわけですね

すると それによって当初考えていた予測が外れるということが起こりますあるいは当初の予測が変更を加えられるとなりますので常に予測というのは結果に対して影響を与えているということを理解する必要がありますそれがアジャイルの基本スタンスです

ですのでウォーターフォールモデルでは予測からスタートしていきましたけれどもアジャイルの場合は予測からスタートしません予測はしますけれども予測を完全に練り切った上で行動しようではなくまずは基本的な スタンスはまず実行します

実行によって結果が生まれますからユーザーに対する価値が生まれたのかあるいは業務に変更が入ったのかその価値を観察しますそしてその観察によって得られた情報から学習します

このあたりでウォーターフォールモデルとかなり形が変わってきますねこの学習に売って得られた情報をもとに予測を立てますその予測から計画を立てますそしてまだ実行して、というループを繰り返すんですけれども

学習によって予測をした場合もともとの当初の立てていた予測とその後の2度目のループで学習したことによって得られた 予測というのは変わってきますから変更を加えるわけですねいわば変化をここで取り入れます

実際の予測がどのようだったかに拘らずこの結果これを重視して実際にどうなのか 、現実の世界はどうなのか、に対してフィットせようというのが、アジャイルの考え方ですですから1年後に株価を予想して何かを行動に起こそうと言うよりは

今この瞬間 現実はどうなのかというのを最重要視して結果、あるいは今残っている現実 、あるいは実績そういったものから開発する予測計画というのを組み立てていくというのが アジャイルの仕組みになりますこの予測に対する態度が 計画駆動型と

アジャイルでは大きく基本スタンスが異なりますそれによって計画駆動型は天気予報型の予測であるにも関わらずそうではないソフトウェアビジネスにそれを適用しようとしてしまっている時点でいろんなところに 歪みが生じるんですね

ですからウォーターフォールモデルが単にでうまくいかない、あるいは失敗するあるいは納期に間に合わない、あるいは予算内に収まらない、あるいは品質が担保できない 、ビジネス要件の変更に対処できない、これらの問題の多くは実はこの予測に対する態度、天気予報型を用いてしまっている、というところにありますこのアジャイルではこの開発フローだけで対処できるかというと

実は このアジャイルにも欠点がありますそれは何かと言うと『全体性を損ね易い』ということですね特にスクラムでは「スプリントという期間に区切って小さく早く作りましょう」「ユーザーがすぐ使えるものを提供しましょう」という基本スタンスですから作るものは なるべく小さく早く作る、そしてユーザーのフィードバックを受けるそれを第一優先度においてどんどん作り始めるわけですけれども

システムというのは絶対性が重要ですから部分としては完成して、機能が提供できてユーザー使えるものができたとしてもそれらを 組み合わせていく過程で 、あるいは組み合わせた結果システムとしても全体としては当初期待していた挙動とまったく違う挙動になってしまうとかでですね

あるいは、ある特定の条件下においてはうまく挙動するんだけれども少し特殊な状況、あるいは当初想定していなかったパターン、シチュエーションではまったくして予測していなかった挙動になってしまうということがシステムというのは往々にしてあります逆に言うとそれがシステムの特性でありシステムとしての価値ではあるんですけれどもそれらをこのアジャイルでは見失いやすいんですね

このアジャイルはもう一つ組み合わせる必要があるこの全体性をいかに損なわないかという視点が重要になってきますそれらをどのように全体性を損なわないようにすればいいのか私はこのアジャイルをするチームにコーチングする際にいくつかのポイントをレクチャーすることにしています

まずはシステム思考そしてリスク管理そして全体性を常に把握し続けるというのはなかなか難しいですからモデリングこれらで全体性を常に視野に入れておく方法をレクチャーします

そして認知科学特に社会心理学ですねこれらの知識を私はチームに対して教えるようにしていますいきなり全部はさすがに注入しませんけれども必要なタイミング必要なサイズでうまく適宜 これらも知識を教えるようにしています

実際にそれをどうすれば上手く使えるツールとして形にできるのかというのを手本を見せたりしながらそのプロジェクト、プロジェクトの状況に対していろんな形で提供することになりますけれどもこうしたことを行っていきますこれから何回かに分けて公開するつもりの動画ではこういったことも触れて

その具体的なツールとしてどう用いればいいのかというのも紹介していきたいとおもいます次回はスクラムボードについてお話をしたいなと思っていますスクラムボードは一応形式として非常にわかりやすくシンプルなものなんですけれどもあれをうまく使うともっと強力なツールとして用いることができますしスクラムではですねあのスクラムボードは基本ですから

1番目のつくところにあるようになりますですからあのスクラムボードをうまく活用することでチームの生産性を上げたりあるいは システムとしての完成度を高めたり、プロジェクトの成功をより確実にしたりそういったことを スクラムボードでできるんじゃないかなと思いますので

次回はそのスクラムボードについて紹介してき たいと思います

シェア
X LINE
← 記事一覧に戻る