FOLIOで学んだマネジメントやリーン開発の知識を本の執筆に活かす

これは、FOLIO Advent Calendar 2018 5日目の記事です。

FOLIOでは2年目のアドベントカレンダー!クリエイターも増えて、去年とはまた違うメンバーで埋まっていて毎日楽しみです。

突然ですが、今月生まれて初めての著書が出ます(@syobochimと共著)。

book.impress.co.jp

出版社の方とコンタクトを取り始めたのは1月だったので、おおよそ1年近いプロジェクトを終えたことになります。実際に書いていた期間はもっと短い(後述)ですが、いわゆるスタートアップであり日々全力疾走するFOLIOで社員をやりながら、業務時間中には一切執筆作業をすることなく*1なんとかやり遂げることができました。

ここまで来られたのは、JavaコミュニティそしてFOLIO、この2つのおかげだと思っています。この記事では後者にフォーカスし、書く際のプロセスや心構えについて考えていきます。一方、前者に関することも、また発売後に別の記事にしたいと考えています。そちらは、多少本の内容にも触れたものにする予定です。

😌モチベーションとの戦いを制する「気合い」以外の方法

今回の執筆は、書く内容自体の難易度が自分のレベルよりも高いわけではなかったし、文章を書くことにはあまり抵抗がないし、自分を突き動かすことこそがポイントでした。そして、年齢を重ねるごとに改善はしているものの、自分は何よりそれが苦手なのです。そこで、終えるために行った工夫やFOLIO社員に教わったことを3つ紹介します。

👆遠い目標と近い目標を立てる

  • 長期的なモチベーションを保つための遠い目標、すなわち、達成したらどんないいことがあるか
  • 短期的なモチベーションを保つための近い目標、すなわち、何をやっていくべきか

を念頭におくようにしました。遠い目標ははじめに妄想しながら設定して、やる気を失ったときに度々思い出す用途で使っていました。

  • Gitについて誰よりも分かりやすく説明してつまづく初心者を助ける
  • 印税をもらうという体験をする
  • 国会図書館に自分の本が並ぶ
  • 表紙の似顔絵*2ネタ思い出にする

などです(赤裸々)。それに対し、近い目標は、担当章が決まった時点で、

  • Gitとは何かを書く
  • forkについて説明する
  • LGTMについて紹介する

といった粒度ですべての章に対し細かい単位で設けました。
遠い目標があることでやる気を維持し、近い目標があることで、次やることが明確になり手を止めることなく進み続けられるというわけです。何気なくこういう取り組みをしている人は多いような気もしますが、心理学で「長短比較」という名のついた手法だそうですね(『やってのける~意志力を使わずに自分を動かす~』で知りました)。

👆作業のWIP制限を設ける

効果としてはこれが1番大きいと実感しています。

WIPとは、Work In Progressの略で、完了していない仕掛りの作業を指します。特にリーン開発の文脈において、チームが同時にWIPを抱えすぎるのはアンチパターンとして語られることが多いです。今回の執筆はチームというより個人作業*3でしたが、考え方は十分活かすことができました。

これを心がけられたのは、間違いなく@Mura_Mi (同僚) たちが中心となって会社でいろいろ教えてくれてきたためです。WIP制限については、今年の3月頃、フロー効率とリソース効率*4の勉強会が開かれたことで気にするようになりました。FOLIOには #study プレフィックスがつくチャンネルが色々あり、日々知見を共有したり議論をしたりしているのですが、その勉強会は #study-lean-agile に集まった有志に向けてのものでした。

では、どんな執筆の進め方をしたか明かします。全部で5章担当したのですが、基本的には章ごとに作業を進めていきました。その上で、WIP制限を原則1 (レビュー進行中のみ2) として、これだけは絶対に守ると決めました。その結果、各章のPRを振り返ると、着手期間はそれぞれ次のようになっていました。

f:id:ihcomega:20181204023010p:plain
各章の着手期間

(あくまでこれは1回目に出した本文の原稿がLGTMとなるまでのようすで、この後スクショの差し込みや細かい手直しをしたり、さらに全章何周ずつか見直したり、後続の作業は山程ありました。)

複数の章に同時に手をつけている期間はほとんどなく、大体着手した順に完了まで運べていることが分かります。これがどう良かったかを伝えることで、なぜWIPがよくないかを考えてみることにします。

