この国では犬が

本と芝居とソフトウェア

「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えた

スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えてみました。

ものすごく長いので(なんせ 38 個あるので)、以下の目次から興味のある質問への回答だけでも見ていただけると嬉しいです。

なお、最初はかなり丁寧に回答していましたが 5 つ目の質問のあたりでこれ終わらないなということに気づいたため、以降はやや簡潔な回答になっています。

スクラムマスターの役割について

アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか?

スクラムはプロセスの集まりではないし、スクラムマスターの仕事はプロセスを守らせることではない。

スクラムは、透明性・検査・適応を軸として、継続的な対話を促すフレームワークであるといえる。
たしかにスクラムマスターがプロセスを守るようチームに働きかけることはあるが、それはあくまで、チームとしての成長を促すフレームワークを活用して、建設的な対話と学習を促進することに主眼がある。プロセスを守ることが目的なのでは決してないし、プロセスを守ればうまくいくわけでもない。

自分の組織でアジャイルがうまくいっていることを示す兆候は何か?また自分の働きが成功している兆候は何か?

以下のような兆候があれば、アジャイルがうまくいっている可能性が高い。

  • 以前に比べて、「一気にまとめて」ではなく、日々、段階的に不確実性・リスクを下げられるようになってきている。(例: リリースのスコープの確度が週ごとに上がっていく)
  • 以前に比べて、重要な課題が広く認識され、建設的な対話によってそれを解決する努力が行われるようになってきている。(例: 欠陥が多発していたことの原因がレガシーシステムアーキテクチャにあることをチーム全体が認識し、段階的な設計改善やテストによるアプローチを模索している)
  • 以前に比べて、チーム全体が、作業ではなく、成果にフォーカスするようになってきている。(例: 「いつまでに実装が完了するか?」「ちゃんとテストを書いたか?」という会話よりも、「この機能を誰が使うのか?」「一番重要なことに取り組めているか?」という会話の量が増えてきている)

また、自分の働きの効果を測るためには、以下のような兆候を見る。

  • 前述の「アジャイルがうまくいっている」兆候が見られるか。
  • 以前に比べて、自分が指示・指導を行わなくても、自律的に活動して対話を重ね、経験から学んで継続的にプロセスを改善できるようになってきているか。

追跡しないといけないメトリクスはあるか?もしそうだとしたら何の目的でどのメトリクスを追跡するか?

チームや組織の状態によって重点メトリクスは変わるが、一般的には以下のようなメトリクスに注目する。

  • デリバリープロセス全体の健全性
    • 要求からデリバリーまでのリードタイム
    • 各プロセスのサイクルタイム
  • 局所的な生産性
    • ベロシティ
    • 各種会議・イベントにかかる時間
    • テスト実行にかかる時間
  • (内部・外部)品質
    • テストカバレッジ(使い方に注意)
    • コード品質(静的解析ツール等を用いる)
    • QA でのバグ検出率
  • チームの健全性
    • 残業時間
    • 発言の頻度・内容(定性的でもよい)

チーム全体としては単一の最重要指標(たとえば、顧客満足度)にフォーカスしながら、そこへ向かうためのプロセスの健全性をいくつかのメトリクスで監視できるとよい。

メトリクスの数値そのものに固執せず、何を知りたいからそのメトリクスを計測しているのかをチームが忘れないようにする。
ボトルネックが移り変わった場合、取得するメトリクスは変更する必要があるかもしれない。

あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか?そして問題をどのように指摘するか?

以下のような理由が考えられる。

  • タスクの粒度が大きく、スプリント計画の正確性が低すぎる。
  • レガシーコードが原因で、計画時に想定していなかったタスク(既存のバグやアーキテクチャの問題による追加作業)が発生している。
  • 計画時に想定しているほどの稼働時間が取れていない。(例: 1 日 8 時間で計算しているが、会議や休憩時間を除くと実際に稼働できているのは 6 時間程度)
  • そもそも、好ましくない対象にコミットメントしている。(例: スプリントゴールや PBI のデリバリーではなく、全タスクの消化をコミットメントしている等)
  • スプリント中に発生する課題をタイムリーに認識できていない。
  • スプリント中に発生する課題にその都度適応できていない。

以下のような話の切り出し方が考えられる。

  • (具体的な事実や数値を示して)このようにコミットメントを守れていないようですが、それは問題ですか?
  • そもそも、チームは何をコミットメントしていますか? 何なら確実にコミットメントできそうですか?
  • そもそも、なぜコミットメントが重要なのでしょうか?

回答に応じて対話を重ね、開発チームが行きたい方向とスクラムチームとして向かうべき方向とを合わせていく。

製品のディスカバリープロセスにスクラムチームは参加してよいか?その場合はどのようにするか?

もちろんよい。
スクラムチーム全体がそれぞれの視点から製品のディスカバリーに貢献することができるし、ディスカバリーに参加していれば、製品への深い理解を持って、創造的かつ効率的に開発することも期待できる。

ただし、開発とディスカバリーとのバランスのとり方がやや難しく、以下のような課題が出てきやすい。

以下のような指針を試しては、結果を観察して改善しながら、自分たちのチームに合ったやり方を探していく必要がある。

設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか?

プロダクトオーナーにすべてを任せず、開発チームもプロダクトバックログ周りの作業に関わってよい。チーム全体で補い合って、プロダクトのことに取り組む。スクラムマスター自身がプロダクトオーナーとペア作業することがあってもよいかもしれない。

どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか?

ステークホルダーにはプロジェクトの早期から、頻繁に連絡を取り、ステークホルダーの関与の重要性を説いて理解してもらう。ステークホルダーは忙しいので、ステークホルダー自身にとっても、有効な時間の使い方ができるよう、コミュニケーションのとり方に配慮する。

どのように複数の異なる部門にまたがってアジャイルマインドセットを広げるか?ITじゃないステークホルダーをコーチするのにどんな戦略をとるか?

異なる部門にとってのメリットを前面に出しながら、興味を持った一部の人たちと一緒に小さく始めて、理解を育てていく。IT じゃないステークホルダーについても基本は同様で、ステークホルダー自身の関心事にフォーカスする。

上級管理職にどのようにスクラムを紹介するか

その上級管理職が重視しているビジネス上の課題を理解し、その課題に取り組むためにスクラムがどう役に立つかを説明する。「透明性・検査・適応」「課題を明らかにする」ことがスクラムの本質ではあるが、それだけでは響かない可能性もあるので、一味つけることも考える。たとえば、ユーザ企業の変化に追従する能力を育てる、開発力の持続的な成長に貢献する、等。(ただし、過度の期待やスクラムへの誤解を植え付ける結果にならないように十分配慮し、一度紹介して終わりではなくその後もフォローアップを続ける)

あなたはすでにステークホルダースクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか?またどんな経験があるか?

まずは 3 ヶ月だけ続けさせてくれないか、同僚にお願いする。もちろん、その同僚がどのような課題があると思っているのかもよく聞き、それにチームとして正面から向き合っていきたいことも説明する。ステークホルダースクラムを理解しているとしても、ステークホルダースクラムの適用を命令させるようなことはできるだけ避けたい。

「激しい抵抗」の経験はないが、「本当に Sprint 単位で製品を完成させるようなやり方が成り立つのか?」という懐疑的な態度には出会ったことがある。当時は組織内で初めてのスクラムへの取り組みで、私はスクラムマスターではなく開発者だった。同じチームのメンバーとして課題意識を共有し、日々の活動を通じてさまざまな取り組みを試してはふりかえって改善を重ね、約 3 カ月後には安定した速いペースでインクリメントを届けられるようになった。

プロダクトバックログのグルーミングと見積りについて

プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか?

その流れ自体は悪くないが、チームからのインプットは「見積り」だけであるべきではない。チームによる技術的なシーズ・制約事項や、その他のアイデアもプロダクトバックログに取り込んで、チーム全体として最良のプロダクトバックログを作り上げたい。ステークホルダーの言っていることが「正しくない」ことも少なくない。プロダクトオーナーはステークホルダーの御用聞きにならず、視野を広く持って、チームも積極的にプロダクトバックログづくりに協力していくのが望ましい。

チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか?

Scrum には、製品について話し、考えるための Sprint Review という時間があるので、そのタイミングで、前回の Sprint Review 以降にわかった短期から中長期までの製品に関わる新しい情報は、何でも話してもらう。プロダクトオーナー自身が何を話すべきかうまく判断できないようなら、チームが何を求めるかを重視する。それでもうまくいかなければ、まずはプロダクトバックログの内容(全体像・優先順位)に直接関わることから話し始めてもらい、慣れてきたら少しずつ会社の全体戦略やマーケットの状況へと視野を広げていく。

誰がユーザーストーリーを書くとよいか?

プロダクトオーナーが第一候補になるが、誰が書いてもよい。また、ユーザストーリーは書くものではなく語るものである。ユーザーストーリーを「ちゃんと書いて」、「要求仕様」と見なすようなことがないように気をつけたい。誰が書いたにせよ、ユーザーストーリーは語られる。ユーザーストーリーについてチーム全体が会話をし、会話から現れてくる価値を届けるための機能を、開発チームが実装する。

よいユーザーストーリーとはどんなものか?どんな構造か?

一般論として、誰が・(どのような場面で・)何のために・何をしたいのかが書かれていてほしい。
また、ユーザーストーリーは階層化したほうがよい。あるストーリー、を実現するためのストーリー群、を実現するためのストーリー群というふうに階層化する。上位階層のものほど、「何のために」にフォーカスし、下位階層のものほど「何を」にフォーカスする。
一方で、「どうやって」は限定しないようにする。「何を」と「どうやって」の間に境界を引き、「どうやって」のエリアで創造性を発揮できるようにすることが、開発チームが活き活きと働くための重要な条件と言える。
また、ストーリーではなく PBI としては、明確な受け入れ条件が指定されているとよい。それが透明性の担保に寄与する。また、受け入れ条件はできるだけ交渉可能になっていると望ましい。そういったよいユーザーストーリーの条件をまとめた INVEST という用語もあり、有用。

「Readyの定義」には何が含まれているべきか?

INVEST のうち、E、S、T が整っていること。すなわち、「見積り」「適切なサイズ」「完成したことを確認する方法(受け入れ条件)」がすべて満たされていてほしい。
もちろん、Ready 以前に V、つまり価値も定義されていることは前提である。(なお I、N は必須ではないと考えます)

