業務外で自分にコードを書かせたくて、別人格「おじさん」にタスクを指示してもらうことにした

## 別人格「おじさん」発生の経緯
仕事が暇で、時間があった。
何かコードを書きたい欲求もあるし、それなりにインスピレーションも湧くのだけど、
このところはコード断片を書いては消し、で何ひとつモノにならなかったので、少し自信喪失気味だった。
<br>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">インスピレーションみたいなのは常にあるんですけど実装がだるい<br>これはもうだめかもわからんね<br><br>思うけど人にさコード書かせたいよね<br>で自分は人にコード書かされるの<br>そういうリソースの交換がしたい</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1036885086979813376?ref_src=twsrc%5Etfw">2018年9月4日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<br>
どうも自分は「他人にコードを書かせたい」、また反対に「他人にコード書かされたい」と思ったらしい。
それって何か楽そう、楽しそう、と思ったのかもしれない。
でもそんな都合の良い「他人」は、少なくとも自分の知る限りではいなかった。
その事実をよく噛んで含めて、モチベーションに転化しようとしたのが、次のツイート。
<br>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">自分が求めるスキルを持つ人間を見つけて仕事をさせる難しさを考えたら自分で自分に仕事をさせるのがいいに決まってるんよ<br>これ100万べんくらい唱えたらいけるのでは</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1036888142320611329?ref_src=twsrc%5Etfw">2018年9月4日</a></blockquote>
<br>
しかし、「自分で自分に仕事をさせる」こんなことが簡単にできたら苦労はない。
それができない理由を、以下のツイートでは「報酬設定が難しいから」とした。
<br>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">自分が自分に仕事をさせるのが難しいのは報酬設定が難しいからかな？<br>わいが仕事するときは仕事相手の信用信頼を得る・維持することが第一<br>そうすれば仕事がやりにくくなることはない<br>まっ、市場価値なり給料は上がっていくでしょーという希望的観測<br>このロジックは残念ながら自分には使えない</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1036892764405784577?ref_src=twsrc%5Etfw">2018年9月4日</a></blockquote>
<br>
その後も何やかんやと思考の整理をしていく中で…
<br>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">自分に仕事をさせるって発想は、IT企業において客先常駐と比較したときの自社サービスにありようが近い気がする<br>自社ならぬ自分サービスがあってそれが客先常駐に比べて十分にお金を生めば自分に仕事をさせられる</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1036914640012238848?ref_src=twsrc%5Etfw">2018年9月4日</a></blockquote>

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">それが最初からできたら苦労はないので<br>ここはひとつ「自分に仕事をさせる」ことを目的にして自分サービスを作るのはどうか<br>ということをもうちょっと考える</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1036914714972831744?ref_src=twsrc%5Etfw">2018年9月4日</a></blockquote>
<br>
別人格「おじさん」が、なかば思考実験的に誕生した。
「もし他人からこんな条件を持ちかけられたら、乗ってもいいかな？」というポイントを探ってみた。
<br>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">自分に仕事をさせるために別人格を作ってみる<br>・勉強会で知り合ったおじさん<br>・副業でサービス作りたいからわいに開発をしてくれと言ってきた<br>・おじさんは開発しない<br>・収入は二人で折半<br>・開発のオーダーはおじさんが出す<br>・議論はするが決定権はおじさんにある<br>・拒否権はわいにある</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1036951119073665026?ref_src=twsrc%5Etfw">2018年9月4日</a></blockquote>
<br>
前述の「報酬設定が難しい」という課題に対して、
「なるべくストレートに収益化する。アイデアは既存のものを使う」という絵を描いた。
<br>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">結局「昔作ったWebサービスの焼き直し」という、おじさんとわいさんでは本来共有できないイメージで、収益化を目指すこととなった…<br>しかしおかげでAmazon商品検索APIの疎通ができた。（昔作ったアカウントだけはあった。）</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1036982062790500352?ref_src=twsrc%5Etfw">2018年9月4日</a></blockquote>
<br>
上記のツイート上で、「おじさん」と自分「わいさん」のキャッチボールがはじまった。
キャッチボールって要するに、「タスク指示」と「タスク完了報告」。
<br>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">わいさんは、今日Amazon Product Advertising APIについて調べた。<br>・Qiitaでググって43記事に目を通した。<br>・スクラッチパッド(お試しWebUI)で遊んだ。10件ずつ50件までしか取れない模様。ソートが割と貧弱。<br>・利用ガイドラインに目を通して、一日8000リクエストくらいは最低でもできるとわかった。</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1037282178181165056?ref_src=twsrc%5Etfw">2018年9月5日</a></blockquote>
<br>
別の日のキャッチボール。
<br>
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">わいさん途中経過<br>Herokuのゴミアプリ整理<br>→heroku/node-getting-startedをGitHub上でフォークしてリネーム<br>→Herokuで新規アプリ作成、リポジトリ紐付け、自動デプロイ設定<br>→Cloud9でリポジトリからワークスペース作成、Run確認<br>→コミット、プッシュしてHerokuへ自動デプロイされることを確認</p>&mdash; しうへい (@cuhey3) <a href="https://twitter.com/cuhey3/status/1037882233091121152?ref_src=twsrc%5Etfw">2018年9月7日</a></blockquote>

