忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
1  2  3 
 喫茶店等で何事か熱心に話し合っていると言えば、以前は生命保険か先物取引の営業と決まっていたものでした。しかし、ここ数年でこれらを圧倒するグループが出現しました。それは、IT事業者です。
 
 しかも、生命保険や先物取引では、どことなくヒソヒソ話であったのが、IT事業者の場合、固有名詞や具体的数字の入ったスライド資料が上映され、進捗遅れの原因やシステムの欠陥が声高に語られます。その場にいない者との携帯電話での会話は、ますます声高になり、店内に響き渡ります。
 このようなIT事業者の「公開業務」は、以前から見られなくはありませんでしたが、普通の顧客は相手にしないような(Tシャツ姿の?)個人事業者が仕事場代わりにするくらいのものでした。しかし今や、それなりのプロジェクトに関与している(立派なスーツ姿の?)事業者が、自社の会議室であるかのように振る舞っています。これでは、顧客としても避けようがありません。
 このようなことが一種の流行なのだとすると、同じことが他の業界であっても不思議ではありませんが、金融業界でも不動産業界でも流通業界でもアパレル業界でも、絶えてないようです。IT業界は、要らぬところで「オープン」にしたがるようです。

拍手[0回]

PR
author : ITS 
 言うまでもないことですが、開発プロジェクトにリスクは付き物です。QCDを考えるだけでも、品質不良リスク、コスト超過リスク、納期遅延リスクがあります。そればかりでなく、目的不達成のリスクやプロジェクト自体の破綻のリスクまであります。そこで重要となってくるのがコントロール、その手段として出てくるのが契約やプロジェクト計画での「義務づけ」です。

 QCDはもちろんのこと、プロジェクトの目的達成や完遂は当然に契約上の義務となります。これらを支えるベンダのプロジェクトマネジメント義務、ユーザの協力義務も、契約上の義務として認められています。また、プロジェクト計画のレベルでは、双方にさまざまな行動義務が規定されます。しかし、プロジェクトのコントロールがこのような「義務づけ」だけで事足れりとするのは、実にナイーブな考え方と言わざるを得ません。
 相手方に義務を課すと一見、自分のリスクが軽減されるように思えますが、これは大きな誤りです。相手方にリスクを移転しただけのことであれば、プロジェクト全体のリスクは変わらないからです。むしろ、不自然・不合理な配分では、全体のリスクが増大するかも知れません。プロジェクトが失敗してしまえば、その後の損失配分をどうしたところで、もはや回復できません。
 より重大なのは、「義務づけ」しただけでは履行される保証がないことです。契約書やプロジェクト計画書に書いただけであれば、借用証一枚で大金を貸し付けるのと大差ありません。ビジネスの世界で担保(あるいは何らかの保証)のない取引は殆どあり得ないことですが、開発プロジェクトではなぜか「無担保取引」が横行しています。無担保どころか、初めから返済見込みのない貸付までが行われています。
 「義務づけ」の発想は、火災リスクは保険を買ってひとまず終わり、為替リスクはオプションを買ってひとまず終わり、とするようなものです。開発プロジェクトには保険もオプションもありませんが、これはリスク自体が不透明で誰も売り手にならないからです。そして、リスクが不透明なのは、それが買い手の側の行動に全面的に依存するからです。逆に言えば、買い手の側を含めた継続的なコントロールが可能であり、また決定的に重要だということです。

拍手[0回]

author : ITS 
 世の中に、標準やガイドラインの類は、数多くあります。IT関係でも、昔からシステム開発方法論というのがありましたし、共通フレームやモデル契約書なども、その範疇に入るでしょう。

 これらの「出来」そのものは、それぞれでしょうし、人により考え方により、評価も異なることでしょう。しかし、これらの全てに共通する、最大の欠点があります。それは、大部に過ぎることです。
 これはある意味、避けがたいことではあります。標準やガイドラインを謳って世に出す以上、最大規模のプロジェクトで利用される可能性がありますから、あれもこれもと詰め込みます。プロジェクトの性質も多岐にわたりますから、最大公約数的に論点を取り込もうとします。学術的(?)にも、せっかく考察した論点を切り捨てるのは、忍びないことでしょう。何より、ガイドラインには、網羅性の要求があります。項目を落とせば、「欠けている」、「不完全」との批判を受けかねません。
 しかし、実務では、大部過ぎるガイドラインは、かえって役に立ちません。不可欠の5項目、10項目をどうしようかと躍起になっているところで、300項目のガイドラインがあっても、使いこなせません。これは特に、中小のプロジェクトあるいは企業という、最も手助けが必要なところでの偽らざる実感でしょう。さりとて、あえて絞り込んだガイドラインを世に問うのも、かなり勇気が要りそうですが...

