2008年10月アーカイブ

文部科学省が進めているソフトウエア関連の研究開発プロジェクト「StagEプロジェクト」は2008年10月29日、
ソフト開発状況を"見える化"するための「ソフトウェアタグ」規格の正式版をVer1.0として公表しました。


このプロジェクトは、『要件定義、開発、実装、テストなど一連のソフトウエア開発工程の状況を発注者が把握できるようにするのが狙い』という事で、開発の効率化や品質への貢献といったものが狙いではありません。

あくまで状況を可視化するというものなので、そもそもの設計や要件定義の誤り、その他見落としがあった場合は救われず、これが普及したとしても「大規模システム構築における発注者の漠然とした不安」というものが無くなるとも思えません。

しかしながら、今後予測されるオフショア開発の拡大においては、管理に貢献する可能性があると思われます。
といっても概念だけなので、実際に使ってみないとなんとも言えませんが。。。

 


『グリーンIT』という言葉を最近よく目にします。
『2000年問題』『ITコンプライアンス』などのようにIT業界が製品や
サービスを売るために創った大義名分なのかな、と思ってますが、
実際はどうなのでしょうか?

グリーンITという言葉の正確な定義は良く知りませんが、ITに環境配慮の
考え方を適用し、様々な形で使われています。
例えばIT製品の生産・流通・リサイクルなどにおける環境配慮から
消費電力の削減、データセンターの利用電力を自然エネルギー化することから
さらには個人のカーボンオフセットのためのWebサービスなどなど。


実際問題として、大企業は環境面への取り組みを真面目にやらないと
ならない時代ですし、実際に多くの企業が環境への取り組みを毎日
コマーシャルで宣伝しています。

従来、費用対効果の問題でIT化されなかった部分も環境への貢献という別の
視点からIT化が必要とされる可能性はあります。
そういう意味では価値観のシフトが新たなマーケットの創造につながると
いう事になりますね。

アイブルームも環境に強い関心のあるメンバが揃っているので
我々なりのグリーンITを世に送り出したいものです。

 

 

改革のテーマを実際の現場に落としていく際に、プロジェクトオーナーが
実際の現場のリーダーと改革の実現イメージを共有できない場合、
プロジェクトの実行は非常に困難なものになります。

コンサルタントが現場のリーダーと一緒に計画を作成しても、オーナーと
意識があっていない限り、内容は評価されません。
また、オーナー側の考えをコンサルタントが無理やり現場リーダーを含めた
クライアントのメンバに伝えても反発され、何もできあがりません。

このような状況になるのは、コンサルタントが自分で改革のイメージを
発信していない、あるいは共有できていないからです。


 

広告を見て商品を購入した場合、期待を超える商品であった場合に満足するかと思います。
期待は広告によって作られるので、過剰な期待を持たせる広告は商品力があっても
期待に届かず、満足できずに文句を言ってしまいますよね?
マーケティングでは期待を抱かせないのは当然NGとして、過剰期待を抱かせる広告もNG
なのです。

コンサルティングでも、クライアントが期待する結果を超える事が満足度につながります。
コンサルティングで異なるのは、最初の営業段階での期待値のマネジメントだけではなく、
常に期待値、スコープのマネジメントを行うチャンスがあり、逆に言うとキッチリやらないと
せっかく良い仕事をしてもクライアントの満足を得られないという残念な結果になりかねません。

 

今まで多くのプロジェクトに携わってきたので、
プロジェクトがうまくいくかどうか、良い状態かどうかというのは
理屈よりも先に肌で感じられます。

前に勤めていたコンサルティング会社のプロジェクトレビューアとして
様々なプロジェクトを見た経験もあるのかもしれません。

プロジェクト監査というのがありますが、私自身がマネジメントをする
プロジェクトも監査を受けた事があります。

しかし、実際にITプロジェクトのプロジェクトマネジメントを行ったことが
無い方が監査をするケースが多く、実質的なレビューにならないという印象を受けました。
もちろん、何もしないより、リスクは低下するのでしょうが、監査を受けるプロジェクト側に
負担がかかる事なので、「わかりきっている指摘」より、「気づきをもらえる指摘」が
欲しいところです。


