開発における処理能力欠乏への対処

「いつも「時間がない」あなたに」を読んで、開発に役立てられることたくさんあるなーと思ったのでまとめる。

"SCARCITY: Why Having Too Little Means So Much" という本の日本語訳。原題からわかるとおり、「欠乏」についての科学的な実験結果と洞察がまとめられている行動経済学の本。時間への欠乏について「も」言及されているが、どちらかというと貧困など社会的な欠乏への対処を大目標においた、現在のまとめ的な立ち位置の本。「おれたちのたたかいはこれからだ」で締められている。

ただまあ非常に読みづらい。神話的というか、口伝的というか、寓話や例が多く登場するが明快なまとめがなく、主張したいことがわかりづらい。時間がない人は最後に訳者が主張を 3 ページでまとめてるのでそこをまず読んで、目次をたよりに具体例を探していくのがよいかも。

というわけで、書かれていることから実際の開発においてこうしたらいいんじゃない ? というのを考えてみた。「処理能力」とか「ショック」とかは本の中で述べられている概念なので気になったひとは参照してください。

処理能力が高いときに作業できるようにする

処理能力が高い時間を極力コーディングなど作業に使うようにする。

たとえば睡眠によって処理能力が回復した午前中に作業するようにする、処理能力が残っている週初めを作業日として金曜日は処理能力が低くてもできることをするなど。ここから、レビューや打ち合わせは午後や金曜日にまわすとか、一週間の予定もたてやすくなる。

ここで重要なのは「公言して協力してもらう」ことかなと思う。そうじゃないとみんな勝手にスケジュールいれてくるという環境の方もおおいと思うので。その際の説得材料として本の要約やこのエントリーを出すというのもアリかな。

ショックを吸収するスラックをつくる

予定をぎゅうぎゅうに詰めない。もしくはマネージャーやサポーターを確保してトンネリングに陥ってもよい状態を作る。

たとえば↑の「処理能力が高いときに作業できるようにする」も考慮して、会議・来客はすべて午後や金曜日に設定するとか、そもそも水曜日は丸一日あけとくとか。この場合「公言して協力してもらう」ことも忘れずに。

あとはプロジェクトマネージャーがプレイしないようにするとか、プロジェクトの掛け持ち禁止とか、わかりきったことですね。

ジャグリングを避ける

そもそも返せる見込みのない技術的負債を抱えない、というのが根本的な対処になるかな。よく技術的負債の必要性について議論されるけど、この本によるとすぐに返せる見込みがないならその負債は処理能力に負荷をかけることでずっと足を引っ張り続けるということになると思う。

この文脈ではノイズにならないものは多少汚くても技術的負債とは呼ばない。負債はひとの処理能力に負荷をかける、目に見えて対処しなければならないことを指すものらしい。

ただし、ひとりで開発してる場合はノイズにならなくてもチームで開発してる場合はまた事情が違ってくる。ソースコードは常に「チームメンバー誰でも読める状態」にしておくこと。誰かが読めない部分 = メンテできない部分だからいざそこが問題になると急に負債になってトンネリングや欠乏の罠にハマる。豊かなとき = 負債になっていないうちにリファクタリングなどして負債にならないようにしておくのがひとつの戦略。

simplicity vs easy の議論も参照。

トンネルの中に重要なことを持ち込む

作業に集中してると次何やるんだっけ、来週はどんな機能を実装しなきゃいけないんだっけ、となったり、プロジェクトの進捗がわからなくなってスケジュール遅延を招いたりする。これを防ぐために有効なのがリマインダーとのことで。

最近はなんでもかんでもリマインドできるようになってるので好きなものを使えばいいと思うけど、次のようなものとか。

• Slack の /remind
  • https://get.slack.help/hc/en-us/articles/208423427-Setting-reminders
  • 日常的に使うツールでリマインドされるならそれが一番コスト低いでしょということで
  • 日本語記事もあった
    • http://qiita.com/takesato/items/335061d7945ebd5c23f7
• Streaks
  • https://itunes.apple.com/jp/app/streaks/id963034692
  • 習慣化を促すアプリを使うとか
  • そんなに重要なら習慣化することを検討する

短いスパンで締め切りを設定する

長い締切が 1 度よりも短い締切が複数あるほうが集中ボーナスを得やすいのでダラっとスケジュール組むんじゃなくて締め切りをいくつか設定しましょうという発想。

とはいってもアジャイルで開発してるなら 1 - 4 週間単位でやるべきことを決めていると思うので普段と変わらない ? ウォーターフォールだと 1 - 4 週間ていどでマイルストーンを設定していくとか。これも定石ですね。

外部の混乱要因を取り除く

ショックを和らげるための緩衝装置をもっておきましょうというハナシなので、外部対応班を組織するのがよいかなと思う。 SCRUM ではスクラムマスターがこれにあたる。ちょっと昔に流行ったサーヴァントリーダーシップとかもこういう発想なのかな。

ただ、こういったことは決定権を持つひとがやってはいけないということに注意。純粋に処理能力を意志決定に使うために温存すべきということもあるし、聖杯問答問題を忘れちゃいけない。

処理能力を温存する

自動化できるものは自動化して処理能力を温存する。技術的には CI / CD はもちろん、定型業務はすべて自動化する。次は下品だけどこの路線の発想は一定の効果はあると思う。

もひとつ、選択肢のデフォルトを処理能力を温存するものにしておくこと。残業によるすり減りを防ぐために子供のお迎えを自分がやることをデフォルトにするとか。

逆に処理能力を消耗してしまうようなことをやる前にいくつかチェックポイントを設けることも効果的。たとえばカレンダーに他人に勝手に予定をいれられるシステムを使っているとして、スラックとしてあけている日に予定を入れるひとがいる場合、問答無用でいれられなくして直接交渉するように公言しておくとか。

ちょっと前にオバマ大統領は同じ服しか着ないとか食べるものは自分で決めないとかいうハナシがあったけどあれも処理能力の温存という文脈では同じことだった。

学習時の処理能力への負荷を最小限にする

良い設計やコーディングができると劇的に時間の節約になるので、積極的にそういったことへの知識・スキルは伸ばす必要があるんだけど、ただ学習するというのは非常に負荷が高い。

そこでとれる戦略としてはそもそもトンネル内に入ってくるような知識・スキルしか相手にしないというものがある。つまり、いまの作業に必要な知識・スキルしか学習しないということ。トンネルに入ってこないものをムリに教えても処理能力への負荷が上がるだけなので、きっぱり諦める。これは経験的にも非常によく作用する。手を動かして覚えたことは忘れない。ただ、これだけだと偏りが大きくなってしまうので、そもそもいろいろな作業を経験できるように計画を組むのが前提。

ただし、いくらバランスよく体験していったとしても体系的な知識として定着しない可能性のほうが大きいので、全体的なマップを示したり、糊となる知識・スキルは細切れにして一緒に体感するなど工夫することで負荷を最小限にしてレベルアップがはかれるんじゃないかなと思う。これは教材重要というハナシになるのかなあ。

まとめ

読みにくいけど、考えるポイントを与えてくれるという点では非常によい本だと思う。オススメ。