「ふりかえり」は、始める前から始まっている

成長するために、PDCAやふりかえりは大切だと思っている。スクラムであれば、レトロスペクティブというイベントで定期的にふりかえりを行う。

ふりかえりで困る「覚えていない」問題

ただ、ふりかえりをするときに難しいことがある。それは、意外と覚えていないことだ。大きなイベントは覚えていても、どんな状況があって、どんなことを考え、どう判断したのかまでは覚えていない。議事録やチャット、メールなどを探しながら、「そういえば、こんなことがあった」と思い出していくことになる。

だからこそ、1週間など短い単位でふりかえる、というやり方は有用だと思う。記憶が新しいうちにふりかえることができるからだ。でも、プロジェクト全体や1年間といった長いスパンでふりかえることにも意味があると思っている。長い時間軸で見るからこそ、見えてくるものもあるはずだ。

長いスパンだから見えること

たとえば、「スプリントに間に合わない機能があった」とする。

短期のふりかえりでは、「次はスプリントに載せる量を減らそう」「レビューをもう少し早くしよう」といった、その週に見えている範囲での改善になりやすい。

一方で、長いスパンでふりかえると、「そもそも間に合いにくい構造になっていたのではないか」と、もう一段広い視点で見られるようになる。

短期のふりかえりを積み重ねることは大切だが、それだけでは見えにくいこともある。時間軸を広げることで、個々の出来事ではなく、その背景にある構造や前提に気づけることがあると思う。

作業ログには「やったこと」しか残っていない

そして、話を戻すと「覚えていない」問題だ。

作業ログもできる限り残している。ただ、「何をやったか」の羅列になっていて、「どういう状況で」「何を考えて」「なぜその判断をしたのか」までは残っていないことが多い。これでは、あとから出来事を追うことはできても、そのときの判断までふりかえるのは難しい。

そこで、今後作業ログを残すにあたって、どんなフォーマットで残せば、あとからふりかえりやすくなるのかを考えてみた。

作業ログとDecision Logを分けてみる

調べてみると、作業ログとは別に「Decision Log」や「ADR（Architecture Decision Record）」のように、判断そのものを残す方法があることを知った。

共通していたのは、「何をしたか」だけではなく、「なぜそう判断したのか」を残していることだった。でも、すべての作業についてそこまで細かく残そうとすると、大変で続かない。そこで、普段の作業ログは、これまでより少しだけ情報を増やして、「状況/考えたこと・行った行動/気になっていること」を残すことにする。

そして、大きな判断については、別途Decision Logとして残す。こちらには、

• 何を決めたか
• 背景
• 検討した選択肢
• 判断理由
• 前提や仮説
• 判断への自信度

を残す。

すべてを細かく記録するのではなく、普段のログは軽く、大きな判断は少し丁寧に残す。これなら負担を抑えつつ、あとからふりかえるための情報を増やせそうだ。

「ふりかえり」は、始める前から始まっている

ふりかえりというと、プロジェクトが終わったあとや、スプリントの最後にやるものというイメージがある。

でも、良いふりかえりをするためには、そのときになって頑張って思い出すだけでは足りない。どういう状況で、何を考え、どんな前提を置いて判断していたのかを、そのときから少しずつ残しておく必要がある。

行動を改善するだけでなく、「そもそもなぜそうしていたのか」と前提を問い直し、さらに「自分たちはどう学んでいるのか」まで見直していく。これは、トリプルループ学習という考え方にも少し近いのかもしれない。

そう考えると、ふりかえりは、最後に始めるものではない。

あとでより良く学ぶための材料を残すところから、すでにふりかえりは始まっているのだと思う。

専門領域の知識ギャップを埋める方法を知れる動画「 知識の非対称性を越える ― PdMがエキスパートと築く、信頼と対話の『意思決定の技術』」

専門領域の知識ギャップを、エキスパートと信頼を築きながら、どう埋めるのかが解説された動画。

今回の動画 

興味を持ったところ

学ぶだけでなく整理してシェアする

わからないことをエキスパートに質問するだけでなく、学んだ知識を整理して周囲にシェアし、信頼の土台を作る点が良い。