なお、そもそも「見積り」そのものは必須ではなく、デリバリーペースの予測に役立つ何らかの手段があって、アイテムがその要件を満たす状態になっていればよい。(#NoEstimates の人たちが言うように、見積りそのものに価値はない)

ユーザーストーリーを時間で見積もらないのはなぜか?

デリバリーにかかる時間は人によって異なり、チームとしての見積りにするのが難しい。サイズ(作業量)の見積りであれば、認識を合わせやすい。
また、デリバリーにかかる時間はチームの状態によっても変わりやすい。チームが新たに学んだことや、開発を担当するメンバーによって、一度見積もった時間は変化する可能性が高い。
サイズで見積もっておけば、それらの変動要因を吸収しやすい。

加えて、時間の議論は「俺なら 1 時間」「私なら 30 分」といった不毛な会話になりやすい。相対サイズの議論なら、どのような作業が見込まれるかにフォーカスして、ユーザーストーリーに潜む穴を素早く見つけることができる。

プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか?スクラムチームは200個のチケットに取り組めるか?

もちろん、並行して 200 個のチケットに同時に取り組むことはできない。(できたとしても、する意味がない)

多くのアイテムがある場合(つまり、ほとんどの場合)、ユーザーストーリーマッピングのような手法を用いてバックログを階層化して、構造が見えるようにする。
また、プロダクトオーナーは取り組みの優先順位を明確に定めて、時間軸上で近くにあるアイテムほど、チームで精緻に議論するようにする。

スプリントプランニングについて

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

前提として、プランニングまでに優先順位付けされた Ready な PBI が揃うように取り計らう。
チームには、解決手段だけではなく PBI がもたらす価値にフォーカスするよう促し、複雑な実現手段に固執しすぎているようであれば、プロダクトオーナーとの対話を試してみるよう働きかける。
プロダクトオーナーには、スプリントプランニングに同席することの価値を理解してもらい、少なくとも常に連絡可能な状態を保ってもらうよう働きかける。
また、全体を観察し、状況を書き出すなどして見えるようにする。流れの悪いところがはっきりしたら、チーム自身が気づいて解決できることが理想だが、必要に応じて介入してもよい。チームの自律を奪わないよう気をつけながら、情報がチーム内・プロダクトオーナーとの間でスムーズに流れるように取り計う。

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

実装前は、製品ビジョンのどの部分にどの程度寄与する見込みなのかや、期待される収入増加やコスト削減などを、複合的にメトリクスとして用いる。狩野モデルなども有効。価値だけでなく、ROI も重要。プロトタイプを用いてユーザビリティテストを行い、ストーリーの価値を実装前に検証することもできる。

ステークホルダーがそう言ったから」とか、「(たかだか一人の)ユーザがそう言っているから」といった表面的な理由は受け入れがたい。ストーリーは実装する前によく磨かないと、すぐに機能過多の鈍重な製品になってしまう。

なお理想の世界では、ユーザーストーリーは直ちにデリバリーされ、アプリケーションやプラットフォームから直接取得できるメトリクス(滞在時間、コンバージョンレート、アクションの成功率、そのストーリーに紐づく機能の販売数等)に基づいて価値を確認できる。ただし実際は、複数のストーリーが同時にデリバリーされたり、直ちに取得できるメトリクスがなかったりする。その場合、大域的であったり定性的であったりするメトリクス(顧客満足度ユーザビリティテストの結果など)を頼りにすることになる。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

前提として、PO が価値に基づいて優先順位をつけているはずだが、何らかの理由で調整が必要になった場合の話として理解します。
基本スタンスは問いかけ。PO にも、チームにも、「どうしたいですか? それはなぜ?」と問いかける。見解が一致すれば、めでたし。多くの場合、価値・PO がやりたいこととコスト・チームができることとのトレードオフになりやすい。その場合、対立構造にならないよう、事態をお互いの目で見るように促す。ちょっとした思い込み(「このように実装する必要がある」とか)を取り除くだけで、PO とチームの双方が納得できる最善の道が開けることもある。

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

目安としては、2 割程度。ただし、そもそもそれらのタスクをどの程度明示的に扱うかはチームによる。リファクタリングや新しい技術の調査は、通常の PBI への取り組みの範疇でできていれば、それでもいい。できていない場合に、最大 2 割程度まで、別途時間を確保したり、PBI として定義して、リファクタリングやバグ修正、技術調査等に取り組むようにする。それらの取り組みが 2 割よりも多くなると、ステークホルダーの期待に十分応えられなくなってくる可能性が高い。

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

チームに自己裁量権を認めることで最大の成果を届けられることを説明し、理解してもらう。また、個人にストーリーやタスクを割り当てようとする理由を聞き出して理解し、その理由となる課題を解決するようなアプローチを一緒に考える。

チームメンバーによるタスクのつまみ食いをどのように扱うか?

チーム全体にリードタイム・サイクルタイムの概念を説明し、理解してもらう。また、タスクのつまみ食いは表面的な事象で、別の課題が隠れている可能性もある。たとえば、T 型のスキルセットになっておらず、実施できるタスクが限られているなど。そういった場合、ペア作業の導入が有効かもしれない。いずれにせよ、個別事象(タスクのつまみ食い)にこだわりすぎず、マインドセット、チームとしての目標、スキルやプラクティスといった様々な面からアプローチする。

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

スプリントの透明性の確保のために、そのようなアイテムはスプリントバックログに入れないのが望ましい。そのため、プロダクトオーナーにはそのアイテムを今スプリントに入れる必然性があるのかどうか、確認する。また、入れる場合のリスクも説明して理解してもらう。それでも入れるという判断をする場合、これは特殊なオペレーションなので、チーム全体としてそうすることの影響を理解し、試してみることへコミットした状態にする(注意: そうすることへの「完全な同意」や、そのアイテムを確実に届けることへのコミットではない)。そうしておけば、その結果への検査と適応がレトロスペクティブのときにやりやすくなる。

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

いくつかの戦略が考えられる。

  • なぜ時間の無駄だと思うのかよく聞いて、対話する
  • スプリントプランニングがチームにとってどのように役立つと見込まれるのか、よく説明する
  • チーム全体でそもそもプランニングをやるべきか、どうやるべきか話す場を設ける
  • ひとまず協力してくれないか、お願いする
  • プランニングをやる・やらない(最小限にする)の両方を試してみることを提案する

おおむね上から順に試してみる。 チームの状態や相手の反応によって、対応を切り替えていく。

スタンドアップやデイリースクラムについて

チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか?

(「スタンドアップ」というのが日次の定期ミーティング、Daily Scrum のことだと想定して回答)
まずはやってみて、しばらくは続けてみることを薦める。
どんなチームにとってもリズムを作ることは重要で、スタンドアップによって日次のリズムを作ることができる。また、頻繁な検査・適応の機会があることで、さまざまな課題を見つけ、対処していける。

人数が多い場合、「3 つの質問」のようなフォーマットにはこだわらず、短時間で最大限の効果が得られるようなやり方を見つけ出していく必要はある。スタンドアップが難しいほどチームの人数が多い場合、そもそもチームの分割を行ったほうがよいかもしれない。

もちろん、達人揃いのチームで、既にスタンドアップよりもよい検査・適応の方法を編み出している場合は、無理強いはしない。(もっともその場合、そのチームは Scrum フレームワークにもこだわっておらず、ScrumMaster の役割も典型的なものとはだいぶ異なっていると想像される)

なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか?

特にスタンドアップを待つことを期待はしない。スタンドアップはコミュニケーションを限定するものではなく、促進するものであり、スタンドアップがあることを理由に日常のコミュニケーション(を通じた透明性・検査・適応の実践)が妨げられてはいけない。(スタンドアップに使われるのではなく、スタンドアップを使う)
いま助けが必要なら、いま求めるべき。

もちろん、緊急性のない事項に関しては、即時ではなくスタンドアップや他の機会に共有してもかまわない。
そのあたりはチームのバランス感覚になるが、一般的に(必要以上に)スタンドアップを待ちがちになりやすいと思うので、そうなってしまっていないか、ScrumMaster が気を配っておくとよい。

スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか?

その人は、なぜ報告セッションにしたいのだろう? もしかしたら、それがミーティングのやり方だと思いこんでしまっているだけかもしれない。だとしたら、スタンドアップの目的を繰り返し説き、場合によってはリードを代わってもらって実践してみせる。チームメンバーにとってほしいアクションを伝えるような話し方を意識してもらったり、逆にあえて雑談をしてもいい。いわゆる進捗会議とは違うということが伝わるようにする。
それでも納得しなかったり、何か別の理由がある場合、その理由にチーム全体として向き合う。なんのためにスタンドアップをやるのかを考え、チームとしての答えを出す。

スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか?

スタンドアップは短時間なので、それほど無駄だとは思われにくいはず。にもかかわらず無駄だと思われるなら、スタンドアップ自体に問題がある可能性が高い。スタンドアップが機能不全に陥っていないか。まずはそちらの可能性からアプローチする。と同時に、その人がスタンドアップを無駄だと思う理由にも注目して、対話する。その人個人にとってスタンドアップがどのように役立つ(役立ちうる)か、チームにとってはどうか、それぞれにフォーカスしながら話してみる。
なお、朝にスタンドアップをしている場合、遅刻については単純に朝が苦手な人の可能性もあるので、場合によっては時間の変更も検討する。「時間どおりに来るのが当然」と決めつけず、現実を見てチームにとって最善のやり方を模索する。

スクラムチームのスタンドアップステークホルダーは誰も参加していない。この状況をどのように変えるか?

そもそも、変える必要があるとは限らない。ステークホルダーとのコミュニケーションは難しい問題だが、ステークホルダーの多忙度合いによっては、週次の Sprint Review で精一杯ということもありうる。無理をして毎日スタンドアップに参加してもらうことがよいとは限らない。

ステークホルダースタンドアップに参加してもらう合理性があり、かつ現実的に参加できそうということであれば、シンプルにその理由(合理性)を伝え、参加をお願いしてみる。おそらく何らかの理由で難しいということになるので、スタンドアップの時間帯を変える、日次ではなく隔日、等の選択肢も含めてチームとステークホルダーの折り合う場所を探る。

もっとも、そこまでするなら、スタンドアップにこだわらず、ステークホルダー専用の時間を設けるほうがよい可能性もある。原則としてスタンドアップはチームのためのミーティングなので。

分散チーム間のスタンドアップをどのように進めるか?

タイムゾーンが同じであれば、音声ないしビデオでつなげば事足りる。音声や映像でつながった状態を保つことはチームの相互理解にも寄与するので、できればそうしたい。

タイムゾーンが異なる場合、どれくらい異なるかにもよるが、チャットの使用を検討したほうがよい可能性がある。おそらく、チーム専用の Slack チャンネルで各自定形の質問(「3 つの質問」のような)に答えてもらうようなかたちになる。https://geekbot.com/ のようなソリューションも役に立つかもしれない。

チーム自体が 2 拠点に分かれている(例: 東京に 5 人、大阪に 4 人)ような場合、拠点ごとにスタンドアップを行い、要点を Scrum of Scrums のようなかたちで共有し合う、という手もある。各拠点では通常のスタンドアップの感覚でやれる一方、離れた拠点のチーム全員の詳細はわからなくなるなど一長一短あるので、そのやり方が効果的かどうかには特に気を配っておく必要がある。

スクラムチーム用の物理カンバンボードをいま書いてください

たとえば、以下のような構成が考えられる。

案 1
Todo Doing Done
... ... ...
案 2
PBI Tasks Doing Done
... ... ... ...
案 3
Idea Ready Developing Developed Testing Tested Delivered
... ... ... ... ... ... ...

気をつけるポイントは以下。

  • 個人ごとのレーンは設けず、アイテムごとにレーンを設ける
  • Doing の列は狭く(WIP が増えすぎないようにする)
  • 必要があれば、明示的に WIP 制限を設ける
  • ただし、個人的には最初はシンプルなものから始めるほうが好みです。

ふりかえりについて

だれがふりかえりに参加してよいか?チームだけか?プロダクトオーナーも参加してよいか?

第一には、チームのためのものと考える。特に成熟していないチームには、心理的安全を保ちながらふりかえりを行える場が必要なので、はじめはチームの関心にフォーカスした方がよい結果を導きやすいと思う。

とはいえ、プロダクトオーナーが参加していけない、ということではない。プロダクトオーナーは参加しても黙っていてもらう、という手もあるし、悪影響が顕在化するまではチーム全体のすることに任せるという手もある。
逆に、プロダクトオーナーが明らかにふりかえりの場でのチームの心理的安全に悪影響を及ぼしているようであれば、プロダクトオーナーに丁寧に説明し、ひとまず不在にしてもらう、というケースも考えられる。

全体の流れとしては、顧客をはじめとするステークホルダーやエンドユーザのことまでを考えたふりかえりになるのが理想なので、時間がたつにつれてプロダクトオーナーまでを含めたふりかえりにしていけると望ましい、と考える。

チームが健全な状態かをふりかえりの中で確認するか?それとも不要か?もし必要だとするとどうやって確認するか?

チームの健全性には日々気を配るが、ふりかえりはよいタイミングなので、確認しておきたい。指標としては、遅刻、欠勤、残業時間、ふりかえりの場での発現頻度・長さ・内容、ふりかえりに臨む態度、メンバー同士の関係性、ふりかえりの話題におけるよいこと・悪いことや、技術的なこと・それ以外のことの割合等に注目する。スナップショットではなく、中長期的な推移にも気を配る。
テクニックとしては、チェックインで今の気分を言ってもらったり、ふりかえりのフォーマット自体を気分にフォーカスしたものにする、普段から記録をつけてもらい(例: ニコニコカレンダー)それをふりかえりの場にも持ち出す、等が考えられる。

過去に使ったふりかえりのフォーマットはどんなものか?

基本的に、「場を設定する、データを収集する、アイデアを出す、何をすべきかを決定する、レトロスペクティブを終了する」の 5 フェーズでデザインする。

主要なプラクティスとしては、週次のふりかえりでは KPT、よかったこと/モヤモヤすること/嫌なこと、スターフィッシュKPT 進化版)等。

