2023年に読んだ本をふりかえり
今年読んだ本の中から印象に残った本をふりかえります。
スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する
Scrum@Scaleの基礎とストーリーで実際の仕事の流れを知ることができました。 マネージャーとして日々の業務の中でプロジェクトマネージャー的視点とエンジニアリングマネージャー視点の両面でマネジメントすることが必要であり、複数のチームの成果を最大にするために良き仕組みのヒントをもらえました。
特に4章のEATとEMSが参考になりました。 EATは問題の解決が可能な権限を有し、プロセスに対する継続的な改善を担う。 EMSは組織全体の戦略ビジョンを策定し、組織全体に浸透させる。 自分の組織にもそれぞれに該当するような官僚組織はありますが、両方の役割を担っているため、EMS側面が強くなり、EAT側の改善サイクルが回りにくい状態かなと感じました。 また、変えても良い・変えられることをメンバーが認識していないとアイデアも出にくい気がします。 その辺りに働きかけていこうと思いました。
頭のいい人が話す前に考えていること
自分の言葉で話すこと、言わなくていいことを言わないことを身につけたくて読みました。
本の最初に全体のまとめが把握できるのには驚きました。読み返さなくて良い本を目指したとの通り、チートシートを見直すだけで行動を振り返ることができます。
知性と信頼をもたらす7つの黄金法則は、話すと言う性質からとにかく相手を中心とした法則でした。 自分が覚えたことをすぐに伝えてしまうところがあるので使い所を間違えないようにしたいと思います。
とにかく仕組み化――人の上に立ち続けるための思考法
三部作を一気に読みました。 購入順序は、リーダーの仮面→とにかく仕組み化→数値化の鬼でした。どこから読んでも問題ないですが、数値化の鬼→リーダーの仮面→とにかく仕組み化の順で読むと具体から抽象へと役割が上がっていく変化に沿って読めるので読みやすいかと思います。
今まで読んできた組織論やアジャイル関連の本とはパッと読む限り全く逆の内容に感じましたが、対極ではなくコアな部分は同じことを言っているのでは?と感じました。
もっと早く本書を知っていれば、認知負荷を減らし、無駄な不安に左右されることもなかったのかもしれません。深い腹落ちは遅れてやってくると言うのはその通りだと思います。
一見ドライで冷たい考えに感じる本書ですが、汎用的で実用的な思考と仕組みがあるので大変参考になりました。その上でチームのあり方や関係性について最良は何かを考え続けていきたいと思います。
解像度を上げる――曖昧な思考を明晰にする「深さ・広さ・構造・時間」の4視点と行動法
チームからの報告が不足して都度質問をすることに不満があったりしたので、言語化をしっかりしようと目標を立てました。
しかし、チームやメンバーがそれをやれるようになるには、どうやれば物事に対して解像度が上がり良い言語化ができるかを示す必要があります。自分自身もそれ自体をうまく言語化したくまさに今読んでいる途中です。
読んで身についた気分で終わらないために
エッセンスは誰かのために使ってこそ血肉になっていくと思います。しっかり実践で使ったり、自分の言葉にして発していきたいです。また、読んだ本で参考にされている本も定期的に読み返したりしたいと思いました。
今年は、目標管理についてのガイドを組織に共有しました。以下を参考にアウトプットでき、別のマネージャーからも感謝の言葉をもらえたのでよかったです。
来年もこまめに自分の言葉でアウトプットすることを頑張っていこうと思います。
2022年のふりかえり
一年のふりかえりだけは残しておこうと思い、一週間前くらいから過去の記憶や記録を漁って記載しています。
1月:マネージャーに俺はなる!
マネージャーという役職に就きました。 上司(直属ではなくその上の層)から「一緒に組織を良くしてほしい」と言ってもらえたのが、自分の向かいたいキャリアパスにあったため、割と二つ返事で「やります」と回答しましたし、「向いてなかったり、悩んだらその時に考えます」と伝えもしました。
ちょうどこの時には「チームトポロジー」を読んで、勉強会に参加したり。
チームとマネージャーのインタラクションはどうしようかなと考えていました。
2月~4月:最悪の中の最善を希求したい
🔥案件にアサインされ、障害対応チームのマネジメントを任されました。前から噂には聞いていたので、色々とやるせない気持ちになっていました。
中に入ってみると組織の成功循環モデルでいうところの悪循環にガッツリはまり込んでいて、メンバーのモチベーションはダダ下がり。顧客本陣の近くにいるテストチーム・マネジメントチームと障害対応チームのコミュニケーションを整理していくところから取り掛かりました。
- ダイレクトチャット禁止。
- 電話で直接指示するの禁止。
- タスクは一元管理して全部みえる化すること。
- オープンなチャネルで随時情報共有すること。
- チームにタスクを投入すること
実際には最後の取り組みはうまくいかなかったです。個人への依存が激しすぎて好転するのに時間がかかりすぎるため目をつむってしまいました。あまりの酷さに感情的になってしまって、マネジメントチームメンバーに強い言葉を使ったところは反省です。
1ヶ月経過した頃に最初にやった取り組みがやっと浸透して効果が現れてきた印象。ただ、正攻法にこだわって時間がかかってしまったかも、もっと上手く情報を共有する仕組みは作れたかも、と心残りはあります。とにかく情報を整理して、割り振って、フォローして、問題を見つけては解決して、できない時にはエスカレーションしての繰り返しでした。
状況が好転するかしないかという道半ばでまた別の案件にアサインされることに。実際にはかなりしんどい状況だったので助かったという気持ちのほうが強かったです。
5月~7月:後悔はないですよ 反省は死ぬほどあるけど
新規案件の要件定義を担当することに。プロジェクトリーダー1人のところに自分ともう1人がエンジニア枠で参加しました。あれ、マネージャーの役割はどこいった?感が否めませんが、マネージャーは隙間を埋めることも役割ということですかね。
業務フローは整理済みということであったのですが、曖昧なところが散見されるので業務部門の方にヒアリング。画面モックアップと業務フローとを合わせてユースケースを明確にしていきました。RDRAの考えに基づいてユーザとシステムの境界を明確にすると日々新しい発見があり楽しい。感謝もされるとなお嬉しい。
業務フローとシステムの境界を整理し、ユーザーヒアリングでユースケースを特定していたら不要な業務が見つかって「何でこれやってたんだっけ?」「これやらなくて問題ないね」となって感謝された。
— m-ono (@msts_0w0) 2022年6月7日
こーゆーのがあるから要件定義は面白い。
7月頃からアーキテクチャ検討を担当。ある程度制約があって、フロントエンドが Vue.js+TypeScript で、バックエンドが Spring。バッチ系はSpring Batch。
フロントエンド周りは初めてのことが多くてめっちゃ学びが多かったです。アトミックデザインも参考にして学習コストも考えて構造を決める。Vue2とVue3で色々変わってきているのにやっぱり2の方の情報が多くて困りました。状態管理周りは特にわからなくて後続のメンバーへ宿題に。
バックエンドは、三層+ドメイン層にしてロジックを分離しました。この辺は今までの経験からスムーズにできたけど慣れてないメンバーに教えるところに時間がかかってしまいました。まだまだ手の内化できていないので改善したいです。
チーム全体で改善したいのは、APIを中心とした開発知識の浸透と効率化。画面機能として一体に考えすぎず、フロントエンドはAPIの制御やデータ状態管理、バックエンドはAPIインターフェース定義と分離して進めた方が良かった気がしています。このあたりもチームによって習熟度が異なったり、案件によって異なったりするので、ナレッジマネジメントによってうまくノウハウを伝えていきたい。
最近読んだこの記事が素晴らしかったので、年末年始に読み込んで活かしていきたいと思います。
8月~9月:大事なことは知るだけではダメなんだ… 時間をかけ魂に刻み込まねば…
要件定義した案件も軌道に乗ってきたので設計レビューしたりしながらチームに任せて徐々にフェードアウト。その他にはITサービスマネジメント・ITILを勉強したり、顧客向け提案書作成したり。「チームで作り込む」タスクから「答えがないものに対して個人で挑む」タスクに切り替わったため、しばらくはパフォーマンスが上がらず苦戦しました。
たたき台を上司に提示して見てもらってからはスムーズなったので、早くたたき台を作ることを意識しておきたいです。しかし、あれだけメンバーには「早目にたたき台を見せてね」と伝えておきながら、いざ自分のこととなるとうまくできないのは何ででしょう。。。
10月~12月:マネージャーになりたいなら、頭 作り替えろ
10月から本格的にラインマネジメント業務をやっていくために、「エンジニアリングマネージャーのしごと」を読みました。
メンバーには1on1を実施することを伝えて、予定を組みました。各案件の都合もあるのでどちらかというと若手メンバーから実施することになり、最終的にリーダーメンバーについては実施した人・できなかった人がはっきり分かれてしまいました。やはり、年上の部下になるメンバーにはどうしても気後れしてしまう傾向がありそうです。また、周りからも難しい人というイメージがある人も同じ傾向があるので、今年度中に解決に向けて動きたいです。
一番効果を実感できたのが「2章 まず自分を管理しよう」でした。「カレンダー」「ToDoリスト」「メール受信箱」「情報を記録する場所」の4つのツールを活用したところ、頭の中にとどめる情報が最小化され、毎日を規律に従って迷いなく動けるようになってきました。ルーチンワークに苦手意識がありましたが、ToDoリストのリマインドによってリズムよく仕事ができています。実は年始に手帳を使ったスケジュール管理を始めたのですが、こちらに移行してから手帳は「情報を記録する場所」のみになりました。ただ、アナログはアナログで素早く確認・ふりかえりができるため今後も続けていきたいと思います。特に、活動の分類(情報収集・意思決定・ナッジング・ロールモデル)のふりかえりがあまりできていなかったので、記録として残すようにしたいです。
また、営業メンバーと一緒に顧客を訪問する機会も増え、そこで記録した情報をデジタルでも残して関係者にメールすることを続けていた結果、上司や営業メンバーからも感謝され、仕組み化され、情報連携がスムーズになりました。情報を開示する範囲やタイミングについては、「12章 情報の証券取引所」をもう一度読んでおこうと思います。
本格的にマネージャー業務を行うようになって、やめた(やめざるを得なかった)ことは「ソースコードを見ること」でした。個々のチームを知ることはもちろん必要で、介入の度合いは状況に応じて変化しますが、一つ一つの内容までを見ることはなくなりました。その代わり品質メトリクスやチームのメトリクスに対して意見するようにしています。
最後に
マネージャーになって一番の変化は視点・視野・視座が明らかに変わったことです。今まで開発チームを率いてプロジェクトマネジメントをしていたときも気をつけてはいましたが、1アカウント2~3チームをマネジメントすることと、複数アカウント複数チームをマネジメントすることは大きな違いでした。説明責任・成果責任も加わるので、意思決定することに以前よりも大きな不安がつきまといます。不安に対してはきちんと向き合って、不確実なこと、曖昧なこと、知らないことを一つずつ具体的なものに置き換えて行く必要があります。
仕事納めの次の日に呪術廻戦0を視聴したのですが、禪院真希のセリフが印象的で痺れました。
じゃあ祓え 呪いを祓って祓って祓いまくれ‼ 自信も他人もその後からついてくんだよ‼
チームメンバーにロールモデルを示せるよう行動し続けることを来年の目標にします。
チームビルディング勉強会 「ちいとぽ」感想会! に参加しました。
team-building-study-group.connpass.com
参加のきっかけ
感想を共有し合う会があるらしいhttps://t.co/dYS6ad7t8D
— kuro (@kurogi_s) 2021年12月3日
kuroさんに紹介されて、本を読み切るモチベーションにもなると思い参加を決めました。
会の流れ
- 自己紹介
- OST(30分×2回)
- チェックアウト
miroを使って情報を共有しながら進めました。 事前にmiroにアクセスしたのですが、個人アカウント未取得でしたのでちょっと焦りました。 よくよく考えるとほとんどmiro使ったことがなかったので、チュートリアルやって慣れておきたいです。
また、オフラインでのOSTはやったことがありましたが、オンラインでは実は初めてでした。色々、初めてづくしだったのですが言い出すタイミングを逃してしまいました。
自己紹介
今回、自分はマネージャーの役職についたこともあり、組織設計・組織マネジメントの学習の意味で本を読みました。 プロダクト開発をする組織ではないため、本のコンテキストと一致していないことが不安でしたが、参加者の方々も様々な立場でチームや組織のあり方に興味を持たれているのだなと安心しました。
「認知負荷について」
認知負荷の解像度を上げたい、認知負荷という概念とは?、具体的な認知負荷はどういうもの?という意見が重なりました。 それだけ、印象深いキーワードなのだなと知ることができました。
認知負荷という概念は教育分野から生まれたもので、関連する論文を読んでも、本に書いてある認知負荷とはまた異なるように思うという意見がありました。認知負荷が低すぎても学習効果が低いそうです。
教育分野の認知負荷には、学習内容に伴う負荷・学習に関係ない余計な負荷・学習に役立つ適切な負荷の3つがあるそうです。3つ目がただ下げるだけでは駄目な負荷となります。
学習内容に伴う負荷は、学習の分野(数学とか歴史とか)ごとに負荷が異なるのだそうです。ここが、ストリームアラインドチームで分割し、より複雑な分野領域はコンプリケイテッド・サブシステムチームが担当する。学習に役立つ適切な負荷はイネイブリングチームが調整するのではと考えコメントしました。それに応じて、学習に関係ない余計な負荷はスクラムで言うスクラムマスターやプラットフォームチームが負荷を下げる・無くすように調整するという意見をいただきました。
他にも、制限しない方が良い認知負荷があるのでは?という意見や、認知負荷が高い状態を検知するにはどうしたら良いか?という問いが出ましたが、なかなか腑に落ちる答えは出ず時間切れになりました。
「チームAPIについて」
チームAPIについてどう思うか?というテーマで対話しました。
- Redmineチケットでコミュニケーションが規定されているのでそれに従ってくださいと言われて、わかるけど冷たいなと感じたことがある。
- チーム間のドラッカー風エクササイズという感覚。それぞれのチームが自分のチームの思いを表明するのに良さそう。
- コミュニケーションは増やせば良い、とりあえず会話しようという認識だったが、そればかりではないことに気づけた。
- レポートラインやロールを意識してコミュニケーションや報告資料を規定し、余計な介入を減らすことをやっていた。これもチームAPIと言えるのではないか。
- チームAPIテンプレートがあるよ。
チームのあり方や働き方など大切にしているもの、何をやっているかを表明してチーム間のインタラクションを円滑にするものとコミュニケーションそのものの規定の2つで意見が出ていました。自分は後者の印象が強くあったので、前者の価値に気づかせてもらえて良かったと思います。
また、チームAPIによっては感情にも影響することが意見に上がっていて、今ふりかえると、こういうのもチームAPIの抱える問題や認知負荷が高いシグナルなのかな?と考えています。
チェックアウト
チェックアウトとしてふりかえりを行いました。
総じて、本を読んでモヤモヤしたところを共有できて良かったという意見が多かったと思います。自分もモヤモヤはあるんですが言語化できていなかったなと感じました。何がモヤモヤするのか、何を知りたいのかを書き出しながら本の感想も書いてみたいと思います。
また、別のセッションでは、節(PARTかな?)ごとに感想戦を実施しており、ふりかえりで章(Chapterかな?)ごとにやっても良さそうという意見がありました。理解を深めるのに良さそうなので機会があれば参加したいと思っています。
全体の感想
人によって目の付け所が違っていて気づかせてもらえたり、同じ感想を持っていることを聞けて安心したり、対話によって学びが深まる体験ができて良かったです。
チームAPIについてメンバーにやってみようよと言いたくなりました。いま、目下の仕事に大変なチームもあるのでメンバーの認知負荷を高めすぎないように気をつけながら整えていきたいと思います。
2021年ふりかえり
COVID-19が猛威をふるい始めて2年が経過しようとしています。今年の年末年始も家でゆっくり過ごすことにしました。 ブログを書くという習慣化ができずにいます。ホメオスタシス頑張りすぎですね。1年に1回は書いているので次は3ヶ月に1回を目指すのが良いでしょうか? 今年はデジタルではなくアナログのメモを残すことを常に行っていましたので、その中からブログに転記するのが良いかもしれないと考えながら1年をふりかえります。
前年の目標に対するふりかえり
- 設計・パタンについて学習を継続
- 役割が変わってきて直接ソフトウェア設計を行うよりもチームを中心にマネジメントするようになった。
- パタン・ランゲージについては学習できていない。まずは読むところから。
- チーム・組織がうまくいく仕組みを考えて実践する
- 達成すべき目標とゴールが先にあってチームでゴールを達成すると考えたい。
- ソフトウェアの設計からチーム・組織の設計に軸をずらすことを意識した。
- 「ゆとり」を組み込む。心に余裕を持つ。
- 自身の役割や環境の変化が激しいと「ゆとり」を組み込むの難しい。
- 自分が行うことのウェイトを周りに宣言することが大事。
- 仕事とプライベートの境界も上手くつけないと。
やったこと
- 1月~3月
- 4月~6月
- お仕事の新規開拓。
「任務は遂行する」「部下も守る」
「両方」やらなくっちゃあならないってのが「幹部」のつらいところだな
覚悟はいいか?オレはできてる
- Scrum Fest Osaka 2021に参加。「場」に参加することで熱量をもらえる。モチベーション上がる。
- お仕事の新規開拓。
- 7月~9月
- 複数プロジェクトのマネジメントを行う。メンバーに委譲しないとあかんやつ。
- 1on1に力を入れていたことの成果が出始めて嬉しかった。飛躍的に伸びたメンバーが3人ほど。
- 第2回1on1カンファレンスに参加。めっちゃ勉強になった。ブログ書こうとして書けなかった。
- 熱量高めの良い後輩が転職してしまって残念。 - 左利きのエレンを一気読み。面白い。
- 10月~12月
- お仕事の新規開拓に失敗。リスクを取らないことも時として悪手だった。0→1の難しさを痛感する。
- とか言ってたら、マイナスをプラスに変えるようにと期待されてプロジェクト支援が舞い込んでくる。年末にこの手のやつ多くない?
- 顧客に対してどんなふうに貢献するか、どう提案すれば喜んでもらえるか悩み中。
読書
積んでいるものは記載せず、読んだものを記載します。 ザクッと見直すと「チーム」「組織」「リーダー」「マネジャー」という単語が多い本ばっかり。ジャスト・イン・タイムで勉強できているから良し。 この中に漫画を入れてしまうと収集がつかなくなるので来年に回そう。
コーチとしてのあり方を教えてくれる本。人にフォーカスし、チーム・ファーストの考え方でチームを最適化すれば問題は解決するくだりが印象に残った。
バズワードとなった「心理的安全性」を分解し、どのように変革を成し遂げ「心理的安全性」をつくるかを書いた本。個人的には、何度か読み返さないと消化しきれなかった。図やモデルを書いたほうが理解しやすいかも。
ふりかえり決定版。ふりかえりの基本やなぜふりかえり行うかを知ることができ、導入から熟達までをフォローしてくれる。チームにふりかえりを導入して3年。自分たちで行ってきたふりかえりをふりかえって欲しいとメンバーに勧めたら、2名のメンバーに購入してもらえた1冊。
チームが機能するために「チーミング」を行う上で必要な(スモール)リーダーシップのあり方、認知を変えるフレーミングが印象に残った。2014年に発行されているのにいまだ色褪せない本。
休むの下手なので読んでみた。正直なところあまり頭に残っていないので定期的に読み直そう。
「スウィッチ化」については、認知を変えると行動が変わるとしていて、そんな考え方もあるのかーと読んだ。7章の「示唆を出せ」のところについては、1on1でメンバーにしたり顔で話をしている。できていない人が結構いるよねと共感した。
組織が抱える慢性疾患へのアプローチとして「対話」のあり方を説き、「2on2」という手法を通して教えてくれる本。まだ、2on2は実践できていないので来年は実践したいと思う。
「仕事ができる」=「成果を出せる」=「センスがある」という点から「仕事ができるとはどういうことか」というWHATについて対話形式で語られる本。HOWについては記載が無いので、自ら考え、示唆を出し、実践あるのみという内容でした。読んだ次の日にメンバーに「仕事ができるとはスキルじゃなくてセンス」って語ったら困惑された。そりゃそうだ。
才能は開花させるもの、センスは磨くもの
及川さんもそう言っている。
コンサル一年目としているけど、エンジニアにとってもベーシックスキルだと思う。1on1の対象としているメンバーに必読としたいくらい論点が明確で、今までの経験や上司からの指摘と照らし合わせても必須スキルと考えている。
今は、イヌから脱却気味のネコちゃんだけど、ここからライオンになるかトラになるか。
今、まさに読んでる途中。今年の個人的ベスト本。 4つのチームタイプと3つのインタラクションを駆使して、プロダクトと組織のアーキテクチャを揃えて成果を出すための本。ただ、自分のコンテキストがプロダクト志向に沿わないので、そのあたりも前提にして上手く適応していきたいと考えている。
わかったこと
- 設計が好きである
- ソフトウェアの設計も好きであるが、役割はマネジメント中心に移行。
- チームの設計、組織の設計に軸をずらして今の役割でのやりがいを見いだせそう。
- チームモデルとチーム間のインタラクションを整えたい。
- 役割や行動のフレーミングが大事
- 人は認知しているフレームの枠を超えて行動することはできない。
- これで良いとするコンフォートゾーンからの脱却は難しい。
- リーダーとして行うことはメンバーをリフレーミングし成長させること。
- 1on1ミーティングの効果を実感
- 認知されている、フォローしてもらえると思っているメンバーの行動は変わる。
- というか、今までまともにマネジメントされていない人多すぎ問題。
- 必要なのは適切なゴール設定とフィードバック。
次やること
新しい役割での1年になりそう。期待半分・不安半分。今まで培ってきた経験・スキル・センスを総動員して貢献したいなー。
- マネージャーとしての成果を出す
- チーム・組織設計について学習と実践
- 1on1ミーティングを継続し、メンバーのセルフ・エフィカシー向上
- アジャイルワーキンググループの活動推進
Scrum Fest Osaka 2021 基調講演を聞いて
今年もSFOに参加しています。 1日目は楽天の椎葉さんによる基調講演「誰も嫌な思いをしない変化」を聴きました。
講演メモ
エンジニアのスキルアップのためのチーム支援
あるチームのエンジニアのスキルアップのために支援を依頼された。
チームを観察して、「いいチームですね」という感想をマネージャーに伝えた。
サービスを良くしたいと改善意欲がある。
気持ちや行動がきちんと噛み合う仕組みがあればうまくいくと考えた。
1年間実践をして、変化して、従業員満足度も上がった。
誰も嫌な思いをしない変化
支援にあたって「誰も嫌な思いをしない」ことをミッションとした。
スクラムって難しい。小学生の方が上手くできるかもしれない。
スクラムは問題を解決してくれるわけではなく、現状(問題・課題)を見えるようにするだけ。
変化を起こすことは最適化されたこれまでのやり方に向き合う必要がある。現状をうまくいくように変化させるところに嫌な思いが発生するのではと思う。
人の行動を変えていこうとアプローチしても一進一退。椎葉さん自身「なんでわかってくれないんだろう」とか「この会社でスクラムやるのは無理だ」と思っていた。
でも変われた。「そっかー」と思えるようになった。
相手に期待をしなくなった
期待に届かないときのイラッとすることが、教えてあげるという気持ちを消してしまう。
期待することが、「残念な気持ちになる」「相手に問題があると考えてしまう」
相手ができることを見るようになった。
相手の気持を考えなくなった
相手の気持を想像しなくなった。相手の気持に合わせて自分の行動が変わってしまうから。かわりに、相手の言葉や行動を見るようになった。
相手の気持に向き合わなくなった。答えてあげないといけない、導いてあげないといけないという、自分が行うことができるかということにフォーカスしてしまうから。かわりに、相手に寄り添うようになった。
実践したこと
観察
事実をみる。
事実の中に想像が入り込んできがち。わからないことは行間を読むのではなく相手に確認すること。
できていることを見る。
つい、できていないことを見てしまいがち。それは、期待があるから。期待と事実の差分を見てしまう。今、できていることを見る。
考察
流れを見る。
前に無理やり進めても流れに押し戻されてしまう。いま、どういう力が働いていまここにいるのかな?と問いかける。
宿題をしない子供に対して命令しても、否定しても、宿題が終わるわけではない。頭と心は別だということ。
前に進まない原因になっている流れの方を見る。
視野を広げる。
流れを見て原因がわからない場合、その外側にあるものの流れが原因であることがある。
選択
「前に進むか?」を自問自答する。
正しさを主張したいだけでないか、指摘したいだけではないか、相手を論破したいのではないか、などなど。そんなときはチョコ食べて一呼吸おく。一晩寝かせる。
選択の結果が期待値と異なったときには、別の流れがあると理解する
改善のための流れ
忙しいことでスキルアップのためのゆとりが無い。
プロジェクトの並行実施をやめる、攻めの計画を見直すなど、年間計画の大幅な見直しを決断してもらった。
できていることを見る
苦手なことは苦手なままでも良い。チームでカバーできていれば。
誰も一人にしない仕組み
バディ形式にして、POもSMも二人にした。
マネージャーがスクラムマスターとして活躍している。チームというプロダクトを良くしている。
いいチーム
貢献したい気持ち、サービスを良くしたい気持ちを持っている。
仕組みを改善していく仕組みもチームに組み込まれている。
嫌な思いをしてほしくない人
自分自身。
自分の気持を変えることをしないですむように仕組みをつくる。自分の行動を変える。
前に進むための選択
変化はつながっている。突然変化は起きない。
できることを見て積み重ねる。ちゃんとしたスクラムから遠くても。
どうしてスクラムって呼びたいの?
恩送り。10年前にスクラムのおかげで一歩踏み出せた。
先輩たちから受け取ったものを次の人におくりたい。
感想
今年度に入って役割を変えた自分にとって、とても大切な示唆をいただける講演でした。自分がマネジメント職(見習い)になり、メンバーの支援や育成に注力するようになると、自らに課せられた責任や目標に対して、メンバーへの期待が大きくなりがちで、できていないことにとらわれてしまうことが多かったです。また、それを「正して、導いてあげなければ」という思いでいたのもそのままでした。
また、例え話が育児に関することなので、「わかるー」の連続でした。 「自分を変える」というのはわかっていても「何で自分が」という残念な気持ちがあるのもまた事実です。そこを「自分の行動を変える」とすると「できそうかな」と思えるのと同時に、自分の気持ちも変に捻じ曲げたり、圧がかからなさそうで良さそう。
お話しいただけた内容(観察・考察・選択)は、フレームワークっぽい(OODAとか)だけど、椎葉さんならではのコツというかエッセンスがあって、「やれそう!」と思わせてくれるところが良かった。五感をフルに使って、かつ、自分の気持ちにも向き合う必要があるのでなかなか大変そうではありますが。
最後に、サービスの改善に向き合って真摯に取り組めるチームが素敵です。人(の行動)を変えたり、プロセスを変えたり、ツールを変えたりして、変化を起こすことの目的がはっきりしているからこそ、やり遂げられたのかなって思いました。
2日目に向けて
今の自分やチームが前に進めるように学びたい。
アジャイルマネジメントセミナーに参加した
マネージャー向けのセミナーということで、今期からマネジメント職にウェイトを置いて行こうとする自分にぴったりだと思い参加しました。
アジャイルを社内に広めていく推進者にもなったので、「現場はウォーターフォールから変えられないよ」というチームにプロセスやプラクティスだけでないアジャイルなマインドセットを根付かせていきたいと考えており、その観点からも期待しておりました。
感想
ロッシェルさん、川鯉さん・尾澤さんのセッションを聴講。リーダー・マネージャーとしてのスキル、振る舞いやメンバーの学びを促進するためのワークなど良いお話を聞けました。
— m-ono (@msts_0w0) 2021年5月12日
岡島さん、黒田さんのセッションは動画視聴します。
全部上司に見せたい。
#アジャイルマネジメントセミナー
私が期待していた観点から育成やリーダーシップのセッションを聴講し、学習とモチベーションの相関や理論的な学び方を知ることができて最高でした。
基調講演から各トラックのセッションの流れでWhy・How・Whatのように抽象から具体に綺麗に流れていきスッと腹落ちする感覚を得ました。
咀嚼してチームに伝え、対話することで、さらに熟達を進めていきたいです。
基調講演 アジャイルと現場力
株式会社シナ・コーポレーション代表取締役 遠藤 功 様
VUCAの時代を生き残るために
- 未来が読めない
- 中期経営計画早めようという会社が増えている
- 3年後の計画を立てても意味がない・合理性がない
- 中期経営計画を立てるエネルギーが大きい、コミットしろと言っても無理
- 自社の未来像(10年規模)を示してそのゴールに向かって進む。長期のビジョンが必要
- 答えがない
- 実行しながら答えを見出していく。早く失敗して、早く学習・改善する
- これが日本の企業はできない
- 完璧主義と減点主義の大きな壁
未来をどのように実現するか
ありたい姿・あるべき姿(理想)に対して、現状からこつこつできることを積み上げる(Present-Push)アプローチを日本は得意としている。
ビジョンを実現するために何をやるか(Future-Pull)のアプローチが必要。日本人は得意ではない。これがいわゆる「Backcasting」
トヨタのBackcasting
20年前(2020年)にグローバル15(世界で15%のシェアを取る)を掲げたからの今がある。 2040年にはMaaSの会社へ変身するというビジョンを掲げている。 今必要かどうかではなく未来の姿を実現するために何をするかを考えている。
日本企業に求められていること
生まれ変わる=Re-born
コロナに直面して必要性を実感するが、本当はもっと早く対応が必要だった。柔軟・機動的な経営が求められる。
コロナ・ショックをコロナ・チャンスと捉える。これからの5~10年が転換期。
競争戦略とオペレーション
価値を再定義する。 「我々は何者なのか・我々の価値は何か」を問う。
事例1:ドイツバーン(ドイツ鉄道)
- 旧:Station to Station トレインオペレーター
- 新:Door to Door モビリティマネージャー
事例2:SOMPO
- 旧:保険の会社
- 新:安心・安全・健康のテーマパーク
競争力はどこにあるのか
競争力は中期経営計画書や本社の会議室にあるわけではない。競争力は企業活動のオペレーションの現場にある。ビジネスモデルを真似されても、実行力・現場力で勝つ。
実行の時代
卓越した実行能力を持つ企業のみが生き残る。戦略は真似できても、ケイパビリティはかんたんには真似できない。最も重要なケイパビリティがAgility。
まず、やってみる。早く失敗し、早く学ぶ。完璧主義・減点主義から脱却する。
SOMPOのスプリントチーム
- DXを手作りで推進するチーム
- デジタイルカの企画・開発を自社内で完結
- エンジニアやUIデザイナー50名超のチーム
- 新たなサービスやアプリをクイックに制作
- 1~2周間で機能設計し、継続的に改善
- これまで70件のPoCを手掛け、10件以上サービス化している
逆ピラミッドの三角形を動かす
現場が主導してアジャイルになり、本社や経営陣が支援する。サービス業や小売業ほど進んでいる。
地域のスーパーは元気!それぞれの店舗に権限移譲して、店舗主導で改善を継続している。
個店主義 VS 本部主義
生まれ変わるとは
未来に選ばれる会社になるということ。 過去・現在に選ばれていることは、未来に選ばれることを保証しない。
QA
ローカルスーパーがそこに至るために何をやったか
- 意識の問題が相当違うのではないか?
- ローカルスーパーの店長は経営者である
- 大手スーパーの店長は中間管理職
- 大手スーパーも権限移譲しているが、権限を使わない
- 自分で決めない。本部の了解をとってしまう。
- 時間がかかってしまう。
- 現場に失敗する権利を与えている
- トップからメッセージが出ないとだめ。
- トップは言っているが、中間管理職が失敗を許さないということがネック。
パーパス経営と言われているが
- パーパスは普遍的・一般的であることが多い。共感されるものである。
- 経営者が本気で言っているかどうかが大事。そうすれば社員は共感する。
- それだけの熱を持った経営者がどれくらいいるか。。。
アジャイルチーム運営しており成功しているが、最後の壁(経営層)をどうするか
- 分社化してイケているチームが経営する
- 事業特性・人事・規約など何もかもが違うのであれば会社を分ける必要がある
- それが最も合理的であり、そうしないと大化けしない。
- スピンオフ!
アジャイルの成功を支えるサーバントリーダーシップ
ジャパン・インターカルチュラル・コンサルティング社長 ロッシェル・カップ様
基調講演の現場力・逆三角形組織との親和性が高い
日本の企業を手伝うと、他の文化だけでなく企業の文化が大切
8つの文化的習慣
simplearchitect.hatenablog.com
- Be Lazy:最小の努力で、最大の成果を出す。エッセンシャル思考。
- リスクや間違いを快く受け入れる
- 不確実性を受け入れる
- サーバント・リーダーシップ
- セルフマネジメントチーム:自己組織化されたチーム
- 従業員への信頼:Netflixの人事が話題になっている
- 個人の自信
- 階層関係のパワーバランス:お客様との関係をパートナーシップ
セルフマネジメントチーム
- 仕事に対して自分たちで考え・決断するチーム
- 仕事の計画・コントロール・改善を行い、問題解決の責任も持つ
- チームがマネジメントするとマネジャーの役割は何か?
- マネジャーはメンバーのコーチングと育成、ビジョンを伝え導く
サーバント・リーダーシップ
- 影で黒子のように支援する人
- リーダーが逆三角形組織の一番下にいる
- BOSSではなくLEADERになる
- ビジョンを明確にし、目標の意義を伝え、パッションを持ってもらう
- プレイングマネジャーではない
- 一緒に引っ張るのではなく、そばに寄り添って支援する
何を行うか
- チームへ支持するのではなく、チームのサポートに集中する
- マイクロマネジメントしない
- 権限移譲する
- チームの障害物を取り除くのを助ける
- 優れた「聞く」スキルと「フィードバック」スキルを持っている
- 従業員が神経質になる過度な批判や過大な要求をしない
どんな人か
- エリート選手のコーチみたいな存在
- アドバイスやフィードバック、環境を整えて支援する
- 外部からはいってくるチームの障害になるようなものを守る
サーバント・リーダーシップのインパクト
40年以上前にIBMを退職した人がサーバント・リーダーシップのコンセプトを作った。シリコンバレーでの導入が進んで、大学の研究が進み、論文にもなっている。その論文で発表されたインパクトが下の通り。
- 会社のパフォーマンス(収益改善)
- チームのパフォーマンスが良くなる
- カスタマーサービスの向上
- 従業員満足度と、仕事への満足度(エンゲージメント)の工場
- 従業員のクリエイティビティ向上
- 従業員の助け合いの度合いの向上
サーバント・リーダーシップがイノベーションの環境を作る。
サーバント・リーダーシップによる行動・スキル
サーバント・リーダーシップはソフトスキルである。
多くの企業では、昇格させる場合に仕事の能力(ハードスキル)で決定する。上手なリーダーになるためには対人関係スキル(ソフトスキル)が必要である。
- Listening:聞く力、上手な質問の仕方
- 傾聴力
- Awareness:気づく力、歩き回りによる管理
- 現場を見る
- Empathy:共感する力、多様性尊重
- 観察力
- Foresight:予見する能力
- いろいろな可能性を描く
- Conceptualization:概念化する力、ビジョンの示し方
- リーダーは時間をもらって長期的なビジョンを考える時間を作る
- 戦術ではなく戦略を考えて伝えることが重要
- Commitment to the growth of people:人間的成長を助長する力、フィードバックの伝え方
- Healing:癒す力、Win-Winの交渉術
- Persuasion:説得する力、意見の述べ方
- Building community:チームビルディング
- Stewardship:長期的な考え方
- SDGsが人気ですが、そのことに当てはまる。
- 長期的に持続的に社会に貢献する
やるべきこと
- 従来のマネジメントは、現代の知的労働にマッチしていない。
- 今までやってきたことを変える必要がある
- スキルを磨くこと
0からわかる部下が自律的に学んで成長する環境づくりの方法 〜 学習科学の理論をベースに 〜
永和システムマネジメント・コーチ 川鯉 光起様
1on1を用いた組織支援コンサルタント 尾澤 愛実様
職場における上達とは
事例
仕分けをしていく中で最適解を生み出していく熟練
- 定型的熟達
- 決まった作業や仕事をより早く、正確にできる
かつおのたたきを作る手順の理由を理解していると別の方法を見いだせる熟練
- 適応的熟達
- 状況に応じて知識や技を組み替えたり、新たな手順や方法を行う
学校での学びは定型的熟達になっているケースが多い
- テストのための勉強
- 正解がある
- 時間制限や点数が求められる
こちらに慣れてしまうと適応的熟達になかなか向かうことができない
アジャイル開発における熟達者の行動
どうすれば適応的熟達者になるのか
- 未知の問題に取り組むこと
- 複数人で話しながら解決を試みること
- 聞かれると分からない、説明を求められるとできない状況に気づく
- 人の知識と理解のモデル
- レベル1:経験則、素朴理論
- レベル2:わかりやすい説明が生むバブル型理解、対話によって生まれる
- レベル3:学校で教える原理原則、科学的概念
- ペアプログラミングそのものである。
- 成果を出すことに対して、切迫していないこと
- 組織が理解することを重視していること
- 挑戦による失敗に対しての称賛
会社で実践できる具体的な施策紹介
未知の問題について話し合うワーク
- 5分:議題のテーマ決定
- 5分:個々に課題について考えてみる
- 15分:どのように考えてきたかを発表し、疑問点などを質問していく
- 25分:その課題を解決するための障害や心配事などを挙げる
- 10分:改めてチームとして、個々としてできることを考える
ポイント
- 無理やり答えを収束させようとしない
- 未知の問題選ぶときに難易度が高すぎないようにすること
クイズ作成/クイズ会
題材を選ぶ
- 3分:グループ分け(2~3人) 知識レベルが近い人同士のグループだと効果的
- 12分:クイズ作成 チームごとに問題と想定回答を2~3問作成
- 説明を促すような問題が良い
- 25~45分:クイズ会
深める読書会 簡易版(ジグソー法をアレンジ)
モブワーク質問チートシート
ツッコミ役をローテーションする
- 同定:どこの範囲を試すのが良さそうかな?
- 疑問視:今わからないことはなんだろう? 気にしているのはなんだっけ?
- 探索:関係しそうな仕組みはどこかな? 他に関係していることはありそう?
- 提案:どこが一番関係するだろうか?
- 確認:これで問題ないかな?
適宜、質問・批判を行い対話する:誰も疑問は無いかな? 全部に対して問題ないかな?
2020年ふりかえり
今年はブログへのアウトプットが全くできなかった。 前回が2019年ふりかえりで今年最初の記事が2020年ふりかえりになってしまった。(間に合ってないw) もうちょっとブログのハードル低くしよう。
前年の目標に対するふりかえり
- 事業の推進者となる
- 貢献という意味でのアウトプットはできていたと思うがアウトカムが弱い。
- 教育者となる
- 学習者であり続ける
- 勉強会への参加は減ってしまった。時間の使い方・確保に工夫が必要。
やったこと
- 1月~3月
- 社内のマネジメント研修でアジャイルになる宣言した。
- お仕事で火消し要員として参加。コミュニケーションの重要さが身にしみる。
- 役割の変動を意識してメンバーへの振る舞いを変えていった。
- 4月~6月
- 新型コロナ影響によるリモートワークを始める。リモート飲み会の実績も解除。
- チームのコミュニケーション量が爆上がり。部下が思いがけない成長を遂げる。
- ソースコードの構造解析に取り組む。ちょっとげんなりした。
- 7月~9月
- ハイキュー最終回に感動。全巻揃える。アオアシも全巻購入。
- リモートワーク本格化。働く時間は明確に厳格にしないと働きすぎ現象が起きる。
- 構造解析結果をまとめて客先勉強会の中で発表。ちょっとはしゃぎすぎたなぁ。
- 10月~12月
- 上司との恊働が増える。マネージャー的な役割を担うことが増える。
- 良くも悪くもメンバー・チームも変化する。チームが最高のパフォーマンスを出せているかを気にしている。
- 火消し参加2。現在進行系で辛い。
読書
積読中のものが増えてきた。とにかくざっと読んで、読み返す方法にしたほうがいいかな? 今年はハイキューとかアオアシとか漫画で学ぶことが多い。まあ、漫画は絶えず読んでいるけど。 以下は、下の方ほど購入時期が古くなっています。中にはKindle Unlimitedで買ったものも含まれてます。
- 【読了】モンテッソーリ教育・レッジョ・エミリア教育を知り尽くした オックスフォード児童発達学博士が語る 自分でできる子に育つ ほめ方 叱り方 島村華子
- 1兆ドルコーチ――シリコンバレーのレジェンド ビル・キャンベルの成功の教え エリック・シュミット
- 【読了】自分の頭で考えて動く部下の育て方 上司1年生の教科書 篠原信
- ピープルウエア 第3版 トム デマルコ;ティモシー リスター
- Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) Robert C. Martin
- オブジェクト指向でなぜつくるのか 第2版 平澤 章
- Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち 株式会社VOYAGE GROUP 監修
- 【読了】エクストリームプログラミング KentBeck
- 【読了】その仕事、全部やめてみよう――1%の本質をつかむ「シンプルな考え方」 小野 和俊
- 【読了】子どもの地頭とやる気が育つおもしろい方法 篠原 信
- SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ Zuzana Sochova
- 【読了】なんでも図解――絵心ゼロでもできる! 爆速アウトプット術 日高 由美子
- 【読了】コミュ力なんていらない 人間関係がラクになる空気を読まない仕事術
- ビジネスモデル2.0図鑑 (中経出版) 近藤 哲朗
- More Effective Agile “ソフトウェアリーダー”になるための28の道標 Steve McConnell
- 反応しない練習 あらゆる悩みが消えていくブッダの超・合理的な「考え方」 草薙龍瞬
- 窮地にいるエンジニアは、ズルい処世術で困難を突破する 佐々木康介
- Agile Testing Condensed Japanese Edition Janet Gregory, Lisa Crispin, and Yuya Kazama
- みんなでアジャイル Matt LeMay 著、吉羽 龍太郎、永瀬 美穂、原田 騎郎、有野 雅士 訳、及川 卓也 まえがき
- GitLab実践ガイド impress top gearシリーズ 北山 晋吾
- 【読了】対話型ファシリテーションの手ほどき 中田豊一 (著), 山崎美帆 (イラスト)
- 【読了】チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
- 【読了】ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 成瀬 允宣
- システムインテグレーション再生の戦略 ~いまSIerは何を考え、どう行動すればいいのか? 斎藤昌義
- 学習する組織 ― システム思考で未来を創造する ピーター・M・センゲ
わかったこと
設計が好きである
- 全てはユーザー体験のため
- 要望・要求・要件・仕様・実装を繋げる
- 設計に関する後継者を育てたい
チーム・組織とコミュニケーションの継続的改善が必要
- 全体を把握し、優先順位をつけ、体制を作る。これの繰り返し。
- 透明性を上げたり、心理的安全性を確保したり、風通しを良くしたい。
- 適切な役割分担を行う必要がある。一極集中はどこかに歪みがでる。
火は消えない。だから最初から発火させないように取り組む。
火を消すには膨大なエネルギーとコストが必要になる。
早く察知する。そのために2.の取り組みが必要。
- 「誰も消防車を呼んでいないのである!」にならないようにしよう。
次やること
- 設計・パタンについて学習を継続
- チーム・組織がうまくいく仕組みを考えて実践する
- 「ゆとり」を組み込む。心に余裕を持つ。