「顧問プログラマ」再考

先週（2015/11/23）にシステム開発を内製するか外注するかという短い記事を書き、はてなブックマークで多少の反響がありました。その後で私が考えたり調べたりしたことを、まとめておこうと思います。ちょっと長い文章ですが、辛抱強くお読みください。

---

システムを作りたい側の視点で考えたとき、内製か外注かという二択になりがちだけれど顧問プログラマ（ソニックガーデン倉貫氏）という第三の道もありますね、ということを先週は書きました。

ここで私が「システム」と呼んでいるのは、情報システムのことです。もっと具体的に言えば、弊社（株式会社オイアクス）の専門である Ruby on Rails で作るような Web ベースのサービスを念頭に置いています。SNS のような一般向けのサービスもあれば、人事管理システムのような企業向けのサービスもあります。インターネットに公開する場合もあれば、社内 LAN で使う場合もあります。いろんな種類のものが考えられますが、銀行のオンラインシステムのような巨大なものは視野にありません。また、私自身が関わってこなかったので、オンラインゲームのシステムも対象外です。

また、以下の文章をお読みになる上で留意していただきたいのは、ベンチャーとかスタートアップとか呼ばれる歴史の浅い会社がシステムを作りたい、という状況を私が想定しているということです。上場企業や昭和の時代から続くような会社の文脈で考えると違和感があるかもしれません。

---

さて、「顧問プログラマ」は聞き慣れない言葉ですが、簡単に言えば顧問税理士のプログラマ版です。企業が経理担当者を社員として雇う代わりに、経理事務を税理士事務所に任せることはよくあります。企業がシステム開発という仕事を「顧問プログラマ」事務所に代行してもらうのです。

顧問税理士と「顧問プログラマ」にはいくつか共通点があります。

• 専門業務を遂行する。
• 通常、（客先ではなく）所属事務所または自宅で作業を行う。
• 業務量は月によって変動するが、通常は月額固定料金。
• 顧客との契約は民法上の準委任契約となる。

特に重要なのは四点目です。「準委任契約」とは何でしょうか。

---

ここまで私は「内製」と「外注」という言葉を漠然と用いてきましたが、もう少し具体的に定義しましょう。

システムを作りたい会社を仮に「A」と呼びます。A がシステムを内製で作るとは、プログラマを社員（正社員または契約社員）として雇いシステムの開発をさせることをいいます。この場合、A とプログラマは雇用契約を結ぶことになります。

他方、A がシステム開発を外注するとは、別の会社（あるいは個人事業主） B にシステムの要件を伝え、完成されたシステムを B から納品してもらうことを意味します。この場合、A と B が請負契約を結びます。

雇用契約と請負契約の根本的な違いは、完成義務と従属関係の有無にあります。

雇用契約の場合、プログラマの義務は労働を提供することです。仮に特定のシステムを開発するために雇われたとしても、完成義務は負いません。失敗の場合に解雇されるかもしれませんが、過去の給与を返せとは言われません。請負契約の場合、完成義務を負います。システムが完成しなければ基本的に対価は支払われませんし、損害賠償しなければならない場合もあります。

雇用契約の場合、プログラマは会社に従属します。制限はありますが、プログラマは会社からの業務命令に従う義務があります。朝礼に参加せよとか、支社に異動せよとか、といったことです。請負契約ではそういうことはありません。もちろん契約時に「一週間ごとに進捗報告をする」と取り決めたのであればそれは義務ですが、一般的には命令や指示に従う義務はありません。

---

「顧問プログラマ」に適用される「準委任契約」は、雇用契約と請負契約とも異なります。準委任契約では、雇用契約と同様にプログラマは完成義務を負いません。また、準委任契約では請負契約と同様に契約者間の従属関係がありません。

この点をまとめたのが次の表です。

	契約	完成義務	従属関係
内製	雇用		有
外注	請負	有
「顧問プログラマ」	準委任

「委任」という言葉から連想されるように、「顧問プログラマ」の本質は、システムを作りたい会社から専門家として信頼され業務を任される、ということです。仕事のやり方やペースを細かく指示されずに、自発的に成果を出すのが「顧問プログラマ」です。

---

「顧問プログラマ」が完成義務を負わない点に納得がいかない、という人は多いと思います。「成果を出す」とは、すなわち「システムを完成させる」ことなのではないでしょうか。

しかし、システムを作りたい会社が「顧問プログラマ」事務所と契約を結ぶことには、大きな利点があります。

ベンチャーとかスタートアップと呼ばれる企業にとって特に意味のある利点です。

それは、直ちにシステム開発を始められる、ということです。

内製でも外注でもシステム開発の前段階にコストがかかります。

内製で大きいのは、採用活動のコストです。広告宣伝費、面接官の人件費、人材紹介会社に支払う手数料、など。

外注の場合は、要件定義に大きなコストが発生します。システム開発を請負契約で受注する会社は完成義務を負いますから、厳密な要件定義を求めるでしょう。要件定義に曖昧さが残ると思えば、リスクを織り込んだ見積書を出してくるでしょう。

他方、「顧問プログラマ」を利用する場合は、要件定義が完了していなくても実装作業をスタートできます。あなたが新しい画期的な Web サービスを世に送り出したいともくろんでいるなら、ぐずぐずしている暇はありません。会社の業務改善を目的とするシステムを作りたい場合でも、開発スタートが遅れれれば遅れるだけ同業他社との競争で不利になります。

