今回は引き続きデスマーチのお話、第三話です！
第一話と第二話をまだ読まれていない方は、是非こちらも読んでみてください！
※第一話
※第二話
第一話と第二話で「エドワード・ヨードンの著書によると、デスマーチの原因は以下４つのどれかに該当している」というお話をさせていただきました。
- 与えられた期間が一般の半分以下
- エンジニアの必要な人数が半分以下
- 予算などのリソースが通常の半分以下
- 機能や性能などの要求が倍以上である
今回はこちらにフォーカスしてお話します！
- 機能や性能などの要求が倍以上である
こちらは他のケースに比べ、デスマーチに発展する事は少なかったのですが、発生件数は一番多かったかもしれません。
なので、皆様も心当たりがある話かもしれませんが・・
早速いつものノリで語りますよぉぉ！
本題に入る前に・・
おいィ、ちょっと待てこの話はどうする？
- 予算などのリソースが通常の半分以下
・・と思われた方いらっしゃいますよね、きっと。
この話ですが、第一話・第二話で話した内容と、結構かぶる部分が多いんです。
「それもう飽きた！」ってなりそうだし、不幸話としても、少々パンチが足りないと思いましたので、割愛させていただく事にしました。
申し訳ございません！
という訳でここから本題です！
機能や要求が倍以上とは？
何かを開発するときって「どんな機能をどこまで作るか？」など議論して作っていきますよね。
例えば「こんなものを作ろう！」と決めて作業を開始したとします。
でも、ある日が気が付いたら、予定していた機能の２倍・３倍のものを作ろうという話に変わっていた。
これだけならまだいいです・・。
更に状況は悪化、要求だけが増え続け、プロジェクトがいつまで経っても終わらない現象に発展してしまう。
何故こうなってしまったのか？
今回もエドワードの話じゃなく、私の経験をもとにしたストーリー形式でお届けします！
終わらない案件への道
①システムを受注して仕様をもとに開発に着手
②仕様書通りの開発が完了し、テストフェーズとなり、お客様にレビューしてみました
③このシステムは複数の部署が使います。A部門は問題ないと言っているが、B部門は「こんなんじゃ仕事できねーだろ！」と大さわぎ。
現場猫にもありましたが、お客様の内部では、まさにこんな感じの事が起きた訳です。
④すぐ直せ、今直せ！と要求を受ける
⑤かなり無茶な話ではあったが、何とか要求通りの改修を実行
⑥今度は問題ないと言っていたA部門から「何でこんな仕様になった？」と言われる。
⑦エンジニアもお客様も混乱して、③～⑥を延々と繰り返す。
⑧そして、気が付いたら、要求がいつまで経っても止まらないプロジェクトに発展！
ここからエンジニアが完全に拘束され、このままデスマーチに発展するケースもあります。
いや、その前に「いつになったらこのプロジェクト終わるんだ！何とかしろ！」とお客様が怒って炎上するのが先かな・・
何で仕様変更が問題なの？
多分、仕様変更ってそんな大変なの？って非エンジニアの方は思うのではないでしょうか。
まだ初期の段階ならいいんですけどね・・出来上がってからやるのはかなり大変なんです。
システムは、予め設計した仕組みと順番でデータを動かしています。
ざっくり説明すると、こんな感じのプロセスで動いているシステムがあったとします。
①A→②B→③C→④D→⑤E
仕様変更により「②B」を変更する場合、「③C→④D→⑤E」も全て変更しなければならなくなります。
実際のプログラムはこんな簡単なものではなく、複雑な条件分岐が山ほどあります。
表面上はちょっとした仕様変更に見えても、都度全体の動作への影響を考えなければならないので、かなり大変なんです。
また、この仕様変更が原因で、大量のバグに繋がり大きな混乱が起きたりします。
その他に無茶な要求である事が理解されず、長引くケースもあります。
例えば「Aという動作」を仕様とした場合「Bという動作」はできなくなる・・みたいなケースって山ほどあるんです。
でも、これをどんなに説明しても理解されず「いいからやれ！」と言われ続けるケースも沢山見てきました。
この経験からわかったこと
これも結局のところ「要件定義」って話だと思いますが、振り返ると、それ以前にこの辺が問題なのかな・・なんて思いました。
- 顧客とのコミュニケーション不足
どうしてコミュニケーション不足なのか？ブレイクダウンして考えてみましょう。
- 何を作るか実は伝わっていない
- お客様との交渉ができない
- どんな作業をするか伝わってない
- 口頭ベースでの議論
- 課題管理がされていない
- 決定事項のエビデンスがない
ブレイクダウンした内容を整理して、さらに原因を考えていきましょう。
整理の方法でおすすめなのが、以下のようにブレイクダウンした内容を構造化するやり方！
何を作るか実は伝わっていない
┗口頭ベースでの議論のみ
┗決定事項でのエビデンスがない
どんな作業をするか伝わっていない
┗口頭ベースでの議論のみ
┗決定事項でのエビデンスがない
お客様との交渉ができない
┗課題管理がされていない
┗決定事項のエビデンスがない
構造化してみて思った事は、もっとプロジェクトを開始するタイミングで、資料などで視覚化を行うべきだった事。
そして、資料化したものをエビデンスとして、各位、共通認識を持った上で、１つ１つ同意を得るべきだったのかもしれません。
このように構造化を使うと、上記のように問題の整理がしやすくなるので、お勧めです！
興味のある方はこちらの記事を読んでみて下さい！
コミュニケーションとは？
コミュニケーションはお客の機嫌を損ねないようにする事や、仲良くなる事ではありません。
コミュニケーションの神髄は、お客にとって不利益な問題でも、ちゃんと正面から相談して折衝ができる事です。
大丈夫！どんなにプロジェクトで対立がおきても、無事完了すれば仲良くなれます！
勇気と自信をもって、お客様にちゃんと報告・連絡・相談をしましょう！
最後に
今回、第三話でデスマーチネタはいったん終了となりますが、いかがでしたでしょうか？
結局のところ、これらの問題って、プロダクトと人がリンクしてない事が原因ではないかな？なんて最近感じています。
実は、最近昔の仲間ですとか、いろいろな方とディスカッションの機会がありまして。
（もちろんリモートで！）
そんなときの話題に、どこも「プロダクト」と「人」がリンクしなくて困ってるみたいなネタはよく話題にあがっていました。
最近ではこれが認知され始めていて「人とプロダクト」をつなぐ、専門部隊の立ち上げが増えている事も聞きました。
実は、私昔から人とプロダクトを整理するポジションに着くことが多かったので、経験で得た解決ネタをいくつか話してみたところ・・
「note」にそれ書いてみたら？と言われまして、閃めいたんです！
この情報をnoteに書くのは面白そう！
よっしーTECHとは別に、noteにテキストのみでまず書いて、どこかでよっしーTECHで解説なんて流れも、いいかななんて・・
なんか面白そうな妄想が広がってきたぜ！
