2009年3月アーカイブ

あまりITプロジェクトで見た目のデザインについて触れることって少ないですが。

業務アプリケーションは人が毎日見るものですし、判り易くて使いやすい、スタイリッシュなインターフェースを提供出来るとユーザも喜びます。

入力項目がたくさんあって、見ただけでうんざりするような画面ってけっこうあります。

デザインがいいと、ユーザーのモチベーションにも影響するものです。

単に見た目がかっこいい画面を作るというのではなく、業務用途に応じた画面デザインが必要だと思います。見た目が良くても大量入力が必要な画面ではパフォーマンスが重要だったりしますしね。

業務判断を促したり、入力ミスを減らすという観点で画面デザイン・機能を見直すと出来ることがたくさんあります。

なかなかプロジェクト組織の中にデザインチームを持つのは難しいですが、開発会社としては差別化できる要素なんじゃないかと思っています。

 

プロジェクトが成功するかどうかは、実は委託者側の問題にけっこう依存する部分が大きいものです。

プロジェクトの成否は要件定義の質で40から50%程度決まります。

要件の定義はレベルの大小はあってもプロジェクトの開始から終わりまで発生してきます。

プロジェクトの開始には、そもそも何を実現したいのか?どのくらいの予算でやりたいのか?

といった要件から具体的な業務・システムのスコープの決定に始まり、どのように業務を変えるのか、システムをどういった機能にするのかといった詳細な部分にいたるまで。

さらには運用や移行の要件などもしっかり決めておかないと問題になります。

《システム開発の受託者によっては、これらの決めるべき(あるいは決めておいた方がトラブルを防げる)要件を事前に聞かない(多くの場合は気が回らない、ノウハウが無い)ケースがありますが。》

 

よくありがちなのが、予算とスケジュールと、おおざっぱなシステム機能だけは決まっていて、いざプロジェクトが始まると社内で要件調整に手間どり、いたずらにスケジュール・予算を無駄にしてしまい開発予算が足らなくなるといったケースです。

これは委託者がシステム開発に対する認識が甘く、きっちりとした体制を組まないケースに多くあるように思います。業務システムの開発は要件を決めることやテストにおいて自社のメンバが必須となる作業があり、ここが非常に大きなポイントとなる事を認識する事がプロジェクトの成功への早道です。(受託者は委託者の巻き込み、啓蒙活動が重要です)

委託者の体制にITプロジェクトの経験豊富な人材を入れる事も大きな違いを生みます。

自社体制で不足している場合には外部のプロジェクトマネジメント支援を行うコンサルタントを活用するのもお勧めです。

プロジェクトの体制はプロジェクトのライフステージで変わっていきます。

設計・開発を行うメンバーが自分の担当分だけでなく全体の業務やシステムについて理解を深める事で設計・テストの品質が向上します。(効率アップも期待できます)

プロジェクトライフステージの中で状況に応じてプロジェクトメンバに対して、プロジェクトの全体像を説明する機会を意図的に設け、初めから計画に入れておくと良いと思います。

また、プロジェクトの共有フォルダには、読んで理解できる資料一式(用語集を含む)を格納し、新しいプロジェクトメンバが速やかに入れるように最初から考慮しておくと良いでしょう。

 

オープン系システムで構築するプロジェクトの場合、よくある事ですが技術要素の組み合わせで社内で実績が無いような場合(ソフトウェアのバージョンの違いも含む)はプロジェクトの初期段階で検証チームを編成し、アーキテクチャを固める事をお勧めします。

プロジェクトの開発が進んでいざテストを実施したら技術的な課題が出たというケースですとプロジェクトの進捗や予算への影響が出てしまいます。

また、技術検証を行う上で基本となるコーディングなどが終わっていれば開発が本格化する際に効率よく着手できます。特に大規模なプロジェクトで1週間程度のロスはコスト的にも非常に痛いので、いかに効率よく開発を軌道に乗せるかという観点が重要です。

PMBOKの普及もあってか、企業統制が求められているのもあり、プロジェクト管理の標準化意識を持つ会社が増えています。

これについては良い事ではあるのですが、標準化作業を実行中のプロジェクトで実施しようという判断をされるケースがあったりします。

プロジェクト管理の標準化のたたき台があって、現場での適用を試験的に行うのではなく、プロジェクトの現場で標準化作業を進めようとするものです。

これが当初計画からのものでプロジェクトの体制・予算・スケジュールに織り込み済みであればいいのですが、そうでないとプロジェクトの現場は相当な負荷がかかるリスクがあります。

(気持はわからないでもないですが。。。。)

 

ところで、この「プロジェクト管理の標準化」って、出来ている大企業はけっこう少ないです。

さらに言うと、標準化があっても適用されない、あるいはガチガチで柔軟性が無いといった問題がある企業も多いです。

「標準」といっても決められた方法に必ず従って実行するというのではなく、標準の管理法があって、それをプロジェクトにあった形でアレンジする必要があると思います。(それがプロジェクトマネジメントの腕という気もしますし)

そのアレンジの幅をどこまでプロジェクトによって認めるのかが企業風土の反映という気もします。

 

 

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

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

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

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

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

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

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

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

 

このアーカイブについて

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

前のアーカイブは2009年2月です。

次のアーカイブは2009年4月です。

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

メルマガ登録・解除
 

ウェブページ

Powered by Movable Type 4.1