| « 2007年3月8日 | 2007年3月9日の投稿 |
2007年3月12日 » |
「誤る」ことが多いから「謝る」ことになるんです。この根幹の１つは、不肖は、いわゆる「用語集」の交換・統一・合意形成ができていないことだと、最近痛感してます。
ユーザ企業のIT部門殿とそこから設計・開発等のSIを受託するベンダーさん。
お互いにはそれぞれITプロジェクトを企画・立ち上げ・実行・展開していくための方法論（注：完成度は別として）があり、それに基づきプロジェクトの方針が随時打ち出されていきます。
ところが、
「用語」の意味がかみあわない。
たとえば、
「要件定義」と「外部設計」
どこまでが「要件定義」でどこからどこまでが「外部設計」か？
委託先と委託元でその言葉（この場合まずはフェーズ定義になりますが）の意味に齟齬が生じていたりします。
それぞれの自社内にはそれまでの文化・慣習・経験があり、
何を決めることが要件定義の目的で、
それらはどんな成果物にどのくらいの粒度で記述さればいいか、
について、従来の「認識」が存在しますが、
プロジェクトというのは、「特定目的のために複数の会社・組織が一体に編成されたライフサイクル（始まりと終わり）がある活動」」と言うことができますから、
どちらかの会社にとって、従来「当たり前」と思っていた決まりごとが、もう一方ではそうでなかったりします。
したがって、
「ここまで定義して欲しかったのに、記述が足りない」
「こんなに詳細にしたら時間かけすぎだし、あとで変更入って手戻するに決まってるじゃん」
みたいなやりとりが不幸にも発生してしまうことがあるのです。
その企業さん特有の、あるいは業界特有の専門用語は、最近は「用語集」を作ってプロジェクトメンバーに周知することはまあまあ定着してきましたが、
どうも最近、これまでは（少なくとも小生は）基本の１つと信じてきた、
１）工程の定義
２）タスクの定義
３）そのタスクの実施手順（フロー）
４）タスク毎に必要なインプットと想定アウトプット（成果物）
５）これらを推進していく基本的なプロジェクト体制と主たる各自の役割・必要スキル
６）これらをプロジェクト管理していくマネジメント方針や管理文書様式
について、
各所に登場する「用語」について、依頼先と依頼元の理解するそれらの意味に、本当に違いがないのか？・・・これについて用語集というか「言葉あわせ」が必要だなあと痛感します。
こんなことを言うとうちの社長に怒られそうですが<(_ _)>、我々が呼ばれるのは、いろいろ問題を抱えて、採算なんかよりこのプロジェクトを「ちゃんと建て直し、無事に終わらせたい」という思いから依頼されてきたお客様の期待にこたえるべく、相当な覚悟と徹底した献身的姿勢で現場に入っていくコンサルタントが登場する必要性があるわけで、
本当は、
そんなことがなくなってしまってもらったほうが、IT業界のためにはいいことなんです。
あーっ！と思い当たる方は是非、周囲をみわたし、ご自身の立ち振る舞いを見直し、巨大な投資にはならないはずなので、この点を是非、熟考いただいてそのプロジェクトを自助努力で改善していって欲しいです。
（とはいっても、どうしても、専門的な解決屋がご所望でしたら、いささか不謹慎ですが^^;、弊社不肖までご用命ください・・・・・・・）
| « 2007年3月8日 | 2007年3月9日の投稿 |
2007年3月12日 » |
顧客に“ワォ！”という体験を提供――ザッポスに学ぶ企業文化の確立
ちょっとした対話が成長を助ける――上司と部下が話すとき互いに学び合う
悩んだときの、自己啓発書の触れ方
考えるべきは得意なものは何かではなく、お客さまが高く評価するものは何か
なんて素敵にフェイスブック
部下を叱る2つのポイント
第6回 幸せの創造こそ、ビジネスの使命