拍手[0回]

author : ITS 
 議事録の重要な役割は、エビデンスとしての役割です。後になって蒸し返しのようなトラブルがあった時に、議事録によって既決事項であることを示せれば、交渉力が違ってきます。もちろん、訴訟になれば証拠にもなります。スルガ銀行と日本IBMの訴訟でも、議事録が証拠として重用されていたことは、記憶に新しいところです。

 議事録で一番の問題は、会議で重要な決定があったのに、議事録がきちんと作られていないというものです。つまり、事実に対応するエビデンスが欠けているという場合です。それでは会議をやった甲斐がありませんから、議事録の作成を励行すべし、ということになります。それはそれで、正しいことです。
 しかし、逆の問題もあります。議事録は一応作られているのに、実態がそれに追いついていないという場合です。例えば、ベンダが重要なシステム方針について資料を作り、会議でさんざん説明して異議は出ず、議事録も作って承認をもらい、その後数か月かかって設計と実装を進めた。ところが、システムが出来上がった段階で話を蒸し返されて、議事録を示しても、「当時は良く分かっていなかった」などと言われてしまう...
 もちろん、この場合の責任は、既決事項を蒸し返したユーザ側にあります。そのような勝手が許されるものではありません。しかし、この段階になって責任論を云々してみても、ユーザが当初の方針に本当に納得してないのなら、事は収まりません。既決事項と言えるほどに機が熟していなかった場面での「エビデンス」は、裁判の証拠にはなるかも知れませんが、事後のトラブルに対する抑えにはなりません。残念ながら、トラブルの種でしかなかったわけです。
 これと似た話に、議事録の「みなし承認」というのがあります。「1週間以内に議事録案の確認がなされなかったら、記載どおりに承認したものとみなす」という取り決めです。これで承認する側の意識が高まれば良いのですが、逆に承認を求める側の詰めが甘くなりそうです。会議で苦労して「言質」を取ったと考える担当者は、議事録確認の段階でそれを覆されたくないと考えます。そうすると、議事録案を作成して1週間経った時点で、胸をなでおろしてそれで終わりにしてしまうでしょう。同じ蒸し返しをされるなら、実装後よりは会議直後の方がはるかにマシなわけですが、その「機会」は失われてしまうわけです。

拍手[0回]

author : ITS 
 ベンチャーに限らず、初め小さかった企業が成長していく過程には、様々な「テイクオフ」があります。外部から人を招き入れる、新たな店舗や工場に投資する...株式上場はテイクオフと言うより、一つの目標であるかも知れません。これらは、伝統的なヒト・モノ・カネに関するテイクオフですが、情報システムにも、どこかで乗り越えなければならないテイクオフがあります。

 今や、企業と呼べるほどの組織であれば、情報システムなしでは済みません。そこで、起業の際のゴタゴタの中、あるいはそれが一段落してから、必要に迫られて、ともかく業務を回すために、必要最小限のものを備えます。しかし、当初は必要最小限だったものが、やがて、メンテナンスを繰り返し、至れり尽くせりの「サボテン」システムに成長していきます。知り合いの技術者であれば無理も利くし、データ量も少ないし、セキュリティもそれほど気にしないから、それが出来てしまいます。
 しかし、次の二世代目の情報システムが必要になるほど成熟したころには、もはやそれは出来ません。普通の(しかし、無理のきかない)ベンダに、普通の(しかし、融通のきかない)開発手順で、普通の(しかし、初代より機能が低い)情報システムを開発してもらうしかありません。次のステップに進むはずの二世代目の開発が、一見すると後退であるかの様相を呈します。システム開発の過半数は、QCDの何れかに問題があると言いますが、このようになってしまった開発では、おそれらくQCDのすべてに問題を来たすでしょう。だからこそ、これを乗り切ることがテイクオフなのですが。

拍手[3回]

author : ITS 
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin