特定非営利活動法人 ITC近畿会

『プロジェクト推進の知恵』 ＜落し穴に落ちないために＞

• 2003年12月 6日(土) 14:54 JST

• 投稿者:

  HP委員会

『プロジェクト推進の知恵』

＜落し穴に落ちないために＞         try,keeping these points in mind

ITコーディネータ　時久 邦博        （ＴＫＥ）

◇1章◇　多額のお金をだすのだから 　多額のお金を出すのだから責任者（プロジェクトリーダはもちろん、お金の決済者も）は計画から設計、製作、テスト、受入検査まで常に関心を持たなければいけません。強い関心があることを担当者やベンダに示します。技術的な細かい点はともかく腑に落ちない点は納得いくまで説明を求めましょう。 　休憩時間やチョットした時に雑談交じりでもよいから状況を教えてもらいましょう。最後になって期待通りの形になっていなかったり、工期遅れが顕在化してから叱り飛ばしたり、ペナルティをとっても失った機会は戻りません。百回怒っても機会損失を取り戻すのは大変です。後方業務がすべて影響を受けます。 　例えば、システム構築が遅れたために工場の生産設備がフル稼働せず、顧客とメーカーが人間コンベア?や人間スタッカークレーンをしたこともあります。また、チョット例は違いますが、商品開発の場合、営業や販売促進部門がリリース時期を頭に入れて新商品の顧客提案をしたとします。ところが開発遅れを出すとこれまでの苦労が水の泡になるだけでなく信用を失うかもしれません。開発者、設計者には実感が掴めないかもしれませんが営業としては結構辛いものがあります。 偉い人が常に関心を示すだけで仕事の出来栄えは相当違います。あとで「責任者は誰や」と言うことにならないように、日々チョットの気遣いが大切です。

(1/11)

◇2章◇　やりたい事を明示しましょう 　やりたい事を紙に書くことができますか。 特に、外部に委託してシステムを作る場合は文書で明示することが大切です。提案依頼書（ＲＦＰ：Ｒｅｑｕｅｓｔ　Ｆｏｒ　Ｐｒｏｐｏｓａｌ）を作成しましょう。なんとなくコストダウンをしたいと言うのではなく問題点を把握してどこを情報化すれば解決でき、コストは何パーセント下がると言うような事を紙に書いて明示しましよう。いざ書こうとすると意外にかけません。普段から問題点とか解決方法を頭の中で整理しておきましょう。 　例えばトップダウンであれば経営戦略、情報戦略や年度計画との関係などを明確にし、組織のメンバーに意図をしっかりとおろす。ボトムアップであれば現状調査・分析をして解決策を示す。自分の中で整理の出来てないことを他人がやってうまくいくはずはありません。システムの構築も普段の仕事も基本は同じだと思います。技術的なことはわからなくても仕事の進め方をしっかり押さえれば何とかなると思います。

*ＲＦＰ・・Software Life Cycle Processes-Japan Common Frame 98（SLCP-JCF98)の中に詳しく載ってます。 SLCP-JCF98はソフトウェアを中心としたシステム開発および取引のための共通フレームです。委託者と受託者間の取引を円滑に行うためのガイドです。

(2/11)

 

◇3章◇　外注先の選定は慎重に 全て内作出来る所は別にして、ここがうまくいくかどうかで結果は天国と地獄です。いい外注さんに出会えばＱＣＤの達成はもちろんのこと改善提案までしてくれます。運が悪いとお金を払って、教えて、バグを作ってもらうことになります。そうならないようにチョット気をつけましょう。 ・発注金額と外注先の規模によって違いますが、それ相応の責任者（営業、技術）と話をするようにします。相手が100人未満であれば社長はよびたいですね。 ?過去の経験システムについて具体的に何をしたか確かめます。私も経歴の所で「交通管制システムの設計」と書いていますが、その中で何を担当したか。もしかすると統計処理だけかもしれない。必要とする能力、経験を確認をしましょう。 ?設計手法、開発ツール、品質管理手法、完成度の計測方法などを尋ねます。説明されることが理解できなくても勉強のつもりで聞けばいいと思います。 ?ＰＲや説明のがやたら横文字で専門用語ばかりだと、わかる言葉で説明をしてもらいましょう。これを一生懸命やってくれない業者はやめた方が良いと思います。これから長いお付き合いになるのだから一生懸命やってくれる会社を探しましょう。 ?初めてのベンダーであれば信用調査をして技術力、組織対応力、財務状況などを第三者にみてもらい参考にしましょう。安全な会社であれば必要はありませんが、ひどい時は途中でバンザイされてしまいます。 ?出来るのであれば相手の会社を訪問して雰囲気や社員の態度を観察する。開発室も見せてもらうと良いでしょう。 ?見積もり依頼は数社に出せればいいのですが、ここで、何をしたいかが明確に示せないと提案内容、見積もり金額が大きくばらつきます。提案依頼書（ＲＦＰ）を文書でベンダーに示します。 　　システム概要（基本方針や期待効果） 　　依頼事項（開発内容や要求技術） 　　指示事項（説明会の日程など） 　　開発体制・環境など 　　保証要件（品質評価基準など） 　　契約事項　　等 選定からはずれたベンダーには、文書で理由を書いてお断りし、提案依頼書は返却して貰います。 ?契約ができても、システムが完成するまでベンダの最高責任者を放さないようにしましょう。

