404 shin1のつぶやきないわー Not Found: プロジェクト管理

何らかのツールで業務フローとそれに対応する機能、その機能が触るリソース類、をサクサクと参照できるようなツールがあると良いのですが。リリースから間が無いものだったら良いですが、数年前にリリースされた機能に対する修正なんかだと、ドキュメントの品質がものを言う（しかも大概において足りていない）んですよね。

【拾一】JCL修正のみでも、修正規模が小規模でもテスト、レビューを必ず実施する。

記事の中の見出しにあった中の

難しいときほど用意周到になろう

というのが何を意味するのか？難しいときほど用意周到にってのは当たり前の話で、単なる誤記なのかな？記事の内容自体は反論の余地はありません。

【拾弐】必ず原本に戻ってテスト・検証を行う。

可能であれば、テストケースは前工程の担当者が設定するべきでしょう。例えば、業務要件・事務要件のテストケースは開発依頼側のユーザー担当者が作成し、開発受託担当部門のサポートを得て自分でテストを実施するのが望ましいのです。

これが理想なのですが、実際はこうはいきません。各フェーズの設計書には常にテストケースを記述する欄を設けて、それが埋まらなければ設計書の完成としないような仕組みを用意するくらいの事ができればよいのですが。さらに、以下の点が重要ですし意識してやっていくべきですから、「要件」「それに対するテストケース」を対で用意し、記入するのは別の担当者で、それぞれでレビューして始めて設計書が完成、という手順を踏むようにするとか？…は面倒ですね、現場からは不満ぶーぶーですね。それでも強制しないことには実現が難しいですしね。TestLinkとかも試して見ましょうかね。

システムテストケースは自分が受け取った前工程のドキュメントから設定し、テストデータを作成

【拾参】リグレッションテストは必ず実施する。、【拾四】プログラムの修正が無い場合でもデータの流れるシステムはテスト・確認を実施する。

回帰テストは当たり前の事ですが、各個人にまかせておくとまず実現できませんから、ちゃんと意識してチェックする必要があります。とはいえ、常に全試験を…ともイカンでしょうから、第10条に書かれている「修正時の影響分析は有識者の経験やツールを駆使して入念に行う」によって範囲を絞る必要があります。全てを自動試験できるのであれば、毎回全部流しても良いのでしょうが、人間のUIがから内容はそうはいかんし、一番悩んでるところではあります。影響範囲については極力「要求：機能：影響対象リソース：関連機能」を管理し、そこから引っ張れる影響範囲は必ず試験対象にする、というようなことを行うことがまず最初の一歩ですかねぇ。このあたりをうまく機械的にできている、仕組みを持っているところの手法を紹介して欲しいですね。

【拾五】プログラム類の本番移行管理は確実に行う。

急がば回れ、が大事ですね、極力、常に一から構築できるような仕組みを用意しておく事が必要だと思います。自動化できるところはできるだけ自動化しておくほうがいいですね、自動化に手間がかかるとしても、自動化できるのであれば手間をかけてでも自動化するほうが良いです。自動化できる事は幸せなことですから。

【拾六】サービスイン（カットオーバー）時には必ず本番チェックを実施する。、【拾七】それでも起こってしまった時は速やかに報告を。

あと、何か起こった時の調査には、地道にひとつひとつ調査、という事が大事です。これも急がば回れですね。 17条以外にももうひとつ菊島先生の記事の紹介を。

教科書じゃ教えてくれない　本音で語る開発案件成功の法則

2007年10月26日金曜日

EnterpriseZine : トラブル削減のための原則17条

トラブル削減のための原則拾七ヶ条とは？【まとめ】

役に立つと思ったので勝手に引用＆コメント。どれも（ほぼ）当たり前の事が書かれているんだけど、あまりにもそれができない事が多いから各フェーズのチェックリストとして使っても良いと思うくらい。でも、気になる点のみコメント。

【壱】書いてある要件はやらねばならない。書いてない要件はやってはいけない。
【弐】「〜と同じ」という要件はない。「〜と同じにする」ための要件定義をする。
【参】口頭での要件、修正変更のやり取りを行わない。
【四】積み残し、先送り案件の明確化と周知徹底。
【伍】エスカレーション･マネジメントを行う。
【六】コンティンジェンシープランを作成する。
【七】有識者なきレビューは開かない。、【八】期限が迫っているからといって、テスト、レビューを省略しない。
【九】開発メンバーの成果は現物で確認する。
【拾】修正時の影響分析は有識者の経験やツールを駆使して入念に行う。
【拾一】JCL修正のみでも、修正規模が小規模でもテスト、レビューを必ず実施する。
【拾弐】必ず原本に戻ってテスト・検証を行う。
【拾参】リグレッションテストは必ず実施する・。
【拾四】プログラムの修正が無い場合でもデータの流れるシステムはテスト・確認を実施する。
【拾五】プログラム類の本番移行管理は確実に行う。
【拾六】サービスイン（カットオーバー）時には必ず本番チェックを実施する。
【拾七】それでも起こってしまった時は速やかに報告を。

