1時に寝て5時に起きた。ホテルのテレビを付けっぱなしで寝たら朝のニュースで起きた。なんとなくニュースをみながら7時ぐらいまでのんびりしてた。

1週間のイテレーションはナンセンス？

毎月行っているマイルストーンのふりかえり。今回で3回目なのでメンバーもだいぶ慣れてきた。11, 12, 1月と3ヶ月に渡って課題管理をメンバーに実践してもらいながら開発してきた。当初、開発のイテレーションを1週間で行うか、2週間で行うかの話し合いで短い方がいいんじゃないかとなり、あまり深く考えずに1週間のイテレーションで開発をまわしてきた。しかし、いまとなってはこれは開発のイテレーションとは違うものになっている。

最初の1ヶ月はメンバーにとって慣れないワークフローだから、1週間のイテレーションでこの issue をやる・やらないといった厳密な取り決めはしなかった。その後、徐々に慣れてきたのを見越して、定例会議のときに issue 一覧をみながら、メンバーに2-3個ぐらいの issue をアサインしたり、issue の優先順位付けを明確にしたりしてきた。必ず issue を完了させるという強い制約を課していないものの、だいたい毎週アサインしたものをメンバーは対応してくれていたので、マネージャーとしての私の視点からもとくに問題はないようにみえた。要はうまくまわっているのでそれ以上の管理をしなくてもいい状態だったと言える。

一方で、本来の課題管理のイテレーションとは異なる開発のワークフローになっていて、それがよいことなのかどうか、私自身にも明確な答えがなかった。それでメンバーに尋ねてみた。いまの1週間単位のイテレーション (開発のワークフロー) をどう思いますか？

メンバーからは、1週間の作業内容を厳密に決めなくてもいいんじゃないかという意見が出た。それは私の考えとも一致していたものの、開発のイテレーションを2週間に伸ばすことについて話しているときに、そうしたとしても、定例会議は毎週やりたいという意見が出た。要件確認や仕様共有のために重要だという。通常、イテレーションの成果共有のために定例会議とイテレーションの長さは一致している。仮にイテレーションを2週間にしたら定例会議は2週間に1回となる。しかし、メンバーの視点からはイテレーションを1週間にするか2週間にするかについて関心はないものの、毎週の定例会議で行っている情報共有は重要だという認識があった。

ここで開発のイテレーションと定例会議の頻度は別にあわせなくてもいいんじゃないかと考えるきっかけを私は得られた。スクラムもスプリントと会議体の頻度はセットになっているのでこの発想はなかった。ちなみにアリエル時代は1つのイテレーションが3ヶ月で定例会議もなかった。そして、うちのチームは1ヶ月のマイルストーンに対してふりかえりをセットにしている。これはもはやイテレーション開発の文脈でいえば、実質うちのチームはマイルストーンと呼んでいる1ヶ月が1つのイテレーションになっていて、1つのイテレーション内に4回の定例会議があるというイテレーション開発のワークフローになっていることに気付いた。課題管理の考え方やワークフローがもっと洗練されていくと、毎週の定例会議をやらなくてもよいようになっていくのが私の経験から自明である。しかし、うちの開発は私も含めて8割以上がフルリモートワークなので、メンバー全員の顔を合わせる機会を作るという観点から毎週の定例会議は大事な場にもなっている。

実際の開発のマネジメントをしてみると、私自身、分かっていなかったことや新たな発見があって、まだまだ自分自身も修行の身であることを実感する。ここでの結論としてわかったことは次の通りで、ロードマップにおける最初のフェーズが完了する3月末までは現状のワークフローを継続してみることに決めた。

• 開発のイテレーションとして1週間は短過ぎて管理対象としてあわない
• 開発のイテレーションと定例会議の頻度をあわせなくてもよい
• フルリモートワークの場合、メンバー全員を集める目的は情報共有だけではない

23時に寝て何度か起きて7時に起きた。起きたものの、なんかしんどくてお昼前まで寝てた。

課題管理勉強会の資料作り

出張前の定例作業になりつつある。本当は余裕をもって事前に資料作りしておけばよいのに、日々の余裕がないから出張直前の日曜日に資料作りしている。これはよくない兆し。次の課題管理勉強会は エンジニアリング組織論への招待 を取り上げる。Chapter 1 の思考のリファクタリングから、私が関心のあるところ、もしくは課題管理で解決できそうな話題などを重点的に取り上げる。たたき台はできた。構成や進行をさらに練りたいので少し寝かせてからもうちょっと考える。読み返していると忘れていたことを思い出したり、課題管理と密接な内容を再発見したり、本の内容をずっと覚えているとかないから自分の勉強にもなる。本当は参加者同士で内容の議論ができるといいんじゃないかと思うけど、少人数の勉強会ではないから発言しにくい空気がある。もしくは発言するのは一部のメンバーに限られてしまう。とくにリモート参加が多いと勉強会は盛り上がらない。それは オンライン飲み会が盛り上がらない理由 と同じ。