(3/11)

◇4章◇　技術課題は必ず最初に解決しておく 　システム構想がまとまったり、やりたいことが明確になったら知識・経験の豊富な技術者やユーザ（実際にそのシステムを使うであろう人）を集めて、そのシステム構築にあたり技術課題があるかどうか見極めます。世間ではよく耳にすることでも自ら経験してないことも含めます。自社で解決できない範疇であればベンダー（採用候補）に解決策をお願いします。後工程を考えるとゆっくりやっている暇はありませんが、この目処が立ったらあとは力仕事で、死物狂いで頑張ればなんとかなるでしょう。 　開発作業が進んでから技術課題が発見されるような事になれば目も当てられません。現在は、デジタル化が日々進歩しているので最新技術の動向と実現時期を調査しましょう。 当然、使う人のスキルアップも必要です。 　ある生産現場で、原材料を混合する鉄の釜にＩＤタグをつけたいと言う話がありました。この釜は熱湯洗浄するのですが、カタログでは熱湯に耐えるものはありませんでした。これができないとお客さんの構想がくずれます。そこで研究所に相談すると開発中のもので熱湯に耐えうるものがあるというので、あとは納期に間に合うよう製品化してもらうことになりました。こんなうまくいく話はそうそうないかもしれませんが大きなポイントでした。

(4/11)

◇5章◇　キックオフミーティングをする 　システム開発、プロジェクトのスタートにあたり関係者を集めてキックオフミーティングをしましょう。プロジェクトに参画する自社の担当者、ベンダーの責任者および担当者を集め、当該システムの概要、開発目的、位置付けや発注者の想いを関係者に理解してもらいます。 　血液が毛細血管をとおって指先まで流れるように、発注者の熱い思いが末端まで届いた気持ちの通じたプロジェクトを作りましょう。所詮人間のやる部分が多い労働集約的な業務なので人間関係がポイントになります。キックオフミーティングのあとは全員で懇親会をして、その場で簡単にほんの一言でも良いから全員に決意表明をもらいます。 　チョット大きなシステムだとお互いの顔をあわすことのない担当者が出たりしますが、一度顔合わせをして一緒に酒を飲んでおけば、何かあった時でもスムーズに行きやすいと思います。お金は発注者もちです。完成してから使うお金より役に立つと思います。ポイントは「人間が仕事をする」と言うことだと思います。 　開発作業に入ってからもこの人たちに会ったら「うまくいってますか」程度の声をかけましょう。

(5/11)

◇6章◇　工程表、計画表を見る 　実際に開発・設計に入る前に計画表とか工程表を作成します。一般的にはウォーターフォール形が多いと思いますが、これがどの程度詳細に記述されているかが問題です。大日程が決まっているわけなので、詳細の日程はその範囲内で計画されるのは当然ですが役割分担が明確になっていることが大切です。 　各作業ごとに担当者の名前、完了期日、作成ドキュメント等が明示されているかチェックしましょう。いくつかの作業のかたまりの責任者が明示されているかチェックしましょう。大中小と落とされた計画の全ての作業について上記の項目が明確になっていなければ、そこから無意識的に無責任が付け込んできます。 　技術的内容が判らなくても、作業の細分化と役割分担が明示されていることを確認しましょう。短期間に同じ担当者の名前がたくさんあったりするのは要注意です。

(6/11)

◇７章◇　進捗の確認 　定期的に開催される進捗会議には出来る限り出席し、計画表どおり進んでいるか確認します。役割分担した作業が確実に消し込まれているかチェックします。この確認は技術を知らなくても進捗状況報告書を見れば判ります。見て判らないような進捗状況報告書であれば作り直しを指示しましょう。 　進捗遅れのものについては、対策も同時に説明をしてもらい、次回の進捗会議で結果を確認します。毎回同じようなことを言っているのであれば要注意です。問題が解決してないと考えて、一歩踏み込んで解決策を検討しましょう。担当の技術者では解決できないものでも上位職や発注者であれば容易に解決できるものもあります。 　また、進捗管理は残作業管理でもあります。残作業の項目が明確になっていて着実に消し込まれているかを確認しましょう。 日常の作業中に納期、コストや品質に関して担当者が皮肉な会話をしているようであればプロジェクトにとって何か面白くない事が潜んでいます。普段の雰囲気も感じ取っておきましょう。 　もし、自分が発注側であれば数回に1回はベンダ側の責任者の同席を要請しましょう。最後まで責任者を逃がさないように。お金を出しているのは自分です。