プロジェクト等中長期のふりかえりでは、タイムラインを使うことが多い。

それぞれのアクティビティについて、大きく分けて各自黙って付箋やホワイトボードに書いてもらう時間をとるスタイルと、声に出してもらってファシリテータが書き留めていくスタイルがある。前者の方が効果的な場合が多いが、そういったワークを好まない人がいそうな場合や、試してみる目的で、あえて後者にしてみることもある。

データの収集においては、できるだけ客観的な事実をすばやく思い出せるよう工夫する。過去には、チームボードのスナップショットをプリントアウトして張り出したり、チームの日記を張り出したり、日付で区切られたチームボード(チームの Sprint における活動の記録がそのまま貼り出されている)自体の前でふりかえりを行ったりしたことがある。

どうやってマンネリを防いでいるか?

ゴールを共有した一体感のあるチームだと、たしかにマンネリになってくることがある。そういうときは、あえてゴールに直接はあまり関係ないことを試してみる、イベントの進め方もちょっと変えてみる(ファシリテーターを変える、プロセスを変える、等々)、イベントに普段は呼ばないゲストを招いてみる、といったことをやる。

そういう「ちょっと試してみる」ことをやりやすいように、スプリント期間はできるだけ短いほうがよい。

チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか?

なぜ行動できていないのかにもよるので、観察から自分なりに原因を見極めると同時に、チームになぜできていないのか、できていないことに対してどう考え、どうしたいか考えてもらう。場合によっては、実際に行動できるよう自ら手助けするのもよいかもしれない。たとえば、進捗の確認(「やってないようですが、やらなくて大丈夫ですか?」といったキュー出しのようなこと)を行ったり、アクションアイテムをプロダクトバックログに含めるよう PO とも協働したり、といったことが考えられる。

どうやってアクションアイテムのフォローアップを薦めるか?

アクションアイテムが SMART になっていれば、その指標にもとづいて適宜確認するとよい。タイミングとしては、Daily Scrum や Retrospective などがちょうどよい。遅くとも Retrospective では必ず前回のアクションアイテムのふりかえりを行うようにする。
達成できていた場合、さらによくするための追加のアクションがあるかを考え、あれば行うし、なければいったんチームとしてのフォローアップは終わりにする。(とはいえ、重要なアクションであったり、継続性に不安がある場合、スクラムマスターで独自に追跡するのもよいかもしれない)
達成できていなかった場合、アクションの有効性(今でも妥当なアクションか)や達成できなかった原因をチームで調べ、継続・変更・廃止などの、次のアクションにつなげていく。

