情報システム部 プロジェクト管理とは？ 現状について
「ベンダーと情報システム部」この両者ではプロジェクト管理のやり方は明らかに変わってきます。ベンダーとはシステム開発をビジネスとしているＳｉｅｒや受託開発企業、パッケージ＆クラウドサービスベンダーのことを指し、情報子会社もこれに当たります。これらのベンダー企業は自前でシステムを開発するので、工数や原価管理、進捗管理や品質管理を、自分達でおこなっていきます。当然、プロジェクト管理をしっかりおこなっています。
一方、情報システム部とは、エンドユーザー内にあるシステム部門のことを指します。
情報子会社化するかどうかはグループ経営の判断であり、エンドユーザーの情報システム部のパターン（以下、情シ）も、製造業や流通業、金融やサービスなどたくさんあり、一般的だと言えます。
これらの情シ企業でも大規模システム開発がたくさん進んでいますが、自前でのシステム開発能力は、ベンダーには到底、及びません。その理由は一般企業の情報システム部であるため、組織規模も大きくなく、ホスト時代の開発であればまだしも現在のオープン系・高度な技術に、内製化のシステム開発レベルではついていけないからです。
よって情シのシステム開発はベンダーに頼ることになります。内製でできない開発を外部に委託することは当然のことであり、現在９０％以上がベンダーに頼っています。ここで一括請負の開発を委託している先を「SIベンダー」、準委任の派遣で開発を委託している先を「外注」という言い方に分けることにします。
※言い方は各社によって違うと思いますが、ご了承ください。意味合いを統一いたします。
＜SIベンダーの場合 開発パターン＞
・システム開発は大規模から小規模を問わず、SIベンダーに一括請負で委託している。
（持ち帰り開発もあるが、客先常駐で開発している場合が多い）
・運用保守は準委任の外注派遣と、社員でやっている。
＜外注の場合 開発パターン＞
・システム開発の詳細設計から製造・テストまでは、外注が準委任で開発している。
しかし開発の指示は、社員がやっている。（外注派遣のリーダーと協力して進めている）
・要件定義から基本設計までの工程作業や、仕様までは社員が決めている。
社員が上流志向でやっている。
・超大規模な開発の場合のみ、SIベンダーに一括請負で委託する。
（例：グローバル会計やＳＣＭなど）
一般的に言うとSIベンダーの場合の開発は「基本的にベンダーへ丸投げ」、外注の場合は「内製志向が高く、自分達で開発をコントロールしたい」と言えると思います。これらはどちらが良いとは一概には言えません。世の中の９０％の情シは、SIベンダーの場合であり、自分達でシステム開発はできないため仕方がないのです。コストは外注の場合の方が安いかもしれませんが、SIベンダーの場合は、一括請負で委託するため、高い品質や、コストと納期の尊守が担保されやすいメリットがあります。
今回は「SIベンダー」か「外注」かのどちらが正しいかという議論ではなく、本ブログではこの２パターンのプロジェクト管理とは？について、ポイントを整理していきたいと思います。
基本的に一括請負で委託する場合は、コストと納期はSIベンダーが守る義務があります。つまり、コストと納期はSIベンダーに任せておけば守ってくれるわけです。しかし現状はそうはいきません。「概ね順調です！」とSIベンダーは言いながら、納期が遅れてきたり、受入テストで品質がボロボロで、進捗が更に遅れたりすることはよくあることです。追加費用を求めてきて、コストまで膨れ上がることもあるでしょう。そこでSIベンダーの場合のプロジェクト管理は下記のようなことを行います。
SIベンダーの場合のプロジェクト管理とは？
・情シとSIベンダーは進捗報告会を行う。週次ミーティング形式や、成果物や大きなフェーズ単位で開催して、製造フェーズであればプログラム単位に、進捗・品質の報告を情シは求める。
・品質管理も受入テスト等では情シが行うこともあるが、SIベンダーの報告を信じている傾向が強い。
つまりコストと納期は決まっているとはいえ、情シは「進捗報告会は定期的にやってもらうよ・・」、「品質にはクチを出すよ・・」というプロジェクト管理のスタイルになっていると言えます。このプロジェクト管理のやり方は一括請負の場合の正攻法であるため、多くの企業がこのスタイルです。
この場合のプロジェクト管理とは？
「SIベンダーを監視する」ということが基本スタイルになるため、プロジェクト管理に必要なＷＢＳはSIベンダーがひき、進捗報告書もSIベンダー側の書式で報告されます。情シ側は、プロジェクト管理ツールを導入して見える化をしたり、自社のプロジェクト管理手法でSIベンダーに報告をしてもらうことは、ほとんどありません。
プロジェクト管理ツール SI Object Browser PM（以下、OBPM）の提案をしても、この場合はほとんど、提案に「はまりません」。SIベンダーにプロジェクト管理を任せ、しっかりと監視していく仕組みを作ることに専念した方がよいと思います。もしも、今後「内製を増やそう！」という方針で組織が変わっていくことがあるならば、弊社にお声がけください。
外注の場合のプロジェクト管理とは？
このケースの情シはプロジェクト管理を自分達でやっていく必要があります。理由は外注のコントロールは社員がやっていかなければならないからです。プロジェクト管理ツール：OBPMの導入事例がありますので、弊社の事例掲載をしているユーザー様の管理手法をご紹介いたします。
カゴメ株式会社様のプロジェクト管理とは？
基本的に社員数十名と準委任の常駐派遣メンバー数十名で、システム開発と運用保守をやっています。
開発のプラットフォームにホストやオフコンはなく、オープン系がメインになります。カゴメ様のケースの場合、具体的に下記のような作業が発生します。
（プロジェクト管理のための作業）
・超大規模の開発は一括請負で出すので、そこはSIベンダーの場合と同じ進捗報告会をする。
・ほとんどは内製であり、例えば３人日の開発や１０人日の小さな開発が多くなってしまう。
・外注メンバーは当然、複数のプロジェクトを兼任している。
・外注のリソース計画は社員が行い、具体的なタスクやプログラム作成の指示は、社員と外注リーダーが相談しながら決めていく。
・カゴメ様のエンドユーザーとの仕様を決めるのは、情シの社員が決め、外注に指示をしていく。
・中規模の要件定義は社員でやっていくため、要件定義の標準ＷＢＳを常に改善している。
・情シ社員も工数入力をすることで、製造原価管理（仕掛原価や完成原価の把握）ができている。
このようなＷＢＳの標準化をすることで社員レベルの底上げをして、外注が空かないようにリソース計画と実績を管理していくことで、外注人員数の適正化や外注コスト管理を、プロジェクトマネジメントしています。常駐派遣の外注体制を構築し、社員が指示を出しコントロールしていくシステム開発体制を、カゴメ様は実現しています。アメリカの開発スタイルはこのようなイメージだそうです。アメリカにSIベンダーが少ないのはこのような内製化ができているからだと言われています。今後、日本の情シも内製化が進んでいく場合は、カゴメ様のような作業が必要になってくるでしょう。
株式会社トーカン様のプロジェクト管理とは？
基本的に社員数十名を中心に、外注は若干数でシステム開発と運用保守をやっています。開発のプラットフォームは基幹系がオフコンベースになり、情報系がオープン系になります。トーカン様のケースの場合、具体的に下記のような作業が発生します。
（プロジェクト管理のための作業）
・大規模開発でも内製で開発をする。エンドユーザーの情シは「システム開発のプロ」ではないため、その分、プロジェクトマネジメントの勉強を組織でしっかりやってきた。過去には失敗プロジェクトもあったが、失敗プロジェクトに学び、更なる勉強を重ね、成長してきた。
・基本的には小さな開発が多くなる。例えば５人日のプロジェクトでもリソース計画やコスト計画は入れていれ、予定工数を事業部門に出すことで「収入」をしっかりと決めて、その計画の中で開発を行う。
・社員は当然、複数のプロジェクトを兼任しているので、全社や部門別のリソース状況を把握している。
・開発案件（重めや軽め）や保守の標準WBSを10個ほど作り、社員全員で共有している。
・設計書などの成果物レビューや、リリース承認の品質管理は組織で必ずやっている。
「我々はシステム開発のプロではないため、半信半疑でやっている」とト－カン様は謙遜しておっしゃいますが、組織全体でしっかりと勉強できていることと、プロジェクト管理ツール：OBPMが「次に何をすべきか、良い方向に導いてくれる」とも言ってくれています。
S社様：情報システム部様の基幹システムリニューアルのプロジェクト管理とは？
S社様はグローバル製造業の企業であり会計システムは、全グローバル拠点が統合できています。しかし販売・購買管理、生産管理（PDM）、MESは各拠点バラバラで、今回のリニューアルですべてのグローバルシステムを統合化することが目的です（以下、新システム）。情報システム部は社員だけでなく、外注：大手ベンダー（一括請負）、外注：常駐する派遣会社（準委任作業）の３グループを主体で進めていくために下記のような管理が必要になりました。
マネジメントを必要する３つのグループとその範囲
１）社員 ・・ 各業務別に業務改善チームがあり（例：設計部業務改善チーム）、チーム別・業務別のタスクのＷＢＳをひいて、ガントチャートで進捗管理をしていきたい。もちろん情報システム部メンバーの作業タスクの進捗管理も必要であり、受入テストやユーザー教育の作業タスクも後半には管理していく。
２）大手ベンダー（一括請負） ・・ 業務システム別（例：生産管理：ＰＤＭ）に、要件定義は準委任で依頼し、基本設計→詳細設計→製造・単体テスト→結合テストまで一括請負で進めていく（以下、製造フェーズ）。要件定義の作業タスクには、情報システム部の社員も参画し、業務改善チームの社員も加わるため、大手ベンダーと協力して、ＷＢＳを引いていくことになる。基本設計以降の製造フェーズは大手ベンダーにコスト管理と進捗管理を任せ、情報システム部側では大手ベンダーの進捗状況をチェックしていくために、進捗ミーティングを定期的に行う。ハードやソフトの仕入管理も大手ベンダーに任せるが進捗状況は把握する。
３）常駐する派遣会社（準委任作業） ・・ 派遣会社（以下、派遣）は主に運用・保守サービスや軽微はシステム開発・改修を担当するために、準委任作業要員として常駐している。つまり、社員の指示により作業タスクを担当し、大手ベンダーとも協力しながらプロジェクトを進めていくので、情報システム部は派遣の進捗管理が必要になる。
このように一般企業は社員（情報システム部）だけで大きなシステム開発を進めていくことはできません。外注：大手ベンダー（一括請負）と、外注：常駐する派遣会社（準委任作業）の協力をもらいながら、新システム開発や導入を進めていくわけですが、全体のプロジェクト管理は当然必要になってきます。それぞれの外注の責任範囲と、自社の責任範囲を切り分けしながら、進捗管理や工数・原価の収益管理、課題管理等のマネジメントを実行していくことが情報システム部に必要なポイントになります。
情報システム部が目指すべき、プロジェクト管理とは？
いかがでしたでしょうか？
情シは企業の中の１部門であり、ITのプロではあってもシステム開発のプロではありません。正直、インフラ構築や保守までが情シで対応できる限界で、システム開発パッケージソフトカスタマイズやクラウドサービス構築はSIベンダーに任せるべきです。上記SIベンダーの場合は、みなさまの開発レベルに沿ってそったプロジェクト管理のやり方で問題ないと思います。SIベンダーとの良い関係を今後も構築していきましょう。
しかし、そのような時代がずっと続くわけではありません。経営側からコスト削減とビジネスのスピードについていくための内製化を突然、求められるかもしれません。もしかすると大規模システム開発でもクラウドプラットフォームやＡＩで、情シが開発できていく時代がくるかもしれません。
そのような時代の変革に対応するためにも、徐々に内製化を増やし、カゴメ様やトーカン様のようなシステム開発体制とプロジェクト管理ツールを準備しておくことも重要ではないでしょうか？
情報システム部のプロジェクト管理とは？
すべてをSIベンダーに頼らず、まず自分達でシステム開発していく範囲を広げていくことから始まっていくのかもしれません。
カゴメ株式会社様 導入事例
https://products.sint.co.jp/obpm/case/kgm
株式会社トーカン様 導入事例
https://products.sint.co.jp/obpm/case/tokan
