hkoba blog

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

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

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

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

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

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

本の要約

私なりに要約すると…

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

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

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

共通点

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

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

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

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

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

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

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

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

フリーランスの限界

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

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

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

まとめは、ありません！

吹き荒れる OOP 批判の嵐の中で独り言〜

(自分への返信にしたから見辛いっすね...)

コード出せよと言われそうなので、一つ貼っときます＞

hktools/sqlite-explain.tcl at master · hkoba/hktools · GitHub

Hachioji.pm #41 に参加してきました

昨日は Hachioji.pm (八王子で開催される、Perl好きを中心としたプログラマーの交流会) に行ってきました。

今回も皆さんの LT、どれも面白くためになりました。 特に xtetsuji さん の パスの左側セッション の話は、やっぱ皆それ考えるよね〜と思ったり。

あと、PHP の Session 事情を uzulla さんが詳しく解説してくれたのも 非常に参考になりました。

自分の LT

LT のざっくりしたお題が Session だったので、私からは YATT::Lite から session を使う例を雑に紹介してきました＞

(git push し忘れとかリンク切れを修正してあります)

おまけ

今回のTシャツは妖精さんでした

一週間前にも間違えて八王子に向かいそうになったのは良い思い出です。

連番ファイル生成、Zsh ならこう書くなぁと...

この blog url が RT されてきたので＞

シェルスクリプトで連続処理 - 作業日記

自分だったら、Zsh でこうするなぁと。

touch hoge{001..100}.txt

マニュアルはこちら＞ Zsh - Brace Expansion

hachiojipm #37 に行ってきました

昨日は hachiojipm に行ってきました。 pm なんだけど ruby や php の話が聞けて (かつ perl 文化圏の人間に分かるように話してもらえて) 最近非常に勉強させてもらってる集まりです。

LT のお題は editor だったので tcltk 関連とか頑張って出そうかとも 思ったのですが、いかんせん、手持ちのツール群はどっぷり業務特化してしまってて断念。

代わりに小ネタとして、先日 @stealthinu 氏との対話で取り上げた "dryrun" ( make -n のように、「実際には実行せずに、何が起こるかだけを画面に出して終わる」) オプションの、私がよく使う実装イディオムについて話してきました。

My Zsh idiom. How to write dryrun behavior in Zsh.

関数 "DO" が肝です。これは引数として渡されたコマンドを画面に出し、 オプション -n が指定されていればそこで終了、 通常は引数列全体をコマンドとして実行、というものです。

あとは「何が起こるか」に相当するコマンドの頭に "DO " と書き加えるだけです。

残念ながらこの方法はパイプラインや file のようなリダイレクトがあるコマンド には適用できません(その場合は、その部分だけ関数にまとめて、関数に対して DO で prefix するのが良いでしょう)。

dryrun は真面目に作ろうとすると変更箇所が増えて大変ですが、 この方法なら、プログラミングの手間がほとんど増えないので、 投下労力対効果が良くて非常に気に入っています。

DO の最後の実行のところを "$argv[@]" にしたほうが完璧ですが、 ここでは読みやすさ優先、ということで。

謹賀新年/2014目標

あけましておめでとうございます。

昨年仲良くしてくださった皆様、ありがとうございました。

また今年もよろしくお願いします。

 

遅まきながら、今年からこの blog での情報発信・意見発信にも取り組んで参ります。初めましての方も、以後よろしくお願いします。

昨年の反省点

  1. プログラミング言語研究のために作ったはずの休日を、体力回復だけで終えてしまうことが更に増えたこと
  2. 部屋の書籍減らしが、思ったほど進まなかったこと

昨年、良かった点

  1. YATT::Lite を CPAN にリリースできたこと
  2. hachioji.pm はじめ Perl コミュニティーに定期的に参加し始められたこと
  3. 未来塾の中級コースで、自分の英語発音の改善の糸口を得られたこと
  4. 長年の顧客に、遂にプログラマー不足への組織的な行動を始めてもらえたこと

今年の目標

  1. 体力維持・向上、健康管理にもう少し労力を割く
  2. 引き続き、YATT::Lite の使用例やマニュアルを拡充していく
  3. OCaml を自分の武器になるレベルでマスターする。
  4. 嫁(彼女)探しを諦めない...諦めないよっっっっ(><)