tnkzw.sake

HomeSeriesTagsAbout

『カイゼン・ジャーニー』から学ぶアジャイル開発

友人に勧められ『カイゼン・ジャーニー』という本を読んだら、とても良かったので学びになった部分をまとめます。

https://kaizenjourney.jp/https://kaizenjourney.jp/

アジャイル開発、スクラム、スプリント、レトロスペクティブ...など、多くの用語がさまざまな書籍やブログ記事で語られており、それぞれの説明が少しずつ異なって見えることはないでしょうか。
私は「これは今の自分たちには合わないかも...難しそう」と感じることも多く、アクションに移しにくいことが多々あります。

こうした悩みが解消されそうな本だと感じました。

  • 筆者の経験をもとにしたストーリーを軸にした展開
  • さまざまな用語と具体的な場面が結びつきやすい
  • 巻末のまとめでストーリーの意図がさらに整理される

この辺りの特徴が本質的な理解を助けてくれるおかげです。

以降、個人的に大事に感じた部分をまとめます。

価値と原則

開発組織をチームとして機能させるためのプラクティスはたくさんある。
しかし、それぞれのプラクティスの目的は分かっても全体像が見えにくい。

本書では、全ての根底として使えそうな「価値」と「原則」がまとめてある。

価値

5 つの価値が挙げられている。自分なりの解釈で整理する。

越境

  • プロダクトの開発に関わる人の集団は、さまざまな境界を持っている
    • 開発チーム、営業チームなど社内のグループ境界
    • クライアント、ベンダーという言葉で表すような社外も含めた境界
    • 自分自身と他人という個々人の境界
    • 自身の中にある「自分のロール」とそれ以外という境界
  • 今の延長で成果が見込めない時、これらを超えて成果を上げ、それを以てチームを巻き込んでいく

自分から始める

  • 現状を打破するために、まずは自分が打ち手につながる行動をする
  • 社外イベントに行く、自分なりに取り入れてみる
  • 頼れそうな人に頼る力も重要そう

フィードバック

  • アジャイル開発は FB をもとにカイゼンを行う営み → 取り組みに FB 機構を組み込むことは最重要
  • 自身で試したこと、やったことからの FB 機構
    • タスクボードで自身の日々の仕事を客観視 など
  • 自分と他人で FB を与え合って改善する仕組みを作る
    • スプリントプランニングとレトロスペクティブ
    • ファイブフィンガーのようなチームメンバー自身の主観状態共有 など

※ファイブフィンガーは、自分自身の本音の状態を 1〜5 の段階で評価し、チームで一斉に表明するもの。
「問題ないです」の基準は人ぞれぞれなので、主観の状態も一緒にチームで共有する。(P.106)

リフレーミング

  • ものごとへの解釈を新たにすることで、非連続なカイゼンが見込めたりする
  • リフレーミングの粒度:自分だけ、チーム全体どちらも重要
  • KPT などのフレームワークを用いたふりかえり(過去から現在を正す)
  • 未来のあるべき姿と現状から考えるむきなおり(未来から現在を正す)

巻き込み巻き込まれる

  • ひとりでは越境もリフレーミングも、自分の範囲でしかできない
  • 例えば自身のメンタルモデルに客観的に気づくには、他人の力が必要
  • 動きを起こす人、乗っかる人が揃ってムーブメントは活発になる

原則

原則は 27 個あり、「思考」「チーム」「時間」「プロセス」「場」の 5 つにカテゴライズされている。

最も重要だと感じたもの、興味深いものをまとめる。

