ざっと読みでの書評・レビュー【スクラム 仕事が４倍速くなる“世界標準”のチーム戦術】
こんにちは！
今回は【スクラム 仕事が４倍速くなる“世界標準”のチーム戦術】のざっと読み書評・レビューです。
オススメ度
オススメ度は0~10のうち「8」。
著者はスクラム考案者のジェフ・サザーランド氏。
ざっと読みと言いつつ何度か読み直しているのですが、スクラムの基本と組織の行く末を示してくれている名著です。
スクラムのはじめ方はもちろん、その歴史的背景からより良い人生に至るまでの至言が溢れています。
各章の最後にまとめもあり、ざっと読みしやすいのもポイント高し。
ただし、洋書全般に思うことですがエピソードや哲学的な話題が多いので、慣れてないと読み進めるのが大変かもしれません。
書籍の概要
スクラムをはじめるために必要な最低限の考え方を身に付けられる書籍です。
理解を深めたい方は、スクラムが考案されたその歴史的背景を読み取り血肉にしましょう。
上手くやり方を模索している方は、著者が考えるスクラムを発展させる考え方や幸せを求める旅路を読み取り、守破離を体現しましょう。
この書籍は、スクラムを活かし切るためにスクラムを超えていく気概を感じます。
あらすじを抜粋するとこんな感じです。
GoogleやMicrosoft、FBIでも採用！
最強のプロジェクト管理法「スクラム」考案者による完全ガイド
「興味深いエピソードと実例が満載。スクラムは、生産性を高めるツールとしてハイテク企業のあいだで最も普及しているプロジェクト管理法だろう。本書は、あらゆる業界のビジネスパーソンにこのツールを伝授するという目的を見事に果たしている」
――エリック・リース（『リーン・スタートアップ』）
あなたの仕事の85%はムダ！
納期遅れ・予算オーバーが当たり前だったソフトウェア開発の現場で、いまや世界的に絶大な支持を集めるようになったプロジェクト管理法「スクラム」。その生みの親が、最少の時間と労力で最大の成果を出すチームの作り方を伝授する。住宅リフォームや結婚式の計画から、FBIのデータ管理、さらに宇宙船の開発まで、スクラムが革命を起こす！
●計画は最初から固めるな
●チームは最大9人まで
●多機能なチームを作れ
●肩書は捨てよ
●リーダーは「ボス」ではない
●仕事は「スプリント」に分割せよ
●スプリントの最後には成果物を出せ
●仕事はストーリーでとらえよ
●タスクは付箋で管理せよ
●毎日の会議は15分で強制終了
●会議では3つの質問だけ聞け
●マルチタスクは厳禁
●仕事をしすぎるな
●無駄は「罪」である参考 Amazon参考
オモシロポイント
スクラムをはじめるために必要な最低限の情報はもちろん面白く、参考になります。
ある程度スクラムに理解があるなら、この書籍からはそれ以上に面白い気付きを得られると思います。
全9章から構成されていますが、いずれの章も示唆に富むエピソードとそこから導き出される考え方がまとめられています。
私が特に面白いと感じたポイントは、3つ。
- 第3章のチーム
1食ピザ1~2枚分で賄えるチームが、仕組みや支援を整えれば1組織として世界を変えるほど活躍できる可能性があること
一人ひとりを信じ、Howを任せて成長と成果を両取りしたいと思う - 第4章と第5章の計画遂行
過去の実績から戦略的かつ現実的な計画を組み、実現するためにチームがベストを尽くすこと
ムダ・ムリ・ムラをなくし、正しくTry&Errorを繰り返したいと思う - 第7章の幸福
現状を改善するだけでなく、未来を創るために組織やその中の人の幸福とパフォーマンスに焦点を当てること
良い人生を高い成果とともに得たいと思う
ざっと読みで得られた気づきや学び
- 改めて気付かされるスクラムの基本とはじめかた
- ウォーターフォールで計画通りいくことが難しい原因、変化と適応のサイクル
- 製造業の生産現場や経営層の意思決定など、ソフトウェア開発以外の状況
- チームのコミュニケーションルート数（n人 * n-1人 / 2）とその複雑性
- 日本文化との高い親和性（例えば、守破離、武道、PDCAサイクル）
- 幸福度をはじめとする定性評価と成果との紐付けによるラーニングゾーン作り
- マネージャーやリーダーの役割を超えて、ボトムアップ型の変革を支援すること
- ソフトウェア開発にとどまらず、スクラムで教育や社会問題を変える可能性
次読むときの書籍への問いかけ
- 実行責任と説明責任が重くのしかかる現状に対し、人材開発や支援の仕方は？
- どれだけ見える形で成果とその過程を築けば周囲を納得させられるだろうか？
- ヒエラルキー型の組織における、変化を起こすことへの拒絶を崩す術は？
- オレオレスクラムで自己満足にならないよう守破離を進めるには？
- 理想のチーム（限界突破、主体性、機能横断的）を組織に広めるには？
おわりに
スクラムは今や開発現場のデファクトスタンダードかもしれません。
どんなケースでもアジャイルが、スクラムが正解。ということはありえないと思いますが、変化の波に上手く乗って生き残るにはTry&Errorが重要だと思います。
また、チームや組織によって挑戦や変化の難易度は異なるでしょう。
正直、私や私が所属する組織ではまだまだ活用しきれていません。
それでも学び、説明し、実行し、結果を出し、それらを継続することで徐々に影響範囲を広げたいと思います。
みなさんもぜひ一緒により良い仕事を実現していきましょう。
ざっと読みでの書評・レビュー【エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング】
こんにちは！
今回は【エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング】のざっと読み書評・レビューです。
エンジニアリング組織論への招待 ?不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: Kindle版
- この商品を含むブログを見る
オススメ度
オススメ度は0~10のうち「8」。
組織論に触れる書籍と重複する内容は多いものの、マネジメントの意味や意義、やり方の全体像を学べる書籍です。控えめに言って名著。
マネジメントを工学的なアプローチで上手くやろうとする書籍なので、複数人で物事に取り組む方であれば業種や職種に限らず参考になると思います。
エンジニア向けに書かれてはいるものの、書籍タイトルに「エンジニアリング」とあるからと言って技術職以外の方が避けるのは勿体無い。
書籍の概要
マネジメントの理論が凝縮されています。
例えば、不確実性、メンタリング、心理的安全性、技術的負債、コンウェイの法則といったキーワードに興味関心がある方なら楽しめそうです。
知識や経験の再確認にもなりますが、点と点をつなげた新しい発見にも繋がると思います。
あらすじを抜粋するとこんな感じです。
「コミュニケーションにおける不確実性を減らすには？」
「技術的負債を解消する方法とは？」
「経営陣とエンジニア間の認識のずれを解消するには？」
エンジニアリングにおける課題を解決する思考の整理方法やメンタリング手法を，さまざまな企業の技術組織アドバイザリーを務めている著者が解説。若手を戦力として育て上げ，成長する組織を設計・運営するためにおすすめの1冊です。参考 Amazon参考
オモシロポイント
根拠としてデータや論文、他の書籍からの引用があるため、納得しながら内容を飲み込めます。
私が特に面白いと感じたポイントは、3つ。
- 梯子の登らせ方
言って聞かせたり、答えを教えるのではなく相手が自ら動き出してもらう考え - コンフォートゾーンとラーニングゾーン
心理的安全性の行き過ぎに対して警鐘を鳴らされたと感じた - 逆コンウェイの法則
複雑な組織の諸問題に苦しめられがちなので、特に共感した逆転の発想
それ以外はGoogleのマネジメント本や学習する組織、アジャイルに関する書籍から、多々ある知見を一連の流れで学べる時短本という印象。
もちろん、上述した3つ以外にも面白い内容が盛りだくさんです。
ざっと読みで得られた気づきや学び
- 不確実性こそマネジメントをしていく者の解決すべき課題
- 改めてシステム思考（自己強化型、バランス型）での分析力の理解
- 他者と向き合うときのメンタリング、認知心理学の重要性
- コントロール可能な部分への注力がやりやすい（思考や本心は難しい）
- 心理的安全性と結果責任のバランスで、ラーニングゾーンへと向かうこと
- 逆コンウェイの法則で強い組織と強いアーキテクチャを得られること
次読むときの書籍への問いかけ
- 次世代のマネージャーにMUSTな考え、技能、経験はなにか？
- 組織の成果を最大化させるマネージャーとはどんな人で、どう評価すべきか？
- 一人ひとり、1チーム毎に異なる状況の中、下記テーマをどう考えると良いか？
・信頼関係の醸成
・権限委譲
・目標管理
おわりに
私が組織論を意識しだしたのは、認定スクラムマスター研修を受けてからでした。
元々マネジメントに関する書籍は読んでいましたが、研修を受けたあとは是が非でも最高の組織を目指したいと熱を上げて組織論を学びました。
組織論でオススメの書籍は他にもいくつかありますが、この書籍はそれらのエッセンスを一度に得られる点が素晴らしい。
私は書籍を読み終わるまで結構時間がかかるので、正直積読が多い。
そんな中一度で何度も美味しいこの書籍はもっと早く読みたかったです（出版するの遅いよ 🤣）。
複数人で物事に取り組む方はぜひ読んでみてください。
エンジニアリング組織論への招待 ?不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: Kindle版
- この商品を含むブログを見る
ざっと読みでの書評・レビュー【独創はひらめかない―「素人発想、玄人実行」の法則】
こんにちは！
今回は【独創はひらめかない―「素人発想、玄人実行」の法則】のざっと読み書評・レビューです。
オススメ度
オススメ度は0~10のうち「8」。
「10」は人生を変えるような書籍に残しておきたいので基本使いません。
「9」はオモシロすぎて今すぐ精読したくなる書籍に残します。
この書籍はざっと読みだとまだ未知数。
とはいえ、かなりオススメできます。
書籍の概要
知的な生産現場においてしがらみなく考えた知を集め、実現までやり抜くことを説く本。
あらすじはこんな感じです。
参考 Amazon参考
オモシロポイント
エピソードの一つひとつにノーベル賞クラスの知の巨人が出てきて、示唆に富む話を交えてきます。
本を読んだあとは、知的な刺激を渇望してしまいます。
一見バカみたいな空想でも、聞き手の得意分野や生き甲斐と紐付け、議論していけば世にインパクトを与えられるという話。
ざっと読みで得られた気づきや学び
- 残酷な現実だが、結果を残す人には優秀さがベースにあること
勉強くらいできて当然（するかどうかは別にせよ） - 誰しも1つ以上は秀でたものや譲れない覚悟を持つものがあるという示唆
- KISSの原則やスピードが重要ということ
次読むときの書籍への問いかけ
- 玄人発想、素人実行でいけない理由は？
- 素人発想するためにはどうすればよいのか？
- 玄人実行するためにはどうすればよいのか？
- 素人と玄人の違いは？
- 前提となる価値観や能力はどのように磨けばよいか？
- しがらみの正体は？
- なぜ現状維持ではいけないのか？
- 独創が必要となる理由、課題感はなにか？
- 素人発想、玄人実行の先にあるものはなにか？
おわりに
正直、私は「素人発想、素人実行」か「玄人発想→素人実行」です。
全然世の中に貢献できてません。
理想の姿とは程遠く、スピード重視で雑になることが多いですし、考えすぎて行動に移せないです。
そのため、この書籍から多くを学びたいです。
モチベーションや示唆を得るだけでなく、実際に世の中にインパクトを与える考え方を学べそうな気がしています。
今回はざっと読みで、今後じっくり読む予定です。みなさんも興味が湧いたら読んでみてください。
書籍のざっと読みで書評・レビューを書く
こんにちは！
今回はざっと読んだ本の書評・レビューはじめることについて書きます。
目標はアウトプットの習慣化。
※本記事はただの意気込みで、参考になることはなにもないです
インプットするだけでは自分にしか影響がなく、正直つまらないです。
みなさんに共有することでよりよい世界を一緒に探求できるよう、雑にでも面白い書籍を共有し、議論できたら最高です。
アウトプットすることで失敗したり間違えたりと不安に思うこともありますが、あえて雑にやることでみなさんの安心につながったら幸いです。
雑なのは根っからですが 👻
はじめに
本記事はただの抱負で、
要点は「今後ざっと読んだ書籍の書評・レビューを投稿します！」という宣言です。
ググればもっと良質な書評・レビューが転がっている中、なぜ私が書くのか？
理由は3つ。
書く理由① 仲間と競争して共創したい
同じ書籍を読んでる人や紹介した書籍に抱えてる課題のヒントがありそうな人、書籍を深掘りしたい人など、色んな人と関わることで多様な視点で書籍が見られると期待しています。
一緒により良い世界を創る仲間が欲しい！
書く理由② バイアスからの解放
当然のように私はバイアスを持っていて、どんな書籍を読んでも考えることや学んでることは似通います。
例えば、型にはめ込むような話には拒否感があり、
変化や成長、自由と責任、協力のような価値観のもと、
ケースバイケースでメリデメを考えながら読んじゃいます。
これでは学びの限界があり、成したいことや描いている理想に対して力不足になりがちです。
現に今どうにも上手くいかなくて困っています。
お互いに学び取ったことを知ることで、知の可能性を広げたいと思います。
書く理由③ アウトプットの習慣化
インプットだけより知識が定着します。
学んだことを実際に活かしたいので、読むだけでなくアウトプットしたいのです。
ネット空間を駄文で汚して申し訳ないです 😅
どんな感じに書くのか？
普段の読み方
昔は最初から最後まで精読してから要約をまとめてく読み方でしたが、これだと読める量が限られます。
特に技術系書籍だと実際にコードも書くので時間がかかりすぎでした。
速読や読む書籍の厳選といった対応も試しましたが、一番合うやり方が複数回読みでした。
複数回読む前提で、最初はざっと読み、気に入った箇所や深掘りしたい箇所を重点的に読みます。
読む流れを箇条書すると、
- 読むか否かをタイトル、目次、はじめにぐらいで判断する
- ざっと読んで（目標は1ページ数秒）、大まかに書かれてることを把握する
面白そうな箇所や気になる箇所に目星は付けておく - 目星を付けた箇所を中心に読み込む
- 特に新しい気付きをくれた箇所やエッセンスと思う内容をまとめながら読む
- 後日、まとめた内容を読み直す
まとめた内容で過不足ある場合、書籍を部分的に読み直す
という感じです。
特に濃い本は、ざっと読みを2〜3回繰り返すこともあります。
一気に読むのは集中力が持ちませんから。特に面白くない本と面白すぎる本はキツイです。
書く内容のテンプレ
テンプレと言いつつ、今後試行錯誤していくからテンプレ自体徐々に変わってくと思います。
１．評価
0~10の中から独断と偏見でオススメ度を書きます。
オススメ度が高い書籍しか紹介しないので、同じような点数になりそうですが。
２．概要
書籍のあらすじを載せつつ、主観での印象を書きます。
３．オモシロポイント
私が面白いと感じたポイントを書き連ねます。
読み返す際、私自身もこの項目に目を通してから読もうと思います。
４．気づきや学び
書籍から得た気づきや学びを書き連ねます。
実際にどう活かせるかをイメージして書く予定です。
５．次読む時の問いかけ
書籍と対話するイメージで、次読む時に解決したいことを書き連ねます。
疑問に思ったことやどうすれば上手くいくのか、書籍が勧めることに対するエビデンスや良し悪しの判断方法がなんなのか、などなど。
おわりに
今後はざっと読んだ書籍をちょくちょく紹介していきます。
みなさんが良書に出会えるキッカケになれば嬉しい限りです。
システム思考の基本 〜仕組みや関係性を理解する方法〜
こんにちは！
今回は「システム思考」という物事の考え方を紹介します。
困っていることや仕事の悩みを解消するのに役立つかもしれません。
基本のみ書くので、すでに概要を把握できているなら「学習する組織」や「アジャイル開発」での使われ方を調べてみるとより理解が深まると思います。
はじめに
みなさんは現状を理解することが重要な仕事をされていたりしませんか？
今ある業務の理解、システム連携の理解、ステークホルダーとの関係性の理解、課題の原因調査、など。
なにかを理解し深掘りしたいとき、あれこれ資料を見たり人から話しを聞いたりしてもなかなか上手くいきませんよね。
システム思考はそれらを上手く解決する手助けとなるはずです。
例えば、
- ごちゃごちゃしていた考えが、まとまる
- 理解が難しい事象が、素早く正しく理解できる
- 説明が難しい話を伝えるにあたって、わかりやすいく図式化できる
など。
基本はシンプル。覚えるのはノードとリンクの2つだけ
システム思考の良さは、やり方のシンプルさ。
覚えることは2つ。「ノード」と「リンク」だけ。
ノードとは出来事や物事といった概念。
付箋や円の中に字を書いたり、簡単な絵で表現したりします。
リンクはノードとノードの関係性を示すもの。
ある出来事（①）が別の出来事（②）を誘発したり、①と②の間に順番があるなら①→②のように書きます。
例として、会社員の1日をシステム思考で雑に分解してみます。
シンプルですよね？
みなさんも登場する物事とその関連をシステム思考で可視化してみましょう。
この例では「流れ」をシステム思考で可視化しましたが、課題の分析にも活かせます。原因の深掘りなど。
例えば、寝不足の原因分析。
可視化する途中でそれぞれの関わり方やどのような影響を与えているのか、どうしたらよくなるのかが見えてくる。かもしれません。
活用例
システム思考はやり方がシンプルなので、色々な場面で試せます。
私が良く使うケースは、大別すると部分最適化と全体最適化の場面。
課題の深掘り（部分最適化の例）
部分最適化では、具体的に絞った課題を深掘りし、改善点を探ります。
例えば、「ブログを書くのが不慣れで文章を書くのに時間がかかる→発信が少なくなる→不慣れが続く→時間がかかり続ける→コスパが悪い」
と分析していき、次にその解決を考えます。
「発信回数を上げる←ネタを簡素化する←書きやすいテーマや内容（初心者向けや、基本のやり方）に絞る」
システムの理解（全体最適化の例）
全体最適化では、全容を把握できていないことの物事とそれぞれの関係性を探ります。
次に、検証しつつ全体をなんとなく理解し、改善点を探ります。
「eコマースの登場で遠くにあるものをスマホで買える→遠くにあるものを買う量が増える→物流が増える→物流のキャパシティを超える←届くまでの手数と時間が多い←移動時間が長くかつ不在時はやり直しが必要←共働き世帯が増えたので不在時間帯が長く受け取れない」
と分析して、次はその解決を考えます。
「→物流の流通を自動化、コスパが見合う近場の倉庫に在庫、時間帯指定配達、人員増や社会インフラ整備」
アジャイル開発や学習する組織での使われ方
アジャイル開発のふりかえりでは、どう改善すればよさそうか議論することがあります。
人の仕事において、相関や因果関係を探るのは難しい。
顕在化した課題を話し合うだけではなく、発生メカニズムを解明することで最適化がはかれます。
学習する組織においては、因果関係を探り、物事のメカニズムを把握します。
負のサイクルが起きている事象に対して、適切な対応やプロセスを足したり引いたりすることで、負のサイクルが正のサイクルになります。
おわりに
システム思考自体は非常にシンプル。
まずはなにか1つシステム思考で分解してみてください。練習大事。
次に解決したい物事の構造をシステム思考で理解してみましょう。
注意点
実は、システム思考は色々な考え方が存在しています。
今回はもっともシンプルなシステム思考を紹介してみました。
Wikipediaを見ればわかるかもしれませんが、今回紹介したことよりも複雑な考え方が多い。
もしシステム思考をもっと使いこなしたいのであれば、ぜひ深掘りしてみてください。
10分でわかるはじめてのスクラム
こんにちは！
今回は開発方法論として、スクラムの基本を紹介します。
スクラムは以前別の記事でも紹介しましたが、今回は基本となる考え方や19のルールに絞ってみます。
想定読者は
はじめに
薄いフレームワーク
大量のルールがガチガチに固まっているわけではなく、覚えることが少ないのではじめることは難しくないはずです。少なくともPMBOKやITILよりかは 👻
また、巷にはオレオレスクラムという自己流スクラムが大量に転がっています。
基本となる考え方やルールはありますが、どれもケースバイケースで良し悪しは変わるという考えがその背景にあります。
上手くやるのは大変なので、誰しもが試行錯誤中かと思います。
開発方法論のデファクトスタンダード
アジャイルの基本は、アジャイルソフトウェア開発宣言にまとめられています。
従来重要とされていた価値も大事と考えつつ、それ以上に対話、動くソフトウェア、顧客との協調、変化への対応を重視する考えです。
アジャイル開発は企業やNPO、政府調達にまで採用されていて、アメリカではほぼデファクトスタンダードとなっています。
中でも成功事例を多く耳にする方法論がスクラムです。
参考 日本と世界のアジャイルの導入状況 - スクラムマスダーの日記
参考 7 top project management methodologies: Which is best?
小さくはじめよう
批判する方もいますが、我流でスクラムを導入すること（オレオレスクラム）は誰しもが通る道。
最初の導入にあたっては、顧客や上司、ステークホルダーに説明することは大変かもしれません。現場にも反対する方はいるでしょう。
それでもはじめる覚悟があるなら、用語を隠したり自分がコントロール可能な範囲で試験導入しちゃいましょう。
やっちゃえスクラム 👊
スクラムの基本
スクラムは問題を発見するフレームワーク
大前提として、世の中の変化は日々早くなっていて、その変化に上手く対応できるかが生き残りの鍵となる状況にあります。
スクラムでは、プロジェクトを上手く進めるための鍵が変化への適応と考えられていて、そのため問題をいかに発見するかが重要と考えます。
さらにアジャイルの本来の意味である「Agility（俊敏さ）」を上げるため、自律的かつ学習し続ける組織であることが望ましいです。
そのため、未来をよりよくするために解決すべき問題、
例えば現在抱えているプロジェクトや組織上の問題を浮き上がらせ、プロジェクトに関係する「人」を中心に対応していく仕組みが整っています。
公式リファレンス
コアとなる考えや、スクラム提唱者や普及団体の考え方は公式リファレンスにまとまっています。説明をかなり省略しているので理解するのは大変ですけどね 😅
19のルールと用語の解説
スクラムの実践イメージを作るため、基本となるルールと言葉の意味を知りましょう。
スクラムの三本柱「透明性、検査、適応」
スクラムの三本柱は、その他のルールの全てに適用されてる大事な考え方。
スクラムをやっていく中で、常に意識しましょう。
例えば、
- 透明性が確保され透明化された物事が活用できてるか
- 過去の踏襲ではなく、常に現状を疑い、良し悪しを検査できてるか
- 発見した変化に上手く適応するため、対話をとおして納得した適応ができてるか
など。
透明性
あらゆる情報や考えをさらけ出し、変化や問題の兆しに気ける状態。
透明性が悪ければゆでガエルじゃないが、現状維持が許され、気づいた時には後戻りできない状況に陥ってしまいます。
プロジェクトの進捗状況は常に誰でも見られる状態にしましょう。
感覚や憶測だけで話すのではなく、データや事実を集めましょう。
ステークホルダーの意見も、失敗した取り組みも、全てさらけ出しましょう。
検査
良し悪しを判定したり、正誤を判断したりできる状態。
主観的だったり曖昧な基準だったりも時には必要ですが、透明性が確保された状態を活かすためにも成功と失敗はハッキリさせましょう。
事実やデータが本当かのファクトチェックも重要。恣意的な判断は排除しましょう。
検査する基準がないなら仮説を立て、定性でも定量でもまずはデータを収集し、検査できる仕組みを整えましょう。
また、検査の仕組み自体が間違っていないかも検査することが大事。
仕組みや基準を撤回するルールや、変更するルールも考えておきましょう。
適応
変化を味方につけるため、状況や問題をコントロールできるよう試行錯誤する状態。
良いことは続け、まずいことは改善する。
そのための適応方法は、変化から学び自律的に見出しましょう。
ただし、一度決めたルールや考え方にこだわりすぎず、臨機応変に対応すること。
役割
PO（Product Owner）
プロダクトオーナー。プロダクトの中長期的な価値最大化に責任を持つ。
プロダクトの意思決定者なので、権限と責任を持つ一名が担当しましょう。
価値最大化には、いかにコスパの良い施策を計画し、後述のTeamに素早く対応してもらえるかが鍵となる。
短期的な施策ではなく、最も重要なタイミング（例えば2020東京オリンピックの開催期間、など）でプロダクトの価値が最大化されるよう計画を立てること。もちろん状況の変化にあわせて計画自体も疑いましょう。
要点と譲れない条件を明確にし、Teamが実作業に集中できるよう短い時間で説明し切ること。
SM（ScrumMaster）
スクラムマスター。POやTeamを含めたステークホルダーが、スクラムを最大限活用できることに責任を持つ。
POが困っているなら支援します。
Teamが困っているなら支援します。
組織や顧客が困っているなら支援します。
あらゆる人や物事を観察し、プロジェクトが上手くいくことを支援していきましょう。
スクラムを周囲に説くこともありますが、スクラムが合わない状況であれば他の開発方法論を提案することも必要です。
スクラムの最大限活用で誰も困らない状況ならSMは不要だし、SMなしでも関係者が自律的に動けるプロジェクトを築けたら大成功です。
Team
チーム。プロジェクトの生産性を最大化させることに責任を持つ。
必要なスキルを学び活用し、開発生産性を上げましょう。
生産性を上げるための方法をPOやSMに提案し、提案内容がいかに重要かを説明することも大事。
流れ作業的に仕事をするのではなく、プロジェクトにおける責任ある立場ということを胸に刻み、どうやるかのがベストかを考えましょう。
あまり大人数だとコミュニケーションが複雑化するので、5±2人が望ましいと言われています。
スクラムセレモニー
スクラム内でやるべきイベント群。
色々なセレモニーを実施し、スクラムのリズムを体感しましょう。
スプリント（Sprint）
スクラムの中心で、一連のスクラムセレモニーを一巡する期間。長くとも1ヶ月間。
スクラムは「計画を立て、作業と進捗を繰り返し、成果を確認し、改善を考える」という流れを繰り返します。
スプリント内でPO、SM、Teamは自分たちの責任を果たすため全力で仕事を進めていきます。
スプリント内で行われた活動により、プロジェクトの成果が生まれます。
スプリントプランニング（Sprint Planning）
POとTeamの共同作業により、スプリント内で完了させるタスク（プロダクトバックログアイテム）を決めるイベント。
POが求めるタスクの優先順位を考慮しながら、Teamはスプリント内で完了できそうなタスクを見繕います。
POは優先順位の理由や一つひとつのタスクの意味や求めている結果を説明し、Teamは内容理解しようと努めます。
POとTeamが納得し合意できる範囲でタスク群を集め、スプリント内で完了させることをTeamは約束します。
朝会（Daily Scrum）
Teamがより実のある1日を過ごすため、毎日集まって話すイベント。
私は朝会として企画することが多いですが、別に朝でなくとも1日のうちどこかで話せれば問題ないです。
前回の朝会からの進捗や状況の変化を一人ひとり話します。
スクラムガイドでは話す内容の例が書かれています。
- 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
- 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
- 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
時間は15分内で終わりましょう。長く話しすぎると他のタスクに影響してしまいます。
話さないとどうしようもない状態なら朝会している場合ではありません。緊急会議を予定するか、POにスプリントの中止を提案しましょう。
リファインメント（Refinement）
POの責任において、中長期的な状況の変化をTeamに説明するイベント。
状況は常に変化するから、今後必要となるタスクの頭出しや現在決めているルール群（例えば、完了条件や後述するアーティファクト）の見直しを図ります。
スプリントレビュー（Sprint Review）
POの責任で、Teamがスプリント内で生み出した成果に対してあれこれ確認やツッコミをいれるイベント。
誰が意見しても問題ありません。POでもその後ろにいるステークホルダーでも、Teamが自らツッコミしても大丈夫。参加して欲しい人をPOが招待しましょう。
実物ができてはじめて気づくこともあるので、より良い価値を世の中に届けるため、お互い遠慮なく議論しよう。それが改善の糸口となるはず。
ふりかえり（Sprint Retrospective）
Teamの責任で、より良い進め方を考えるイベント。
やり方や進め方はTeamが責任を持つのが望ましく、だからこそTeam自身でやり方の問題を発見し、取り組みを検査し、改善に向けて変化に適応しましょう。
アーティファクト
アーティファクトは、各役割の人がスクラムの中で作り込む成果物です。
SBL（スプリントバックログ）
スプリントプランニングをした結果出来る、スプリント内でのタスク群。
POとTeamがお互い納得し、合意できていること。
PBL（プロダクトバックログ）
プロダクトの価値最大化のため、今後やっていくであろう全タスク群。
一つひとつのタスクはPBI（プロダクトバックログアイテム）と言う。
スプリント内のあらゆるタイミングで追加、更新、削除しましょう。
障害リスト（Impediment List）
スクラム全体をとおして、上手くいかない要因をまとめたリスト。
主にSMが追加、更新、削除、対応することが多いかもしれません。
内容は何でもOKです。
例えば毎回朝会が遅れるとか、自動テストが長い、など。
A.C.（Acceptance Criteria）
PBIの完了をPOが受け入れる条件。POの責任で決めること。
スプリントレビューでツッコミが入ろうが、A.C.が満たされているなら完了は完了。
ツッコミに対するタスクは別PBIとすること。
逆に十分作り込まれた成果物があろうとも、A.C.が満たされていないならTeamは勝手にPBIを完了扱いにできません。POも納得した上でA.C.を変えるなら、そこは柔軟に。
その他
スプリント停止
POの責任で、スプリントを止めること。
スプリントを途中でどうしても止めたい場合、スプリント停止を宣言し、全てをやり直す。
完了条件（Definition of done）
Teamの責任で決める、PBIをリリース可能と判断する条件。
DoneとUndoneの2つの概念がある。
PBI一つひとつで満たすべき条件（例えば単体テストが実施済、関連ドキュメントが作成済、など）は、Done。
PBI一つひとつでは満たせない条件（例えば複数のPBIが揃ってはじめてテストできること、負荷テスト、など）は、Undone。
両方の完了条件を満たしてはじめて出荷可能（リリース可能）と判断する。
リリース可能なプロダクト（Potentially Shippable Product Increment）
A.C.やDefinition of doneを満たしたプロダクト。
おわりに
スクラムの基本的な考え方やルールは把握できましたか？
分かりづらい点やツッコミがあればぜひフィードバックをお願いします。
そして、スクラムに興味があったりすでに取り組みはじめているなら、共に頑張っていきましょう。
時には失敗することもありますが、まずはTry&Errorで良いと思います。
これからスクラムをはじめるなら、別記事も参考になるかもしれません。
それでは、良いスクラムライフを！
10分で理解するはじめての1on1 〜信頼関係コミュニケーション〜
こんにちは！
以前にも1on1で考えていることは記事にまとめましたが、今回は改めて1on1の基本を紹介します。
想定読者は
- 1on1という言葉を聞いたことがある程度の方
- はじめてマネージャーとなる方
- 1on1をする/しているが、よくわからないという方
より深掘りしたい方は別記事を見てみてくださいね。
- 1週間に1度、30分間で予定を入れる
- 現場のための対話を心がけ、現場主体で進める
- 小さな一歩でも良いから、次の行動をお互い約束する
本記事も要約すると上記と同じ話なんですが、
あらためて10分ほどで理解できる1on1の基本を押さえていきましょう！ 🤓
はじめに
1on1はマネジメントの1手法として使われることが多いです。
ということで、まずは「マネジメントとはなにか？」簡単におさらいしましょう。
マネジメントとは、森羅万象の中のなにかを良い方向に向かわせること。
いろんな言葉で表現されているので、詳しくは調べてみてくださいね。
manageの意味・使い方・読み方 | Weblio英和辞書
プロジェクトマネジメントや品質マネジメント、経営マネジメント、などなど色んな単語にマネジメントがついています。
英語のmanagementは管理や制御と訳されることもありますが、対象とする物事を良い方向に向かわせることがマネジメントのポイント。
1on1はチームマネジメントや組織マネジメントで使われることが多いので、今回はチーム（チーミング）を良い方向に向かわせることをイメージして1on1を考えていきましょう。
1on1の前段階の概念をなんとなく理解したところで、1on1の基本に入ります。
基本しか書かないので、早く実践した方やざっくり理解したい方に合うかと・・・ 😅
1on1する目的はなにか
ズバリこれという答えはありません。
チームマネジメントをうまくやるという大前提がありつつ、そのために必要なあらゆることを意識しましょう。
例えば、ベースとしてチームとの信頼関係が重要となるため、チームメンバーとの信頼関係づくりを意識しても良いでしょう。
チームメンバーの考え、意見、経験、性格、性質などを知ったり、逆に自分のことを知ってもらったり。
他にも、
- 関係している案件の進捗を上手くすること
- チームの状況を把握すること
- 抱えている課題を共有し合うこと
- お互い刺激し合いスキルを伸ばすキッカケとすること
- 上位の組織やその目標と相手を紐付けること
と、目的の候補を挙げればキリがありません。
所属する組織や会社での立ち位置、チームの状況、チームメンバーや自分の強みや弱み次第でも1on1の目的は臨機応変に変えて良いと思います。時には雑談するなど。
ただし、1on1自体が流れ作業になると意味がありません。なにかしら目的意識は持ちましょう。
1on1の背景にあるマネージャーの課題
別記事でも紹介していますが、1on1の背景には従来型チームマネージャーの課題があります。
- マネージャーは対話しなさすぎ、下手過ぎ
- マネージャーは現場を知らなすぎ、周りを振り回しすぎ
- マネージャーは自分で物事を抱え込みすぎ、客観視できなすぎ
など。
全てがダメなマネージャーがいるわけではありませんが、程度に差はあれどなにかしら課題を感じたことはないでしょうか。
マネージャーとしてもっと上手くやれるはずにもかかわらず、手間取っている印象。もったいない。
1on1のやり方
1on1自体には決められたルールはありません、おそらく。
よく聞いたり紹介されたりするやり方の特徴は、定期的、相手主体での対話、お互いにフォロー、次のアクションを約束する、など。
定期性
まずは週に一度、30分ほど話すと良いでしょう。
定期的にやらないと、チームの根幹であるチームメンバーをないがしろにしがち。
顧客や上司や同僚とばかり話したり、マネージャーがやる必要ない仕事をこなしたり。
やることが多すぎるという課題があるなら、尚更1on1の時間だけは死守しましょう。
チームメンバーをマネジメントする1on1を重要視し、重要でない仕事は減らしましょう。
相手主体
話しすぎず、チームメンバーの話を傾聴したり共感したりしましょう。
聞き流すだけとか、オウム返しだけとは違います。念の為。
あなたが一方的に話す場では、参加するだけの無意味な会議と同じです。
チームメンバーが話す内容に対して深掘りできるよう質問したり具体化したり、あなたが得意な方法でフォローしましょう。
約束
何を考えるか、今後何をしていくか、お互い次のアクションを約束しましょう。
ただ話すだけでは、現場の無責任化やマネージャーの放任主義が助長されがち。
時には雑談だけで楽しく終わるのも良いですが、チームメンバーの成長のためにもできる限り次のアクションにつなげましょう。
1on1をあなた流にハックするコツ
目的、背景、やり方と紹介してきましたが、まだなにかモヤっとすることはないでしょうか？
1on1は万人に合うわけではありませんし、今回紹介した内容で全てを説明しきれているわけでもありません。
あなたの経験や価値観はあなただけの強みですから、それらを活しきることが腕の見せ所です。
雑に1on1をやったり、調べ尽くして変に固くなったりはせず、基本は押さえつつ今モヤっとしていることを改善したあなた流の1on1を生み出しましょう。
例えば、目的や状況によってはあなたからのフィードバックを全面に出し、チームメンバーに内省を促しても良いと思います。
相手や状況によっては、進捗報告会やただ傾聴するだけの場としても良いかもしれません。
コツがあるとすれば、下の3つをハッキリさせること。
- あなたが一番解決すべきと考えていること
- その解決に向けて一番上手くフォローできると思うこと
- フォローするために相手に求めること
長々と考える必要はありませんが、たまには1on1と同じ時間（30分）か、せめて数分でもチームメンバーとの1on1を事前にイメージしてみましょう。特に最初の頃は 👻
1on1にこだわりすぎないこと
1on1は1つの手法にすぎません。
場合によっては1on1を使わないという選択肢もあります。
ただ、
知らないから、
やったことはないけど意味ないと思うから、
誰かにやれと言われてないから、
やらない。というのはもったいない。
良いところは取り入れ、良くないところは改良し、ケースバイケースであなたのチームマネジメントを洗練させてください。
おわりに
初めてマネジメントを担当する方は安心してください。
マネジメントは大変難しく、上手くできなくて当たり前とも思います。
最初上手くいかないからといったヤケになったり自己嫌悪する必要はありません。
ただ、マネジメントの失敗はチームや組織にとって致命的になる場合もあります。
やる以上は全力で取り組み、盛大に失敗し、挑戦を続けることでベストなマネジメントに近づいていきましょう。
マネジメントの道は進めば進むほどその長さや困難さに絶望しますが、人の成長や自分の成長を間近で見られる面白い道です。しかも組織の成果にもつながります。
大変だと思いますが、共に頑張っていきましょう！
