1. 受託開発のこれから

2. これまでは....
作った物の工賃をもらう発想。いかに最小のコストで高く売
るか？というモノ作りのビジネス
● 開発手法を統一して生産性アップ
● 一度作ったモノを再利用
● 数多く売る
とか当初は考えていた。
今になって見えてきたことは...

3. 「開発手法を統一して生産性アップ」の問題
開発技術の進歩も早く、あっという間に古くなる。LAMP構成とかMVCフレーム
ワークなんてことすら崩れかけてる。
開発手法を統一する事で同じものを作る時の生産性はアップするが、新しい価
値を生み出す時に、固定観念が足を引っ張ることも....
● 学習することには労力がいる。新しいことを試す前に「実戦で使えない」「む
ずかしい」と逃避してしまう
● 旧技術に縛られ四苦八苦する。「これが限界」
● 「学ぶ」習慣が身につかない。「まねる」だけ「教えてください」
開発手法を絞る事はよいが、「自分はこれでいい」と居座ってしまうと、非効率な
やり方で時間を浪費する。
今では仮想マシンのおかげで、色々なことを試すことが容易になった。
一つの技術に固定し学習コストを下げて生産性をあげるメリットよりも、他の技
術の良さを取り入れられないデメリットのほうが大きくなってきている。

4. 覚えることを減らして学習コストを下げるのではなく
● 情報収集の仕組みを持つ。調査担当を決めドキュメント化。→他の人が同
じことを調べるコストを減らす。
● 勉強会/ハンズオン実施→導入の敷居を下げる。開発者のモチベーション
を駆り立てる
● ML/ユーザグループ参加→アドバイス/バッドノウハウの収集
のように組織としての情報収集能力を上げることで、各個人の調査コストを下げ
る。
各自で調べた知識が脳内にあるだけでは価値を生まない。これらをアウトプット
することで価値を生む。
すぐに実戦で使えなくても、現状と比較検討できることは強みになる。自分たち
が古い考えに縛られていないかを見つめ直すことができる。

5. 「一度作ったモノを再利用」の問題
「既存サイトコピーして別サイトに流用」
「オープンソースCMS使って....」
みたいなケース
よい設計であれば、再利用は考慮されているし、デザインは案件ごとに調整が
必要なので、コピーでコストダウンとなることはない。同一ソースであっても枝別
れして亜種となった時点でメンテナンス対象は増える。
担当者の命は永遠ではないので、必ず引継は起こる。担当者が変われば、再
度作ったモノを把握するコストが必要。
安易に引継を丸投げする方法では、コードのクオリティや担当者のスキル依存
になり、事前のコスト予測が難しい。

6. ● 職人/見習い制。ペアプログラミング
● あえて担当を切り替えて引継を習慣化。脳内仕様をなくす
● コードチェック/テスト自動化。根性論でのチェックをしない
● コードレビュー。積極的なリファクタリング
のように、継続運用のためのコストを受け入れる余地がなければいけない。
予算ないから....と個人任せにしていると、担当者がいなくなった時点で、予期せ
ぬ代償を支払うことになる。
コピーは材料費もかからないしタダで出来るが、メンテナンスする限りにおいて
モノは完成していない。ローンチ時点でなくサポート停止した時点までにかかっ
たコストが作ったコストである。
このコストとそのための対価が得られているかを分析しなければいけない。

7. 「数多く売る」の問題
お客さん毎に求められる要件はさまざま。お客さんの数はサポートできる範囲に
限られる。
そもそもすでにニーズがない。既存サービスはローンチされており、移行リスク
を冒してまで新しい業者を採用することはあまりない。
数を増やして売上確保に走る発想では
● お客さんを増やしてもサポートしきれない
● 新たなお客さんを獲得するのが大変
のジレンマに苦しむことになる。
既存のお客さんにフォーカスして貢献していくことに専念すれば、信頼を生み安
定した売上はついてくる。自分たちがなくてはならない人材になればよい。

8. ● 作ったモノは古くなる
● 作った技術も古くなる
● 作ったモノは負債
モノとして売れば売るほど苦しくなる。従来の受託開発のコ
スト算出方法では、うまく利益をあげられない。

9. 通じなくなった考え方
● 人月見積（工程/スケジュール）
● 納品
● 保守
開発現場がアジャイルもどきを取り入れても、経営戦略・リスク分析が従来のま
までは、柔軟にスピーディーに対応するただの便利屋。

10. 危険なキーワード
「実績のあるものしか使わない」
使えるかどうかの検証を怠っている。
今では試すことが容易。情報収集能力が高いところが有利
「動いているからさわらない」
さわれるようにリファクタリングするノウハウがない。
何が悪かったかの評価もされない。
「手作業が確実」
作業内容がコード化されていない。手順が脳内記憶
保守は暫定的な作業という発想
「保守で稼ぐ」
何もしないでお金が入るという幻想。何もしないとどんどん腐る
開発/保守という括りはもうない。

11. これからは....
● より良い開発手法を取り入れられる柔軟性
● 作ったモノを継続的に改善しつづけられるメンテナンス力
が必要。リファクタリング/テスト/デプロイ 一連の作業をいかにスムーズにでき
るか？いかに時間を浪費せずに済むか？
「メンテ性は置いといて、とりあえず動くものを作る」というのはスピード感を求め
られるケースではありだが、作ったあとにメンテしやすい（空き時間を増やせる）
ように改善しつづけられることが重要。
「メンテしやすいように作る」という発想も、時に開発者のエゴで過剰な実装にな
りがち。メンテしやすい設計に悩み時間を浪費するのでは意味がないし、その手
法も古くなる。
生き物のように育てていく。そのための人材を組織がどれだけ持っているか？

12. できることは何か？
まず自分たちから変わってみる。
● 自分たち自身の業務を改善して時間を増やす
● 空いた時間を情報収集に充てる
● 得られた成果を発信する
「金にならない」とされてきたことを価値にする。