企業システムの構築プロジェクトにおいて、システム開発を委託する会社は、開発会社の選定をしてお金を払えは終わりというものではありません。

特に大規模なプロジェクトであれば専属のプロジェクトメンバをアサインするべきだと思います。

このような場合に、どのような人間を社内からプロジェクトメンバとして入れるべきかという質問があります。

システムの品質を決定づける要件定義をスムーズに、そして精度高く実施するにはシステム要件をとりまとめる人間と業務要件を出す現場とのスムーズな連携環境を構築する必要があります。

業務改革の伴うシステム構築では時に現場の思いと衝突があったりしますし、日常の業務の中でプロジェクト作業をこなすという負担増もあり、現場の理解を得るための人間力や社内ネットワークがある方がプロジェクトマネジメントチームにいると非常にプロジェクトの進捗にメリットがあります。

若手は将来を有望視される、いわゆるホープを選ぶべきでしょう。

全社プロジェクトであれば社内を横断的に知る良い機会ですし、様々な事を俯瞰できる能力が身につきます。また、プロジェクトとしても現場の業務を深く理解している視点から様々な業務要件・システム要件を検討できるので創り上げるシステムが大きな成果を出しやすくなります。

ただ現場作業に影響が出てしまうので、社長からのトップダウンで業務部署からの理解を得ることが望ましいでしょう。

 

プロジェクトは何も問題が起こらないという事は無いものです。

何か問題が起こった際に問題の発生原因や誰が悪いといった事にフォーカスしすぎないで速やかに解決に向けて指向する事がリーダーの重要な役割です。

プロジェクトで何が起ころうと、部下のワーニングを見過ごしたり適任者をアサイメントできなかったり、マネジメントが原因であったりと行き着くところはプロジェクトのリーダーが悪いのです。

何かの問題の原因や責任を追及しても問題の解決にはなりません。

期間の限られたプロジェクトで問題解決を脇において問題にばかりフォーカスしているのはリーダーとしては無責任です。

また、どんな組織でもそうでしょうが、問題の責任ばかりを問うと部下は責任のある仕事をしなくなります。自分のタスクとして明確にされていない仕事を拾わない組織は、プロジェクトとしては致命的に弱い組織になってしまいます。

 

 

やっていて当たり前のようですが、以外とできていないのが「仕様変更管理」です。

設計の変更要因は仕様障害、要件もれ、仕様の詳細化不足など様々ですが、仕様変更で一番やっかいなのが、設計書の記載レベルが粗すぎて仕様変更なのかどうか揉めてしまうケースです。

「仕様変更」というと直接コストに跳ね返るような気がして、誰の責任なのか、といった話になりやすく仕様変更依頼をあげずに仕様変更をさせようとするケースもあったりします。

仕様変更管理はなぜ必要なのか、どういう目的で行うのかを明確にしてプロジェクトに適用できれば良いのですが、プロジェクト外部の方も含めて理解を完全に得て進めるのは難しい場合もありますね。

仕様変更はプロジェクト記録、情報共有という意味合いを強く出す方が、スムーズに運用に乗ると思います。

仕様変更の管理を行わないプロジェクトでは、担当者レベルの判断で項目の追加や動作の変更を行いシステムの全体整合性がいつの間にか損なわれるというが起こります。

こういう状況が発生しだすと、大規模プロジェクトでは底なし沼に陥るようなものです。

仕様変更の発生がむやみに現場レベルで行われないこと、そして発生した変更内容をプロジェクト内で共有できる事が重要な目的のひとつです。

それから、プロジェクト記録として重要な役割があります。

プロジェクト実施中に「いつの間にか」仕様が変わってしまう事をゆるすと、承認された設計書の位置づけがあいまいな物になってしまいます。

現場の担当者がユーザに求められて対応を行った仕様変更が、後に元の(承認された)仕様で無いことが問題になった場合、開発者側が元に戻すことを求められるリスクがあります。

設計書や仕様書を仕様変更のたびに書き換え、それを版変えして再承認を得るという運用は無理に近いので、仕様変更管理の運用を行います。

コストマネジメントの観点でも、重要です。予算内で対応できるのかどうか、対応の重要性はどうなのかといった事を常に把握できるプロセスを構築できるのです。予算超過するかどうかは予算根拠からの乖離について常に意識を向けているかが重要です。

 

 

 

 

 

 

 

プロジェクトに属するメンバ、あるいはチームに対してタスク分担が明確であることは重要ですが、これだけでは、うまくいかない場合があります。

プロジェクトのアクティビティはすべてWBSに落ち、それぞれに担当がふられるのが「あるべき」運営なのかもしれませんが、実際問題としてWBSに定義されていないタスクがあった場合に誰がそのタスクを拾うのでしょう?

プロジェクトは予期しないことが起きますし、たいていの場合は予定どおりにすべてが実行されるという事はありません。キーパーソンが退職する事もあれば、法律改正や企業統合がいきなり起こる場合もあります。このような変化に常にさらされるプロジェクトという組織体では個々の担当者のタスク定義の前にミッションを明確にする事が重要です。

ミッションで動く組織は柔軟で、そしてモチベーションが高く維持される傾向にあります。

 

開発者が大勢参加するプロジェクトでは開発規約を用意するのが普通ですが、意外とコーディング規約や開発に関する決めごとをしっかりと定めてプロジェクトを実行しないケースがあったりします。

命名規約、コーディング規約等を定めることは開発品質だけでなく保守の際にも理解されやすいという点で非常に重要です。

技術要素などに統一性があるような場合は社内の開発規約を統一する事が出来るのでベターかもしれません。ただし、プロジェクト独自の部分が大抵の場合はあるので、プロジェクト用として改めて定義するのは必要なタスクだと思います。