11冊を並行で読む

年末年始休みだからいっちょ気合い入れて本でも読むかと思って読んでいる。

だいたいこういうときには多数の本を一気に読み始めてしまう。
今は知りたいことが多いから、一緒に読んでいる本も多い。

ビジネス/マーケティング

ブルー・オーシャン戦略

こないだ読んですごくよかった『突破するデザイン』で引用されていたから読んでみる。
戦略策定には実行手順を組み込める」という主張が特によい。

ブルー・オーシャン戦略では、策定と実行の連動性を重視している。大多数の企業ではこの両者を切り離しているかもしれないが、我々の研究によると、策定と実行が分断されてしまうと実行に時間がかかって効果も怪しくなり、機械的に手順を追うのがせいぜいである。

そうなのだ。
経営戦略、だいたいまともに実行されずに終わる。いかに戦略がよくても、まともに実行されなきゃなんの意味もないのだ。

キャズム

キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論

キャズム Ver.2 増補改訂版 新商品をブレイクさせる「超」マーケティング理論

キャズム関連の主要な用語やその主張するところは聞きかじって知っているものの、この本を読んだことなかったのでこの機会に読む。
エスケープ・ベロシティ』もそうだったけど、ジェフリー・ムーアの本は読みやすさと面白さが両立していてすごい。サクサク読めてしまう。

イノベーションへの解

イノベーションへの解 利益ある成長に向けて (Harvard business school press)

イノベーションへの解 利益ある成長に向けて (Harvard business school press)

イノベーションのジレンマ』がめちゃくちゃ面白かったから、その続編ということで読む。
ジェフリー・ムーアの本とは対象的に、読むのに時間がかかる。それは論理の緻密さの裏返しでもあるので、がんばって読む。

INSPIRED

INSPIRED: How to Create Tech Products Customers Love (English Edition)

INSPIRED: How to Create Tech Products Customers Love (English Edition)

初版は日本語で読んで、すごくよかった。
去年出た第 2 版も翻訳が進んでいるらしいのだけど、早く読みたいし旧版を一度読んだ本で英語の勉強にもちょうどいいかなと思って読む。

デザイン

Design Systems

Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド

Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド

最近関わってる製品でデザインシステム構築したほうがいいんじゃないか説があって試行錯誤してるので、ちょうどいい本出てるやんけと思って買った。
まだ序盤だけど、かなりいい。最新の事例がビシバシ出てくるのもいいし、デザインシステムとはなにかの話をアレグザンダーのパタン・ランゲージの話から始めてしっかり積み上げてくれるところもいい。買ってよかった。

UIデザイナーのためのSketch入門&実践ガイド

UIデザイナーのためのSketch入門&実践ガイド 改訂第2版

UIデザイナーのためのSketch入門&実践ガイド 改訂第2版

Sketch は使ってないんだけど*1、巷のプロトタイピングツールはだいたい Sketch みたいなものと聞いたので買ってみた。
おおむね期待通り、Figma 触ってみてイマイチよくわからなかった用語とか概念が解説されていてよい。後半にはモダンな周辺ツールの紹介とか UI トレースのすすめみたいな章もあるっぽいので楽しみ。

プロとして恥ずかしくない 新・配色の大原則

プロとして恥ずかしくない 新・配色の大原則

プロとして恥ずかしくない 新・配色の大原則

最近会社でやってるデザイン教室(?)の課題図書。
読み進めていくと世の中のモノとか Web とかアプリとかの配色について言葉で説明できるようになっていくので、たいへん面白い。

IA Thinking

IAシンキング Web制作者・担当者のためのIA思考術

IAシンキング Web制作者・担当者のためのIA思考術

こちらも同様に課題図書。
仕事始めまでに読み終わって課題もやっといてねとのことだったので、安全策として実家への帰りの新幹線でさくっと読んでしまう予定。

About Face

About Face: The Essentials of Interaction Design

About Face: The Essentials of Interaction Design

ゴール指向設計およびペルソナ・シナリオ法の父である Alan Cooper 御大の本。
旧版である About Face 3 は日本語版が出てるんだけど絶版で古本が高い。うっかり新版の翻訳出ないかなってずっと待ってたけど出る気配ないし、観念して英語で読む。

息抜き

イノベーション・オブ・ライフ

イノベーション・オブ・ライフ ハーバード・ビジネススクールを巣立つ君たちへ

イノベーション・オブ・ライフ ハーバード・ビジネススクールを巣立つ君たちへ

クレイトン・クリステンセン先生の本があまりにも面白かったので(そういえば去年読んだ『ジョブ理論』も面白かった)、最近敬遠してた人生指南(?)系の本だけど読んでみることにした。
まえがき(序講)に「今回も容赦はしねえ、理論で攻めるぜ」(意訳)みたいなこと書いてあるからワクワクしたものの、期待したようなキレッキレの論証とかはなくて、先生も人間なんだな~というあたたかい気持ちになりながら読んでいる。

Effective Java 第3版

Effective Java 第3版

Effective Java 第3版

ほか色々

このへんがメインで、合間に詩とか小説とか他気になった本とかをはさみながら読んでいくことになる。
予定。

まとめ

といった具合に、やたらめったら読む。

関連するジャンルの本を並行で読むと、似たようなことを言っているところ、少し切り込み方が違うところ、(極端な場合は)同じ事例を扱っているのに逆の主張をしているところとかが見つかって、自分の中での対話が捗る。

久々の感覚で、ちょっとたのしい。

*1:業務用の Mac がないから使えない、とりあえず Windows でも使える Figma を使ってみてる

読み比べたらぜんぜん違うのだろう

もともと 2018 年をふりかえっておこうかと思って書き始めた。

ところが、何か意味のあることを書こうとするとどうしても愚痴や恨み言めいたものになってしまう。
でもそれは本意ではないというか、筋ではないというか、少なくとも公共の場で語りたいようなことではないので、結果としてほとんど何も書くことがない。

こういうときに、人は詩を書いたりするんだろうか。

最近は、小さくて美しいものを見て心をなごませている。

Irene さんという、アメリカ在住で飼っている 3 匹の犬の写真を毎日 Twitter に上げている人がいて、その犬たちの幸せそうな様子を見ては、幸せな気持ちになっている。
犬はありがたいし、Irene さんもありがたい。

古賀及子さんという、Web ライターの人がいて、日常のことをはてなブログで書いている。お子さんのことが多いけれど、それだけでもない。
淡々と日常を綴っているだけで、煌めくような美文というわけでもない。そもそも僕にとって赤の他人の日常である。