「分からない人が理解できるように言語化・構造化した資料」は、後から入ってくるメンバーにとっても役立つ資料になる。「教わる立場」から「貢献する立場」になれる行動だ。

フェーズごとにKPIを設ける

「フェーズ1: 会話時間、フェーズ2: 整理の数、フェーズ3: ズレの発見数」と理解のフェーズごとにKPIを設定されていた。KPIを設定することは今の自分が何に集中すべきかを自分自身に宣言し、ブレない軸を作るためのセルフコントロールになると思った。

さいごに

わからないことは専門家に聞いて、まとめて、議論する。言葉にすると当然のことだが、その取り組みの詳細に工夫が施されていた。

整理してシェア、ステップごとにKPIを設定は日々の行動に取り入れてみる。

変化に適応する仏教哲学を学べる一冊『ビジネスシーンを生き抜くための仏教思考』

好きなPodcastの超相対性理論やCOTEN RADIOで仏教の話が出てきたことがある。また、アジャイルイベントでも仏教とアジャイルを組み合わせて発表されている人がいる。

という点で仏教に興味を持った。
仏教と言っても法事のようなことではなく、仏教の思想体系で、どうすれば生きやすいのかが整理されている。

ビジネスシーンを生き抜くための仏教思考

「仏教」と聞くと、葬儀や法事、あるいは「欲望をすべて捨ててお経を唱える修行」といったイメージかもしれない。 しかし、本書の著者である松波龍源さんは、仏教を「宗教」ではなく「世界を正しく捉え、より良く生きるためのロジカルな思考のOS（哲学）」として定義します。

開祖であるゴータマ・シッダールタ（釈迦牟尼）が説いた教えをひと言で表すと、何かに思想や生き方を預けることなく、自分で「よく考えなさい」ということ。

第1部は現代のキーワード(VUCA/ポスト資本主義/バズと承認欲求)などを仏教の視点で解説されている。第2部は仏教の思想体系が説明され、第3部では他の宗教との違いが説明されている。

印象に残ったこと

1. 承認欲求は「川に流れる雨の一滴」

「雨のときは一滴だが、川に流れると一滴を特定できない」

「私」という存在は、他者からの反応があって初めて認知される。だからこそ、人は他者と違うことで自分を認知しようとし、承認を求める。 しかし、他者からの評価ばかりを気にしている状態は、「自分の評価を他者基準にしてしまい、自分で自分を評価することを放棄している状態」なのだと著者は指摘する。

仏教には唯心論があり、他者ではなく自分が「世の中をどう見るか」が重要だという考えがある。自分がどう思うかが重要なのだ。

釈迦牟尼でさえ、何かをしても、あるいは何もしなくても、常に誰かから文句を言われていたそう。 他者からの意見や批判には真摯に耳を傾けつつも、「自分の価値を決めるのは、他ならぬ自分自身」という軸を持つことが重要だ。

2. 「コントロール可能」という思い込みが苦しみを生む

私たちが「VUCAの時代（先行きが不透明な時代）」と呼ぶ現代。しかし、著者によれば「最近になって複雑さが高まったわけではない」と言う。一寸先は闇と昔から言っていた。昔から未来はわからない。

「だから、未来を見るな」というわけではなく、コントロール可能という思い込みを見直すことが苦しみを減らす考え方だと言っている。

スクラムも長期間の予測は精度が低いため、予測可能性を最適化してリスクを制御するために、イテレーティブででインクリメンタルなアプローチを採⽤している。

おわりに

読後のマイ・アクション：目の前の仕事を「自分ごと」にして、チームを内側からアップデートする

この本を読み終えて思ったのは、私が日頃から大切にしている「アジャイル」の精神は、まさにこの仏教思考と関係があるかもということです。

アジャイルの本質を「不確実な世界の中で、目の前の事実から学び続け、チームや自分をアップデートしていく哲学」と捉えると、本書の教えとシンクロします。

私がこれから現場で実践していきたい「アジャイル×仏教思考」のアクションは次の3つです。

適応（アジリティ）に全力を注ぐ 「計画を完璧にコントロールする」という思い込みから脱却し、「変化するのがデフォルト」であることを受け入れる。スケジュールとか予算があると、なんとか合わせようという意思が動いてしまうが、予定調和に固執せず、目の前のリアルな状況変化に素早く、しなやかに適応したい。

