システムを持たぬ時代に、あえてフルスクラッチに特化する：前編：SEの未来を開く、フルスクラッチ開発術（1）（2/2 ページ）
プログラムレス開発が全盛の中、フルスクラッチ開発こそ、顧客のためになり、SEにとっても強みとなると主張する企業がある。彼らはなぜあえて今、このような主張をするのだろうか？
パッケージのカスタマイズこそリスキー
――しかし、ソフトウェアで完結させたいという場合、通常はEC-CUBEや市販の汎用パッケージのカスタマイズということになるのでは？
内藤氏 私たちは、パッケージのカスタマイズの方がリスキーだと思っています（図1）。
――その理由は？
内藤氏 まず、パッケージへの精通が必要であること。パッケージを作った企業ならまだしも、他の企業がある特定のパッケージに精通しようと思ったら、人を育てる時間とコストがかかります。ということは、見積もりにそのコストを含めないといけない。
――なるほど。教育コストの問題ですね。ただ、フルスクラッチでもそれはあると思います。これも後で詳しくお聞きします。
島田氏 営業面の問題もあります。提供側としては、教育コストと要員の確保の問題があるので、そのパッケージでの案件が次々と見込めるかどうかが、一番の経営課題なります。すると営業面が先に立ち、本当はそのパッケージに向かない案件でも、むりやりお客さんに勧めるケースが出てきます。それでは、システムを導入する理由があべこべになる。まさに本末転倒です。
――確かにそうですね。
内藤氏 仕様書やマニュアルなどのドキュメントに載っていない技術的制限があることも多い。データベースのテーブル仕様が公開されている場合、項目を追加・修正したりしても構わないとエンジニアなら思います。ところが実際にやってみると、予期せぬ理由でシステムがダウンする。技術の理屈はあっているはずなのに、どうしてだろうと思うことが多い。
――具体的に、どのようなことでしょうか。
内藤氏 例えば、検索を速めようとテーブルにインデックスを張るだけでシステムがダウンするようなことが、実際に起こっています。
――それは、私も似たような経験をしてきたので分かります。なんでそんなことになるのだろうと思いますよね。
内藤氏 こうなると、内部仕様が分からないとどうしようもない。仕様なのかバグなのかの判断さえできません。市販パッケージでなく、オープンソースの場合だと情報は入手しやすいのですが、それも仕様なのか何なのか分からないことが多い。結局、実験して確かめるしかない。ただ、それでも推測でしかありません。これではお客さんに自信を持って勧められません。
島田氏 コストをかけて、あるパッケージに精通したと思っても、バージョンアップがあると再勉強が必要です。マイナーなバージョンアップならまだしも、メジャーバージョンアップがあるとまったく別のソフトになったと言ってもいい。
――そうですね。データベース管理システム（DBMS）でもかなり苦労します。パッケージソフトだと、なおさらです。
島田氏 さらにサポート終了になると、これはもうお手上げです。次のパッケージを探すしかない。提供側の経営者としてもリスキーですし、お客さんにはもっと脅威だと思います。
フルスクラッチに必要な技術はシンプルでつぶしがきく
――パッケージのカスタマイズをする場合には、パッケージに精通することが必要だというお話でした。しかし、フルスクラッチも、広範で深い技術に精通しなければならないのではないでしょうか？ つまり、教育コストはパッケージ開発よりもっとかかるのではないでしょうか。
内藤氏 私たちはWebサイトの開発をフルスクラッチでやっています。特に多いのは、バックオフィスを含めたECサイトの開発です。これに必要な技術はLAMP（Linux、Apache、MySQL、PHP）と呼ばれるものだけです。
――LAMPもバージョンアップしますよね？
内藤氏 ええ。でも、ベーシックな技術なので寿命が長い。また、それぞれが他のもの、例えばPHPがRubyに代わっても応用が効くので、習得が早い。
――私がエンジニアとして働いていた当時も、LAMPに該当するものはありました。なので、お話はよく分かります。当時は、アセンブラやCなどのベーシックな言語を使っていました。その後、開発リーダーとして標準化に携わった時は、Perlやシェルスクリプトなどで開発用ユーティリティを作りました。最初にベーシックな部分を押さえておけば、それ以降の技術習得は確かに早い。まさにつぶしが利くという感覚です。
島田氏 ただ、やはりジレンマもあります。開発生産性の向上には、アプリケーションフレームワークは使わざるを得ない。フレームワークを使うと、いろいろお膳立てをしてくれる分、自由度は下がる。なるべく開発効率が高くて自由度も高いフレームワークを使いたいけれど、それにはいろいろと比較が必要になってきます。
内藤氏 ですが、PHPのフレームワークを比較検討するにしても、PHPが書けないと、どこをどう便利にしているいるかが分かりません。従って、フレームワークを選択する上でもLAMPの知識は必要になってきます。
島田氏 フレームワークに精通することと、プログラムが書けるということが同じだと勘違いされると困るのです。そのため、弊社のプログラマやSEには、教育期間中、素のPHPでのコーディングを必ずやってもらっています。
内藤氏 フレームワークはお客さんが指定してくることもあるので、特定のものに依存するわけにはいきません。フレームワークが変わっても基礎力があれば対応できますが、逆はありえません。
「フルスクラッチに必要な技術はシンプルでつぶしがきく」「要件定義段階では、できる／できないの判断はしない」――次回は引き続き、フルスクラッチにこだわる企業のメソッドを紹介します。
筆者紹介
森川 滋之
1963年生まれ。1987年、東洋情報システム（現TIS）に入社。TISに17年半勤務した後、システム営業 を経験。2005年独立し、ユーザー企業側のITコンサルタントを歴任。現在はIT企業を中心にプロモー ションのための文章を執筆。
著書は『SEのための価値ある「仕事の設計」学』、『奇跡の営業所』など。日経SYSTEMSなどIT系雑誌への寄稿多数。誠Biz.IDに「奇跡の無名人」シリーズを連載中。
Copyright © ITmedia, Inc. All Rights Reserved.