プロジェクトチームに付きまとう制約を打破するために：ユーザーサイド・プロジェクト推進ガイド（6）（2/2 ページ）

[山村秀樹，＠IT]

時間を調達する

　プロジェクトチームが（4）の実習生タイプとして頑張るためには、周囲にシステム開発を理解してもらうよう働き掛けて“時間を調達する”ことが必要です。これに関しては第4回「不良システムを作らないプロジェクトの枠組み」も参考になると思います。また、その一方で、時間を無駄遣いしないようスキル習得に努めたり工夫したりすることも必要となります。

　システム担当部署か業務部門かにかかわらず、IT化の体制や人材確保について問題を認識している人は多いようです。しかし、トップマネジメントがIT人材育成を課題としている企業は少ないのが実態のようです。これは、トップマネジメントがコンピュータ活用──すなわちコンピュータがビジネスに対して及ぼすインパクトについて関心が低いことを示しています。システム担当部署はもう少し声を大きくする必要がありそうです。

　最近になって企業の不祥事が噴出し、コンプライアンスの重要性が強調されるようになっていますが、これは不祥事の数が多くなっただけではなく、インターネットなどの普及によって告発の垣根が低くなったことも要因の1つです。

　これはITの力のほんの一例です。ITには「IT革命」といわれたように、社会を変化させるだけの力があります。しかし世の中には、ITを有効に活用しようという意識が十分にない企業がまだ数多くあります。なかなか実行されることのなかった内部告発がされるようになったのと同じように、いままでは何度やっても定着しなかった仕事のやり方や決め事などでも、ITを利用すればできるようになることはいろいろあるのです。

「システム開発はない」のは本当か？

　こうしたコンピュータ活用に対する理解が少ない企業のシステム担当部署の方ならば、「コンピュータ・システムの開発は、企業や事業所のコアコンピタンスではない。そんなに力を入れる必要はない。システムの開発はもうない」といわれることも多いのではないでしょうか？

　ところが、実態をよく見てみましょう。現場には、現場の人々が工夫して作った小システムがいっぱいあります。誰かが「システムの開発はもうない」といっている一方で、現場が自力で作っているのです（現場で作れるから、「システムの開発はない」といっているのかもしれませんが）。

　「システムの開発はもうない」というせりふは、善意に解釈すると「システムを開発する人間の育成も含め、投資するだけの価値あるシステムの開発は当分ない」ということでしょう。ところが、トップのIT化への無理解やコスト圧力にさらされているシステム担当部署が「カネが掛かる割に価値がない」などとシステム化を拒否したり、バックログのまま案件をたなざらしにした結果、現場の業務部門は自らの労力と時間をかけてシステムを作っています。

　業務部門とシステム担当部署の意識にアンマッチが見られます。「現場が自力でできたことが、システム担当部署にはできない？」「システム担当部署が見合わないと判断した案件は、実は現場では切実なことだった？」「システム担当部署と業務部門の間には、事態の認識やシステムに求める要件などに差異がある」ことに興味を感じます（ベンダとユーザーの間にも似たような現象があります）。

　システムを総合的に管理し、プロジェクトを一元的に見渡す専門（ないしは兼任）のシステム担当部署は不要なのでしょうか？

　業務部門が自作するシステムは、ExcelやAccessなどによって属人的に作られていることが多く、作った人が人事異動などでいなくなれば、途端に困ることが予想されます。また、個別業務に最適化されたアプリケーションは、全体最適に貢献するかどうかは分かりません。あるいは似たようなシステムが社内のいたるところに無秩序かつ無関係にあり、いろいろな無駄が生じているかもしれません。これらを調査、整理し、相乗的な効果が得られるシステムを安く開発したらどうなるか──。システム担当部署が貢献できることは、まだまだあります。

　次回は、実際のチーム作りを考えていく予定です。

筆者プロフィール

山村 秀樹（やまむら ひでき）

某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、中でもシステムの開発プロセスについて興味を感じている。

Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。

「ユーザーサイド・プロジェクト推進ガイド」バックナンバー

• 業務の可視化で、多くの関係者を巻き込め！
• 工夫と規律で「システム用語辞書」を実現せよ
• 社内用語を統一する「用語辞典」作成のポイント
• 言葉の不統一がもたらす業務とシステムへの悪影響
• ドキュメントを作成しないユーザーは、失敗する
• プロジェクトメンバーがそろう前に行っておく事前準備
• システム開発プロジェクトの魅力を伝えよう
• プロジェクトチームのマインドとルールを方向づけるには
• プロジェクトキックオフ！ オリエンテーションで話すこと
• プロジェクトリーダーは十二分な準備で自信を生み出せ
• プロジェクトチームのリーダーに向く人、向かない人
• プロジェクトチームにおける“システム担当者”の役割
• プロジェクトチーム結成──業務部門との関係を考える
• プロジェクトチームに付きまとう制約を打破するために
• タイプ別プロジェクトチームの問題点
• 不良システムを作らないプロジェクトの枠組み
• スケジュールとコストは、ユーザー側が始めからつかめ
• 最初が大切──構築システムの“概要”を作る
• ユーザー企業側プロジェクトチームの使命と役割