まだ日は浅いけれど、キャッチボールはおおむね順調に進行している。
「おじさん」の視点で、「どうタスクを切り出したら、気持よくコードを書いてくれるかなぁ？」と考えるのも存外楽しい。


元は一人なのにこの楽しさは何だ？ということで、「今回はいけるのでは？」と期待を持てるくらいにはなっている。
せっかくなので、この記事を書いた。

## 別人格と仕事して得られた気づき

### ボールを返すことに意識を集中するとパフォーマンスが出る

与えられたタスクを完了したことで、得られる結果（評価）は様々である。

1. 依頼者が受け入れて、さらに心象が上がった。
2. 依頼者が受け入れた。
3. そもそも完了することができなかった。(依頼者のタスクが不適だった。)
4. そもそも完了することができなかった。(自分の能力不足で。しかし得られるものはあった。)
5. そもそも完了することができなかった。(自分の能力不足で。得られるものもなかった。)

上から順に好ましい結果だとする。タスク開始時点で目指すは1であるけれど、結果はやってみないとわからない。
なのでそこに気を配るより、完了/不完了をすべてひっくるめて「ボールを返すこと」ととらえ、
どうやったらボールを返せるか、に意識を集中すると、思考がスッキリして捗るように感じた。
もし結果が同じなら、ボールはなるべく早く返すのが好ましい。スピードと達成度の配分は自由である。
返された結果を元に、依頼者は次のタスクを考えはじめるだろう。


### タスクは大きすぎると負担になるが、絵は大きく描いて見せるのが望ましい

タスクが大きいと、ボールが長時間手元に残ることになる。
そうすると、人の心理として、だんだんイライラしてくるし、不公平感を感じはじめる。
自分などは、別人格「おじさん」に対しても「折半はやっぱり割に合わないナァ…」などと感じ始めるから、相当なものである。
こういう時は素直に依頼者に申し出て、タスクを分割してもらうべきだろう。

では最初からタスクはストレスがたまらないサイズにすべきか？というと、そうでもないと考える。

- タスクの正確なサイズは当人にしかわからないし、着手してみないとわからない部分があるから。
 - その上で「その…やっぱり…大きいです…」と言えるのが正しさだと感じる。
- 依頼者が十分にタスクを小さくしてしまうと、一連の作業のコンテキストを、実行者が見失ってしまう可能性がある。絵は大きく見せておいた方が、全体で見た時の齟齬が少ない。
 - 世に出回る、正確性を無視したパワポ概要図に意味があるとは、自分には思えないけれど。

### 「おじさん」は理想のディレクターか？

「実装以外の仕事をする人」をここでは便宜上ディレクターと呼ぶことにする。
「おじさん」は、実装こそしないが、技術レベルは実装者である自分と完全に同一であるし、
実装者に何ができて何ができないのかを、完全に把握しているので、無理難題は絶対に言わない。
また、タスクの説明も超上手くて、コミュニケーションロスは発生しない。

我々のような実装者が、日常的にディレクターに抱く不満を、「おじさん」は完全にクリアしている。
だけれども、それがディレクションのすべてではないと、「おじさん」側も演じてみて、ちょっとわかってきたかもしれない。

（この点については、今後気づきがたまったら、また記事を書こうと思います。）


## パペット駆動開発、爆誕！

Twitter上では「おじさん駆動開発」と呼んでいたのだけど、
これだと知らない人に読ませても1mmも意味が通じないから、
この機会に「パペット駆動開発」という名前をつけてみた。
英語だと <b>P</b>uppet-D</b>riven <b>D</b>evelopment で <b>PDD</b>。

しかし実際には、ウシ君やカエル君のようなパペット相手だと仕事が進まないだろうから、
なんだかそれっぽい人格や、呼称を与えることがふさわしいと思われる。


…というわけで、皆さんも何かの折には「パペット駆動開発」を試してみてください。
なにか面白いことがありましたら、こちらの記事へフィードバックをいただけたらうれしいです。

#### (…お試しの際は、多重人格者になってしまわないよう、くれぐれもお気をつけあそばせ…)