私自身がプロジェクトマネジメントの支援を行う際には、実質的なマネジメントの
改革を心がけるようにしています

 

ウォーターフォールでプロジェクトを進めて行くと、ほぼ間違いなく仕様の変更や追加などで
前のフェーズの成果物に影響のある修正が発生すると思います。
例えば基本設計書の内容に変更を加えないとならないような場合、基本設計書をバージョンを
あげて変更するかどうか、その場合、誰が行うのかという議論はあらかじめ行っておくと
後々トラブルになるのを防ぎます。
システム開発において設計書のメンテナンスはかなり工数がかかるため、設計書のメンテナンスを
開発ベンダーに委託するとシステムコストの増加の原因にもなります。

プロジェクトによっては、基本設計書と詳細設計書の不整合を防ぐために「システム設計書」という
ひとつの成果物にしてしまうケースがあります。
この方が設計書のメンテナンス漏れや整合性確認などの手間が省けるというメリットがあります。

設計書については、各企業で求めるものがあるので、どうあるべきかを一概には決められませんが、
変更がある事を前提に、どのような方針で進めるかを予め決めることは大事ですが、意外に忘れがちな
ポイントかもしれません。


 

前にも書きましたが、部分最適を追求すると必ず全体最適からはずれます。

プロジェクトを実行する上で個別のチームスケジュールの最適化を優先すると全体スケジュールは

伸びます。

大規模なプロジェクトで複数の会社が関わるようなプロジェクトの場合、各企業は各契約の中で

最適なスケジュールを組むため、プロジェクト全体の最適化は、ほっておくと実現しません。

 

プロジェクトマネジメント側が意識的に全体最適のための調整や指導を行っていく必要が

あります。お金が関係してくるので、早めに意識的なマネジメントが必須です。

 

 

ついに日経平均が終値で1万円を割りました。
952円安は戦後で3番目の下げ率だそうです。

今回の金融危機は、間違いなく長引く事でしょう。
米国経済の悪化だけでなく、来年にはヨーロッパにかなりのダメージがおよぶと思います。
外需頼みの日本経済は、このままでは大変なダメージを受けてしまいそうです。

私のクライアントも急激にIT投資予算が減ってしまったというお客様もいるのでIT業界にも影響は
出てくるのではないでしょうか。


そんな中、明るい話題がありました。
ノーベル物理学賞を日本人3名が受賞されたの事。
資源の無い日本を発展させるにはイノベーション力を向上させることだと思います。

不景気には不景気時なりの経営があると思います。
ピンチをチャンスに変えられる、そんな経営者がたくさん誕生する時代にさしかかっているのだと思います。

 

ITプロジェクトの失敗は要件定義の精度やスケジュールの遅れが原因である場合がほとんどではないかというくらい多いです。
原因は様々あると思いますが、ひとつは要件定義をするノウハウを持った人材の不足だと思います。
プログラムなどの技術は本でもセミナーでも学べる窓口は広いのですが、要件定義は経験していかないと難しい部分が多々あります。
いかに要件を整理し、システム構築コストと運用コスト、実行性を考えて最適化するかといった事はなかなか難易度の高いものです。
ここにユーザが非協力的だとプロジェクトは困難さを増します。

・ユーザの意見がまとまらない
・ユーザが時間を作らない

こんな事は良くあることです。

しかし業界的にも要件定義に時間とお金をもらえないという事も実は大きな問題だと思います。
というのは、ユーザがシステムを欲しいと言いだした時、あまり根拠もなくカットオーバの
スケジュールだけが決まっていたりします。

そして後ろからスケジュールを組み立ててムリな計画をたててしまいます。
ムリな計画でプロジェクトが失敗しても結局は誰もハッピーになりませんが、これが大規模な案件ほど多かたりします。
ムリを無理でなくす方法もありますが、そこにはそれなりのシナリオがなければなりません。

このアーカイブについて

このページには、2008年10月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年9月です。

次のアーカイブは2008年11月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1