でもなぜか、泣きそうになる。
今気づいたのだけれど、この淡々とした文体は、僕が大好きな『帰ってから、お腹がすいてもいいようにと思ったのだ。』の高山なおみさんに少し似ているような気がする。

たぶん、読み比べたらぜんぜん違うのだろう。

11 月には 4 回目の舞台に出た。
今年は、職場の人たちも何人か見に来てくれた。

荒れ放題になっていた部屋の掃除をしたら、少しすっきりした。

「全員常時ペアプログラミング」は「チーム開発初心者」向けなのではないか

週 40 時間ペアプロ

ここ 3 ヶ月ほど、所属しているチームの開発者全員が常時ペアプログラミングしている。

今やっている開発は、ほぼ、「ケント・ベックの本に書かれている XP」そのまんまのスタイル。*1

プロダクトマネージャが書いたユーザーストーリーを、プロダクトバックログの上から順に、4 人の開発者が週 40 時間労働で、毎日朝から夕方まで常時ペアプログラミング、TDD で開発している。*2

このように日常動作がペアプロなので、自然、ペアプロについてメタ的に考えることがある。
そんな折、ふと「この常時ペアプロするスタイルって初心者向けなのでは?」という考えに至った。

守破離の守

守破離」という言葉がある。

以下に Wikipedia の記述を引用する。

まずは師匠に言われたこと、型を「守る」ところから修行が始まる。その後、その型を自分と照らし合わせて研究することにより、自分に合った、より良いと思われる型をつくることにより既存の型を「破る」。最終的には師匠の型、そして自分自身が造り出した型の上に立脚した個人は、自分自身と技についてよく理解しているため、型から自由になり、型から「離れ」て自在になることができる。
守破離 - Wikipedia

この「守破離」でいうと、チーム開発において「常時ペアプロする」というのは「守」なのではないか。

言い換えると、チームで生産性の高いソフトウェア開発をしようと思ったときに、「まずは常時ペアプロする」のがいいのではないか? ということ。
「できるところから」とか「必要なときに」ではなく、いきなり「常時」やる。

逆に言うと、「常時ペアプロする」のはあくまで「初心者の動作」であって、チーム開発が上達するにつれて、やがて「常時ペアプロ」ではない形態に転換していくのではないか? ということ。
チーム開発に熟達すると、必要なときにペアプロし、そうでないときにはそれ以外のスタイルを取れるようになるのではないか。

XP におけるペアプロ

ところで、ペアプロというプラクティスは、「ケント・ベックの本に書かれている XP」の肝だと思う。
ここのところ、「週 40 時間ペアプロ」する日々のなか、ペアプロを日常動作の中心に据えることで、XP の価値・原則・プラクティスが、美しく統合されることを実感している。

XP の価値である「コミュニケーション」も、「フィードバック」も、「勇気」も、「リスペクト」も、ペアプログラミングというプラクティスからなめらかに導かれるし、ソロであればついつい設計や実装に不要な複雑さを持ち込みがちなところ、ペアで作業していれば「シンプリシティ」も保たれる。

「経済性」という原則については結論を(直感的には)即断できないとしても、「人間性」「多様性」「流れ」「機会」「冗長性」「品質」「責任の引き受け」といった大半の原則が、ペアプログラミングからほとんど直接の効果を得られる。

多くのプラクティスについても、同様のことがいえる。

「常時ペアプログラミング」することで、XP の価値・原則・プラクティスに則ったチーム開発が格段にやりやすくなる。

ペアプロのペイン

ここまで、ペアプロをほとんどべた褒めしてきた。僕はペアプロが好きだ。
でも実は、ペアプロには苦手なところもある。

コードを書くのが速すぎて、ペアの相手がついてきてくれないのである。

これは、僕のプログラミング能力が(チーム内で相対的に)高すぎるのか……そんなことって……、とか考えていたら、実はそうではないようだ、ということに気づいた。

僕は、コードを書くときに「トップスピードで試行錯誤しまくることで最短時間で正解にたどり着く」ようなスタイルを取るのが好きだ。マシンにできることは、マシンにやらせたい。*3

でも、ペアプロのときにこれをやると、実質「ペアの相手はマシン」という状態にになってしまう。僕とマシンのペア。
すると、人間のペアが置いてきぼりになる。

それではまずいので、常に思考を発話し、相手の理解を確かめながら進める。ところが、相手の理解を待っていたら、トップスピードではなくなってしまう。*4
理解を待たないわけにはいかないので、結果として、ソロでやったときよりも、その場の開発スピードは落ちることになる。

もちろん、ペアの相手が僕の知らないことを知っていて、ペアの力で速く進めることもある。これは、ペアプログラミングの重要な利点でもある。
だとしても、その場の開発スピード(の平均値)はソロのときよりも落ちる、というのが偽らざる実感で、そこがペアプロのちょっとだけ苦手なところ。*5

ペアプロの生産性

では、僕がいるチームでは、ペアプロしないほうがいいのか?
「しない」とは言わないまでも、「ペアプロしたり、しなかったり」するほうがいいのか?

そう考えてみても、やっぱり、今は「常時ペアプロする」方がいいと思う。

それは、ペアプロがもたらす価値が、「今コードを書く速さの低下」を補って余りあるから。
定量的に説明するのはちょっと難しいけど、「XP におけるペアプロ」のところで並べ立てた、XP の価値や原則、言い換えると「チーム開発の生産性を高めるための道」をペアプロが導く、ということが、説明になっていると思う。

プログラミングはコミュニケーション

関連する話題をもう一つ。

プログラミングは、コミュニケーションだと思う。

もちろんプログラミングの第一義は機能の実装、価値を届けるために動作するコードを生産することなんだけど、その生産性を高めるためには、「プログラミングはコミュニケーションだ」ということを理解している必要がある。

読みやすいコードも、整然としたアーキテクチャも、チームのメンバーや、将来の自分、そして将来そのコードを読み、使い、変更する人とのコミュニケーションのためにある。
テスト駆動開発によって設計を導くのも、チームメンバーとのコミュニケーションのためであり、理解しやすく変更しやすい設計による将来のコミュニケーションを導くためだ。

なぜコミュニケーションが重要かというと、コミュニケーションのなめらかさが、製品の品質や、生産性に跳ね返ってくるから。

そして、XP は「コミュニケーションとしてのプログラミング」の「先生」であって、ペアプログラミングこそがそれを導くものだと思う。
ペアプログラミングがそれを導くなら、常時やればいい。

プログラミングがコミュニケーションであることが、「今コードを書く速さが落ちるとしても、ペアプログラミングをした方がいい」ことの説明になる。

ペアプロの「破」「離」