さいごに

仏教は「何かを信じなさい」という教えではなく、「世の中変わり続けるんだから、自分で考えなさい」という教えなので、働く考え方を知るうえで参考になる部分がある。

学びが広がる場を作りたいと思った『 スクラムフェスから学んだ「コミュニティとしてのカンファレンス」のつくり方 』

Muturelism Conferenceはナレッジのシェアではなく、問いを大切にしている他とは少し違うカンファレンスだ。そのConferenceの歴史と作り方が学べるセッションだった。

今回の動画 

興味を持ったところ

社内でリベラルアーツの大切さを語り、コミュニティを作ろうとしている人がいる。考えているだけでなく、実際に行動し、勉強会を開催し、仲間を集め行動している。

その熱意と行動力にとても尊敬する。

リーダーシップの力

その方からリーダーシップをとても感じる。誰かから期待されているわけでもない。自分で必要だと思い、行動しているのだ。それが素晴らし、熱量がある。周りを巻き込むのは熱量と引っ張る力だと思う。環境が出来上がるのを待つのではなく、環境を作ることが大切だ。

説明するとＷＨＹが見つかる

本セッションでも何でやりたいのかを繰り返し説明したと話されていた。固まっていなくてもビジョンだけ説明していると自分のＷＨＹが固まってきたと話されていた。

最近、よく聞くpodcast『ぼくらの戦略論』でも戦略はＷＨＹが大切だと語られる。そのＷＨＹは固まるまで動かないのではなくて、動きながら見つけるのが大切なのだ。

再燃

この「動きながらWHYを見つける」というプロセスと、環境を自らこじ開けていく熱量から、改めていろんなことを学びたいと思った。

アジャイルについて熱狂的になっていたことを思うと、今は少し落ち着ていると思う。かつて、アジャイルの勉強会で登壇された方が楽しく働いている姿を見てあこがれた。仕事をこんな風に楽しくする環境があるんだと思った。

しかし、ビジネスの現実は 熱意だけではなかなか進められない。アジャイルはあくまでのビジネスを成功させるための手段であり、目的ではない。手段が目的化してはならないのだと、ある種の割り切りを覚えた。アジャイル系の勉強会でもそのように指摘された。それは成熟かもしれないが、あの頃の熱量はどこかに置いてきてしまった。

だからこそ、社内でリベラルアーツのコミュニティを立ち上げ、熱量を持って突き進むその方の姿が、輝いて見えるのだ。

たとえ不完全でも、動きながら自分の「WHY」を語り続け、熱量を持って環境を自ら作っていくこと。そのカッコよさに改めて敬意を表しつつ、私ももう一度、自分のいる場所で、自分なりの熱量を持って動き出してみたいと思う。

あなたの才能を目覚めさせる一冊『天才になれなかった全ての人へ』

『左ききのエレン』というマンガが好きだ。

広告代理店で働く若手デザイナー・朝倉光一と、圧倒的な才能を持つ山岸エレンを中心に描かれる、クリエイターたちの物語である。

そのマンガの1ページ目は「天才になれなかった全ての人へ」から始まる。

alu.jp

俺たちはまだ天才になれるんだと思ってほしいと思って著者はマンガを書いたそうだ。そして、今回読んだ本はその著者が書いた才能論となる。

天才になれなかった全ての人へ 自分だけの武器が見つかる才能論

この本では、「天才」を特別な人だけが持つ才能としてではなく、“天才状態”として定義している。天才状態とは、自分の能力を100％発揮できていて、その能力が発揮される環境にいて、成果につながっている状態のことだ。

つまり、天才とは生まれつき決まっているものではない。
自分の特性を理解し、それが活きる場所を見つけ、そこで全力を出せている状態なのだと思う。

本気でどれだけやれるか

本書の中で、印象に残ったのが「1周を2万回繰り返せ」という話だ。著者がキャッチコピーを2万件作ったエピソードが紹介されている。そこまでやることで、はじめて自分の特性や限界が見えてくるという話だった。

この部分を読んで、改めて思った。

結局、まずは本気でどれだけやれるかが大事なのだと思う。