12時頃にオフィス来て、途中に休憩を取っているけど、ひと段落して気付いたら23時まわってた。明日は始発で新幹線に乗る。このまま起きたまま夜通し出張の準備をして新幹線で寝る作戦に移行する。

22時に寝て2時前に吐き気で起きて少しだらだらして寝て7時に起きた。

ストレッチ

今日の開脚幅は開始前154cmで、ストレッチ後158cmだった。あまり数値は振るわなかったものの、この1ヶ月ぐらいではもっとも復調しつつある。まだ腰の張りがやや残っていて全快とまではいかないものの先週よりはよくなりつつある気はする。先週から左右への開脚以外に前後の開脚のときの股関節のストレッチを重視するよう、トレーナーさんからも指示はあったものの、今週は全然そんな余裕がなくてあまり取り組めなかった。それを余暇でうまくできなかった分の、数値の悪化かなとも受け取れた。

2-2. 傾聴・可視化・リフレーミング

エンジニアリング組織論への招待 のメンタリングの技術の章を読み直し。前回 からだいぶ間があいた。

メンターはメンティに対して「問題を解決してあげよう」ではなく「モヤモヤしていない問題に変換してあげよう」と考えることが重要。問題を次のように考え、

• 感情的に固執していて解けないので「傾聴」をする
• 客観視できずに解けないので「可視化」をする
• そもそも解けない問題なので前提を変える「リフレーミング」をする

というのが、メンタリングで意識すべき流れになる。

共感と同感の違い

• 共感という言葉の意味は「相手がそのような気持ちになった理由を理解する」こと
• 同感は「自分が相手と同じ気持ちになる」こと

傾聴において示すべきことは、「共感」であって、「同感」ではありません。

認知フレームとリフレーミング

• 人はありのままに物事を見られない
  • 人は認知する枠組みの範囲でしか処理できない
  • この枠組みのことを「認知のフレーム」と呼ぶ
    • この外側にあることは「心理的な盲点」と呼ばれる
• 対話によって認知フレームを変えることを「リフレーミング」と呼ぶ
  • 「解けない問題」を「解ける問題」へと変えていく

確認された前提を「一旦、この前提がなかったらどうなりますか？」というように外して考えるようにすることで、リフレーミングを促すことができます。 また、この中で「一番重要だと思うものは何ですか？」というように前提の優先順位を問うこともリフレーミングを促します。気になって仕方なかったことが、実はあまり重要ではないかもしれないと気がつく契機になります。

「情報の非対称性」を解消するには、

• 自分の情報を相手に伝える
• 相手の情報を自分が聞く

という行動をとればよいのですが、この当たり前のことができなくなってしまうケースがある

これは、メンター役になる人に対しても重要な警句です。メンターは、メンティの問題を「自分の課題」として捉えてはいけません。メンターにとっての課題は「メンティを自立的な問題解決」に導くことであって、「メンティの課題を解決すること」ではないのです。

この節を読み終えて、課題管理とは、メンターを必要とせず、自分で自分をメンタリングするツールとも言い換えられるかもしれないと思えた。課題管理を習熟すると自分で自分の間違いに気付けるというメリットを周りに伝えたりしていたことがメンタリングで大事なことのいくつかの共通することが書いてあった。

車を運転して実家へ

明日は父の35日なので夕方から購入した車で初めて実家に帰った。神戸の高速道路の路面が少し濡れていたり北淡で小雪が降ってきたりして、さっそくタイヤ周りを汚れてしまった。まぁ仕方ないか。door-to-door で1時間15分ぐらいで実家に帰れる。高速バスで帰るとこんな段取りになる。

• マンションからバス停へ移動する (10分)
• バス停でバスが到着するのを待つ (待ち時間10分)
• 高速バスで移動する (1時間20分)
• バス停まで親に車で迎えに来てもらって実家へ移動する (15分)

待ち時間の調整が入ると2時間ほどはかかっていた。これが自分の都合で移動できるので調整時間がない分のストレスが溜まらない。帰ろうと思って1時間強で移動できる気楽さがある。