ということで、「常時ペアプロ」がチーム開発の「守」にあたる、という話に戻ってくる。

やや乱暴な言い方をすると、常時ペアプロすれば、チームとしての生産性が上がる、とも言える。
「すれば」→「上がる」というのは、まさに「守」だ。いつペアプロすべきか、とか、何をどう工夫すれば、とか、考えなくていいのだ。*6

では「破」「離」はなにか。
それが「いつペアプロすべきか」考えること、そして選ぶこと、なのだと思う。

まだその域に至っていないので、何が「破」で何が「離」にあたるのかはわからないけど、いずれにせよ、ペアプロするとき、しないとき」を使い分けるのは「上級スキル」だ、という感覚が今はある。
下手に「一人でやったほうが速いから」ということでソロ作業を取り入れると、「速さ」以外の、コミュニケーションにかかわる価値を損なって、結果としてチームとしての生産性(要するに、中長期的な「速さ」!)が低下しかねない。

だから、初心者のうちは、常にペアプロした方がいい。
そうすれば、ペアプロのメリットもデメリットも余さず体感できるし、経験が少ないうちは、下手な工夫でやったりやらなかったりするよりも、チームとしての生産性の平均値は高くなるはず。

とはいえ、いつまでもずっとペアプロを盲信するのではなく、いつか「破」に移行して、また「離」にいけるといいな、と思う。

それはモブプログラミングのような形かもしれないし、もしかしたら、全員がソロに戻るという可能性もある。
結局、常時ペアがいいということになるかもしれないし、それらの間になるかもしれない。

結論

僕は、今いるチームで「全員常時ペアプログラミング」することで、チームの生産性向上を感じている。
チーム開発の初心者や、集まったばかりのチームは、「少しずつ導入」するよりも、むしろ「全員常時ペアプログラミング」を試してみるといいのではないか。

ペアプログラミングは、「コードを書くスピード」が落ちることもあるけど、「コミュニケーションとしてのプログラミング」を強力に推進する。
それはチームとしての生産性の向上を導き、中長期的な生産性にもつながる。だから、やる価値がある。

はじめは「常時ペアプログラミング」して、慣れてきたら、「ペアプログラミングしないとき」について考え始めるといいのではないか、と思う。

補遺

ペアプログラミングには、「誰もが好むわけじゃない」という課題がある。

ペアプログラミングの研究者が書いた本にも書かれていることだし、僕の周りにもペアプログラミングが苦手な人はいる。(もちろん、それは責められるべきことではない)

僕の場合、今のチームには、少なくともペアプログラミングが「すごく苦手」「大嫌い」という人はいなそう。(直接面と向かって「大嫌いですか?」と聞いたことはないけど……)
だから、成り立っている。

もし、チームの中にそういう人がいそうだったら、導入は慎重に。
強制すると、みんな幸せになりません。

*1:ブログ購読者の方向け: 今は、以前スクラムをやっていたチームとは別のチームにいます。以前のチームは、形を変えながらもスクラムによる開発を続けています。ちなみに、モブプログラミングを実践しているみたいです

*2:なお見出しにはわかりやすいように「週 40 時間ペアプロ」と書いたけど、定時が週 37.5 時間なのと、プログラミング以外の時間もあるので、実質は 30 時間くらいだと思う

*3:コンパイル言語でテストも書いてれば、考える時間ってあんまり必要なくて、書かれたストーリーを見て、上からいくか下からいくかだけ仮決めして、あとはIDEとテストの導きに従ってひたすらキーボードを叩いてたら、コードはできあがる。立ち止まって考えるのは、最初と、打鍵しながらと、機能が一通り動いて少し大きめにリファクタリングしようと思ったときだけで十分。

*4:これは能力差の問題というより、非対称性の問題。マシンは人間より桁違いに速いので、正しい入力も間違った入力も、瞬時にフィードバックしてくれる。でも、人間はそうはいかない。相手が僕の 2 倍くらい速い人じゃないと、トップスピードは出せないと思う

*5:これに気づいて(つまり、「僕の開発スタイル」が原因で、「ペアとしての生産性」が最大化できていないようだ、ということに気づいて)、自分の開発スタイルを「ペア用」にチューニングすることを考え始めたのだけど、この記事の本旨とはずれるので、ここでは議論しません

*6:「考えなくていい」というのはもちろん言いすぎで、考えるのはいいことだし、考えたほうがいい。でも、考えながらも、基本動作としては「常にペアプロする」。

2017 年のふりかえり

2017 年をふりかえります。

年間目標のレビューから。

目標 : 月に 1 冊以上技術書を読む

今年は、以下 15 冊の技術書を読みました。

  • みんなのGo言語
  • M2M/IoTシステム入門
  • レガシーソフトウェア改善ガイド
  • [改訂第3版]Jenkins実践入門
  • The DevOps ハンドブック
  • ユーザーストーリマッピング
  • Lean UX
  • The Nature of Software Development
  • Running Lean
  • リーン顧客開発
  • 初めての自動テスト
  • テスト駆動開発
  • 継続的デリバリー
  • エリック・エヴァンスのドメイン駆動設計
  • おうちで学べる人工知能のきほん

年間 15 冊ということで月 1 冊以上のペースなので、目標達成ということになります。

総括

前半はチームとか組織のことをやってたので、どうしても興味がそっちにいきがちでした。
9 月から異動で役割が開発者になったため、そこから一気に稼いだ感じです。

もともとこの目標は、今年の前半みたいなマネジメント的役割にあっても技術のキャッチアップを続ける……という意味での「月 1 冊」だったので、開発者になった今となっては微妙っちゃ微妙な数字です。
ただ最近は入門書・技術ハウツー本というよりは第一人者が書いた鈍器系の本をしっかり読み込むことが増えてきたので、月 1 冊ペースでも十分着実に学んでいるとも言えます。

とにかく達成してめでたい。

開発職に戻った(しかも新製品開発!)ので最近は開発本をビシバシ読んでいるのですが、なかでも『エリック・エヴァンスのドメイン駆動設計』を読んだのは収穫でした。
自分で言うのもなんですが、今所属している組織にあって「Java で適切なコードをすばやく書くスキル」は割と限界付近まで高まってて、それでもイマイチ価値を出しきれてない感じがしたのでチーム/組織とかプロダクトマネジメントの方に関心が向いていたのですが、コードのレベルでも(あるいは、コードのレベル「から」)まだまだやれることがたくさんあるのだと気付かされました。

関連書籍

技術書かは微妙なところだけどソフトウェア開発関連の本というところでは、以下の 10 冊あたり。

  • アジャイルコーチン
  • 変革の軌跡 世界で戦える会社に変わる "アジャイル・DevOps" 導入の原則
  • カンバン ソフトウェア開発の変革
  • 今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント
  • The DevOps 逆転だ!
  • The Great ScrumMaster
  • スクラム 仕事が 4 倍速くなる "世界標準" のチーム戦略
  • Mob Programming: A Whole Team Approach
  • リーン・スタートアップ
  • IntelliJ IDEA ハンズオン

