開発内製をしている組織が、業務委託で外部の方の力を借りて開発をお願いするというケースにおいて、発注者側が業務委託で仕事をお願いする時に思ってることを書いてみようと思う。
エンジニアで独立心が高い人であれば、技術顧問だけじゃなくても、部分的な工数を切り売りして複数のプロジェクトに関わりあいたい気持ちもあったりと思うので、そういう人に向けても一助になれば幸いです。
前提条件
ここ背景的な追記事項なんですが、基本的な対象者は、「社員になってもらえたら超ラッキーみたいな人が、すでにフリーランスだったり、自分の会社を持っていて、別の仕事もやっている」という先方都合が上位なケースにおいて、業務委託でのみ契約に至る時に考えたりしたこと、という前提条件を追加しておきます。
ちょっと一般化して書いてみたら、もっと世界が広かったようで、そちらの世界の方で誤解を生んでいるケースもあるように思えました。それは純粋に失敗でした。
だから冒頭に書いた、「技術顧問」はもちろんのこと「フリーランス的に他社にも関わってみたい」と思っている人に、発注側がどう期待したいと思っているのか？が参考になったらいいなと思って書いています。
あとWeb業界、というか、当然僕が書いてるのでWeb系スタートアップが前提です。お手伝いいただく方は、大きくなった元スタートアップや現スタートアップでWebやスマホの開発経験が十分ある人をイメージして書いてます。
あと、この記事、働き方の話だよねって指摘もありますが、はい、それはその通りです。何もメンバーに話すようなことはネットでは書かなくていいですので、比喩的に適用可能な範囲が業務委託という表現でした。
（ちなみにお金の話なんてここで書くはずないので、そこが見えなくて物足りない、という人はあしからず。というか、当社に面接をお受けいただければ、当然、そこのお話はさせていただきます。謎なのは、安く買い叩いてんじゃね？というコメントの意味が全然わからないです。お願いしているのはこちらなのですから、同意が得られない取引が成立するハズはないのに。むしろ、何故、そういうコメントに至ったの？ということを聞いてみたいと思うケースがちらほら。）
考慮ポイント
１．お願いするタスクが、丸々お願いするような仕事なのか、それとも社内にメイン開発者がいて、その人の補助という形になっているか。
２．作業をお願いできる割合は、週２日なのか、週３日なのか、週５日のフルコミットをしてもらえるのか。
3.その人に期待するマインドシェアはどれぐらい？テンポラリで猫の手も借りれればOKなのか、もしくは成長にある程度コミットして欲しいのか。
4.その人のスキルは、フリーランスやアウトソースの業者としても、開発者としてのスキルもプロフェッショナルな働き方ができる人か。
変数としてはこれぐらいでしょうか。
相手に、どれだけの期待をしたいのか？
個人的においているラインは、
お願いする相手が神レベルの人で補助タスク
-> 週１でも週２でもいい。（技術顧問もここに入る）
相手は普通に作業をお願いできる方で、かつ、通常の補助タスク
-> できれば週３はコミットして欲しい
とある開発のパートを丸々をお願いする。社内に同じことをやってる人がいない
-> iOSアプリの開発などを想定。週５じゃないと辛いことになる。妥協して週3以上
経験が少なく、この仕事を通じて成長すべき人
-> ジュニア級のケース。週5ぐらいを前提にできないなら雇わないほうが吉
ポイントは、マインドシェアをどれだけキープできるか、というのと技術者としての集中力の使い所の配分なのかなと思っています。
超絶高いスキルの人で、分業が慣れている人は、そもそも優秀である以上に、時間外でもいつでもチャットが繋がったりと、関わっている時間に限らず、並行して、いろいろ考えていてくれたりします。
でも、それが契約の前提にはなりえないので、お願いする側としてのスタンスは契約時間に対してどれだけのパフォーマンスを発揮していただくか、ということが期待するポイントになるという部分に、言葉では言い表せない信頼に繋がっていくところになるのかなと思います。
ここで問題になるのは、
・集中力が削がれるテンポの働き方は、その人の生産性を落とす。
・そもそも作業日数が少ないので、単純にスケジュールが伸びる。
例えば週２日だけのコミットだと、残りを別の作業にあててるので、そもそも集中力を維持することと、作業そのもののスイッチングコストが高いです。そういうのに心底慣れているプロでなければ、Windowsのresume復帰のように、前のタスクを思い出す時間が必要になって、効率が悪いです。作業も分断しているので、あまりよい状態ではありません。
コンテキストスイッチに対して損失が生まれるのが機械と違う人間の特徴だと思っていて、その損失量は経験や実務能力に依存するので、コードが書けるからと言って安易に分業をするといいことがないと思っています。
結局、アウトプットの品質と生産性において、例えば、コードを書く人の集中力の密度ｘ時間ｘスキルという関係性があったとして、スキルは短期間においては、ほぼ一定なので、集中力の密度と、かける時間がアウトプットの品質と生産性に影響をもたらすと思っています。コンテキストスイッチは、集中力の密度に悪影響を及ぼすし、作業工数が少なければ時間に影響がでます。
それ故に、まだまだ学びが必要な経験が少ない人の分業は最悪だと思っていて、３歩進んで2歩下がるみたいな状況にお金を出すことになりかねないので、そういう人であればフルコミットを前提にできなければお願いしない方がいいです。
リリースサイクルも分業サイクルに合わせる必要が出てきますし、仮に社内で作業が並行している人がいると、その人の影響にもでてきてしまいますので、作業工程もギクシャクしがちです。頼める仕事の内容も、どこか限定的になっていきます。
特に、新規開発の場合は、集中力は分断されるは、作業は細切れになってしまうわで、とても非効率です。新規開発であれば社内で週５日のピッチを刻んでいる人のお手伝いをするというお願いのスタイルを作るのが望ましい姿です。
あとスタートアップのように時間を買ってでも成長しなくてはならない立場だと、しっかり組織として構造化しておかないと、その人に依存させるわけにはいかないです。
人の想いはお金では買えない
業務委託であるとか、社員であるとは無関係に、そのプロジェクトに関わる全ての人における理想的な関係性は、
「24時間365日、そのビジネスにどれだけコミットしてくれているか」
だと思います。
これは、ひたすら働くという意味ではありません。どこに現れるか？というと、休日のセレンディピティにおける優先順位、マインドシェアに現れたりします。
例えば、シャワーをあびている時にいいアイディアを思いつくとか、街を家族で歩いている時に、あれはもっとこうしたほうがいいんじゃないか？というアイディアを浮かぶようなのが一つの現象と言えるでしょう。そのような想いの集合体は、チームとしての総合力に繋がっていくように思えますし、そのような想いをベースとして、技術を学ぶ原動力になったりする人も少なくないですので、案外バカにしてはいけない概念かなと思っています。
少なくともそれが適切な距離感でできている人は、社内でもマネージャ候補になっているのかなと思います。
しかし、その人の最優先事項が、違う会社のビジネスに向いていたら、同じセレンディピティのタイミングにおいて、思いつくのは別の仕事の方かもしれませんし、優先順位が、おもいっきり趣味の世界の人は、そもそもそういうのを期待できないわけですから、それを踏まえた関係性で活躍いただくのがお互いのためによい関係性かとは思います。
業務委託の人に、そういうのは期待してはいけないにせよ、優秀な業務委託の人は、そういうのをうまくやってくれているケースが多いです。要は、ついつい社員としてジョインしてほしいと思うタイプですね。そういう人が最も信頼されやすいタイプ = 優秀な人であると定義しますと、優秀な人なら関わりあう日数が少なくても大丈夫かもしれないけど、多くの人にとっては、コンテキストスイッチにおける損失を最小化するためには、マインドシェアを維持するのが望ましく、それ故に、出来る限り多くのコミットを得られる方が望ましい、ということになると思います。
まとめると
・コミット日数が週５を割ると、基本的には「これだけの作業をしてもらえばOK」という作業者の形に近づいていく。
⇒そのサービスの成長やコミットすることに、仕事のやりがいを求めてる人にはあんまり向いてない働き方です。
・そうじゃなくて、何かを一緒につくり上げる気持ちが強いのであれば、継続的なマインドシェアをもってもらいやすい契約形態になっているか？が大事。
⇒ここにおいて、週３日以上というのは割と重要なパラメータかと思っています。
・複数の作業をやっている場合、コンテキストスイッチには損失が伴う。
⇒この損失量を補う方法は、そもそも、それに慣れているプロであるか？、もしくはマインドシェアを確保して、関心をキープしやすい状態を作るか？のどちらかがある方が望ましいと思います。
・人の想いはお金で買えない。
⇒仮に「それっぽく見せるのが上手い人」というのがいたとすれば、それは、この働き方におけるスキルのような気はしますね。
・超絶優秀な人は、すべてを超越しうるよ
⇒でも、そんな人めったにいないよ。
・すべては信頼ベース！
⇒信頼とは、「この人にこれをお願いしたらちゃんとやってくれた」という実績の集合体ですね。これを抱き続けられるだけの信頼が維持されていれば、いかようにでもなる。それを作るまでが大変。（だから、こういう仕事は紹介ベースが多いんですよね）
ちなみに、ここで書いてない、頼んではいけないパターンですと、「スキルは高いけど、開発者として割いてもらえる時間も関心も少ない」ケースですね。マインドシェアを得られてない上に、工数も少ないので、いてさえくれれば嬉しいですという状態でもなければ、アウトプットに対する信頼が生まれにくいので、お互いの関係性においてオススメはしません。
さいごに
たまたま帰りの駅で工事をしていて、はつり屋さん（コンクリを壊す作業の人）を見ていて、こういう人のマインドシェアってどこなんだろうなぁと思って、このことを考えていました。コストも壊したコンクリの体積に対して数万円というルールらしいんですよね。そういうオブジェクト指向の再利用パーツのように割りきった関係性で良いなら、それが一番いいんでしょうけど、僕らの仕事はUXなどという言葉が示す通り、成果はもう少し曖昧かつ、継続性があるが故に、継続的な改善サイクルを回すためにもウェットな関係性を求めていたりもしますよね。
あと、受託系のディレクターの人で、抱えてる案件が１０個とかになると、人の心がなくなるっていいますよね。いわゆる右から左に流すだけになって現場の反感を食らう系のディレクションですね。つまり、沢山の仕事をやって、関心が分散してしまうことは、原則として人間には向いていないということなんじゃないかなって思いますね。顧問弁護士さんとか税理士さんみたいに、タスクが分散できる仕事ならもっとキレイに分けられるんでしょうけどね。
・・・と、週末大学院生としてアテンション確保に苦労してる現実逃避的な書き込みでした。
p.s.少し推敲と、意図を損なわない形での加筆を行っています。
【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください