Aチームはアジャイルで成功、BチームはWFで失敗するとき、Bチームが成功する条件を述べよ
ご質問をいただいたような気がしましたので。
誰でもウォーターフォールを出来ると思ってたの。そんなのあるわけないじゃん… - 室長のひとりごち
勉強不足で恐縮ですが、アジャイルだから上手くいった、ウォーターフォールなら失敗していた、というプロジェクトがあったとして。それってウォーターフォールでも上手くいったんじゃないか?って思ったり。
2017/12/03 16:05
たびたびブログの中で、アジャイル開発もウォータフォールもどちらもシステム開発手法の仲間であると書いているのでそれについてはご理解いただけていると思います。
設問
では、あるプロジェクトがあり2つの手法を2つのチームが実践したときに、次の結果となったとします。
このとき、ウォーターフォールでも実は成功する条件を述べよ。なお、2つのチームの技量は同じであるとする。
検証例
Bチームが採用したウォーターフォールで成功する場合の条件を考えてみます。ウォーターフォールでのシステム開発は、俗に計画駆動型とも呼ぶように開発当初からスコープが決まっている場合のプロジェクトにフィットします。
プロジェクトを開始するために計画を立てる時点でプロジェクト完了時のゴールである要求(スコープ)が固定(変動しない)であり、それはQCDが開始時点で設定可能ということです。
これは要求が固定しているため、リソースと日程を見積もることができる、という意味もあります。
Bチームが成功するためには、要求が固定していることが必要です。逆に言えば、要求が固定していない、つまり、要求が変動する状態であればリソースと日程を精度高く見積もることができないため、失敗する可能性が高いです。
Aチームが採用したアジャイル開発は設問では、成功したことになっています。ご存知のとおり、アジャイル開発は総称で、実際のシステム開発手法名には、スクラムやXPなどがあります。ここでは便宜上、スクラムと定義します。
スクラムでは、リソースと日程が固定です。これはチームの人数を最初から固定します。日程についても決めたサイクル(一般的には2週間)で固定し、繰り返し開発を行います。一方、要求(スコープ)は固定されたリソースと日程の中で対応できる可能な範囲でしか開発の対象とはなりません。
言い換えれば、開発テーマのボリューム(テーマごとの規模)が2つの要素を掛け合わした面積に入るだけしかやらないのでどの開発テーマを選ぶかにより変動するということを意味しています。
Aチームが成功せるためには、リソースと日程を固定し、面積の中で要求を調整できれば成功できます。逆に、要求が固定であった場合もリソースと日程の面積に入るのであれば成功します。
ただ、要求が固定の場合、アジャイル開発をシステム開発手法として選択する価値はありません。
結論
要求が変動する場合のみ、ウォーターフォールを採用したプロジェクトは失敗する。
要求が固定 要求が変動
Aチーム アジャイル開発 成功する 成功する
Bチーム ウォーターフォール 成功する 失敗する
まあ、現実には要求の変動がプロジェクト内でコントロールする可能な範囲でプロジェクトを制御し続けるため、結果的に成功の範囲内でプロジェクトが集結しているだけです。
調達 お祝い 遠隔地のお友達の出産祝いに
アマゾンギフトカードで。
これでママさんの気分転換になるものでも買ってもらえればいいかなー。
Amazonギフト券- Eメールタイプ - 出産祝い(ゆりかご)
- 出版社/メーカー: Amazonギフト券
- 発売日: 2012/05/17
- メディア: Ecard Gift Certificate
- 購入: 1人 クリック: 1回
- この商品を含むブログを見る
測定と許可を願うより継続的なリリースが自己組織化のチームを作る
ここ数年、特に今年になってからシステム開発を担うチームに対して自己組織化がさもありなんという感じになってきていると思うのですけれど、さて、実際のところはどうなんでしょうか。
自己組織化するチームは実はそれほど珍しいことはなくてマネージャから裁量を与えられているケースは少なくないのです。例えばプロジェクトのチーム内でのプロジェクトマネージャの方針によりメンバに多くの意思決定を手渡すことはよく見られることです。
エンジニアを受身に慣らす
ではどうして裁量を渡しているはずのエンジニアが受身に慣らされてしまうのでしょうか。
それは、生産的な活動ではない仕事を介してコマンド&コントロールを刷り込むマイルストーンを強制しているからです。
生産的な活動ではない仕事とは、成果の測定と次の行動の許可を得させることです。
成果の測定とは、測定できる定量的な数値の計測であり、時間や出来高で表されます。
次の行動の許可とは、許可を与える組織に対し、成果の測定を報告することで次のアクションへ遷移することを許可を伺う行為です。
こうした権限を持つ誰かに情報を提供し、その状態が適切であるかどうかの判断を委ねてしまうことは自ら考え行動するという自己組織部分を自ら逸してしまうのです。
測定と許可の存在
成果の測定と次の行動の許可は、組織が過去にプロジェクトがトラブって得た教訓であったり、初めてプロジェクトをマネージするプロジェクトマネージャや経験の少ないメンバで構成されたチームから参考にしたい仕事の仕方の提供を求めて形作られていきます。
こうした積み重ねが組織の中で制度化し、標準化されていきます。
これは普段、作業プロセスの標準化や管理されることに対して敵対意識を持っているエンジニア自身が、状況が変われば自らがそれを求めるということを意味しています。
この状態が長く続くと組織の中でのお作法となり、やがて家風とも言える組織の文化が醸成されてしまうのです。
これを回避するためにもC&Cから測定できる定量的な数値に変わるチームの進捗を表す別の何かで伝える必要が出てきます。
C&Cから逃れるために
定量的な測定から逃れたい、組織の標準化に縛られたくないとするとき、エンジニアはどのようにすればそれが実現できるでしょうか。
プロジェクトでの作業を繰り返す短いスパンで設計し、その成果を測定できる作業時間やコード量ではなく、プロジェクトの存在意義である目的の部分を動くシステムとしてリリースすることで代替することができるようになります。
ただ、作業を繰り返す短いスパンでのリリースが途切れてしまうと作業が進捗しているかを確認する手段がなくなり、結果的に測定できる何かしらの数値で成果になるまでのしかかり状態を通知し続けなければならなくなります。
実際は短いスパンでリリースできるようになるまでが大変で、やり方は理解できてもムリぽと思ってしまうのはプロジェクトでリリースするフィーチャのロードマップを企画する力量がないから、という現実があったりするのですけれど。
誰でもウォーターフォールを出来ると思ってたの。そんなのあるわけないじゃん…
アジャイル開発のスクラムの アジャイル宣言 に書かれたことを実践するのはとてもハードルが高いと思っているということは以前に書いたことがあります。周りの知り合いでCSMなどの認定を受けていて実践しているの何人かに実践することの難易度について尋ねてもだいたい同じような答えが返ってくるのでそれほと間違ってはいないのでしょう、と思いたいところです。
もちろん、高いと思っているハードルに挑戦し、(理想的な)チームづくりに取り組むことは楽しいと思う方の人なので前述のハードルについては所謂、いい意味で、なのですけどね。
あれ、ウォーターフォール出来ないの…
とあるプロジェクトをプロジェクトマネージャに任せていたら、どうも様子がおかしい。プロジェクトのアーキテクトとランチをしていると愚痴っぽいことが出てくるようになってきたのでした。
色々と聞いていると専門がプロジェクトマネージャですからそんなのああすればい、こうすればいいと言いたくなりますし、なんでそんな当たり前な基本的な所作が出来ていないのか不思議でしかなかったのです。
とはいえ、最初からあれこれ口を出すのは育成や自律などの意味合いでよろしくないし当事者のプロジェクトマネージャだって面白くないでしょうし。だから経過を観察していたんですよね。そうしたら…
課題管理…
課題管理がまず杜撰だったことが判明したのです。
いや、課題管理で課題と識別して、優先順(優先順位ではない)を高レベルに設定いたいくつもの項目が期限を過ぎてもオープンしたままで全くクローズする気配もない状態でした。
課題管理の期限はそれを超えてしまうとスケジュールにインパクトを与え、余波でコストまで影響を受けるなどプロジェクトの進捗上の問題にクラスチェンジしてしまいます。
まあ、そういったケースが目白押しだったんですよ。
おかしいじゃないですか。課題管理をしているのに課題のコントロールをしていないんですから。
進捗管理…
課題管理がそんな状態での進捗というか作業計画がどうなっているかを想像できる人は手を挙げて考えを述べてください。
そうですよね、ひっちゃかめっちゃかになっているんですよ。課題は一向にクローズできない。でも、できることをやろうとするから迷惑なのはチームのメンバですね。次のタスクが予測できないと前段取りができませし、やっても割り込みになってしまいますからね。
で、おかしいと思ったんですよ。あれ、シニア層のベテランのエンジニアもいるし、って。
「アジャイル開発の本質とスケールアップ」では…
P76の欄外注記には、
アジャイルのリーダーであるジム・ハイスミスは次のように述べている。なぜ計画通りに進まなかったのか、自分たちの責任の所在を明らかにしようとしている多くの良いチームを見て、結論として、チームではなく計画が問題だったことを発見した。
計画のボールドは原文のままですが、計画なのかと思うんですよ。そうじゃいないじゃないかって。
計画を目の敵にしなければならない対象なのか。でも、振り返ってみれば、担当したプロジェクトは全て計画どおりに終わっているのです。
ただ、他のプロジェクトマネージャが担当したプロジェクト(上述の例など)の中にはやはり失敗しかけたケースもあるのも事実です。
アジャイル開発の本質とスケールアップ 記載の計画が原因だったと発見したとあるようにそういう見方もできるので実は計画ではないのかもしれないと考えたのですが。
新しい発見…
ハイスミスがいう原因が計画にあるとするのは、上記の事例からいえば裏付けるエビデンスになります。一方、ワタシの実績例をエビデンスとするならば、ハイスミスがいう発見は誤りになるのではないでしょうか。
ここで上記の事例のプロジェクトマネジメントが途中でおかしくなってしまったことをプロジェクトを担当したプロジェクトマネージャの資質の問題にしてしまうのは間違いです。それではそのエンジニアを排除するか矯正することが対策となり、その人の属性問題になってしまい、他のプロジェクトにプラクティスを共有できなくなってしまいます。
そういった局所的な物の見方をするのはエンジニアに多いので常に外観から見る訓練をしておきたいところです。
さて、では外観から見たときに何が原因であったのか。
それは、ウォーターフォールというシステム開発手法自体を理解し、実践するための適合性があるのではないか、とうことです。
言い換えれば、ウォーターフォールは実践しようとするプロジェクトマネージャやエンジニアを選ぶ、ということです。
これって冒頭のアジャイル宣言と同じではないですか。
言い換えれば、誰でもウォーターフォールができると思ってはいけない、ということです。これって衝撃ですよね。でも、そうだと仮説を立てるとこれまで失敗とされてきたプロジェクトの原因を説明できるのではないか、と思うのです。
少し検証は必要かもしれませんが。
アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)
- 作者: ディーン・レフィングウェル,玉川憲,橘高陸夫,畑秀明,藤井智弘,和田洋,大澤浩二
- 出版社/メーカー: 翔泳社
- 発売日: 2010/02/18
- メディア: 大型本
- 購入: 6人 クリック: 261回
- この商品を含むブログ (21件) を見る
納期が厳しい仕事を積まれてもあたふたしないで仕事をしたいなら
年明けのイベントが競合が多くてほとんど期待をしていなかったところに復活当選的な知らせが入ってきて一気に作業バッファがマイナスになりかけそうな年の瀬となりそうな気配というか、ほぼ確定で息が止まりそうです。はい。
冒頭のほとんど期待をしていないというは、これは仕事で経験したことの一つで、物事は確定するまでは期待してはいかんよ、という意味合いのやつです。例えば提案をしていて、担当ベースではほぼ確定的なことを言われていても、稟議を回したら横槍が入って政治決着でひっくり返された、なんてことはよくある話です。そういうこともあって、注文書を受け取るまでは期待もしないし、幾ら雰囲気が良くても信じないことにしています。
まあ、これは進捗を%で報告するエンジニアを信じないのと同じですね。現物ができたのかどうか、だけしか信じません。
それはさておき、仕事が山積みになったとしても割と冷静でいられるようになったのは、どうしたら山積みになった仕事を片付ければいいか自分なりに学習したからということが大きいですね。
この体験自体は30代半ばに自分なりにそう納得できたのでその辺りから随分と幾ら仕事を積まれようがどうにかなると思えるようになったのですけど。
積んでいる仕事を眺める
別に品評会をするわけじゃないですけれど、そう言えば先週も割と仕事を積んでいたんだった…、いくつの仕事を自分がやろうとしているか、をザクっと見渡します。
これをエヴァのシンジくんのように「やらなくちゃ、やらなくちゃ」と思ったりせずに「あー割と締め切りが近いのがアレコレあるな」くらいで他人事のように一歩引いて見るのがオススメです。
仕事ですから、周りが見えなくなってしまうようなほどのめり込んではいけないと思うのです。趣味ならのめり込んでもいいですけど。
- タスクA 来週半ば
- タスクB 来週末
- タスクC なる早
タイムアタックでスピード力
なんでも同じですが、繰り返しやったことは無意識に体が動くようになるのとリズムが作れるので仕事のスピード力が断然違ってきます。
子どもの頃に習い事をすると必ず基礎を繰り返し練習させられるところは、こうしたところで生きてきます。
つまり、繰り返し仕事をする中でタイムアタックをし続けることでスピード力をつけよう、という事です。
もちろん、自分の考える作業の出来、品質をクリアしていることが必要だし、仕事の成果をチェックする人=依頼してきた人の要求レベルに合わせて終わらすことが必要です。
それをやるんだよ
結局、リソースが自分しかない場合、それをやるのは自分です。そこでどうしようと悩んでいても進捗はゼロです。
手を付けないといけないし、とは言っても闇雲に手を付けてはやり直しで二度手間です。二度手間にしないためには繰り返し仕事のやり方を覚えればできるようになります。
仕事ごとに少しづつ違うよというケースも、共通項、汎化しているところを見つけられればそこは同じ作業で、入力か出力のパラメータが違うだけと見切れたりします。
見切れればあとは本当に作業になるので、そこで必要なのがそれを(自分で)やるんだよ、という自分に言い聞かせることです。
これはとても大事な考え方で、仕事が役割相応で難しくなって考え過ぎてしまう嫌いになったとしても、それをやるんだよと言い聞かせて何かしら頭の中にあることを見えるように具現化し始めると試行錯誤しながらでも一歩一歩済むのである時点で方向性が固まって進むようになります。
でもそれは結果であって、それをやるんだよと言い聞かせたから出来たことなんですね。
なので、今日の仕事に手をつける前に
「それを(自分が)やるんだよ」
と言い聞かせてみてください。確実に進みますから。
よかったらたまにははてブでも押していってください。
これ作るのにお幾らかかりましたか
えっと、なかなか記事の内容がアレな感じなので捨てておこうかと思ったけれど。
以下、引用は全て元記事からです。
気持ちはわかるような今ひとつ大丈夫かな、と思ってしまうのが狙いのところ。
時間を浪費しがちな開発業務をAIで効率化し、システムエンジニア(SE)が、開発業務の様々な作業や成果物の品質の向上に充てる時間を捻出する狙い
いつも書いていますけど、品質の向上という概念がおかしいのです。それでは品質がない状態に対して事後対策をするということです。
品質は、プロジェクト化した目的である業務要件を実現するためのプロジェクトの目的そのものなので、品質を備わったものを作る活動をするのです。
モグラ叩きを永遠に続けたいのかな、と思いますね。
開発プロジェクトの作業や成果物の品質の低さが課題になっていることがある。「品質を現場の人任せではなく、技術で底上げする。それによって品質が原因の不採算の案件を減らしたい」
事象は認識できても真因にたどり着けなければそれにかかる労力は徒労でしかないです。お金をドブに捨てるようなものですよ。
システム開発において、不採算案件につながる要因は様々だ。設計書の不備による手戻りが発生したり、ソースコードの品質を高めるのに多くの工数がかかったりするのはその典型だ。
不採算案件なんて生温い言葉で表現しているから一向に収束しないのですよ。赤字、でしょう。あ・か・じ。
赤字になる1番の源泉、起因となる工程は設計書の、じゃないですよ。要件定義でしょう。それを設計工程でまるっと一括りにしてしまうセンスにはどうかと思うけどなぁ。
上流工程は問題ないけど下流工程、つまり外注にアウトソースすることろに問題があるといいたのではないかと勘ぐってしまうなぁ。
それが事実であったとするならば、アウトソースの調達プロセスに何かしらの問題があるのだろうし、成果物の受入検査の仕組みに問題があると捉える方が自然じゃないかしら。
スキルが高いSEであれば、品質で問題を起こすことは当然少ないという。ただし、こうした高スキルの人材には負荷が集中しやすく、リソース不足に陥りやすい。
そりゃメンバで不出来なエンジニアを採用したままで作業品質をモニタリングしていなければ、自然とプロジェクト最適化が働いて出来のいいエンジニアに仕事が集中するのはスループットが出るからだけど、出来るエンジニアのHPが削られてクマまで放置するというかタスクを積み上げるのでSPOFとなってポシャるだけのことですよね。
そこでKIWareを導入し、「高スキルのSEの作業負荷を下げる」「若手SEのスキルを底上げする」という2つの効果を狙う。
高スキルのSEはリソース不足になりがちなところを下げるためには不出来なエンジニアの不出来を正さないといけないんだけど。
あと、いきなり若手SEのスキルを底上げとあるけれど、まず何が底上げされるのかねぇ。技術的な経験知でしょうか、それとも技法的な形式知でしょうか。それとも基礎スキル的な人間の性質に深く依存するところでしょうか。
どれも無理っぽいですけど。
これによって開発の作業品質、成果物の品質を高め、品質が原因の不採算プロジェクトを減らすことを目指す。
作業品質の前に、プロジェクトの作業プロセスやプロジェクトマネジメントとしての基本的なところに欠陥があるから赤字になっているのではないのかしら。
実現できるプロジェクトの作業プロセスを設計しないと計画作成時から赤字に至るリスクをプロジェクト自ら負うのですよ。
成果物の質を高めるのではなく、作業プロセスの中で品質を持てるように作業させるのですよ。いったいそれはどこで表現されているのかしら。
成果物の品質に影響しやすくSEの負担が多い作業にAIを適用し、ソースコードや設計書の品質向上を目指したものが目に付く。
きになるのはやはり手を付けやすい下流工程の成果物からやっているところですね。
要件が実装されいているかどうかが品質を備えているかどうかにつながるのでトレーサビリティをどう考えるかがポイントなんですけれど。
さらに言えば、多分に現状の下流工程の成果物を変えることをしないでなんとかしようとしているところでしょう。リポジトリを統合せずにドキュメントで分解していたり、人が理解できるドキュメントに分けた状態を AIでやってもダメですよ。
全然ダメ。
これらのツールで効率化する作業の多くは、「システム開発のプロジェクトで必要だが、付加価値の低い作業」
いやいや、多段階で要件をコードに変換するのは顧客もエンジニアも要件を翻訳する実用があるから、そういったシステム開発手法を取っているのでしょう。そうでなければいきなりコードを書いて見せて要件満たしているかを顧客にテストさせればいいのだから。
ということでいつまで使われるのかなーというか幾ら掛かったのかなー、これ作るのに。
- 作者: 東京工業大学エンジニアリングデザインプロジェクト,齊藤滋規,坂本啓,竹田陽子,角征典,大内孝子
- 出版社/メーカー: 翔泳社
- 発売日: 2017/12/15
- メディア: 単行本
- この商品を含むブログを見る
テストのキャプチャは必要なんですか
そう言えば、過去に言われたことありましたねぇ…。何度か。
初めてそういった問いかけがあった時には「必要です」と。あまり良い答えじゃないなと思ってはいました。
必要かどうか、で言えば、契約に書いてあるので必要だったんですが、形態的に聞かれたものが必要だったかどうかと言えば再考の余地はあったかもしれません。そこがそのときの引っかかり=学習ポイントだったのでした。
ときは過ぎて別のプロジェクトのときに、やっぱりテストのエビデンスが必要かどうかを問われました。
そのときのメンバの問いかけに対する回答は、
「テストの正当性を確認できれば変えても良いよ」
という言い方に変えました。成果物としての文書名称は決まっていましたが、テストのエビデンスの形態までは言及していなかったので、それはこちらからエビデンスはこれですと説明すればいいわけです。
#経緯的には一旦決めたものを変えますね、くらいの仕切りはしないとな、とは思っていました。
もちろん、テストの目的をかくにんできなければエビデンスにはなりませんけど。
結果的には、メンバ同士で代替策を考えたようですが、変えずに当初予定のエビデンスで行くことに。
変えてもいいんだということはメンバにとっては一つの驚きだったようです。
どうしてエビデンスが必要なの
ところで、テストのエビデンス、何に使っているんですか。みなさんのプロジェクトで。
そういった問い掛けってしたり、されたりすることないんじゃないですかね。なので訊きますよ。
何にテスト結果のエビデンスを使っているんですか。
どうしてエビデンスが必要なんですか。
ねぇ、ねぇ。
契約書に書いてあるから
多分、ほとんど、契約書に記載されて成果物として出さないといけないから、くらいじゃないでしょうか。
それとも慣習で、でしょうか。
実際、何に使っているの
じゃあ、テストのエビデンスを何に使っているんですか。
成果物として納めるとするなら、作業プロセスに入っていないとおかしいですが、テスト工程での作業プロセスにきちんとエビデンスの仕様について決めていますかね。
成果物として捉えていて、それが納める義務が契約上あって、とするなら作業の対象になるので工数も割り当てられるし、進捗も管理されるし、エビデンスの品質も検証されないとおかしいですけど。
してるんですかね。
エビデンスの使い道
エビデンスの使い方、でも良いかも。パッと出てくるのがこの2つですね。
- 成果物
- 要件を満たしていることの確証
成果物はお金を払ってでも欲しいと顧客が要求するので業務ですね。エビデンスを作ること自体が。
でも、実際は、成果物の意味合いが作ることが慣習化し過ぎて、テストの進捗管理の1つのアイテムになっているきらいがあるのでありませんか。
実際の現場でエビデンスを作って集めるのは進捗の実績に成り代わっている、というわけです。
もちろん、品質管理に活かされることも皆無です。
そんなことをしていれば、テスト結果であるエビデンスは作りっぱなしになるのは当然の成り行きですね。だから、年度末納入などがあるようなプロジェクトでは、集めたときになんじゃこりゃとなるわけです。
2つ目はテスト目的を証明するための確証という位置付けです。要件がシステムに、コードに実装されていることをそのエビデンスで証明するために使われる。
第三者が来て監査されようが、確証としてのロジックを作ってあるのでこれ見てねと言えるものになっていないとマズイので。テストのエビデンスとしての要件を満たしていればいいので、何も画面キャプチャである必要もないわけです。
テストプロセスの観点
でどうエビデンスを扱うか。
それを考えましょう。
作業のプロセスはプロジェクトマネジメントの観点では、アウトプットを作る作業を定義すればいいのです。
ただ、テストでは直接的なものづくりはないです。作ったものに要件が充足されているかを検証するプロセスです。
その観点から言えば、テストでは、
- テスト仕様やテストコードを作るところ
- それをレビューするところ
- テストを実施するところ
- テスト結果を評価するところ
が主な作業です。エビデンスは3の副産物なのですよね。なのでキャプチャである必要は全くありません。
それよりは、テスト仕様の出来の方が重要です。作業プロセス的には1つ目をきっちり押さえておかないとやりなおしになってしまうので。
それで、あなたのプロジェクトのエビデンスはなんのために使っているんですかね。