組織・体制の最近のブログ記事

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

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

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

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

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

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

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

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

 

業務アプリケーションを導入するにあたり、現場の業務担当者

あるいは責任者にプロジェクトへ参画してもらうのは、とても重要です。

 

場合によっては「現場の意見は聞かない」というプロジェクトも存在しますが、

よほど業務に精通している方が主導している場合でないと、

「使われない」「業務負荷の高い」システムになるリスクを高めてしまいます。

 

現場の方はたいてい、自分の利用しているシステムが改善されるなら

積極的に時間を作っていきたいと考えています。

しかし、単純に時間が無い、評価の対象外、過去のITプロジェクトへのネガティブなイメージなど

様々な理由から業務側の主体的な参加を求めるのが難しい場合があります。

 

このような場合、ひとつのテクニックとして、業務側の責任者を明確にし、

プロジェクトの全体スケジュールの中で業務側のタスクを明示的に示し、他タスクとの関連を明確にする事です。

 

プロジェクトの進捗を業務責任者と共有し、業務側の遅延がプロジェクトの遅延理由になりそうな場合に、業務責任者にとってのプロジェクト関連のタスク重要度が自然と上がるはずです。

 

 


モチベーションと組織体制というのは、けっこう密接な関係があります。
プロジェクトにおいて、どのような体制をデザインするのか、プロジェクトの特徴や人材によって様々ですが、忘れずに行いたいのが各サブ組織のミッション定義です。
タスクの定義でなく、ミッションの定義というのが重要です。
プロジェクトは生き物ですから、タスクはいくらでも変化します。
人に与えられたタスクをこなすのと、ミッションを与えられて何をすべきか考え行動するのでは、おのずとモチベーションが異なります。
また、タスクが頻繁に変わることを他者の問題であるとしてしまい、モチベーションの低下を招きかねません。

ミッション定義はマトリクスな組織においては特に重要です。
ITプロジェクトでは業務単位、技術要素単位、地域単位などで組織分けが行われますが、プロジェクト規模が大きくなるとマトリクス的な組織設計をせざるをえません。
このような場合に指示系統が煩雑だとプロジェクトメンバのモチベーションは著しく低下します。
ひとりの人間が複数の人からタスクを指示するような状況でタスクのボリュームや優先度を決めてあげないと最悪です。
(よく、プロジェクトの雑務をお手伝いするヘルパーさんにありがちな状況ですが。。。)

まぁ、そこまでのケースはあまり無いでしょうが、マトリクス組織になると、お互いのチームのタスクだと思ってタスクが漏れる、もめる、等がありますが、
チームミッションを定義しておくと比較的に責任範囲、指示系統などが整理されます。

このアーカイブについて

このページには、過去に書かれたブログ記事のうち組織・体制カテゴリに属しているものが含まれています。

前のカテゴリは見積りです。

次のカテゴリは方法論です。

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

メルマガ登録・解除
 

2009年3月: 月別アーカイブ

ウェブページ

Powered by Movable Type 4.1