受託開発で学んだこと

  ブログ投稿3日目

２日目の受託開発のことを書いていたら、やっぱりいろいろ思い出すことがあり、これは当社の社員にも役立ちそうなこともありそうかなと思えてきたので、もうちょっと書いてみようと思います。

2005年～2009年ぐらいは、受託開発をめっちゃやっていました。私が営業、打ち合わせ、契約書作成、それからスケジュール管理など、しかもシステム開発もやっていたので、とにかく猛烈に忙しかったです。

案件のプロジェクトマネージャーも兼務していました。社員は開発とバグ取り、私が全体の方向性を決めて、スケジュール管理する感じです。

当時使っていたプロジェクト管理ツールはMicrosoftのProjectというソフトで、さっき調べたらまだありますね。

今はオンラインでクラウド化されているので共有も簡単になっていますね。

当時は、エクセルで管理していたのですが、タスクの見積もり時間を1つ変えると、全体に反映しないので、いろいろ探した結果、Projectになった感じです。自分のPCにインストールして、全部のタスクを書き出す感じです。

タスクの時間を修正したりすると、自動的に人月とか後工程の工数時間が自動的に延長されて、納期も自動計算される、超便利でした。ちなみに、公式サイト見る限りだと、今もそんなに変わってないような感じがしますね。

このガントチャートを顧客と共有して、見積金額の根拠にしたり、このシートをメールで共有しながら受託開発していた感じです。

受託開発で学んだこと

創業時から考えると、受託開発は合計で6年ぐらいがっつりやっていたわけですが、そこから学んだことをいくつかまとめてみたいと思います。

受託開発は納品事故率が高い

受託開発は、そもそも論として定格化されたパッケージソフトを納品するわけではなく、顧客要件に合わせて納品するので、「これが完成品」という物理的にも視覚的にもわかる基準がありません。非常にあいまです。

ですので、納品時に納品を受領するか否かは、相手の納得度で決まると今でも信じています。

よく、要件定義を書き、契約書を巻き、納品ゴールを明確にしておくべき、なんて本にも書いてあるし、大学教授とかコンサルタントとかも言っていますが、そんなきれいごとでスムーズに納品できたら超ラッキーでしょうね。

大企業のサラリーマン担当者なら、要件定義と契約書だけあれば、自分事ではないので、ある程度スムーズに進みますが、中小企業の社長相手となると、契約書と要件定義書はあくまでも儀式的なもの。こんな契約書数枚でプロジェクト納品時に意見ひとつ言わずに納品するなんてありえません。

中小企業というのは、自社サイトのシステム開発は経営の運命をかけた一大プロジェクトなんです。「契約書に書いてあるから」「要件定義書に書いてあるから」こんな理由で相手が納得してもらえたら、それはまことに良い顧客ですな。

私が納品間際というか、顧客との電話でよく話していたのは、

システムの受託開発は物理的な完成品ではないですよ。「ハサミ」や「のこぎり」のように、納品したら、それ以上加工できない場合は、納品そのものが最終ゴールになる。しかし、ソフトウェアは、納品といっても、次の日に簡単にソースコードの改変ができるし、見た目だって、簡単に変更可能なんです。

なので、社長さん、ソフトウェアの納品は、あくまでも山登りの△合目と同じ考え。あなたの理想とするソフトウェア、使い勝手を実現するなら、ここからじっくりとやっていきましょう。

って話していました。結論からいえば、全然納得しないので、だから裁判沙汰にも結構なったし、不条理な顧客がまあ多いことって感じました。

人間の本能ってやつが、もろにぶつかった瞬間を感じました。理屈ではわかっても、納得感とかお得感がないと絶対に納品を認めないっていう人間の本能なんでしょうかね。

2013年に発売された本ですが、なぜシステム開発は必ずモメるのか？49のトラブルから学ぶプロジェクト管理術　を後々読んだのですが、まあ、同じ業界にいた人なので、大体言っていることは同じかなと。

結局、要件定義とか、ほんと意味ないと今でも思う。無駄までとは言わないが、ソフトウェアは物理的・視覚的に検証可能な工業製品とは100%違うわけですよ。ソフトウェアは生き物のであり、管理・保守があって初めてお互いにWin-Winの関係になれると思っています。

当時は、自社ECサイトを持つ中小企業が爆発的に増えたこともあり、こうしたソフトウェア開発に関する基本的なリテラシーが開発側も発注側も貧困だったのもこうした納品事故になった1つの原因だったんでしょう。

今も当社では受託開発案件がありますが、完成を作って終わり、、というのはもうないですね。必ずプロジェクトを支えるチーム、企業の目指す中期的なゴールを共有し、そこに向かってプロジェクトを推進する形になっています。

受託開発の要件定義をする人と仕事をしないこと

今でいうと、50代以上の人って、ソフトウェアをクラウドで利用するケースと、パッケージソフトウェアの買い取り or それをカスタマイズした受託開発でプロジェクトを推進する人が結構いると思います。時代的にそういう仕事の進め方だったからでしょう。

カスタマイズっていうのは、先ほども書きましたが、納品の定義は超あいまいになります。要件定義しても、あとからころころ変わるし、作る側も要件定義は最終的に動くものを頭の中で空想しながら作るしかないので、お互いに契約時にかなりの労力を消耗します。

一番良いのは、完成品のイメージに近いものをプロトタイプとして作ってしまうことです。ソフトウェアはやっぱりブラウザなどで動く状態で初めてアイディアや意見、不足している要件がわかってくるので、プロトタイプは絶対に必要です。

20代の時に大学の公開講座の検索システムを開発したのですが、その時は打ち合わせの後すぐに（たしか1週間程度で）自分でプロトタイプを開発して、関係者に見せました。検索結果をGoogle Mapと連携させ、一括見積、一括資料請求ができるシステムです。今でいう不動産検索のSUUMOに近いシステムを15年ぐらい前に自分で開発していました。

ちなみに、この時に開発したスキルセットしては、PHP MySQL Ajax HTML+CSSで、当時はBootstrapがなかったので、インターフェースを開発するときはインプレッシブの藤田社長によくお願いしていました。私がプロジェクトと案件を調達し、藤田社長がＵＩをデザインするみたいな感じで、当時自社ＥＣサイトを作りまくっていましたね。

DROPBOXを探したら出てきたのですが、当時制作してもらっていたWEBデザインというのは、こんな感じです。

あ、ちゃんと多言語サイトになっていますね。osCommerceで開発してましたので。

お話を戻します。

その完成度の高さと開発スピードに発注者から圧倒され、デジタルスタジオはその発注者から当時出資（数千万）を頂いたという過去があります。社員さんならお分かりですよね？

今でも株主にもなっていますが、その出資者は今でも良好な関係を維持しています。

お金は、求めても来ない。お金はエネルギーのある源流に向かっていくものだと学びました。

ちょっと話がそれましたが、受託開発の話はこのあたりで終わり。

また明日。