特にアーキテクチャの設計思想とアプリケーション開発の思想が一致して整合性を保たせるには明文化しておく事が必要だと思います。

開発会社へ開発委託するようなケースは予め決められた規約に従うようにRFPに記載しておけばスムーズです。

開発規約はプロジェクトに参加する設計・開発者すべてがスムーズに理解できるという事が何よりも重要です。

規約の類は理解しずらければ意味をなしません。

「使いやすく、わかりやすい」が開発規約のキーワードです。

 

 

一般的に(特に大企業では)情報システムは業務インフラでもあり、経営力が仕組みから強くしている会社では情報システムも非常に革新的である場合が多いと思います。

ITが経営のすべての悩みを解決するわけではありませんが、経営のボトルネックを解消する事は可能です。

経営者は経営のビジョンを伝え、それを企業システムに落とし込む事ができれば理想なのですが、実際には情報システムは各部署からの要望を個別に引き上げ対応を行うというケースが多いのではないでしょうか。このような結果、経営方針との乖離したシステム、個別最適化された無駄の多いシステムが出来あがってしまいます。

このような状況を防ぐには経営、業務そして情報システムに明るく、俯瞰する能力を持った人材がいる事が望ましいのですが、なかなか一般の企業のキャリアパスでこういった人材を育てるのは難しいようです。

しかしながら、経営において情報システムを重要なものであると位置づけるかどうかは経営者の意思が反映されます。総務部情報システム課と社長室情報システム部では自ずとミッションが異なってきます。

情報システムのオープン化でTOC削減といった時代では無いと思います。

ビジネスイノベーションを実現させるためのIT、それを支える人材改革はまずは経営者の意識改革から始まるのは間違いないと思います。

 

一般的にプロジェクト監査といわれるサービスがありますが、弊社ではプロジェクトレビューというサービスを行っています。

なぜ、「監査」ではないのか?

自分自身がプロジェクトリーダーで「監査」を受けた経験からいうと、プロジェクトマネジメントをやった事が無い方に監査事項をチェックされて報告されても。。。(失礼!)

実際問題として何を目的としたサービスにするか、という事がポイントかと思いますが、監査というのはあらかじめ決められたルールにのっとっているか、あるいは一般的な監査ポイントとの適合や報告内容は正しいかという観点でチェックが行われます。

これはこれで、価値はあるとは思いますが、私が行いたいのは実質的なプロジェクト品質の改善につながるレビューの実施です。

プロジェクトの現場が見落としているリスクや、改善すべき内容について自らプロジェクトを行ってきた経験に基づき指摘を行うものです。

プロジェクトおよびクライアントの未来利益を守る非常に価値の高いサービスだと思っています。

 

特に大規模なプロジェクトですとプロジェクトの初期段階で認識していれば大きな問題にならなかった事が後になって大きな問題となる事が多々あります。

状況に応じたリスクの把握と対策を経験豊富な第三者からの指摘に基づいて行えればプロジェクトのリスクは大幅に軽減すると思います。

実際、前職でプロジェクトレビューを行っていた際にレビュー参加に積極的で指摘事項を改善できるプロジェクトは大きな問題が発生しませんでした。

 

基幹系のシステム開発で実施するテストは色々なやり方がありますが、業務視点からデータのライフサイクルを追って検証を行う方法にシナリオテストがあります。

これは業務一覧や業務機能定義を元に主だった業務プロセスを洗い出し、さらに業務処理、データ処理の観点から検証すべきパターンをシナリオ化していきます。

シナリオを一覧化したら、各シナリオで使用するデータやスケジュール、検証ポイントを定義し、シナリオテスト実行のスケジュールを明確にします。

テストの目的にレアケースの運用処理の検証を加えても良いので、気になるシナリオは検証した方が良いでしょう。

基本的には業務観点から出すべきですが、システム処理の観点から検証シナリオを出す事も含めると良いと思います。このようなケース出しは設計段階に洗い出すとフレッシュな状態で出てくるので負荷も比較的低くなります。

 

あけましておめでとうございます!

年明けにシステムがカットオーバという方は年末年始大変ごくろうさまでした。

私も年明けにシステムを切り替えるプロジェクトをやったことがありますが、年末にプロジェクトメンバに休みをあげられなくて非常に申し訳なく思いました。

そういう経験も過去の事になると良い経験のように思えてしまいます。

そういえば2000年になる年末はシステム関係の方はかなり待機組を含めて影響を受けましたね。

これも、今では笑い話のようなものですね。

 

さて、新年です。

あまり景気の良いニュースはありませんが経済はメンタルな部分が大きいので明るい気持ちで新年を過ごしたいものです。

今年は初日の出を見に行きました。

雲があまりなく、良い初日の出でした。

きっと良い一年になると思います。

今年もすべてのプロジェクトが良き成果を出せますよう、本年もよろしくお願いいたします。

ITプロジェクトを実行する上では関連する部署が複数あり、様々なタスクを各部署に依頼する事があるかと思います。

各部署は通常業務が行われていますので、プロジェクト実行に関するタスクはなるべく平準化したいですし、業務の多忙時期には対応できなくなります。

プロジェクトはこれらの業務多忙期への配慮を行う事も大事ですし、依頼を行うことをとりまとめ、管理を行う必要があります。

関連部署では、プロジェクト実行のどの時期あたりにどういったタスクがあるのか理解し人員の手配なども行う必要があるからです。

意識的に管理を行わないとプロジェクトの各担当者が個別にぱらぱらと依頼が行われる形になってしまいかねません。

指示系統の混乱などによる各部署からの反発を避けるためにも、依頼事項を各部署の管理責任者にあらかじめ伝え個別調整に入ることが重要です。

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1