---

もうひとつ考えるべき点は、ダメな人や開発会社と契約してしまったときのことです。

雇用契約の場合、法律的にも社会通念的にもなかなか契約破棄（解雇や会社都合退職）は難しいものです。解雇には「合理的な理由」が必要で下手をすると裁判で負けるし、労働者が納得しない限り会社都合退職にも持ち込めません。また、解雇や会社都合退職を行うと厚生労働省管轄の助成金がもらえなくなる、という不都合な事情もあります。

請負契約の場合、法律上は発注側の権利が守られているように見えますが、実務上はそうでもありません。完成しなければお金を払わない、納期に遅れたら違約金を取ると契約書に書いてあっても、いざ紛争になれば膨大な時間と費用が失われ、トータルでは勝ったのか負けたのかよく分からないようなことになりがちです。

その点、「顧問プログラマ」の準委任契約は、基本的にいつでも契約解除できます。契約書に事前通告期間が設定されていればそれに従うことになりますが、そこは契約時の交渉次第です。また、「顧問プログラマ」が完成義務を負わないといっても、いわゆる「善管注意義務」は負うことになります。ちゃんと仕事をしていなかったことが明らかであれば、減額要求や損害賠償請求が可能です。

ダメな人や開発会社と契約してしまった場合、早めに見切りを付けることが大切です。しかし、請負契約の場合に特に言えるのですが、開発の途中で「これは失敗しそうだな」という雰囲気になったとしても、簡単にはやめられません。経営的にはいち早く「損切り」して別の方向性を探るべき局面なのですが、最終的にプロジェクトが炎上して焼け落ちるまでずるずる進みがちです。

---

事業継続性の視点から見た場合でも、「顧問プログラマ」は悪くない選択肢です。

Web システム業界の雇用流動性はとても高いので、多くのプログラマが数年間隔でさまざまな会社を渡り歩いています。システム内製化のために雇った社員が優秀であればあるほど、転職への誘惑は強くなります。システム開発のノウハウは文書化しにくく、個人の脳内にとどまりがちです。突然エースプログラマがやめれば会社が傾きかねません。

もちろん「顧問プログラマ」も転職するわけですが、「顧問プログラマ」は法人間契約に基づくサービスである点で普通の社員とは異なります。「顧問プログラマ」事務所には、個々の「顧問プログラマ」が転職しても顧客の事業が回っていくような体制を組む義務があります。そこで複数の担当者を付けたり、積極的に文書を残したりするわけです。

請負契約でシステムを開発した場合でも、納品後に適切な保守契約を結べば「顧問プログラマ」と同様の体制を組んでくれるでしょう。ただし、会社によっては開発チームと運用・保守チームが別の部署になっているところもあります。Web サービスの場合、開発フェーズと保守フェーズの区別は明確ではなく、リリース後も継続的に開発を続けるのが普通です。そういう要望に応えられるかどうか、最初の請負契約を結ぶ際にきちんと確認しておくことが大切です。

---

最後に、「顧問プログラマ」とソフトウェアエンジニアリングサービス（SES）との関係について、簡単に述べたいと思います。

法律的な観点から言えば、両者は同じものです。準委任契約に基づく労務供給です。どちらも、何かを完成させる義務を負わずに、特定の業務（例えばソフトウェア開発）への技術者の労務の提供を行う契約です。

しかし、「SES」という言葉には、ある種のネガティブなニュアンスがあります。

私自身は SES 業界にいたことがないので伝聞情報に過ぎませんが、現在の慣行では「SES」は「客先常駐」のほぼ同義語として使われてるようです。客先の会社の事務所に常駐して、ソフトウェアを開発する仕事です。本来の定義では「SES」として常駐するプログラマへの指示は、在籍している会社が行うことになっています。しかし、実際には客先の会社からの指示に従って仕事をすることが多いようです。いわゆる「偽装派遣」です。

私が「顧問プログラマ」と呼んでいるサービスは、それとはまったく異なるものです。

基本的に「客先」には常駐しません。仕事は所属会社の事務所（あるいは、自宅）に持ち帰ります。顧問プログラマは顧客に従属する（指示・命令を受ける）立場ではなく、むしろ助言をしたり相談を受けたりする立場です。多くの場合、仕事に着手する時点でシステムの要件定義は完了していません。要件定義と開発を同時に進め、状況に応じて要件を柔軟に変えていくお手伝いをします。

また、複数のプログラマがチームを組んで担当するのも特徴です。特定の人を特定の顧客に専属させることはしません。ひとりのプログラマは複数の顧客を担当します。

「顧問プログラマ」は報酬に見合う成果を出す必要がありますが、あらかじめ厳密に決められた成果物を出すという形ではありません。いつでも契約を解除されかねないというプレッシャーの中で、プロフェッショナルとして最大限の努力を払う、そういう存在です。

うちの会社ではそんな曖昧な契約を稟議に通せないよ、と思われた方もいらっしゃるでしょう。ちゃんと申告通り仕事をしたのかどう確認するのか、成果が報酬に見合うかどうかどう判定するのか、と。

しかし、システム開発が会社の命運を握っているのなら、経営判断として「顧問プログラマ」に委任することも選択肢に入れて考えるべきです。