大規模システム開発の世界における開発モデルと大切なことを議論する
電子頭脳ハレルヤ |
おはようございます。
2014年2月のビルメン関係の配信記事です。
筆者は今のビルメン業者の前に、システム関係の仕事もしていました。
そこで大切なことは、そもそも何のために、どのようなシステム(プログラム)を組めばきちんと納品できるのかという見極めです。
大規模なシステム開発、例えば銀行の勘定系(預金為替融資に内国為替といった基幹業務を司る)システム開発などにおいてはウォーターフォール開発という古くからある最もオーソドックスな手法が取られます。
これは読んで英語で滝の如く、若干の工程ごとの言い方に差はありますが、時系列が下っていくにつれて、「要件定義」「概要設計」「外部設計」「内部設計」「詳細設計」「開発プログラミング」「単体テスト」「結合テスト」「総合テスト」「運用テスト」「ユーザーテスト」「検収」「納品」「運用開始」といった作業フェーズに分割し、前の工程の完了レビューを待って次工程を開始しないという縛りを設け、前工程の成果品質を確保していくという方法です。
これが守られる限り、前工程への手戻りは発生しません。線表(ガントチャート)というスケジュール表によって工程の管理がなされます。
そもそも最初の要件定義が最も大切
しかし、最初の開発局面である「要件定義」というのは発注側・ユーザー側が主体となって進めないといけません。ここで往々にして起こるのが、これから作るシステムの利用者がそもそもそのシステムで何を実現したいのかが明確になっていないということなのです。
ここでSIというシステムの専門家(加えてユーザーの気持ちも分かるマネージャークラス)が支援して一緒に要件定義をまとめ上げることになりますが(筆者はこのポジションでした)、いつしか支援している側に開発の責任が擦り付けられていくといったことをよく経験したものです。
そうしてようやく出来上がった要件定義ですが、このいわば設計図に従って何十人ものSE(システムエンジニア)が数ヶ月にわたってプログラムを組んで動かし走らせるという膨大な人件費を投入することになるわけですから、繰り返しレビュー(説明会)をして抜けや穴がないか多数の目で精査することが必要です。
しかし実際にはお粗末にも要件定義と言えないレベルのメモ書き程度のものを要件定義書としてこれで概要設計を行え、システム開発の見積もりを出せと言われる場合が多くたいへん難儀いたしました。
加えて要件定義書が完成したということの「確認」を誰に取ったらいいのかということでも悩むことになります。
ここではユーザー側の肩書はあまり役に立ちません。真にその業務に精通しているユーザーの支持を得ていなければ、例え社長がやれと言おうがシステムは正しく動かないのです。
専用端末の前で、テストプログラムを走らせるための取引データを数時間手動入力し続けて手がしびれるような経験もありました。
誰の意見が会社の意思になるのかの見極めが、システム業者生き残りの鍵だと思いました。
統合システム開発現場からは以上です。
(平成26年2月28日 最終更新:平成28年2月28日)
【関連記事】