このエントリーは KLab Advent Calendar 2015 の12/23 の記事です。

VoQn です。KLab で現行は主に内製のUnityライブラリ開発をやってます。

今回は特にソフトウェアな話というより、ピープルウェアの話をします。

問題「やっていく気持ち」

サービスでもツールでも、当然 「必要がある」 から、あるいは 「価値がある」 から開発に着手するわけですけれど、
その意義を信じきれるかどうかは個人の心象に依ります。

または、当初は意義のあるミッションを担っていると思っていたとしても、開発が難航したりある程度の目処がついたタイミングで、

• 「本当にすべきことをしているんだろうか」
• 「他にすべきことがあるような気がする」
• 「完成させたところで、そこまで価値のあるモノを出してない気がする」

と、余計な雑念に囚われて生産性が下がったり、完了が遠のいたりしてしまう事があります。

これは最初にどれだけ意欲が高かろうと出会う問題で、当人の意思の問題であろうと、結果的には成果そのものに影響しますし、

「君たち、最近モチベーションが低いぞ。もっと熱意を持って！」 と叱咤激励して解決するものではありません。

対策の方針「(意識が低かろうと)やっていけるようにする」

この記事は、過去に自身が経験した 「やっていく」 プラクティスを紹介しつつ、自戒として、「来年も一年頑張るぞい…」と奮起するような内容です。

[見積もり編] 1.「必要になる工数」より「成果を確認する期日」

無論、無理な締め切りを設けても良くないのですが、全ての課題で正確な作業量が見積もれる事は稀で、プロジェクトの進捗を大きく狂わせないように 「ピボットするための期日」 を予め明確に設けた方が結果的にマシな成果に落ち着きます。

最初は「どんなに軽くても1スプリント(2週間=10日)を最短として提示する」のがコツです。10人日という工数でなく、2週間後に成果物をチェックする、という約束がポイントになります

1営業日は1人日ではない

1 「急ぎでなくていいから」と言われて迷ったとき

こう返しましょう。 「リリースできないと困る時はいつまで？」

2 「要求がデカすぎる」としか思えないとき

「欲を挙げたら一ヶ月も二ヶ月もかかるぞ」 としか思えないトピックに対しては 「2週間待ってくれ、プロトタイプをでっちあげてみせるから」 と一旦そこで合意をとって、その約束は守った上で計画の修正を約束してもらうようにします。

[見積もり編] 2. 「優先度」と「難しさ」と「煩わしさ」は別々に

プランニングポーカーなどで、長期計画のタスクの優先度や難易度をチームで重み付けするにあたって、 『だるさ』(億劫度) は必ず事前に予測するようにします。

実際の業務でも 「技術的な難しさ自体は簡単な方だけれど… とにかく、着手するのは億劫だ」 と感じるモノゴトはあります

• 技術的 『妥協点』 を求められること
  • 既存の運用との折衝や合意形成を必要とすること
  • 必要な開発コストに対して、求められる期日に明らかな無理がある 等
  • 要件がそもそも 「夢のような技術」 を求めていること
    • 再度 実現可能な要件に分解する交渉が要る
• 自動化されてない、膨大で退屈な作業を要するもの
  • OSのバージョン毎の挙動確認を要するコト
  • Webブラウザ毎の挙動確認を要するコト
  • ... etc

スプレッドシートなどに課題をまとめる時、こんな風にします

重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。

「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します

恥ずかしながらこういう経験があります。

• 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ
• 「だるさ見積り」しなかった => +20%〜40% も遅延した。
  • 終わった後の生産性の低さも本当にもう酷かった。
  • ごめんなさい。。。。

やろう！『だるさ』見積り！本当に大事だよ！

[見積もり編] 3. OKR を意識したバックログ

具体的には Github の issue サマリを記載していく事柄で実践します

• Objectives : この PullRequest で何ができてほしいのか
  • サマリの見出しに
• KeyResults : この一連のコミットで具体的に何が変わるのか
  • 箇条書きで

Github Issue のフォーマット

また、自分がPullRequestで書く際に意識しているフォーマットは以下の通りです

• [必須] 目的（どういうことにしたいのか）
• [必須] TODO（何をするか、したか）
• [推奨] 留意事項（前方互換性の有無、利用上の注意点、仕様変更）
• [推奨] レビューポイント（どこを重点的にチェックしてほしいか）
• [あれば] 検討事項（討議して決めてしまいたいこと）

[やってく編] 1. ポモドーロテクニック

意識の高い時はこういうシートをコレクト社の 情報カード セクション 5×3 に書いてから退社していました

- [ ] 開発タスクA (8)
  - [ ] モジュールa のテスト追加 (ワークフローHoge と Huga の異常系が不足) (2)
  - [ ] モジュールa のHoge Huga Fooの実装改修 (2)
  - [ ] モジュールb のリファクタリング (2)
  - [ ] モジュールc のインターフェースのDocコメント (2)
- [ ] 頼まれてたPR #XX のコードレビュー (2)
- [ ] 定例の報告書く (1)
- [ ] 休む日の勤怠連絡出す (1)
- [ ] 勉強会資料の草稿書く (2)

丸括弧の中の数字は「そのタスクに今日かけるポモドーロ単位(25分)」を見積りで出します

