hkoba blog

プログラマーです。プログラミング言語ミーハーです。ツッコミ歓迎です。よろしくどうぞ(能代口調)

「納品のない受託開発」、フリーランスな私の場合

先日、「納品」をなくせばうまくいく、という本を買いました。タイトルに近いことを自分も長年感じていたので、即買いでした。

「納品」をなくせばうまくいく

「納品」をなくせばうまくいく

私は(この本の著者さんと違って)フリーランスですが、 (実質的に)納品のない仕事の請け方を追求してきたので、非常に納得する点が多く有りました。 また同時に、自分の現場には適用できない点や、 フリーランスな自分では辿り着けない点も多々見つけられたので、 少しまとめてみます。

本の要約

私なりに要約すると…

  • (特に Web サービス系の) ベンチャー事業にとって、従来の「一括請負⇒納品して終わり」 という形の受託開発は相性が悪い。なぜなら、
  • 一括請負型の受託開発ビジネスとは
    • 全機能の要件定義と見積もりを最初に行い、
    • 全機能をまとめて開発して、納品して完了
    • 保守・運営(運用) は別会社に、 というものである。
  • これに対し、Web サービス事業で、どの機能が当たるか予め全て予測することは困難。 事業の成否はサービス開始後の、運営しながらの継続的改良にかかっている。

つまり、発注側が「頑張って欲しい」と思っているところと、 受注側が「頑張る所」が根本的にズレている。 ズレの根っこが「納品」というゴール設定にあるので、これを取っ払って、 新しい仕事の請け方、頼み方を組み立ててはどうか?と。

フリーランスな私との比較

共通点

  • 仕様書なし、見積もりなし、納品(完了)なし
    • (作って納品して終わりでなく) 日々改良していく
    • 月額定額制
  • 一人の開発者が目標設定の打ち合わせから開発・運用まで、一貫して関与(伝言ゲームにしない)
    • 要件定義や仕様書などの「実行できないペーパー」で事前に縛ろうとしない。
    • 何を作るか、何を優先して作り始めるかのコンサルティングも、開発者の仕事
  • 顧客にも動作確認の責任を分担してもらう

私がガチガチの納品というゴールを避けるようになったのは、 本来好きで楽しいはずのプログラミングが、 仕様と締め切りを固められただけで (どんなに凄いプログラムでも) 出来て当たり前となり、 妙に苦しくなることへの疑問が有ったからでした。 そこでいつからか、エンドクライアントの居る案件でも 「お客様にお知らせする仕様&納期にベストエフォートだと断りを入れる」 ようにした結果、精神的に随分と楽になったので、最近は全てそうしています。

異なる点:スタッフさんの訓練まで請け負うなら遠隔勤務は難しい

フリーランスであること以外で、「納品のない〜」と私の仕事の最大の違いは、 リモート作業が主か否か、です。この著者さんの会社の場合、 基本的な開発作業は自社で行い、会議もリモートで参加するようです。 ですが私の場合は、少なくとも現状では顧客のオフィスに出勤せねばなりません。 その最大の理由は、私が 「サービス運営スタッフさんへのプログラミング教育・訓練」 を請け負っているからです。

私の顧客の事業は受注案件ごとにプログラム開発(作成、と言うべきかもしれませんが)を行うもので、 (年間数百件の開発を私が直接作っていては事業がスケールしませんから) 顧客が人を雇って開発を行ってもらっています。 しかも顧客が雇うスタッフさんは、実はプログラミング未経験者ばかりです。 業務的に知名度がないことに加えて、CSを取ったプログラマーだと すぐに飽きて(辞めて)しまうようなプログラムを、次から次へと年がら年中、書かねばならないためです。 未経験の方が、何年も掛けて現場で学んでいける分、定着して下さっています。

そういう状況ですから、私の仕事は、

  • プログラム未経験者でも戦力になれるような Web App Framework と、そのための (簡易) IDE を提供する
    • プログラミング未経験者でも (頑張れば) 習得できる DSL を提供する。
    • 綴り間違いなど、陥りがちな単純ミスを、可能な限り静的に検出する。("use strict")
    • 作成作業の中で、手間がかかって思考を分断させるところや、取り違えミスの温床になりそうな所は、出来る範囲で GUIして、トラブルを減らしていく。
      (彼らを完全に救えている、とはまだまだ言えないのが心苦しい所です ><)
  • その WAF (や、その後継機) 上で用いる業務応用モジュール群を大量に提供する
  • スタッフのプログラミング上の質問に答え、彼ら彼女らの成長・自立を助ける。
    • 自ら受注案件間の共通部分を見出して、部品を生み出していけるように。
  • 業務のテンプレート集、業務マニュアル wiki なども書きますが、これについては 私が全部を書くのではなく、スタッフが自分で書く勇気と習慣を身につけられるよう、 うまく導かねばなりません。

です。遠隔勤務だとどうなるか、なかなか難しそうです。

フリーランスの限界

私は独りで仕事を請けています。人を雇える状況ではないので、後継ぎもいません。 つまり、 モジュールのマニュアルを読んでくれる人も、 コードレビューもペア・プログラミングの相手も居ない状況を ほぼ 10年以上、引きずってしまいました。

そうして、残念ながら、私自身が顧客の事業SPOF - Single Point Of Failure になっている…この点が、上記著者さんの会社と見比べて、今の自分が最も見劣りする部分です。

幸い、顧客企業とは散々話し合って、この点の問題意識は共有できているので、 今後は八王子PMなどの勉強会・交流会に少しでも顔を出して、 一緒に仕事をして下さる方を増やしていこう…そういう感じです。

まとめは、ありません!