私たちの実践する「納品のない受託開発」では、担当のエンジニアがお客さまの顧問となって仕事をしていきます。（参考：顧問弁護士や顧問税理士のような「顧問プログラマ」という仕事と働きかた）
お客さまと長い関係を結べることが会社にとって安定をもたらし、お客さまにとっても安心してもらえるため、担当するエンジニアも長期的な関係を築くことを目指します。
しかし、そうすると、必ず聞かれるのが「その人がいなくなったら、どうするのか？」という課題です。私たちのビジネスは、プロフェッショナルサービスでもあるので、人に依存すること自体を見直す必要はありません。だからといって、リスクに対して何も手を打たない訳にはいきません。
この記事では、私たちがどうやって個人に依存する問題へのリスクヘッジを行っているか、少し専門的な話になりますが、私たちの取り組みとその背景について書きました。
Lonely / vishwaant
目次
ドキュメントを書かない
「納品のない受託開発」の進めかたの一つに「ドキュメントを書かない」というものがあります。「納品がないからドキュメントを作らない」というのは事象の結果であって、理由ではありません。その理由について、もう少し掘り下げてみましょう。
一般的にドキュメントには、開発側から見た工程間の伝達や保守への引き継ぎのための設計書と、顧客から見たソフトウェアがどのように動けば正解かという仕様書の２種類があります。
私たちの場合、お客さまとの対話から運用まですべてを同じエンジニアが担当するので、工程ごとに伝達するための資料はいりません。保守運用も同じ人が担当することで、引き継ぎの資料もいらないのです。内部的にはドキュメントがいらなくなります。誤解のないように書いておくと、設計書を作ったりはしませんが、設計作業は毎週少しずつ行っています。
また、仕様書を作ったからといって、その通りにソフトウェアを作りさえすれば良いかというと、それが事業として価値があるかどうかわかりません。大事なことは動くソフトウェアで価値を産み出しているかどうかです。そこで、動いているソフトウェアそのものが仕様である、と考えるようにしています。常に動くソフトウェアで動作確認し、直し続けていくのです。
そもそも動くソフトウェアを構成しているのはソースコードです。ドキュメントではありません。ソースコードこそがもっとも貴重な資源であり、仕様を現した事実です。最終的にはソースコードを読むしかありません。そのソースコードを自ら書いて読めるエンジニアがずっと担当していることで、いつでも仕様の把握ができるのです。
私たちは、こうして前提を変えていくことで、アジャイル開発でよく言われるような「必要最低限のドキュメント」というものすら何もなくなってしまったのです。ただし、こうしたやり方で心配されるのは「その人がいなくなったら・・・」という課題です。
人に依存するリスクへの対処
私たちがこの個人に依存する課題をどうやって解決しているか、それは技術的な観点と、仕様的な観点の２つがあります。
まず技術的な観点で言えば、ドキュメントを書かない代わりに、ソースコードだけで情報共有ができることを目指しています。そのための大きな前提として、「納品のない受託開発」では、どのお客さまであっても扱う技術を統一しています。
案件ごとにベースとなる技術要素を変えて提案をすることは、新しいチャレンジができて楽しいかもしれませんが、当然ですがコストもリスクも高くなりますし、社内でのノウハウ共有も難しくなります。私たちは、お客さま向けの仕事では技術を統一することで効率化を図りつつ、社員同士のノウハウの情報共有もしやすくしているのです。
新しい技術への挑戦は自社サービスの開発の中で行っています。会社としての技術戦略とは、こういうことではないか、と思うのです。技術の統一が出来るのも「納品のない受託開発」でお客さまが期待しているのは動くソフトウェアであって、その中身ではないからです。
扱う技術を統一した上で、現場で徹底的に行っているのは「コードレビュー」です。少なくとも本番環境へ展開する前に、必ずレビューを行うようにして、自分以外の誰かに必ずチェックしてもらうようにしています。そうすることで保守性が高いコードになっているかどうかの確認ができるのと同時に、自分一人しか見ていない状況をなくします。
長く保守運用を引き受けるため、私たちが最も大事にしている品質特性は保守性です。保守性のためには、DRY（Don’t Repeat Yourself）と呼ばれるような重複がなく、誰にとっても読みやすいソースコードであることが重要です。コードレビューを通じて、誰が書いても読みやすいソースコードにしていくのです。
もう１点。ソースコードだけでは結果としての仕様は把握できるかもしれませんが、そうなった意図や背景までは知ることが出来ません。そこで、仕様的な観点から私たちが行っているのは、担当のエンジニアに加えて、お客さまとの打ち合わせには２名で参加し、もう１名がサポートに入るようにしています。そこで、お客さまとの信頼関係も築きつつ、お休みの場合や不慮の事態に備えるのです。
サポートに入るのは、担当するエンジニアの弟子であるケースもあれば、同じ１人前のエンジニアがつくこともあります。場合によっては、私や副社長のようなビジネスのわかる人間が入る場合もあります。エンジニアにとってみても、すべての問題をたった一人で向き合うのではなく、助け合っていくことができますし、それが最大のリスクヘッジにもなっています。
チームだからこそ対応できる
エンジニアの個々人がお客さまの顧問として担当するという言葉から、ソニックガーデンは個人商店の集まりみたいなものだと思われる方もいますが、決してそんなことはありません。前述の通り、コードレビューや打ち合わせへの参加など、一人だけでは担保しきれないところはチームメンバーがサポートに入ります。チームだからこそ対応できることなのだと思います。
クラウドソーシングで個人に発注したり、フリーランスのエンジニアに依頼する場合は、人に依存するリスクマネジメントは発注側が行う必要があります。しかし、「納品のない受託開発」では、そうしたこともまとめてサービスとして提供しているのです。だからこそ価値があるのだと考えています。そのために、私たちはチームとして活動することを大事にしています。
フリーランス同士の集まりではなく、会社として利害の一致した仲間同士で助け合うことで出来ることです。何かあった時に助けられるようにコードレビューをしておくことは、コードレビューをする自分自身にとっても意味のあることで、そのように真剣に誰かにコードレビューをしてもらえるというのは、エンジニアとしては非常に安心できます。
また、すべての工程を担当できるようにエンジニアは努力していますが、人間なので、得手不得手は必ずあります。不得手な場面でも、お客さまから期待されるのは一流のサービスです。そうしたときにチーム内で助け合う訳です。必要なタイミングで自分の得意とする領域でカバーに入ります。
新規事業で内製をするために一人のエンジニアを採用するリスクは、実はその点にあります。社内に一人しかエンジニアがいない状況であれば、その人が苦手なことがあった場合、足りないところを補うために別の人を採用しなければいけなくなります。しかし、そんなことをしていたら相当コストがかかります。スキルは丁度になっても人手が余ることになれば、無駄なものも作ることになるかもしれません。「納品のない受託開発」では顧問として契約しているように見えて、実は、個人でサービスを提供しているのではなく、チーム全体で価値を提供させてもらっているのです。
チームになることで、お客さまへのリスクだけでなく、エンジニア個人にとってのリスクも回避できます。また、その中で人を育てる余裕も出来てきます。人が集まることで安定し、将来の担保をお互いにしあうことができます。それが会社である意義です。大企業である必要はないけれど、たった一人でいる必要もありません。チームで安心できるからこそ、個人としても高みを目指していくことができます。
この記事で書いたように、人に依存するリスクに対しては経営と現場の両面での対策を行っている訳ですが、何よりも最も大事なことは、そもそも社員がずっと働きたいと思ってもらえるような良い会社でいることと、チーム内の助け合いに労を惜しまないような人を採用すること、そしてもし何か起きても一緒に問題に向かってもらえるようにお客さまとの信頼関係を築いておくこと、だと私は考えています。
