PR

 現場の担当者たちを新しい業務フローの世界に巻き込めた、と判断できた時点で、新システムで使用する操作画面のプロトタイプを提示した。

 プロトタイプの提示を急いではいけない。これは私の持論である。どういう場面(状況)でどういう業務をするのかを分かってもらってから、操作画面を見せ、入力すべき項目や必要な機能について意見をもらう。

 自分達の業務であることをしっかり分かってから、議論を交わすようにする。現場の強みを徹底的に生かしつつ、要求の膨らみを防ぐコツである。

 一方、データ要件はデータモデルとしてまとめていった。要件定義の段階から、データモデリングをボトムアップで実施した。現行の伝票や資料の項目を基にして、あるべき姿を埋め込んでいった。

 本来のやり方は逆だと私は思っている。データモデリングの基本はトップダウンである。業務改革を伴うわけだから、トップの意志を反映したうえで、現場の業務とシステムを構築したほうが投資効果を出しやすい。トップダウンで骨組みを作り、ボトムアップで肉付けをするわけである。

 だが、今回はボトムアップで進めるほうがよいと確信した。トップの意志は入っているものの、落とせない要件の多くが現場に近いものだったからだ。限られた時間のなかで稼働するシステムを構築するためには、これしかなかった。

 この確信は間違っていなかった。現場に密着したシステムのデータモデルが出来上がっていった。

いよいよ開発に入る

 こうして要件、業務フロー、データモデルをついにまとめあげた。いよいよ開発である。開発メンバーは6人。要件定義(業務設計含む)と基本設計が私。社員4人と外部のプログラマー1人が開発する。

 開発プロセスはウォーターフォールの枠組みを残した反復開発にした。「詳細設計、製造、テスト」を繰り返すやり方だ。こうすることで新業務を固めつつ、システム品質を向上させていく。業務フローはテスト工程でも徹底的に利用した。

 新システムの開発に当たって、アジャイル開発の適用も検討したが、すぐ断念した。メンバーにアジャイル開発をきちんと理解してもらうには時間がかかるが、時間がなかった。開発方法論を検討しているより、とにかく手を動かす必要があった。

 それに新システムは昨今の言葉で言えばSOR(システム・オブ・レコード)のものであり、ウォーターフォールの枠組みを残したほうがうまくいくと思った。アジャイル開発はSOE(システム・オブ・エンゲージメント)に向く。私はこういう考えを持っている。

短期開発を成功させた鍵はリポジトリ

 大規模ではないといっても実質9カ月で、工場の受注から発注、製造、出荷、納品までこなす基幹システムを稼働させる必要があった。時間の制約が厳しいプロジェクトだったが、リポジトリが大活躍した。

 新たに開発したシステムについて、データモデルや業務フローをXupperというツールのリポジトリに入れていったので、途中で仕様変更があっても楽だった。現行システムのうち再利用した箇所についてデータ項目やロジックを簡単に調査できた。こうして、要件の変更に耐えつつ、品質の高いシステムを開発することができた。