納品のない受託開発を読んで、システム開発の種類を大別してみます。
システム開発の分類
あるシステムを構築したい時の選択肢として挙げられるものは、 大体は以下のようになります。
- パッケージ
- 受託開発（SIer含む）
- 内製
- 技術顧問（納品のない受託開発・フリーランス）
ここでは、現状がどうなっているかはおいておいて、本来どうあるべきか、強みはどこか、 これからどうなっていくのか、を考えてみようと思います。
パッケージ
概要
多くの顧客に同じものを提供することでコストメリットを生み出すモデル。 プログラミングでいうところのライブラリを作ってる感じ。
「ソフトウェアは複製が容易」なことをフルに活かしているモデル。
メリット
既に実績がある、かつモノが納品されることが主なので大体信用できる。 相対的に安い。
デメリット
自分たちの使いやすいようには作られていない。 実業務に耐えうるかは使ってみないとわからないが、 たいていは、「自分たちの業務をシステムに合わせる」か、 「システムを自分たちの業務に合わせるために追加開発を行う」ことが必要。 SIerがパッケージを選定してカスタマイズすることがよくある。
向いている案件
汎用化できるもの。変更の少ないもの。 ビジネス本来とは別だが手間のかかる部分（会計・SCM・コミュニケーション）などが主流か。
個人的感想
カスタマイズをしたら負け。それはビジネスモデルの崩壊を意味する。 費用対効果の高いところのみに注力して他は切り捨てていく覚悟がなければ、 何でも屋になってしまいコストメリットを提供できない。
いずれ、ツール群の提供としてOSS化していくんじゃないかと思う。 パッケージベンダーは、そのシステムをどう組み込むか、といった運用・カスタマイズの部分で利益を得ることになるのではと。
受託開発
概要
事前に要件定義をしっかり固めておいて、それを満たす（顧客に最適化された）システムを なるべく安く作って納品することで顧客に価値を提供するモデル。
内部では０から作ったり、いろいろなシステムを統合したり、下請けに投げたりなど様々。
納品がゴールなので、保守・運用は別契約（別会社）になることもしばしば。
メリット
自分たちの企業にマッチしたシステムを受け取れる。
普通は要件定義を手伝ってくれるので、プロの知見を元に要件を固めることができる。
デメリット
カスタマイズを行う分、コストが多くかかる。 納品することがゴールなため、要件定義をしっかり握れていないと、ただの使えないシステムが出来上がる。 プロジェクトが成功するかどうかわからない。（納品のQCDにおいて、日本ではよく炎上する）
向いている案件
パッケージだけでは賄えないもの全般。 （外向けの、デザインなども必須なもの。自社独自の仕組み・ワークフロー）
事前に要件を決めきれるもの。変化しないもの。
個人的感想
「向いている案件」に該当する案件はあるのか？というのが率直な疑問。
製品・不動産などにおいては一般的な形態だろうが、それはハードの世界ではパッケージ化ということができないからなのでは？と思う。
まして、ソフトウェア業界は技術の進歩がとても速いため、１，２年かけて作った頃には陳腐化していることもありえる。
内製
概要
自社でエンジニアを持ち開発を行うモデル。 社内で進めるので、保守性・意識のすり合わせ・スピード感の点で優れる。
システムのレベルは、社内のエンジニアのレベルがダイレクトに反映される。
メリット
社内に抱えているため安心できる。 意識のすり合わせのコストが激減する。
変更の要求が容易に行えるため、 変更の容易さ、カスタマイズしやすさ。機密性の高さが挙げられる。
デメリット
自社でエンジニアを抱える必要がある。工数が割かれる。 （レベルの高いエンジニアを集めることは難しい。）
向いている案件
社内秘を扱うようなシステム。 自社の業務に直結するようなシステム。
個人的感想
IT屋さんであれば、自社にエンジニアを抱えているし、 そもそも外注とかコンサルティングを受けようという発想も少ないだろう。
ただ、他の業態の企業であれば、そもそも社内にエンジニアのリソースなどはないはず。 （あったら、その会社は本業からズレている。）
IT屋だけがとれる戦略だが、なんでもかんでも自分たちで作るより、パッケージ化されたものを買ってきたほうが安上がりなことも多い。
技術顧問
概要
社外雇われ技術責任者（CTO）的なポジションを担うことで、その会社を技術の側面から支援する。
立ち位置としては、弁護士や会計士のような技術コンサルタント＆開発者。 （技術者は、フリーランスでも組織に属していてもどちらでも構わない。）
メリット
比較的ローコストで始められる。小回りがきく。 要件が固まっていなくても進められる。
デメリット
規模が小さい時は有効だが、大きくなるとコスパが悪くなる。
担当の技術者のレベルに大きく依存する（属人性の高いモデル）
継続的にサポートされるのかどうかに不安が残る。
向いている案件
エンジニアがいないような会社はうってつけ。 （これによってメイン業務に注力できる）
個人的感想
製品を提供するのではなくてコンサルタントに近い。 スタートアップなどでエンジニアを確保できない場合に有効だと思われる。
技術に疎い人が判断するのは難しいが、相手をプロとして信用できるかが大事。 （弁護士や会計士における国家資格のようなものが欲しい）
また属人性が高すぎて、いざ担当者が抜けた場合のことを考える必要がある。
そのため、提供する側のブランディング、継続性の担保が肝になる。 （テクノロジスト集団・OSSのコミッター etc…）
今後のビジネスモデルとして
技術動向（ツール・指向）
インフラやプログラミング言語の進化によって、プログラマの作業がよりコアな部分に集約され知的労働化されているため、凄腕のエンジニア一人が１００人分の力を持つことが当たり前になっています。
フルスタックエンジニアという言葉がバズワード化していますが、 技術が複雑・細分化していて、言葉通りの意味の人材はツチノコくらいレアでしょう。
また、技術の進歩がものすごく速いため、重要なのは今のスキルでなく、 新技術を積極的に学びとり、それを現実で活かせるだけの地頭・指向だと思います。 それがある人材さえいれば、少数精鋭でもなんでも作れる時代です。
また、SaaSと行った言葉に象徴されるように、 これまでのプログラムを作って納品するモデルから、プログラムを使ってサービスを提供するモデルへと変化しています。
技術者のニーズ
（※ここでは上記の優秀なエンジニアに該当する人たちを指す。）
そんな技術者たちのニーズは、先ほどの特徴から推測すると、
- 自分の知らない分野を学んだり切磋琢磨できること
- 目の前の仕事に忙殺されず、知的好奇心を探求できること（趣味も含む）
- 本来の目的に合致した業務を行えること
- 周りからフィードバックを受けられること（PDCAを回せる）
- 場所・時間を制限されないこと
が挙げられるのではないかと思います。
それを満たす職場環境として、「納品のない受託開発」で触れていたような、
- 技術者が集まって交流しあえる場があること
- 自ら要件定義、開発、保守を行えること
- 忙しすぎない（締め切りを一方的に決められない）こと。
などが要件に入りそうです。
技術者の評価・地位
ソフトウェア業界は技術の変化は変化が激しいため、国家資格のようなものはありません。
また、システムというモノが残り長期的に使用されるのに目に見えないという点で、 素人が成果を評価するのは無理です。（なんなら会計士などの専門職よりも判断しづらいと思います。）
というわけで、技術者の評価は第三者に委ねるのが合理的です。
第三者として挙げられそうなのはやはり他の開発者たちでしょう。
OSSでの貢献を測る格付け機関とかもできるかもしれませんし、 ギルドのようなエンジニアの会合とかがあればそこでお互いに発表しあって評価しあえるかもしれません。 （詳しくないですが、弁護士とかも弁護士会的な感じで同業で集まってんでしょ？きっと）
結論
今後は技術顧問だけでなく、テクノロジ集団の需要も上がってくると思います。 理由としては以下。
- エンジニアは互いに協調することを望む。
- レベルが高ければ数人でも大規模プロジェクトを回せる。
- 日本では人を採用することはリスクなので、費用対効果のわからない技術者は抱えづらい。
- エンジニアの格付けを行う必要性がある
パッケージ
→ソフトウェア独特の形態でメリットはあるので、業態としては生き残ると思います。
ただ、いいツールはどんどんオープン化していき、製品でなくサービスでのビジネスモデルになると思います。 対外的な技術アピールと、お試し期間を設けることができるからです。
まずは試してもらって、実際に運用するならライセンス料を払ったりメンテナンスを受けれるようにする。 保守・サポートで稼ぐという、よくあるフリーミアムのモデルですね。
SIer
大規模開発の外注というモデルの崩壊
→少数精鋭のプロ集団に外注するか、自社内でエンジニアを大量に抱えるタイプに変わると思います。
ただ、本業が別にある会社がエンジニアを抱えるモデルは現実的ではないので、プロ集団に外注する形になると思います。 その場合、形態としてはSIerと呼べるものかもしれないが、現行の人月単価のカスタマイズ業者とは異なります。
フリーランス
信用のある第三者に格付けされることが重要。
個人でやる作業は、信用や継続性・開発者個人のモチベーション的にもあまり広がらないのではと考えています。
（あと、フルスタックエンジニアじゃないと厳しいかも。）
ギルド
個人的に本命だと考えるもの。
エンジニア同士のコミュニティ。（たぶんデザイナーも入ってくる）。 会社のように雇用契約を結ぶのではなく、サークルに近い集まり。 お互いに定期的に交流し、技術を磨き合ったり評価しあったりする。
チームを組んで開発を行う。チームは固定でも流動でも様々。
開発者は、お互いに高め合ったり補完しあえるし、良い物を作るモチベーションも湧く。
依頼者としても、スピード感やレベルの調整ができるし、いきなり逃げ出される心配も少ない。 （そうなったら違うチームに声をかければいいし。）