役に立つと思ったので勝手に引用＆コメント。どれも（ほぼ）当たり前の事が書かれているんだけど、あまりにもそれができない事が多いから各フェーズのチェックリストとして使っても良いと思うくらい。でも、気になる点のみコメント。
※第10条以降はまだ未公開になっているようですから、後日の楽しみですね。
もちろん、要件を読む側も、みなしや、決め付け、推測を排し、不足や疑問を感じた時、理解に確信がもてない時、また、行間を読むような事態になった時は、必ず開発依頼者に確認をしなければいけません。そして、記述に不足、不明確な所があった時は、必ず確認の上、補記、追記をして要件定義書を開発依頼者と協力して完全なものにしていかなくてはならないのです。
この「確認」手順はプロジェクトの体制によって変わりますから、途中参加の人間でもすぐにこの行動が取れるように手順を明確に定義しておく事が必要ですね。
基本的には同意。第二条のタイトルは、記事の中にある
同じでよいというのは、プログラム仕様書についている付属資料のデータテーブルなど、個別具体的なものをさす場合だけ
という文でもいいんじゃないかな？とも思いました。また、「超上流から攻めるIT化の原理原則17条」からの引用として書かれている
発注者は、文書・モックアップなどの手段を講じて、要件を表現しつくす努力をする。
という内容は少し疑問。これって発注者がやることなんでしょうかね？
激しく同意。
開発依頼側、開発受託側も協力してミスが発生しない体制を作り、しっかりとしたプロセス定義にしたがって、ベースラインドキュメントを軸に仕事を進めること
そうですよね、第2条にコメントしたのはまさにコレのためです。第二条で引用されていた個所も引用せずに少し訂正した文を掲載した方がいいんじゃないかな？と思います。「受託側がモックアップなどの手段を講じて発注者へ協力し、要件を表現しつくす努力をする」といった内容が良いんじゃないか？と。発注者に重いものを押し付けすぎるのはイカンですよね。
この中での話ではありませんが、これら「積み残し、先送り案件」の具体的な管理方法はどうでしょうかね。先送りしたことは明文化してトランザクションとしてメールなどで流し、機能一覧のようなマスタからは抹殺してしまうべきなのか？フェーズに応じた対応方法を考える必要はあるんでしょうね。
「問題」の大きさ、等の話もあるかもしれませんね。大きすぎる問題は末端作業者に見えない、といった事もあるので難しいですね。チームビルディング系の話でもあるでしょうね。
「コンティンジェンシープラン」って一般的な横文字なんでしょうか、私はこの単語は知りませんでした。恥ずかしいことなのかな？
文中にも「耳慣れない言葉」とされてますね。
コンティンジェンシープランは、簡単にいえば、システムのトラブルについて、一定期間のお手上げ状態に対する対応といってもよいでしょう。お手上げ状態なのですが、それでも業務は動かす。システムは動かなくても業務は動かすためのプランなのです。
チェックリストとして使用する場合はこの文を簡単にしたタイトルに置き換えた方がよさそぅです。ただ、リスクドリブンとして最初にこの問題をクリアするための行動を起こしておけば、業務への理解も深まりそうですね。
おっしゃるとおりです、そのとおりです。だけど、第7条については少し疑問。レビューってのは必ずしも全てが本格的である必要はないんじゃないでしょうか？最終的には本格的なレビューは必要ですが、その前段階として「観葉植物や壁、ぬいぐるみなどのマスコット」を相手にレビューするのもアリだと思います。第7.5条として、「人間以外にレビューをしている人をみかけてもバカにするな」とかを追加したいです。
みんな一所懸命やっていることを否定しません。しかし、プロジェクトを円滑に確実に進めるためにはやはり、現物で確認、完成度を事実でチェックするべきです。
...
情報公開による会社健全化の効果と同じで、見える化の力はプロジェクトとプロダクトの品質を上げるのです。
掲げてある内容はおよく理解できるのですが、その実現方法がイマイチ掴めないんですよね。例えば作業場所が「中国と日本」のように極端に離れている場合にこれを実現できる方法、ツールが欲しいと思ってますが何が良いのでしょうね。最悪、もんのすごいコストがかかるであろぅ、「定期的な目視確認」であってもやった方がいいという事をおっしゃってるんでしょうか。
これより後の第10条以降はまだ公開されていませんが楽しみです。ただ、全体的に「掲げていることはよくわかる、でもそれを実施する事ができる、それの実施をラクにできる、ツール類の紹介が欲しい」というカンジがします。もちろん、自分で探せばいいんですし、会社やプロジェクトに応じて変化するものですけどね。
0 件のコメント:
コメントを投稿