もちろん、人にはそれぞれ向き不向きがある。最初から得意なこともあれば、どれだけ頑張っても人より苦手なこともある。ただ、「努力できること」や「本気を出せること」も、一つの特性だと思う。そして、この特性は後天的に伸ばせる部分が大きいのではないかと思っている。

たとえば、足の速さや身長のように、先天的な要素が大きいものもある。
しかし、時間の使い方や、どれだけ継続するかは、自分でコントロールできる余地が大きい。

1日は誰にとっても24時間しかない。
その時間を何に使うか。
どこに集中するか。
どれだけ繰り返すか。

そこには、自分の意思が入り込む余地がある。

社会人は、努力が成果に反映されやすい

私の経験上、特に社会人は、努力が成長につながりやすい。学生の頃は、国語、数学、理科、社会、英語のように、みんながある程度同じ科目で競っていた。だから、得意不得意や順位が見えやすかった。

しかし、社会人になると必要なスキルは一気に細分化される。

企画ができる人。
開発ができる人。
データ分析ができる人。
文章が書ける人。
人を巻き込める人。
現場感を持って判断できる人。

しかも、一つのスキルだけでなく、複数のスキルを組み合わせられる人は意外と少ない。たとえば、Aができる。さらにBもできる。そのうえで、Cの視点も持っている。そうなるだけで、社内ではかなり希少な存在になれる。

圧倒的な天才でなくてもいい。
一つひとつのスキルを積み上げていくことで、自分だけの武器は作れる。

さいごに

大事なのは、自分には才能がないと決めつけることではない。自分の特性を知り、それが活きる環境を探し、そこで本気でやり切ることだ。

詰め込み型から「学び方を学ぶ」研修を知る動画『アジャイルなマインドセットを「取り戻す」新人研修づくり』

アジャイルを学んでいると、チームや組織を成長させたいと思う。強くしたいと思う。そのためには、採用と育成が重要ということで、興味関心がわいている。

ということで、今回の動画だ。

今回の動画

スライド

この動画はアジャイルなマインドセットを育むための新たな新人研修の取り組みを解説している。従来の先生が生徒に教えるような研修では、新人が本来持つ自発的に学ぶ姿勢を奪ってしまう。本動画では配属後も自ら進んで学び続け、実務でも活躍できるエンジニアを育てる研修について語られていた。

興味を持った点

研修が「受け身な姿勢」をつくっている

もともと「成長したい」と前のめりだった人も、入社後の研修の詰め込み型の学習により、「必要なことは教えてもらえる」と受け身な姿勢を作っているではないか。そのため、「学び方を学んでいただく」という話があった。

入社直後は「成長したい」と前のめりだったはずの新人が、詰め込み型の研修を経ることで「必要なことは教えてもらえる」という受け身な姿勢に変わってしまう――。もし、良かれと思って行う研修が受動的な人間を生み出しているのだとしたら、大問題だ。

近年『働くとなぜ本が読めなくなるのか』という書籍が話題になったが、大人が学ばなくなる一因が、実は「社会人一歩目の研修」にあるのだとしたら、悲しすぎる。

特にAI時代においては、特定のプログラミング言語を「知っている・書ける」というスキルの価値は相対的に下がっている。これからの時代に本当に必要なのは、既存の知識を詰め込むことではなく、未知の状況に対応するための「学び方を学ぶ」こと。研修こそ、教える場から「自ら学ぶ姿勢を取り戻す場」へとシフトすべきかもしれない。

どういうエンジニアになって欲しいのか、理想の組織から考える

動画には出てこないが、採用や育成を考えるあたって、それぞれの目的にとなりうる「理想の組織(チーム)」を定義した方がよいと思っている。

採用や育成を議論するとき、つい「どんなカリキュラムが良いか」という手段に目を奪われがちだ。しかし本当に必要なのは、その先にある「理想の組織（チーム）」を定義することだと思う。

すべては、そこからの逆算であるべき。極論、指示通りに動く「受け身なエンジニア」で構成された組織を目指すのであれば、詰め込み型研修で受け身な姿勢が育つことは、むしろ大成功と言える。

