What is 「設計事務所」？
前回に引き続き、今回は「設計事務所」という仕事の内容と、その役割がどうやって生まれたかについて少し紹介します。
■設計事務所誕生秘話
秘話、というほどのことはないのですが……。まずは、奇跡プロジェクトの体制図を添付します。エンドユーザーは約2000名。IT担当グループと情報システム部は合わせて約20名。開発会社は大手メーカー3社＋地場・関連会社3社＋ベンダー2社。プロジェクトのフェーズによって多少変わってきますが、かかわった技術者はのべ800人だそうです……。
体制図は、最初からこの形であったわけではありませんでした。我々はSIerの位置付けで、開発会社の統括という役割にありました。
ところが、あまりにプロジェクト規模が大きく、1つの（比較的小さな）サブシステムでさえ会社の資本金を上回る始末。全社員30人の中小企業が、プロジェクト参加者のみで100名を超すといった大手開発開発会社たちを統括するなどできようはずもなく、あえなくお客様の方から「お前らは横にいて支援しろ」と、図の様な位置付けをいただきました。
我々としては結果的に良かったのですが、プロジェクトの途中で体制ややり方をがっさりと変えてしまったことで、各社が多くの痛みを伴いました。しかしながら、成功の観点で考えなるならば、そこが重要なターニングポイントだったのでしょう。
■役割
前回の内容の繰り返しになりますが、「設計事務所」の役割を列挙します。
- システムの企画構想
- 全体設計
- パッケージ評価、選定
- プロジェクトの統括管理
- 予算管理（伺い、資材発注手伝い）
- 顧客の他部門や経営層への調整支援
- データ整備・移行
- システム移行
- 端末導入支援
- 業務通し試験支援
- システム構成管理
- 教育計画策定、教育実施
- システム評価
- ヘルプデスク運営
- 利用状況調査などなど
こうして見てみると中立の立場ではありますが、顧客企業側への支援作業が大半を占めていることに気付かされます。言いかえるならば、顧客側作業のいかに多いことか。我々自身、出自は開発側の立場ですが、今回「設計事務所」という立場から改めて顧客と開発側の両方を俯瞰して、初めて気が付いた一番のポイントでもあります。
■結局、どうだったのか
このプロジェクトと「設計事務所」の役割の意味を工学的に評価・分析した内容は、後ほど詳しく本コラムでもご紹介したいと思っておりますが、簡単に「どうだったのか」と総括したいと思います。
＜本プロジェクトの特色：3つのない＞
- 顧客、開発会社共に規模的、技術的に経験がない
- 開発会社は顧客の業務が分からない
- 顧客企業は、ITが分からない
＜だから＞
- 最初から作業や役割を細分化できず、中間的な「何でも屋」が必要だった
- 業務とITの翻訳機能が必要であった
- 特に顧客企業は導入手法（開発会社の開発手法に対比して）は体系化されていないのでさまざまな角度ので支援が必要であった
次回は、本プロジェクト中に起こった悲喜こもごもなエピソードをご紹介したいと思います。