コンテキストスイッチを防げる

作業の切り替え時には、頭の切り替えを伴います。さらに、前やっていた作業に戻る場合は「何をどこまでやっていたか」を思い出す必要もあり、非常に時間やパワーを使います。言うまでもなく、同時に複数の作業をやると切り替えも多発してオーバーヘッドがどんどん大きくなるというわけです。WIP制限をしておけば、ある期間に考えるべきことを減らすことができます。

終わったことは忘れられる

先ほど思い出すのにかかる時間を減らせると紹介しましたが、そもそも思い出さなくてよくなるのも嬉しい点です。着手したものから順に完了させるようにしたら、一度完了まで到達したあとはしばらくその作業について考えずに済みます。今日の日付や昨日食べたものすら覚えていられないのに、複雑な作業内容をいくつも覚えているなんて難しいことです。

早めにフィードバックを受けられる

着手した順に作業が完了するということは、完了したものからレビューに回せるということを意味します。WIPが多く、どの章も終盤に完了を迎えるということになると、レビューの開始、そしてフィードバックをもらうのが遅れます。早めに気付いていたらそれ以降書く際に気をつけられたことも、終盤まとめて修正するとなると大変です。遅れることで時間的成約により妥協せざるをえなくなる可能性もあるので、クオリティが下がる原因にもなります。

やる気を保ちやすい

多くの章に手をつけると、たくさんの章の進捗があって一見良い気もしますが、「ひとつも(あるいは、ほとんど)完了していない」という状態が比較的長く続きます。これでは、TODOリストやissueに表れるようなタスクが消化できず、何も進んでいない気がして疲弊します*5。一方、WIP制限があると、少しずつ「終わった!」という体験を積み重ねられるので、小さな達成感を感じることができてちょっぴり安心します。

終わる時期の見当がつけやすい

WIPが多いと(つまみ食いのように好きなところから着手するような形をとるとさらに)、全体の何%終わっているのか図るのが意外と難しいです。制限しておけば、WIPとなっている章の進捗さえ分かったら、残りの章は終わったか終わってないかのどちらかなので、全体に対するボリュームをそのまま進捗に換算しやすいです。

レビュアーのWIPを減らせる

レビューがある場合、上記のような恩恵をレビュアーにもおすそ分けできると考えています。終盤にレビュー爆弾を送りつけることなく終えられるわけです。執筆もレビューも人がやる作業であることには変わりなく、WIPが多いと頭の切り替えが辛いし、心理的な負荷が高まります。

😞スケジュールとの戦いに敗れた「本業が多忙」以外の敗因

👆プロジェクトバッファを使ったマネジメントをしたかった

色々うまくいったことを並べましたが、失敗したり迷惑をかけたりしたことも多々ありました。1番大きいのがスケジュール管理で、脱稿予定日を出すための見積もりが何度も派手に外れた上に、ケアも疎かでした。もちろん本業の状況も刻一刻と変化するため、作業できる時間が安定しないというのは仕方ないことではあります。そうした状況だからこそ、もっと見積もりおよび予実管理に頭を使うべきでした。

これも同じく#study-lean-agileや実際のプロジェクトでの学びですが、各タスクの作業時間見積もりのうち、バッファにあたるものをすべて合算しプロジェクトの終わりに置く方法があります。

f:id:ihcomega:20181205035955p:plain
バッファのとりかた-1

f:id:ihcomega:20181205040058p:plain
バッファのとりかた-2

上の図でいうと、 バッファのとりかた-1 ではなく バッファのとりかた-2 のようなスケジューリングをするということです。作業中は予定をはみ出てバッファを食いつぶしたらそれを把握しておき、各タスクの進捗とバッファの消化状況から順調なのか、危険で対策を打つべきなのか判断するといった管理をします。今回でいうと、バッファの消化状況が不穏であれば出版社にアラートをあげるといった対応をすることで、締切近くなって「すみません、出来ませんでした」とゴメンナサイするよりはマシな状況に持っていくことが可能です。
また、実はモチベーションとの戦いにも有効です。タスクごとにバッファを設けると、結局バッファ込みの時間で終えようという心理が働いてしまいがちですが、それを取り除くことでタスクの締切を守ろうという動きを取りやすくなります。

かなり前に立てたスケジュールのスクショを引っ張り出してきました。このときは全体のバッファを設け、やる気だけはあったことが伺えます。