※第10条以降はまだ未公開になっているようですから、後日の楽しみですね。

【壱】書いてある要件はやらねばならない。書いてない要件はやってはいけない。

もちろん、要件を読む側も、みなしや、決め付け、推測を排し、不足や疑問を感じた時、理解に確信がもてない時、また、行間を読むような事態になった時は、必ず開発依頼者に確認をしなければいけません。そして、記述に不足、不明確な所があった時は、必ず確認の上、補記、追記をして要件定義書を開発依頼者と協力して完全なものにしていかなくてはならないのです。

この「確認」手順はプロジェクトの体制によって変わりますから、途中参加の人間でもすぐにこの行動が取れるように手順を明確に定義しておく事が必要ですね。

【弐】「〜と同じ」という要件はない。「〜と同じにする」ための要件定義をする。

基本的には同意。第二条のタイトルは、記事の中にある

同じでよいというのは、プログラム仕様書についている付属資料のデータテーブルなど、個別具体的なものをさす場合だけ

という文でもいいんじゃないかな？とも思いました。また、「超上流から攻めるIT化の原理原則17条」からの引用として書かれている

発注者は、文書・モックアップなどの手段を講じて、要件を表現しつくす努力をする。

という内容は少し疑問。これって発注者がやることなんでしょうかね？

【参】口頭での要件、修正変更のやり取りを行わない。

激しく同意。

開発依頼側、開発受託側も協力してミスが発生しない体制を作り、しっかりとしたプロセス定義にしたがって、ベースラインドキュメントを軸に仕事を進めること

そうですよね、第2条にコメントしたのはまさにコレのためです。第二条で引用されていた個所も引用せずに少し訂正した文を掲載した方がいいんじゃないかな？と思います。「受託側がモックアップなどの手段を講じて発注者へ協力し、要件を表現しつくす努力をする」といった内容が良いんじゃないか？と。発注者に重いものを押し付けすぎるのはイカンですよね。

【四】積み残し、先送り案件の明確化と周知徹底。

この中での話ではありませんが、これら「積み残し、先送り案件」の具体的な管理方法はどうでしょうかね。先送りしたことは明文化してトランザクションとしてメールなどで流し、機能一覧のようなマスタからは抹殺してしまうべきなのか？フェーズに応じた対応方法を考える必要はあるんでしょうね。

【伍】エスカレーション･マネジメントを行う。

「問題」の大きさ、等の話もあるかもしれませんね。大きすぎる問題は末端作業者に見えない、といった事もあるので難しいですね。チームビルディング系の話でもあるでしょうね。

【六】コンティンジェンシープランを作成する。

「コンティンジェンシープラン」って一般的な横文字なんでしょうか、私はこの単語は知りませんでした。恥ずかしいことなのかな？文中にも「耳慣れない言葉」とされてますね。

コンティンジェンシープランは、簡単にいえば、システムのトラブルについて、一定期間のお手上げ状態に対する対応といってもよいでしょう。お手上げ状態なのですが、それでも業務は動かす。システムは動かなくても業務は動かすためのプランなのです。

チェックリストとして使用する場合はこの文を簡単にしたタイトルに置き換えた方がよさそぅです。ただ、リスクドリブンとして最初にこの問題をクリアするための行動を起こしておけば、業務への理解も深まりそうですね。

【七】有識者なきレビューは開かない。、【八】期限が迫っているからといって、テスト、レビューを省略しない。

おっしゃるとおりです、そのとおりです。だけど、第7条については少し疑問。レビューってのは必ずしも全てが本格的である必要はないんじゃないでしょうか？最終的には本格的なレビューは必要ですが、その前段階として「観葉植物や壁、ぬいぐるみなどのマスコット」を相手にレビューするのもアリだと思います。第7.5条として、「人間以外にレビューをしている人をみかけてもバカにするな」とかを追加したいです。

【九】開発メンバーの成果は現物で確認する。

みんな一所懸命やっていることを否定しません。しかし、プロジェクトを円滑に確実に進めるためにはやはり、現物で確認、完成度を事実でチェックするべきです。 ... 情報公開による会社健全化の効果と同じで、見える化の力はプロジェクトとプロダクトの品質を上げるのです。

掲げてある内容はおよく理解できるのですが、その実現方法がイマイチ掴めないんですよね。例えば作業場所が「中国と日本」のように極端に離れている場合にこれを実現できる方法、ツールが欲しいと思ってますが何が良いのでしょうね。最悪、もんのすごいコストがかかるであろぅ、「定期的な目視確認」であってもやった方がいいという事をおっしゃってるんでしょうか。これより後の第10条以降はまだ公開されていませんが楽しみです。ただ、全体的に「掲げていることはよくわかる、でもそれを実施する事ができる、それの実施をラクにできる、ツール類の紹介が欲しい」というカンジがします。もちろん、自分で探せばいいんですし、会社やプロジェクトに応じて変化するものですけどね。