スクラムやらカンバンやらの本をほとんど片っ端から読んでる感じで、なんかひどいですね。

以下は再読。

実践していると、再読からも得るものがたくさんあります。

今読んでる本。*1

実践の中にいないと学べないタチなので、開発者やってる今のうちにこの辺のところにどっぷり浸かっておきたい。

近いうち読みたい本。

最近はとにかく買う本を減らしていて、というのは買っても読めてない本がいい加減積み上がりすぎているからなのですが、「買わない」という選択を続けていると、本は世の中に一生かけても読めないくらいたくさんあるのだ、ということを実感して、寂しい気持ちになります。

ただ寂しいというだけではなくて、今読んでいる本は、選んでそれに(時間を)投資しているのだ、ということもひしひしと感じます。

何を選んで、何を選ばないのか、ということに意識的になります。
意識していようがいまいが選んではいるのだから、意識できるようになったのはきっといいことです。

目標 : 月に 5 回以上演技クラスに通う

年間延べ 56 回。

月 5 回ペースだと 60 回になるので、4 回不足でした。
海外出張とか劇団の本公演とかで休んだ分をリカバリできなかった。

とはいえ、一年通してコンスタントに通い続けることができました。
このペースだとさすがに劇的な成長みたいなのを感じることはないのですが、少しずつ色々なことができるようになってきています。

少しずつ。

目標 : 本は月 8 冊、観劇は月 6 回程度(まで)にする

本は、92 冊。

月 8 冊ペースだと年間 96 冊なので、ほぼぴったりです。

観劇は、47 本。

月 6 回ペースだと 72 本なので、だいぶ下回っています。
だいたい月 4 本ペースですね。

なんか、これくらいがちょうどいいんじゃないか、という感じがします。

かわりに何をしたか

この目標には、去年まで時間の大半を注ぎ込んでいたアクティビティを減らして、減らすことで他のことができるようになるはず、という含みがありました。

かわりに何ができたかというと、

  • 演技クラスに通う
  • 鈍器系や英語の技術書を読む
  • 映画を観る

この辺でしょうか。

演技クラスについては、前述の通り。

技術書については、

あたりの(物理的に)重い本を読んだり、

  • The Great ScrumMaster
  • The Nature of Software Development
  • Developer Testing

あたりの英語の(翻訳されていない)本を読んだりすることができました。

一日の中で本を読む時間はある程度確保されているので、冊数を減らすためには、一冊にかかる時間を増やす必要があります。(妙な理路ですが……)
結果として、この辺の読むのに時間がかかる本を読むことが増えました。

というか、実はこれは偶然の結果ではなくて、その辺が狙いの一つだったので、狙いが的中しました。

映画は年間で 20 本弱くらい見ました。
前半よく観たのですが、後半あまり観なくなってしまいました。

どうもやっぱりどこかで映画を信じてないところがあるっぽくて、映画はメジャーエンタメなので仲良くなりたいのですが(ぼくもメジャーになりたい)、なかなか仲良くなれません……。

月 8 冊 / 6 本ってぶっちゃけどうなのか

月 8 冊という読書ペースは、はっきり言ってしんどいです。
読みたい本の多さに対して、スループットが低すぎて。

とはいえ、人としてこれくらいがまともなペース、という感覚もあります。
だから、選んでいく、厳選していく必要があるのだと思います。

ちょっと仕事に傾倒しすぎて、詩とか小説とかをほとんど読めなかったのが大いに反省ポイントです。もっと読みたかった。
来年はバランス取っていきたい。ただ、詩とか小説とかって計画的に読むものでもないので、悩ましいところでもあります。

観劇については、結果として月 4 本ペースでも何となく満足してしまいました。
もっと観たかったかと聞かれれば観たかったのですが、観なけりゃ観ないでなんとかなってしまうというか……。ちょっと意外でした。

といっても、年間 100 本(近く)も観たのは去年だけなので、去年が異常だっただけなのかもしれません。

月 4 ≒ 週 1 というのはわかりやすい数字で、これだけあればそれなりに色々観られるので、来年もこれくらいを目安に観ていけるといいのかなと思います。

目標 : 毎月計画してふりかえる

8 月までやってました。

7 月あたりから仕事とプライベートの計画を統合してやっていたのですが、9 月に異動になって、仕事のスタイルが大きく変わったのにともない、気がつくと個人の計画をやらなくなってしまっていました。
7 月の時点では統合しないメリットがない、と思っていましたが、統合するとこういう事故も起こるのですね……。

目標もおおむね達成できているし、結果オーライかな? という気もしますが、これは 8 月まできっちりやっていたおかげ(その慣性で達成した)という気もするので、やはりあんまりいいことではないかな。

来年 1 月からは仕事の様子がまた少し変わるということもあるので、新しい計画とふりかえりのやり方を模索していきたい。

目標 : 丁寧に暮らす

会社の移転に合わせて、11 月に引っ越しました。

そして、荒れてます。

ものが多いというのは一因。
右のものを左にやると左が埋まるだけ、みたいな状況なので。

引っ越しに際して本と CD を段ボール 2 箱分減らしたのですが、引越し先で棚に詰め込めるだけ詰め込んだら段ボール 4 箱分残りました。
なんということでしょう。

やるべきことは見えていて、この 4 箱分を何らかの形で部屋から出すことです。
まあ、処分するべきなんだろうな。

既に処分する対象は選定していて、でも全然 4 箱分に至らないので途方に暮れています。
たぶんこのままでは埒があかないので、まずは選んだ分だけでも売ろう。

そうしよう。

まとめ

2017 年も色々なことがあったにはあったのですが、総じて言うと、今いる場所でやることをきっちりやっていたら終わった一年、という感じがします。
悪いことではないのですが、よくもないですね。

いい面を見るなら、やることをきっちりやるのはもう当然のようにできる、ということです。

でも、やることって、なんだ?

かれこれ 10 年近く前からずっと、最大の課題が「自分がどこに行きたいのかよくわからない」ということで、ごまかしごまかしやってきたものの、いい加減年貢の納め時なのでは、という気がしてきています。
世の中誰もが「自分がどこに行きたいのか」わかってるわけでもないのだとは思うのですが、ずっと引っかかっていることなので、何らかのかたちで折り合いをつけたいと、いう気持ちがあります。

たぶん「解決した!」という状態には一生ならないのだろうなとは薄々思いつつも、一歩でいいから先に進みたい。

*1:読みかけは技術書以外も含めると 100 冊以上ありますが近いうちに読了予定のものだけピックアップ……