「カイゼン・ジャーニー」を読んだ
フルリモートで働くようになり、開発チームのメンバーと直接顔を合わせることが無くなった。そのような状況の中で、チームでプロダクトを作っていくとはどういうことか？チームとしての生産性を高くするにはどうすればいいのか？ということを考えるようになり、以前から気になっていた「カイゼン・ジャーニー」を読んだ。
自分が大事だと考える箇所と各話の感想を読書メモとして残していった。そのメモを読み返してみると、「こうしていればよかった」や「難しそうだ」ということが多く書いており、それがかつての自分には見えていなかった境界であり、今の自分に見える境界なのだと思う。
今の自分では、見えているすべての境界を一気に超えることは出来ないため、まずは自分一人で出来る越境を試みる。具体的には、本書で挙げられている4つのプラクティス（タスクマネジメント、タスクボード、朝会、ふりかえり）を使って状態の見える化から始めていく。
1回読んだだけでは腹落ちしていないものもあるし、気付けていないこともある。新しい境界が見えたときや1つ越境したときに、本書は越境のためのヒントを得る本として、今後も何度も読み返すことになるだろうな思う。
各話の感想
第1部 一人から始める
第1話 会社を出ていく前にやっておくべきこと
勉強会や本などで学んだことをそのまま自分の環境でやってみようとして頓挫するのはあるあるだなと思う。
他人の背景・制約と比較して自分の状況・制約ではどう活かせるかを考えるためには、そもそも自分の置かれた環境を把握する必要があるが、自分のことというのはフラットに見ることは難しい。
第2話 自分から始める
今まで「朝会」「ふりかえり」をチーム単位でやることはあったが、朝会は今日やることを報告するだけで状況の整理と問題の検知ができていなかったように思う。
また、ふりかえりもふりかえって出た改善策を継続できなかったように思う。改善策を試して本当に効果があったのか？ということを検証せず、やりっぱなしで終わってしまい、経験・知見が蓄積されていない印象だった。（KPTのKeepが増えていくが本当に継続されているかが不明だったり、意味のないものがKeepに残り続けているようなイメージ）
「タスクマネジメント」「タスクボード」「朝会」「ふりかえり」の4つとも試そうとしたがそのうち形骸化してしまい、習慣付かずに消えてしまっていた。なぜやるのか・何が目的なのかということを意識できていなかったのだろうなと思う。
第3話 一人で始めるふりかえり
今もKPTでふりかえりをしているが、過去のKeepの見直しやTryの効果判定があまり機能しておらず、1つの課題が Problem → Try → Keep という道筋をたどった段階でその課題についての学び・気づきが蓄積されず消化されていることが多いように思う。せっかくふりかえりの場があるので、せっかくなのでより実りのある場にしたい。
また、Tryにおいても表面的な対策で済ましてしまっていることが多いので、本に書かれている「事実」「意見」「対策」で真因を探すようにしたい。
第4話 一人で始めるタスクの見える化
ここが全然できていない。
渡されたタスクの精査・分割をせずそのまま着手してしまい、ゴールまでに気を付けることは何かが整理できていないために大幅な遅延が発生したり、関係者と認識のずれが生じて手戻りが発生したりといったことがそこそこの頻度で発生してしまっている。
タスクボードを利用して、タスクを1日で終わる単位に分割し「どうなったらこのタスクは終わるのか」がパッと見える形にする。
第5話 明日を味方につける
朝会が今日やることの確認をする場にしかなっていない。タスクを1日で消化できるサイズより大きい状態で管理してしまっているので、数日間同じタスクが今日やることになってしまっていて何も管理できていないのと同義になっている。
大きなタスクだと自分自身でも進捗しているのかが実感できず中だるみのようなことになってしまうことが多いので、タスクマネジメント（タスクの分割）とタスクボードと組み合わせて今の状況を打破したい。
第6話 境目を行き来する
現状ではタスクボードを使っていないので、タスクボードを使ってタスクを管理することから始める。
他人に依頼したタスクは投げっぱなしで、思い出したときに都度確認する形で頼んでいたことすら忘れてしまうことが多かったので、同じタスクボードで管理してこのようなことが起こらないようにしていく。
第7話 二人ならもっと変えられる
行動を変え、新たな一歩を踏み出すのに「遅すぎる」ということはない、行動を始めるべきと気づいたその時が、その人にとって最速のタイミングだ。決して、気おくれするな。
という言葉に背中を押されて、一人でタスクボードを使ってのタスク管理と、それをもとにした朝会・ふりかえりをやってみる。
オフィスでやっていれば、「あいつ何をやってるんだ？」となるけど、フルリモートの場合は意図的に発信しないと他人を巻き込めないので、自分の中でリズムが出来てきたらこんなことやっているよと言おうと思う。
第8話 二人で越境する
出来事への対処療法的（場当たり的）な対応で満足してしまっていて、氷山モデルでいうメンタルモデルどころか行動パターンへの深掘りすらできていない。
メンタルモデルを変えるのに必要な、対話ができる（巻き込める）ほど行動ができていないので、とりあえず、一人で行動パターンや構造まで深掘りできるように4つのプラクティスをやっていく。
第2部 チームで強くなる
第9話 一人からチームへ
開発チームの説明にしれっと「自己組織化」という言葉が出てくるが、開発チームのいちメンバーとして思うのは、自己組織化したチームを作るのも難しいわけで・・・
第10話 完成の基準をチームで合わせる
プロダクトオーナーとの対話を通して、チーム全員でプロダクトバックログアイテムの受け入れ条件の認識を合わせるということはかなり有意義だったように記憶している。ただ、機能要件ほど非機能要件について深堀りすることは少なかったので、ここはもっとうまくできたのかなと思う。
それよりも、物語の中で出てきた「ただタスクを消化しているだけの感覚が強まっている」「自分たちが作っているプロダクトがそもそも一体何なのか見えないまま、機能だけ作っている感覚」という点に共感し似たような感覚を感じていることが、チームでプロダクトを作るということとはなんだ？ということを考えるきっかけになり、本書を取った要因になっている。
第11話 チームの向かうべき先を見据える
1度インセプションデッキを作ったことがあったが、確かにその瞬間はチームで認識を合わせられたように思う。ただ、定期的に見ることも見直すことはなく、チームの増減やプロダクトの方向性変更が重なり実態にそぐわなくなり忘れ去られてしまっていた。
また、プロダクトオーナーの役割を担っていたメンバーがその場にいなかったため、開発チームだけの言ってしまえば自己満足のようなものになっていたように思う。
さらに、プロダクトにフォーカスを当てすぎていて「我々はなぜここにいるのか」への答えがメンバー間で似通っていたように記憶している。この本に書かれているような「このチームでプロダクト開発のやり方を体得し、他の現場に伝えられるようにすること」のような組織全体に視野を当てたような問が出てもよかったように思う。
そのためには、視野を広く持ちそれぞれの視座で考える力が必要になってくるのだろうなと思う。（これは同著者の「正しいものを正しく作る」で触れられていたことに近いのでは？）
第12話 僕たちの仕事の流儀
余裕がある状態で成功循環モデルを見ると確かにそうだよなぁと思うが、切羽詰まっているとついつい短絡的な答えに求めがちになってしまうように思う。そもそも、そういう状況に陥ることが「関係の質」に問題があるということなんだろうが。
書かれていることだが Working Agreement はインセプションデッキと同じく「チームで決めた（考えた）」という点が重要で、誰かが決めたルールはどうしても「自分たちを縛るもの」と考えてしまい軽視しがちになるように思う。
そういった点で言うと入ったばかりのメンバーは Working Agreement をそういう風に捉えられてしまう気がする（採用の際に価値観に合うかどうかを見ているとは言え）。
ルールの見直しのタイミングでそのような考えはなくなるとは思うが、初めに「自分たちで決めた自分たちのルール」であることを伝えておくとよいかも。
第13話 お互いの期待を明らかにする
人はえてして、勝手な期待を押し付けがちだし、必要以上に自分を責めて勝手な期待を背負いすぎたりしまう。そして期待がミスマッチであるために過度なストレスや不満がお互いによって引き起こされてしまう。
これには強く同意できる。チームから期待されていることがはっきりすることで自身を持って業務にあたれる。
かつてドラッカー風エクササイズを試した時に、他人と比較してしまい「得意なことが無い」と考えているメンバーに素直に自己開示してもらうことが難しかったように記憶している。 インセプションデッキやWorking Agreementと違い個人の内面を開示することになるので、ハードルが高くファシリテーターの手腕が問われるのだろうなと。
第14話 問題はありませんという問題
ここにきて本書では繰り返しメンバー間のずれ（認識のずれ、価値観のずれ）について言及されているなということに気づいた。自分は割と「多分こうだろう」という勝手な思い込みで進めてしまうことが多くずれが生じて問題を起こしてしまっていたなと思う。
チームで仕事を進めるうえで思い込みは無くしていかないとなと。
第15話 チームとプロダクトオーナーの境界
かつてスプリントレビューをしたときは、作ったプロダクトを確認したのみで、価値を最大化するために次に何をすればいいかということを話したことはなかったように記憶している。なぜスプリントレビューをするのかということをメンバー間で共有できていなかったのかなと思う。
リファインメントに開発チームとして携わらなかったことが、プロダクトバックログに積まれたアイテムを消化していくだけに感じることの要因だったのだなと読んでいて思った。
今になって思うと、開発チームはプロダクトオーナーがメンテナンスしたプロダクトバックログを消化するだけの社内下請けのようなことになっていた。
スクラムについて学ぶたびに思うのが、1つのプロダクトを作って運営している会社では、開発チームだけでどうにかなるフレームワークではなく、会社全体を巻き込んで動く必要があるなぁと。
例えばエンジニアが技術的なことだけを考えるのではなくプロダクトの方向性をマーケティング的な立ち位置で考えられるようになる、といった感じで組織の全員が越境する。
第16話 チームとリーダーの境界
むきなおりが有効に機能するには、開発チームがただバックログを消化するだけの組織ではなく、ミッション・ビジョンに対してしっかりとした認識を持ち、どうすればユーザにより良い価値を届けられるのかを考え実行できるような組織になっている必要がありそうだなと思う。
それは、視点を変えることであり、越境なのだろう。
第3部 みんなを巻き込む
第17話 チームと新しいメンバーの境界
チームビルディング三種の神器として紹介されているものをすべてやったことがあるが、自分がその目的（チームビルディング）をちゃんと把握できていなかったために、それぞれが独立したものと考えシナジーを感じることができなかった。
「なぜやるのか」「目的は何か」ということを考えられていれば、メンバーとしてチームをよりよくするために動くことができたのではないかと思う。
言われなかったし・・・というのは言い訳なわけで、目的なんてものは一言聞けばいいだけなのに、それを面倒（勇気がなかった？）だからとしなかった。
スクラムをやってみようと試行錯誤していたあの人は越境しようとあがいていたのだなと今になって思う。
モブプログラミングもやったことがあるが、特定の人物だけが発言し続けるといった感じで、到底モブとは言えない状況になってしまった記憶がある。チームとして心理的安全性的なものがなかったのか、どうせ言ってもみたいな諦めムードになっていたのか・・・ 。
結局数回やって、チーム内からもモブプログラミングに意味があるのか論が出て自然消滅してしまった。
第18話 チームのやり方を変える
「スクラムに一人のヒーローはいらない。ヒーローはチームなのだ。」この考えをメンバー全員が持つことが重要なのだろうが、ヒーローがいればその人に頼れば良くて楽なので難しいなぁと。
開発のプロセスを改善しようとしても開発チーム（エンジニアだけ）内で閉じてしまうことが多く、局所最適化になってしまいあまり意味のない「やったつもりになっただけ」の状況になることが多いように想像する。ここでも、組織全体を変える必要があるように思う。やはり、越境が重要ということなのだろう。
ただ、組織全体を変えることはそうそうできるものではなく、個人→チーム→会社全体という感じで影響範囲を広げていくのが現実的なのだろうが、チームから次のステップに行くのがかなり難しい。
第19話 チームの解散
チームが解散することがない場合でも一定の期間（クォータ）毎にポストモーテムをするのが良いのだろうなと。
スクラム開発ががっつり話に絡んでくる影響で、「アジャイルサムライ」の内容とかなり似通っているように感じた。「アジャイルサムライ」を読んだ当初はSIerでインフラの運用・保守に携わっていたので、こんな世界があるんだなぁぐらいで流し読みで済ませてしまっていた。改めて「アジャイルサムライ」を読み直してみようと思う。
第20話 新しいリーダーと、期待マネジメント
ここでも認識・期待のずれを素早く修正することが重要であるということが言われているのだと感じた。認識や期待を可視化（表明？）し思い込みや疑問をなくすことで余計な軋轢を生まずプロダクトに向き合うことができるのだろう。
ただ、そういったことを抵抗なく自身の内から出すには心理的安全性が重要なのだろう。これまで漠然と心理的安全性は大事だよねぇと思っていたが、自分の認識・価値観を素直に表現しチーム内での認識・期待のずれを修正するための前提条件として心理的安全性が無ければならない、ということなのだと思う。
本書で触れられているモダンアジャイルについてしっかりと調べたい。
第21話 外からきたメンバーと、計画づくり
プランニングポーカーの数字（規模）と見積もり日数（期間）が別物だという意識は、見積もりをする際に重要ということは痛感している。
プランニングポーカーをする際には、ユーザーストーリーを一番把握しているプロダクトオーナーが必須だが、何かしらの（CTOとか）と兼任していると時間が取れず不在のまま不明点を残す、もしくは仮定をおいて見積もりすることになり、極論意味のない見積もりとなってしまう。ほかに仕事があって忙しいからみたいなことが多発するのであれば、プロダクトオーナーを別の人にするか、忙しいとかを無視して無理やり引っ張り出すかの対応が必要なのだろう。
第22話 外部チームと、やり方をむきなおる
スクラム・オブ・スクラムの発想は良いと思う。複数チーム間での連携というものを経験したことがないので、この程度の感想しか出てこないが、このような環境に身を置くことになればスクラム・オブ・スクラムのことを思い出して実践してみたい。
第23話 デザイナーと、共通の目標に向かう
「What（何）だけで議論していると折り合いがつかないところも、Why（なぜ）までさかのぼることで、Whatの再定義ができる」これはその通りだと思うが、実践しようとすると難しい。
Why（インセプションデッキの「なぜ我々はここにいるのか」）を共通の認識を持てていれば楽そうではあるが、そうなってくるとインセプションデッキは開発チームだけのものではなくなってきて、（1つのプロダクトを運営している会社では）最終的には会社全体のものとなるのだろうなぁと。
第24話 視座を変えて、突破するための見方を得る
こんな機能があればいいのでは？という前提からスタートして、そこに向けて理屈を積み上げていくという流れになりがちな印象がある。そういったときに、いったん落ち着いて視座を変えて考えるのに、こういったキャンバスが有効なんだろうと思う。
こんな機能を追加してほしいといわれた時に本当にそれが必要なのかといったことをPOと話すときにキャンバスを利用するのがいいんだろうなと思う。
第25話 広さと深さで、プロダクトを見立てる
自分が一線を越える一人目になるには、勇気が必要だよなと思う。だからこそ、スクラムの価値基準の1つに勇気があるのだろう。
第26話 チームで共に越える
また、直接的に声を聞くことはチームメンバー一人ひとりの当事者意識を高めることにつながります。目の前の人から寄せられる困りごとや要望を、自分たちの仕事で解決するかもしれない。その可能性がプロダクトを作っていく際のモチベーションにつながるはずです。
実体験として、これは本当に重要だと感じている。これからもユーザと直接話せる場があるのであれば積極的に参加していきたい。
第27話 越境する開発
「システム開発の現場では、顧客やアーキテクチャ、開発人数や構成など、文脈が全く異なる。つまり、まったく同じ経験を他の人が手に入れることはできない。」これを意識できればアウトプットへのハードルはかなり下がるように思う。
フルリモート下でハンガーフライトの場を作るのは難しそう。ハル研ブログにあるハンガーフライトラジオが面白そう。
この記事が気に入ったらサポートをしてみませんか？