成長のベクトルは無数にある。自己管理されたチームを目指すのか、統制型を求めるのか。目指す組織像がはっきりしていないまま育成を議論しても、それぞれが自論をぶつけ合うだけの空中戦に終わってしまう。まず、「どんな組織を共につくりたいのか」という根本的な問いも向き合うべきだ。

価値ある構造を作る力について考える動画『 アーキテクチャレベルで考える開発生産性』

開発生産性について考えている。直近だと以下のブログでも考えた。

生産性の理解が深まる動画 『「LeanとDevOpsの科学」をきちんと解読する』 - はんなりと、ゆるやかに

その後も動画を見たり、ブログを読んだりしながら考えていた。その中で感じたのは、開発生産性を「早く作ること」だけで捉えていては不十分だということだ。

もちろん、早く作れることは重要だ。リードタイムを短くすることも、デプロイ頻度を上げることも、テストやリリースを自動化することも大切だと思う。

ただ、それだけでは足りない。

いくら早く作れても、作ったものが顧客のニーズを満たしていなければ弱い。さらに、価値のある機能を見つけられたとしても、それを継続的に変更し、育て続けられる構造になっていなければ、長期的な開発生産性は上がらない。

開発生産性を考えるときには、開発プロセス、アーキテクチャ、顧客価値、事業成果のつながりを意識する必要があるのだと思った。

点の改善だけでは部分最適になる

何かを改善するために、個別の施策を打つこと自体は良いことだと思う。

たとえば、CIを高速化する。テストを自動化する。レビューの待ち時間を減らす。デプロイを簡単にする。こうした改善は、開発の流れを良くするうえで重要だ。

ただし、それが部分最適にならないようには気をつけたい。

たとえば、開発チームがとても早く機能を作れるようになったとしても、その機能が顧客価値や事業成果につながっていなければ、組織全体として生産性が高まったとは言いづらい。

局所的な改善が、最終的にどの価値につながっているのかを見る必要がある。

開発生産性は、単に開発チームの作業効率だけで決まるものではない。何を作るか、それをどう届けるか、届けたものが顧客にとって価値を持つか、さらにその価値ある領域を継続的に変更できるか。そうした一連の流れで考える必要がある。

今回の動画

アーキテクチャレベルで考える開発生産性 / architecture-and-productivity - Speaker Deck

開発生産性を高めるには、開発プロセスや自動化だけでなく「アーキテクチャ設計」が不可欠。収益のベースとなる「競争優位性のある機能」を見極め、そこに開発リソースを集中させることが重要。さらに、その重要な機能の変更容易性を高めるための戦略的設計として、ドメイン駆動設計（DDD）を活用する方法が解説されている。価値のあるドメインを構造化し、素早く成長させ続けられる構造を設計することこそが、アジャイル開発および開発生産性向上につながる。

顧客ニーズを満たすこともソフトウェア品質である

印象に残ったのは、ソフトウェア品質の話だ。知らなかったのだが、ソフトウェアの品質には「機能性」という観点があり、顧客ニーズを満たせているかどうかも品質に含まれる。これは自分にとって大きな気づきだった。

いかに早く、いかに低コストで機能を作れたとしても、その機能が顧客ニーズを満たしていなければ、品質としては片手落ちになる。

これまで開発生産性というと、どうしても「どれだけ早く作れるか」「どれだけ安定してリリースできるか」に目が向きやすかった。もちろんそれらは重要だが、作ったものが顧客にとって本当に必要なものだったかという観点も、同じくらい重要だと思った。

開発生産性は、価値ある変更を継続する力

今回の動画を見て、開発生産性に対する捉え方が少し変わった。開発生産性を高めるとは、単に開発速度を上げることではない。価値ある領域を見極め、そこに集中し、その領域を継続的に変更できる構造を作ることだと思う。

そのためには、開発プロセスの改善だけでなく、プロダクト戦略やアーキテクチャ設計も重要になる。どれだけ開発フローを改善しても、価値につながらないものを早く作っているだけでは意味が弱い。逆に、価値ある領域を見極められていても、変更しづらい構造になっていれば、継続的に価値を届けることは難しくなる。

開発生産性とは、「早く作る力」ではなく、「顧客価値につながる変更を継続的に届ける力」なのだと思った。