ポイントは 仕事始めでなく、仕事の終わり に書く癖をつけることで、次の日に出社した時に始めるべき事をちゃんと積み残せる分、ダラダラ深夜まで会社に残るのを防げました

(逆に言えば、こういう習慣を辞めた途端にgdgdになって勤怠が大いに狂ったままになった)

[やってく編] 2. こまめに成果をデモとして見せていく

その時に着手しているコトに対して、一番モチベーションを高く保ちつつも、開発そのものを楽しめるのに一番効果があるやり方でした。

• 全ての機能が未完了でも、一つでも何か出来たら周りに見せる！
• 実はバグだらけでも見せる！
• 普段全然カラミがない人にまで見せて回る！
• そこでクリティカルなフィードバックを得たり、予想してなかった要件を掘り当てられたりする

プロトタイプやデモアプリケーションや、あるいはスクリーンショットでもいいので、 「今しがた、こんなのが出来た！」 と見せびらかすのは大きな意味がありました。

[やってく編] 3. 未来の自分へありったけ報告

躍起になって開発している最中は自身が抱えてる技術的課題も、それに関する知識も新鮮に記憶していますが、喉元すぎれば熱さ忘れるもので。
開発に関して調べた記事のURLや、読んだ本、キーワードは出来るだけ書き残して、次に同種の悩みにブチ当たった同僚にさっと助け舟が出せるようにしておきます

Git のコミットログに悩み事も綴る

明確に振り返ることが出来ていたプロジェクトでは以下のようなコミットログを意識していました

#${issue_id} ${コミットサマリ}
-- ${何を削ったか}
++ ${何を追加したか、変えたか}
* ${レビューなどでツッコミ入れて欲しいこととか、判断に迷ってる事柄}
-> ${↑ に対して、自分なりに「〜とかでいいのでは」と思っている解決方法}

コードレビュワーに「この件を念頭においてレビューしてほしいんだ」と伝えるための備忘録として使います。

あと、こういう風にコミットログを書けるような程度にコミット粒度を細かくするというのも意識していけます。特に Unity プロジェクトはうっかりすると土石流のようなdiffを産んでしまいがちなので。

定期報告は「手短な項目と冗長な説明」

報告の仕方にもよりますが、定例のミーティングの報告が書面で共有されるのなら、報告は細やかにした方が振り返り時に価値のある資料になります

# とあるタスクについての進捗報告
## Done: 完了させたコト
- (ざっとした報告の概要)
  - (グッダグダした言い訳)
## Doing: 未完了&着手中
- (甘い現状認識)
  - (ダラッダラした言い訳)
## ToDo: 積みタスク
- (雑な課題意識)
  − (意識の低さの言い訳)

グダグダした報告を慎んで、寡黙に「結果を優先してさっさと出そう」としたところ、そっちの方が却って進捗が遅れました。

プロジェクトオーナーからしたら、計画のズレに対し「なぜ？」「どうして？」 が材料として多く持てなければ、 「えっと… 急いで？」と圧(あつ)をかけていく しかなくなるわけで。

「沈黙は金、雄弁は銀」とは言いますが、チームワークにおいて黙ったまま進捗遅れてたら世話ないですし、何より技術的問題を共有しなければ協力し合えないので、手持ちの情報は洗いざらい出しきるつもりでいった方がいいです。

[振り返り編] 1 見積りと実績の差分を計算する

ポモドーロ・テクニックで作業量を記録してあると楽ですし、実態も正確に測れます。
これは、タスクが終わった直後にする方がいいです。

次回に同種の開発項目にあたる際の見積りの精度をより高められれば、未来の自分が苦労しなくて済みます。

数週間すぎてからだと、数字も曖昧になりますし、総括も対策も的確なものでなくなってしまいます。

[振り返り編] 2「学びがあった」ことは広く共有する

成果物以外に 「この開発を経て、何を得たか」 を人に語るのはモチベーションを維持するのにも、自身の成長にも効果があります。

リリースノート以外に、社内のメーリングリストに 「こういうものを作ったよ！こういう風に使えるよ」 と宣伝もかけて流したりしましたが、
それらの技術的なノウハウは（しなかったトピックよりも）忘れずにいられています。

振り返り時に報告するのもいいし、勉強会で発表したり、ブログに書くとかでもいいでしょう。
この記事自体も、そういうことをこまめにやらずに、ひどい下半期を過ごしたことへの反省の意味も込めて書いています。

[各自やっていく編] これらのプラクティスを強要しない

これらは実際にやってみて、確実に効果を実感するものばかりでしたが、その意義を共感させる間もなくチームメイトに啓蒙するのは悪手であるとも感じています。

なぜそうした習慣をはじめるに至ったのか？ を省みることもなく、闇雲に強制してしまっては、それが果たしたい目的から逸脱し、ただ漫然と日々の作業を面倒な儀礼として潰してしまうだけです。

これらの習慣は、あくまで 「自分は〜において失態やらかして、そこで導入してみたら効いた」 こととして紹介するに留めています。

むしろ、もっとより簡素で手軽な方法を各自で編み出していいわけですし、そうした小さな事柄でもノウハウとして交換しあえる環境と文化が耕されることが大事かなと思います。

まとめ

各自やっていきましょう

p.s. パズルワンダーランド を応援よろしくおねがいします！

本題には関係ないのですが、最近リリースされた パズルワンダーランド をどうか何卒よろしく応援お願いします！！！