思考

  • Why から始めよ
    • サイモン・シネックのゴールデンサークル(TED Talks
    • 人間は「何を」の方が思いつきやすいので、What→How→Why の順に考えてしまいやすい
    • 必ず Why→How→What の順で考える、説明するようにする
  • 自分は何者か
    • 「自分は何をする人なのか」これを考えないと、文句を言うだけ、不満を持っているだけの人になりやすい
    • 常に立ち返るための問いかけを持っておくと良い
    • どこで聞いたか忘れたが、好きでメモっていた次の言葉もいい問いになりそう
      • What do you want to be remembered for?
  • 制約から捉える
    • プロジェクトは常に有限のリソースで最大のリターンを求める制約付き問題
    • 理想状態での目標と制約付き状態での目標は全く異なる
  • 思いやりファースト
    • 人は互いに思いやらないと、簡単に殺伐とした個の集まりになってしまう

チーム

  • 全員で考え抜く、共通認識を持つ
    • 個々の腹落ちは仕事なので無視して、やるべきことを進める...のような思考は NG
    • 不確実性の高い仕事で高い品質、パフォーマンスを出すという条件では「全員」が大事
  • 期待マネジメント
    • XX さんがやると思ってました、が発生する状態は不健全
    • 誰が何をできるのか星取表を作ったり、ドラッカー風エクササイズで互いの期待値を共通認識にする

時間

  • 遅すぎるということはない
    • 「今更やってももう遅い」はない
    • 気付けた時がそれをできる自分(チーム)の最速
  • 見直すことを厭わない、立ち止まって考える
    • 「決めたことだから」と言わず、違和感があったら立ち止まる
    • インセプションデッキなどの成果物は作った時のスナップショットでしかない
    • 状況は進むにつれて変化するので、スナップショットからの差分は生まれうる

プロセス

  • 見える化
    • プロダクトバックログなどスクラムの基本
  • 分割統治
    • 大きな問題を小さく分割し、その全てを解決することで最初の大きな問題を解決する
    • 目安:1 日以上かかるタスクは大きすぎる
    • タスクを大きなまま扱うデメリット
      • 認識のズレが起きやすくなる → 小さな問題ですり合わせ
      • 進んでる感がなくなる → 小さな達成で今日は何をした日か認識する

  • 外に出る
    • いつもの環境にいると視点や考え方が他人でも良くも悪くも揃ってしまいがち
      • 外に出ることで問題解決の視点が広がる
      • ただし、そのままの手法は使えないことが多い
      • しっかりと自身の現場と相手の現場の diff をとって適用方法を考える
    • ユーザーインタビューのような動きも、時にはエンジニア主導でやる
  • 全員同席
    • ユーザーストーリーマッピング、合宿など全員でやってこそ意味がある手法がある

特に参考になったトピック

本書ではストーリーに登場人物たちによる解説、筆者によるコラムなどが織り交ぜられています。
以下は中でも印象に残ったものの要点です。

素朴理論と建設的相互作用(P.52)

自身の経験から得られた知識の集合を『教育心理学概論(新訂版)』では「素朴理論」と呼ぶ。

人は体験していなくても書籍や学校、人との会話から知識を得ることもできる。
しかし、こちらの知識は説明を求められると窮するような場合がある。

このとき、説明のために調べなおしたり、作り直したりして原理原則の知識と経験の間を埋めるように知識を強化できる。

異なる視点からの問いかけを二人以上で行うことで、上記のような異なるレベルの知識をつなげるきっかけを得られる。
こういった相互に依存しながら一緒に考えることで理解が建設的に促進されることを同書で「建設的相互作用」と呼んでいる。

成功循環モデル(P.93)

組織として成果を上げるために、どんな視点で改善に取り組むと良いかの指針を得るためのフレームワーク。

バッドサイクル

  1. 結果の質:成果が上がらない
  2. 関係の質:対立が生じ、押し付けや命令が増える
  3. 思考の質:面白くなく受け身に
  4. 行動の質:自発的・積極的な行動が起きない
  5. 結果の質:さらに成果が上がらない

結果追求の重力が強く、結果の質の向上から始めようとすると、このサイクルになりやすい。

グッドサイクル

  1. 関係の質:お互いに尊重し、一緒に考える
  2. 思考の質:気づきがあり、面白い
  3. 行動の質:自分で考え、自発的に行動する
  4. 結果の質:成果が得られる
  5. 関係の質:信頼関係が高まる

結果は行動から、行動は思考から発生する。
思考はメンバーの関係性に大きく影響を受けるので、まずは関係の質を上げる。

Working Agreement

いきなりチームになれ、良い関係を作れというのも難しい。
最初はチームとしてのお互いの期待値ズレを起こさない(基礎の信頼関係を構築する)ために、最低限の振る舞いの約束事を決めておくことが有効な打ち手となる。

スローガン的なものは解釈が曖昧になりやすいので、具体的で同じ見解になるものにする。
例えば

  • デイリーを欠席する時は、開始時間までに Slack のチームチャネルで連絡する
  • 疑問に思うことはすぐに質問することに価値がある
  • テストのないコードはコミットできない など

チームビルディング三種の神器(P.134)

  • インセプションデッキ:プロジェクトやプロダクトの目的や方法論
  • ドラッカー風エクササイズ:チームメンバーの価値観(チーム内期待すり合わせ
  • 星取表:目的を達成するために必要なスキルと各人の現状

ドラッカー風エクササイズ(P.100)

『アジャイルサムライ』で紹介されている手法。
チームメンバー全員が次の質問に回答を書き込む。

  1. 自分は何が得意なのか
  2. 自分はどうやって貢献するつもりか
  3. 自分が大切に思う価値は何か
  4. チームメンバーは自分にどんな成果を期待していると思うか

批判、否定はしないことを宣言して、安全な状態で行わないと効果がない。
それぞれを出し、相互に確認しあった上で 5 つ目の質問をする。

  1. その期待は合っているか?(A. 完全に合っていない/あまり合っていない/ふつう/だいたい合っている/完全に合っている)

自分の思う期待される成果に対し、メンバーの期待も合っているかの擦り合わせを行う。
これを通じて共通理解を得る。

リーダーズインテグレーション(P.173)

リーダーとメンバー間の信頼感を醸成するためのワークショップ。

  • リーダーについて知っていること
  • リーダーのためにできること

などをリーダー抜きでメンバーが意見を出し合い、それにリーダーが回答してから議論を行う。

具体的な手順

  1. リーダー、メンバー、ファシリテーターが集まる
  2. リーダーが自己紹介、豊富、価値観などを発表(5min)
  3. リーダーが退出
  4. メンバーだけで以下を話し合い、書き出す
    1. リーダーについて知っていること(10min)
    2. リーダーについて知りたいこと(10min)
    3. リーダーに知っておいてほしいこと(10min)
    4. リーダーのためにみんなができること(10min)
  5. メンバーが退出し、リーダーが入室
  6. ファシリテーターがリーダーに議論の流れや行間を共有(10min)※発言者は伏せる
  7. リーダーは書き出されたものを見て、回答を考える(10min)
  8. メンバー入室、リーダーはメンバーに回答する(25min)
  9. 慰労会やフリートークでざっくばらんに雑談する

ファシリテーターは全く中立の人が望ましい。
時間はリーダーとメンバーの関係性などから調整する。

CCPM(Critical Chain Project Management)(P.188)

各タスクには個別のバッファを持たずに抑えめな見積りをし、全体としてのバッファを持ってプロジェクトを管理する方法。
仕事の量は与えられた時間いっぱいまで膨張するというパーキンソンの法則への対処法となる。

バッファの見積もり方法は、例えば次の通り。

  1. 五分五分で達成できる工数で個々のタスクを見積もる
  2. プロジェクトの全タスク工数の合計の半分をバッファとする

ユーザーストーリーマッピング(P.234)

時間の流れに沿ってユーザーの行動を洗い出し、その変遷を可視化するワーク。
マッピングと「ing」で表現するのは、成果物のマップ以上にチーム全員で作ることに意義があるため。

利用シーンをああでもない、こうでもないと話しながら作ることで、共通の解きたい課題認識を作ることができる。

SL 理論(P.251)

リーダーシップのスタイルとメンバー成熟度の関係モデル。
S1→S2→S3→S4 という段階を経て、メンバーは成長していく。
自分のリーダーシップスタイルに固執せず、メンバーの状態を見て柔軟にスタイルを変える。

  • S1(教示的リーダーシップ):具体的に支持し、事細かに監督する
  • S2(説得的リーダーシップ):こちらの考えを説明して、疑問に答える
  • S3(参加的リーダーシップ):考えを合わせて決められるように仕向ける
  • S4(委任的リーダーシップ):仕事の遂行の責任を委ねる

ハンガーフライト(P.255)

新しい場作りを行う活動の一種。
かつて天候が悪くて飛行機を飛ばせない時、パイロットたちは格納庫(Hangar)の片隅で経験談などの雑談をした。
電子制御や航空機の技術の進歩がない時代では、心理状態が伝わる本音の「雑談」こそが貴重な情報源となっていた。

これに倣って、経験を積極的に共有し、他の人の経験を自分のものとして体得するための機会を「ハンガーフライト」と呼ぶ。

話す人と日時を抑え、お祭りのような気持ちで開催するのが良い。

まとめ

変化が激しく、先が読めない現代において価値あるプロダクトを作るチームとなるために、

  • 自分からでも小さく始め、フィードバックを活かしてリフレーミングを有効に行う(アジャイル開発)
  • さまざまな境界を越境し、巻き込み巻き込まれることの重要性を認識する

ことが価値につながっていく。

プロダクト開発は、不確実性が高い目標へ辿り着くプロセスを求める制約付き問題のように捉えられる。
現実的に精度が高い方法で目標に向かうためには、リソースなどの制約を捉え、達成したい目標を起点に現在やることを思考する必要がある。
制約と目標を可視化し、そこへ向かうプロセスを認識するためのプラクティスとしては、インセプションデッキやユーザーストーリーが挙げられる。

また、不確実性は個々人の認識の不一致を招きやすいので、共通認識を持ち、チーム内外との期待値を合わせ続けることも重要になる。
こちらはチームビルディング三種の神器や日々のデイリースクラムなどでチームの認識を揃え、インセプションデッキでチーム内外両輪の期待値を揃えることができる。

不確実であるがゆえに、時間に応じて状況が変化しやすい。
そのため、過去の決定の見直しは必要であり、違和感を感じたら立ち止まることを避けてはいけない。
どんな策も、必要と気付いた時がそれをできる最速のタイミングであり、もう遅いと躊躇する方がもったいない。
KPT を用いたレトロスペクティブやミッションビジョンレベルから見直すむきなおりで、過去・未来の両方の視点から現在位置を補正できる。

共通認識を保つために、タスク(状況)の見える化や大きすぎるタスクの分割は非常に重要になる。
大きなタスクはタスクの範囲、責任が曖昧になりやすいが、小さければ認識を合わせやすくなる。

日々のタスクをこなしているだけでは、停滞や問題に気づけなかったり、解決策が思いつかなかったりする。
必要な時はチーム全員で合宿をしたり、相互理解のためのワーク、認識すり合わせの USM やインセプションデッキの見直しを実施するのが効果的。
また、ハンガーフライトの開催や社外勉強会への参加を通じて、新しい視点やカイゼンの種、他社の経験に基づく知見を得ることで、個々人の成長が促される。