f:id:ihcomega:20181205040756p:plain
脱稿予定が8月だった頃のスケジュール

しかし、当時

  • バッファを設けたところで、何をウォッチしどうマネージすべきなのかを理解していなかった
  • 余裕がなかった
  • 妥協してしまった

などから途中で諦め*6、失敗に終わっています。『エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング』いわく、納期の重要な案件とも相性がよいようなので、(融通はきくものの)締切という概念の存在する執筆において取り組む価値はあったなぁと今になって残念に思います。

😍多岐にわたる同僚のヘルプ

ここからは、感謝の意を表すちょっとしたおまけエピソードです。

先輩執筆者たちのアドバイス

幸いFOLIOでは身近に執筆経験者がたくさんいたので、迷ったときに話を聞いて救われていました。

GitHubポケットリファレンス (POCKET REFERENCE)

GitHubポケットリファレンス (POCKET REFERENCE)

特に、@yasuharu519は、直前にGitHubの本 (競合…!) を出していたため記憶が新しかったということもあり、どんな進め方したか教えてもらったり、「完璧を求めたくなるけどできる限りやればそれで十分ですよ」「印税出たら寿司でいいですよ」などと言われたりしたおかげで勇気が出ました。

ストレスフリーな作業環境の提供

環境というと、執筆はマークダウンで行って、GitとGitHubを使って・・・みたいな話もしたいですが、ここでは作業マシンの話。今回、Windowsスクリーンショットを撮ることになったのですが、持っていなかったので同僚に借りました。

社内Slackにて
「どなたかWindows端末貸していただけませんか」
「使ってないThinkpadありますよ」

って@d_akatsukaに渡されたのがメモリ24GBも積んだハイスペックマシンでした。壊したらどうしようと怯える日々でしたが、それはもうスムーズに、滞りなくスクリーンショットが撮れたのでした。


偶然にも著書の販売がタイムリーだったのでFOLIOの業務と直接関係のない内容となりましたが、ちょっぴりFOLIOの取り組みやメンバーを紹介するお話でした!

執筆は、8月に終えるつもりだったのが9月までかかっている時点でお察しですが、決してスムーズに進んだとは言えません。しかし、終わらせるための道具は気合いのみ、という心許ない状態で作業するのではなく、良しとされている方法で自分をコントロールするために工夫ができたのはポジティブに評価したいです。おそらくこの1年間くらいでのFOLIOにおける学びや考え方の変化がなければこうはなっていなかったでしょうし、事態はより悪化していたことが予想できます。

#study-lean-agileチャンネルはほんの一例ですが、FOLIOには情報を持ち寄る場があること、そしてそれが活発であることがとても嬉しいです。しかも、学んだ内容はすぐに業務で活かす取り組みが日々見られるし、今回書いたように、個人でも試したくなる、あるいはより深く調べたくなるようなものが多いのがさらに嬉しいです。今どき社内勉強会なんて珍しくないものの、FOLIOのそれはとても質が高いと思っているし、実践的なのです(ありがたい)。たまにメンバーが社内勉強会のスライドを公開したりブログを書いたりしていますが、面白いものが多いのでとってもオススメです😋

さ〜て明日は!隣の席のDDDお兄さんこと@yoskhdiaによる、「Scalaを例に『仕様』パターンを実装する」です!

本記事は著書の宣伝行為ではありません。


参考文献

*1:仕事にも執筆にも集中できず何もかも効率が悪くなることをおそれ、仕事中は急ぎの連絡を返す程度にとどめ、なるべく本の進捗を出すことは考えないようにしていました。

*2:冒頭の商品ページ参照。著者の異常にリアルな似顔絵が掲載してあります。

*3:共著とは言え、ほぼ100%分業していました

*4:フロー効率とリソース効率についてはリクルートさんのフロー効率性とリソース効率性について #xpjugの資料が分かりやすいです。

*5:もちろん、章より小さい単位でタスクを作成すれば消化できますが、章で切るのはちょうどいい粒度だと感じていました。タスクが細かくなりすぎると、今度はメンテが大変になる可能性があります。

*6:最近の業務ではやっています!

*7:WIPについての章をパラパラとめくってみたら、まさに「この本の執筆時、色々な章に手を付けてしまい失敗した」というコラムがありました。まるかぶりだ!