スクラッチ開発は本当に良いのか？
前回パッケージ導入の考察を行いましたが、今回はスクラッチ開発による業務システム導入を考えてみます。（生産管理システムを例にしています）
現場感覚で言うと、パッケージ導入よりもスクラッチ開発での導入の方が顧客の事を思うと良いのに、と考えているＳＥが大半だと思います。大手ＩＴベンダーは基本的にパッケージありきでビジネスを行うケースが非常に多いので、そういった環境にいるＳＥの方ほど実はそのように感じている人が多いようです。身近な友人でパッケージ導入で顧客価値向上も出来て、プロジェクトも成功出来ると言って、実際業務パッケージを使った大型プロジェクトを成功させ続けているＳＥがいますが、このような人は非常に少ないのではないでしょうか？
では、ＳＥが好むスクラッチ開発ですが、実際の所どうなのか考えていきます。
スクラッチ開発での導入を成功させるには
パッケージ開発の時と同様に、成功する為の条件を考えてみます。
- 導入担当側の担当者やチームが具体的な目標をRFPに落とし込み、文書化出来ている。
- 業務の流れを導入企業とシステム開発会社がきちんと共有出来ている。
- システム開発会社側のＳＥが導入企業の業界に関する業務知識を持っている。
- システム開発側が要件をシステム化する際に抽象化作業を行う事が出来る。
最低限上記の４つが必要だと思います。パッケージ導入と比較して、一つずつ検証していきましょう。
１．導入担当側の担当者やチームが具体的な目標をRFPに落とし込み、文書化出来ている。
まずは目標の設定が定量化されていて、外部の人間にも分かる物が必要です。パッケージ導入の場合にも必要なのですが、パッケージの選定やコンペがあるのでRFPを必ず作るのですが、スクラッチ開発の場合は意外と作らずに進めてしまう事があります。必ず作って、導入のゴールを共有すべきです。
２．業務の流れを導入企業とシステム開発会社がきちんと共有出来ている。
これが出来ていないと非常に危険な事になります。 パッケージ導入の場合、少なくとも一通りの機能を標準で揃えていますので、導入を進めていて全く用意していなかったという機能が開発の後半（特にユーザテスト）に出てくるとこは少ないです。しかし、スクラッチ開発の場合、基本的にはイチから構築するので、一部の機能が完全に抜け落ちていた、などという事も起こりえます。そのような事が起こらないためには、対象範囲となる業務の流れは双方で正しく共有出来ている必要があります。新しいシステムの業務フローは大概の場合作りますが、現行の業務フローは作らないケースもあります。新しいシステムの構築をするのだから現行業務のフロー作成は工数の無駄と思われがちですが、導入企業とシステム会社のどちらが作っても構いませんので作成して双方で共有すると、思わぬ落とし穴に入ることが減ると思います。
３．システム開発会社側のＳＥが導入企業の業界に関する業務知識を持っている。
スクラッチ開発の場合、システムの構造を作る側が対象企業の業務を理解していないと成功可能性は下がります。パッケージ導入でも同様なのですが、スクラッチ開発の場合はシステムの基礎となるデータベースモデリングをイチから作りますので、いわばお手本が無い状態で設計する事になります（もちろんシステム開発会社内に過去製造した同一業界のシステムがあればそれをお手本にすることはありますが）。その場合、設計者が業界の常識やしきたりを知っている事は非常に重要です。もし、未経験の業界だった場合は、導入企業側のメンバーが親身になって色々と伝えていくなどの作業が必要になります。
４．システム開発側が要件をシステム化する際に抽象化作業を行う事が出来る。
パッケージ導入であればデータベースモデリングは基本的に終わっている状態で、あとは企業特有の管理項目を追加するなどを行うのが一般的です。しかし、スクラッチの場合は先ほども書きましたがデータベースモデリングから構築します。この場合、業務のあるべき姿に合わせた適切な正規化を行う必要があります。さらに、現実の情報をそのままモデル化して設計すると柔軟さにかけた、硬直したシステムになります。システム稼働当初は良いかもしれませんが、時間が経つにつれて、ビジネスに変化が生じた場合に変更が難しくなるなどの問題が生じます。この辺りは非常に説明が難しいのですが、勘所としか表現できないようなノウハウが存在すると感じています。例えば現在は材料購入を１材料品種につき１社への注文となっているという事で、注文機能も、材料を管理するマスタもこのルールで構築したとします。本稼働後に社内改革活動として、複社購買をして仕入れ値を下げる活動が実施される場合に、システムが対応していないから出来ないという結果になってしまいます。この場合改造は容易でないことが想像されます。データベースのキー構造を変えて画面の修正を行う必要がありますので。かといって今は存在しない色々な事をシステムに取り込んでいくと機能のボリューム、難易度が膨らんでいきます。このさじ加減がまさに勘所とでも言うべきノウハウです
スクラッチ開発で導入すべきケース
上記４つに当てはまる場合はスクラッチ開発による導入で上手く行く可能性が高いと思います。 お読みいただけると分かると思いますが、システム会社側の負担（ＳＥのスキルやノウハウ）はパッケージ導入に比べて大きくなります。他の事でもそうですが、元々存在する物を改造していくよりも、ゼロから構築していく方が考えるべきことは多くなり、難易度は高くなります。
多くのＳＥがスクラッチ開発をやりたがるのは、難しいことにチャレンジしたいと考えて言っているのかも知れませんね。
冒頭で紹介した友人のＳＥはその事を良く分かっていて、業務パッケージを上手く活用した導入を行っています。ある程度以上の規模になると、時間的に全てを一人で把握できなくなります。そこで、パッケージの基本を使って設計を進めて、勘所が必要な個所に対しては全体把握出来るようにマネージメントしています。そもそも大規模なプロジェクトのプロジェクトマネージャがシステム内容全般を理解しているというのが非常にレアケースと言えなくもないですが・・。
結論
前回コラムの冒頭で述べたとおり、どちらが良いかはケースバイケースであると結論づけていますが、ここまで書いてきた内容もまさにケースバイケースと言えると思います。このコラムで述べたかった事は、どちらの方式にも成功する為の必要条件（十分条件ではありません）があり、それを満たさないと成功はおぼつかないという事。さらに、両方式に共通する成功する為のポイントがあります。それは、
- 導入側ユーザがいかに本気になり、情熱をもってシステム導入を進めるか
- システム開発会社がいかに本気になり、情熱をもってシステム導入を進めるか
という点です。ここが無いとどんなパッケージを持ってきても、どんな優秀なＳＥがスクラッチで設計・開発しても良い物は出来ません。多くの場合、システム導入はプロジェクト体制を組んで実行されます。導入側の担当者は多くの場合日常業務と兼任でその任につきます。その忙しさの為に往々にして日常業務が優先されてしまいます。システム開発会社も仕事だからやっているというような心持では親身に考えることなど出来ません。
ここをどのように解決するかが実は私は一番大事だと考えています。２回に渡ってシステム導入について書いてきましたが、すべては情熱が一番大事だよ、と言いたいだけでした。ただそれだけを言うと根性論のように聞こえるので、こんな回りくどいことを書いてきました。ここまでお付き合い頂きありがとうございました。
ちなみに、私なりの情熱を生むための方法は、TALONを使った「新しい開発プロセスのご提案」に記していますので、ぜひ続けてお読みいただければと思います。
文=古関 雄介