(7/11)

◇8章◇　人材育成 　プロジェクトを推進する中で意識的に人材育成をしましょう。若いプロジェクトリーダやサブリーダの中から一人か二人（多いと面倒がみきれない）将来の幹部候補になってもらうために本人に宣告してプレッシャーを与えます。 　技術的なことはほっておいても勉強しますが、リーダシップの発揮、メンバーの労務管理（超勤管理、苦情処理、悩み相談・・）、後輩の育成、業務改善提案、費用管理等はプロジェクト推進の中で行われているかフォローしましょう。プロジェクト終了後には課長の業務の何割かを理解、代行できるレベルにはしたいですね。 　技術力向上の努力を惜しまず、倫理観の欠如無く、責任感が強く、鷹揚でいて繊細、素直で明るい若手幹部社員を育てましょう。 　最後は人間が頼りです。みんなが「あの人の言うことなら、あの人のためなら・・・」と思ってくれる人を育てましょう。

(8/11)

◇9章◇　検証と妥当性確認 　SLPC-JCF98(ソフトウェアを中心としたシステム開発および取引のための共通フレーム）やＩＳＯ９０００では検証プロセス、妥当性確認プロセスとか設計検証、設計の妥当性確認というのがあります。 　だいたい「検証」というのは、成果物が仕様どおりに作成されているかどうかチェックするもので、たとえその仕様が間違っていても、仕様が正しいとして成果物との突合せをしたり、設計工程のなかで、その工程のアウトプットがインプットした要求事項を満たしているかをチェックするものです。 　妥当性確認は製品が使用者のニーズ、要求事項を満たしているか、使いものになるかをチェックします。 　発注側の責任者はこれら検証と妥当性確認がちゃんと行われているか確認し、必要であれば自らその場に参加して状況をチェックしましょう。検証の場合は、設計に関わるところなので理解が難しいかもしれませんが、妥当性確認は自分のやりたい事がわかっていれば設計途中の段階でも可能です。 　例えば、この仕様は今の段階ではどのように設計されているかをきけばよいのです。細部まで理解できないまでも作業がつながっていることは確認できます。ＩＳＯ９０００を取得しているベンダーであればすべて記録が残されているはずです。 　責任者と言われる人(経営者、プロジェクトリーダ、部門長・・）は常に関心を持っていることをメンバー全員に示しましょう。

(9/11)

◇10章◇　テスト 　テストは対象の規模によっても違いますが、概ね「単体テスト」「結合テスト」「システムテスト」「受入テスト」となります。受入テストの場合は、受け入れ側がテスト項目を作成してテストを実施します。あまりベンダ任せにならない方が良いでしょう。 　単体、結合、システムテストは設計側で実施しますが、十分テストされているかチェックが必要です。テスト計画書、テスト項目リスト、テストデータとかテスト結果書などが準備されているか確認しましょう。また、テストの仕方や合格基準をどう考えているかを確認しましょう。そして前もって文書で提出してもらい、あとで結果を照合しましょう。 　一般に、テストにかかる時間は全体の３?４割程度です。あまりテスト時間が短いと運用に入ってからバグとお付き合いすることになるので要注意です。 　最近、ｅ?コマースでＷｅｂを早く立ち上げるために要求定義からテストまでかなりきついスケジュールで作業を行っているようですが、運用開始時期に迫られてテストを省略して稼動後トラブルが発生しているの雑誌でよく見かけます。 　これは、テストだけのことではないですが、設計は手品でもマジックでもないので手を抜けば後でキッチリお返しがきます。納期近くなって進捗遅れが明らかになった場合運用開始に向けてをどう対処するか、発注側責任者は重大かつ辛い決断を迫られます。前半でも書きましたが、ここで叱り飛ばしても解決になりません。

(10/11)

◇11章◇　本番 　いよいよ本番に入ったら、実績データをとります。 もし、変なデータがでたりおかしな動きがでたら紙に記録して、テストの時のデータと比較します。テストの抜けなどが実運用にはいって発見されます。実運用者の長年の間に身についた感覚はたいしたもので、現場から出た意見はそれなりに的を射てることが多いと思います。 　そうした場合、そこだけの改修だけでなく横展開して同様の不具合にも対処しておきましょう。 ドキュメントの修正も忘れずに行います。操作性の悪い部分も記録して改善をしましょう。 　業務プロセスのサイクル（時間、日、週、月、年）の変化点にはベンダーに待機を要請したほうが良い場合もあります。ベンダーとは長く良いお付き合いができるよう心がけましょう。 　 良いスタートが切れたら関係者を集めてご苦労さん会をして労をねぎらいましょう。 ◇◇◇◇◇◇◇　完　◇◇◇◇◇◇◇◇

(11/11)