Training for D-Day

ブログの内容は個人の見解であり、所属する企業を代表するものではありません。

アジャイルソフトウェア開発宣言の誤解

agilemanifesto.org

プロセスやツールよりも個人と対話を、 のところ、 英語だと Individuals and interactions over processes and tools

なので、 プロセスやツールよりも、個々人(を信頼し)そして対話を重んじよう という感じのような気がする。

個人と対話 チームと対話

”と” が and なんだけど

個人といっしょに対話を 個人のみと対話を

と勘違いされる方もいらっしゃるようないないような。 日本語難しいですね。

プロセスをガチガチに決めたり、ツールでコミュニケーションを取るよりも、個々人を信頼し、対話を重んじよう

ってことですかね。

真訳アジャイルマニフェスト、でも書くか。

Interactionsだから、対話でもないのかな。相互作用だよな。キャッチボール、マッシュアップ、ミックスアップ的な。より響きあい、成長していくみたいな。 でも日本語だと対話で良い気がする。

Innovation Games

Product Backlog Refinementの効果的な手法の一つに、Innovation Gamesがある。

翻訳されていない。

基本的にゲームにしたほうが楽しいし、効果的である。 12のGameが紹介されている。

以下のようなときに使える。

What do you want to understand? Consider These Games
Unmet and/or idealized market needs. Product Box Me and My Shadow Buy a Feature Give Them a Hot Tub Remember the Future
Products and services usage and relationships. Spider Web Start Your Day Me and My Shadow Show and Tell The Apprentice
Product and service functionality Product Box] 20/20 Vision Me and My Shadow Speed Boat Start Your Day The Apprentice Buy a Feature
How to shape your product for the future. Remember the Future 20/20 Vision Buy a Feature Prune the Product Tree

パソコンの奴隷・アナログ回帰・適材適所

働き方改革や最近のコロナ騒動で在宅勤務・リモートワークが流行っています。

私自身は、在宅勤務・リモートワークは好きにすれば良いと思うのですが、
在宅勤務・リモートワークをしても生産性が下がらなく、オフィスの存在が不要だという意見もちらほら聞くようになりました。

この場合、『もともとオフィスでの仕事が、オフィスというものを効果的・効率的に活用できていないのではないか』という問いにつながると思います。
オフィスでの仕事のやり方を変えれば、これまでの数倍効果的・効率的にできると思います。

現在、ほとんどのホワイトカラーと呼ばれる人たちは、パソコンを使っています。WindowsMacUbuntuとかですね。

オフィスに行っても、ほとんどパソコン使ってるんじゃないですか。

打ち合わせ中もパソコンをずっと見てますよね。ノートパソコン・ラップトップの蓋を閉じることって移動中くらいでしょうか。

大切な書類も、パソコンやオンプレサーバ、クラウドにあるんじゃないですか。

仕事にパソコンを使うほど、生産性は下がります。

おそらくほとんど意味のない作業です。

特にソフトウェア開発をやっている方は、

・コードを書いて、ビルドする
・アプリをテストする

以外にパソコンを使わなくて良いと思います。

と言うBlogをパソコンを使っている自己矛盾ではあります(笑


何が言いたいかと言うと、

パソコンはあくまで、ツールなので、適材適所で使うべきということです。

もう本当に常識になってしまって、パソコンに記録しておくことが当たり前になりすぎています。

でもそれが生産性を下げます。

打ち合わせ中の議事録をその場でパソコンに書く。みんなパソコンを見てる。
共感できる議論ができるわけがない。


パソコンが得意なこと、パソコンにしか出来ないことって何でしょう。

ソースコードをビルドする・デバックする
・アプリを動かす
・長期的に記憶しておきたいことを保存する
スプレッドシートで計算を正確に素早く計算する
・インターネットを使って人に文章や絵を多くの人に読んでもらう・見てもらう。
・文章を書く


ぐらいかなー、私はこれぐらいしか思い浮かばないですね。

スプレッドシートに文章をすごい書いちゃったり、設計書書いたりしているところもありますよね。これも適材適所で、見極めが必要だと思います。
ほとんど制限がないぐらい、書けてしまいます。

これをA3の紙1枚しか使っちゃいけない、となったらものすごい頭をひねると思います。
そこから本当に大切なものが見えてくる。
制限がないと創造性が発揮しづらいのです。


今こそ、アナログに回帰しましょう。というのは言いすぎですが、適材適所の見極めですね。
とにかくパソコン、という思考停止をやめたほうがいいと思います。

あ、でも、紙を使うと、環境問題はあるなぁー。

Project ManagerとAgile Coach/Scrum Masterの考え方の違い

プロジェクトマネージャーの考え方 Agile Coach/Scrum Masterの考え方。
成果物は、プロジェクトのQCDの達成である。 成果物は、『学習する組織』であり、『自己組織化されたチーム』であり、そのような文化を持つ会社であり、人々である。
計画し、計画の通りに仕事をする。 ”計画すること”は重要だが、計画自体は役に立たない。
人・モノ・カネはリソースである。 人はリソースではない。人は学び、成長する。 学び、成長するものはリソースと呼ばない。パソコンなどの成長しないものはリソースと呼んでも構わない。
要求(スコープ)・期限・コスト(予算)の3つの制約は互いにトレードオフの関係にあり、コントロールできる。 時間と予算(チームの人々)は一定を保つ。 要求(スコープ)のみが変動である。 自分自身以外の他者はコントロールできない。ましてやマーケットは。 如何に変化に迅速に対応できるかが鍵であり、変化に迅速に対応するために、意思決定は、一番現場に近い人(チームメンバー)が行うことが最も正確で最も速い。
計画は、アクティビティの段階(要件、設計、開発、テストなど)を通してプロジェクトを完成させるにつれ、時間の経過とともにより正確になる。 計画は常に変更され、チームの実際のパフォーマンスに合わせて調整される続けるため、計画は時間の経過とともに正確になる。
時間通り、予算以内、要求通りであることが成功。(QCDの達成が成功) 顧客が必要とするビジネスバリューを顧客が得ること、チームがどれだけ成長でき、楽しんで仕事ができたかが成功の目安です。 顧客とともにチームは成長しますし、顧客もまた、ともに成長します。ともに成長することを楽しみます。
要求(スコープ)の変更は受け付けません。プロジェクトの後半にそれが必要な場合は、変更要求として扱います。変更管理プロセスを厳密にまわし、 変更箇所を周知徹底します。 要求(スコープ)は柔軟なままです。どんな種類の変更も、プロジェクトの後期であっても、受け入れます。ウェルカムです。 そこには透明性が存在します。顧客・ステークホルダーは、チームのキャパシティがどれくらいで、この変更を受け入れたら何ができなくなるのかが、チームの部屋に行き、メンバーと話をすると瞬時に把握できます。
プロジェクト全体をコントロールすることが私の仕事です。 プロジェクト全体をコントロールすることは可能ではありません。そもそも自分自身以外はコントロールできません。コントロールという言葉自体使いません。だから、私はチームがより組織やチームがアジャイルになれるようにコーチします。絶対の結果など保証できません。
タスクの進捗が価値の提供を示します。(ガントチャートのパーセンテージ) 動くソフトウェアのみが進捗と価値を提供します。

SAFeとLeSS

まず前提として、SAFeとLeSSは比較するようなものではありません。
SAFeの本質は、予算管理にあります。Lean Portfolio Managementを導入していないにも関わらずSAFeとは言えません。
Lean Portfolio Managementは、10週間(四半期)に一度、限られたバジェットの中での予算配分を動的に柔軟に変更する、ということです。これによりプロダクト毎の優先度を変化させていきます。
そのためにKanbanを使って、各Productの状態を把握したり、Program Backlogと呼ばれるProduct backlogのもっとEpicレベルのもののみを扱ったアイテムの優先順位を決めたりします。
また、開発チームはScrum、Kanban、XPなどどのような手法をとっても良いと書かれていますが、SAFeに出てくるScrumはScrumではありません。PO、SM、開発チームの役割がScrumと異なっています。 つまり、イテレーション開発です。Scrumではありません。

Remove References to Scrum from SAFe!



LeSSには、予算管理のような概念はありません。
これは明確に記載されている訳ではないので推測ですが、LeSSは、究極的に、1Productに予算権限・収支報告(P/L)まで割り当てることを見込んでいるからだと思います。各Productが一つ一つの会社のようなイメージでしょうか。
そこまでシンプルにすると、予算管理もシンプルになります。プロダクトバックログだけで予算・収支まで考えられるようになるぐらい、シンプルにする。
もちろん、Productとは何か、という定義は必要で、且つLeSSの場合は非常に、広いものになります。
LeSSは、Scrumと同じなので、PO、開発チーム、SMしかありません。CEOもCIOもCFOも登場しないのです。
LeSSは、”従来の考え方”に疑問を投げかけてくれています。
まとめる人、管理する人、整理する人って本当に専任で必要ですか?ということです。
究極的にはそうかもしれませんが、既存の企業は、この境地に辿り着けるのでしょうか。ボトムアップだと20年くらいかかりそう。


今現在、SAFeとLeSSは共存できないという見解です。なぜならLeSS = Scrumだから。
複数チームでScrumをやるとLeSSになる訳ではないのです。

ティール組織で言う、
オレンジ組織であれば、SAFe導入がしっくりくるでしょう。ヒエラルキーを保ったまま、大規模アジャイルを実践します。
グリーンからティール組織であれば、LeSSがしっくりくるかなと思います。ヒエラルキーがなくなりつつあります。マネージャーは残るかも知れませんが、役割は少なくなります。


SAFeは、Do agile
LeSSは、Be agile
SAFeは、ビジネスドリブン
LeSSは、現場、開発ドリブン
という感じがします。

  Essential SAFe(4.5) Large Solution SAFe(4.5) Full SAFe(4.5) LeSS LeSS Huge
規模 50~125人  1トレイン 2トレイン以上 2トレイン以上 LeSS:2Team-8Team LeSS Huge:9Team
役割 RTE/System Arch/Product Mgmt PO/SM/D-Team Essentialに加えて、 Solution Arch/Solution Mgmt/STE Large Solutionに加えて、 Epic Owners, Enterprise Architect PO 1人 SM 1人で3チームくらいまで見れる D-Team LeSSに加えて、APOが入る場合がある。 1エリアは4チーム以上。
バックログ Program Backlog Team Backlog or Kanban Essentialに加えて、 Solution Backlog Large Solutionに加えて、 Portfolio Backlog Product Backlog1本 LeSSと同じだが、エリア属性が加わる。
導入の考え方 (清水主観) 教育・研修によるトップダウンアプローチ マネージャーやCEOを先に教育する ←に同じ ←に同じ ボトムアップ(チーム中心)を重視 本質的なマインドセット変革 ←に同じ
際立った特徴 10sprintに1回、PIPlannningがある。10Sprint分の計画を事前に建てる。 ScrumMasterやProductOwnerがScrumはできない。=SAFeでも、スプリントという言葉は禁止されていて、イテレーションと呼ぶことになっている。 SAFe内で表現されているイテレーション開発は、Scrumではない。TOOになっている。仕組み上仕方ない。 SAFeの中からScrumという言葉を消してくれムーブメントが起こっている。 http://remove-scrum-from-safe.tilda.ws/ ←に同じ ←に同じ Scrumにいくつかのイベントを足しただけでシンプル ←に同じ
チーム 75%はFeature/25%はComponent ←に同じ ←に同じ Featureを強く推奨 ←に同じ
働く場所 同じ場所は必須ではない ←に同じ ←に同じ 同じ場所を強く推奨 ←に同じ

スクラムと経済学・社会学・心理学

あるCSTの方と話をしていて、スクラムは組織論と心理学に基づくと言われました。 もっとスクラムマスター極めたいと思ったら組織論と心理学を学べと言われ、ちょっと調べていたのですが、そもそも組織論ってどのような学問なのか調べていたら、社会学と心理学だという。 組織行動のマネジメントに載ってた。

また違うCSTの方と話をしたら、おそらくJeffとKen(スクラム創始者)は、偶然スクラムのやり方を発見し後から理論を紐付けているのだろう、と。

でもそんな文献どこにもないから、自分で考えようと思った矢先、めっちゃいい本出た。

世界標準の経営理論

世界標準の経営理論

あやうく通信制の大学入り直すところだったよ。危ない危ない。

これで、スクラムと理論を結び付けられるかも。 スクラムすべて、つまりプロダクトオーナー、スクラムマスター、開発チームにも関連すると思ったら印をつけている。
ということで、概要レベルでの紐付けは以下。今後深堀りしていこう。2020年のテーマができた(笑 

f:id:kshimizu1226:20200121055506p:plain


○=直接的に関係がありそう
△=間接的に関係がありそう

こうみてみると、意外にも社会学の繋がりは弱い。LeSSで考えるとまた違うのかも。
リアルオプションは不確実性という文脈で、どちらかというとアジャイルに馴染む。

SCP理論

SCP理論をベースにした戦略フレームワーク

リソース・ベースト・ビュー(RBV)

SCP対RBV、および競争の型

情報の経済学(information economic)

情報の経済学(エージェンシー理論)(agency theory)

取引費用理論(TCE)

ゲーム理論(Game theory)

リアル・オプション理論

カーネギー学派の企業行動理論(BTF)

知の探索・知の深化の理論(exploration and exploitation)

組織の記憶の理論(SMM&TMS)

組織の知識創造理論(SECIモデル)

認知心理学ベースの進化理論(evolutionary theory)

ダイナミック・ケイパビリティ理論(dynamic capabilities)

リーダーシップの理論(leadership theories)

モチベーションの理論(motivation theories)

認知バイアスの理論(cognitive bias)

意思決定の理論(decision making)

感情の理論(emotion theories)

センスメイキング理論(sensemaking)

エンベデッドネス理論(embeddedness)

『弱いつながりの強さ』理論(weak ties)

ストラクチャル・ホール理論(structural holes)

ソーシャル・キャピタル理論(social capital)

社会学ベースの制度理論(institutional theory)

資源依存理論(resource dependence theory)

組織エコロジー理論(organizational ecology)

エコロジーベースの進化理論(evolutionary theory)

レッドクイーン理論(red queen theory)

2019年振り返り

2019年もお疲れさまでした。2019年の印象に残った本をご紹介します。だいたい2019年は、漫画を除くと100冊くらい読みました。進撃の巨人はクライマックス、ワンピースもあと数年で終わりそうですね。


「影響言語」で人を動かす

「影響言語」で人を動かす

Coachとしての資質の一つに必要かも知れない、Profiling。この本では、LABプロファイリングとして人を14種類の特性に分けて、どのように分類していくかが語られている。

組織行動学が学問的にどのように派生されてきたかも記載されている良書。心理学や組織論を体系的に学びたい方にはおすすめ。

すぐれた意思決定―判断と選択の心理学 (中公文庫)

すぐれた意思決定―判断と選択の心理学 (中公文庫)

意思決定の方法が様々記載されている。

ファシリテーション・グラフィックの元祖らしい。ミーティングのススメ方や結束力の高め方などが記載されていて、何回も読み返したくなる。

Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (English Edition)

Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (English Edition)

  • 作者:Gojko Adzic
  • 出版社/メーカー: Neuri Limited
  • 発売日: 2009/01/05
  • メディア: Kindle
ビジネス部門と開発部門のコキュニケーションのギャップを無くしたい、そのために・・・という本。 ATDDやBDD、Specification by Exampleの先にある本。Kindleだとすごい安いので、電子版がおすすめ。

一兆ドルコーチ内に参照されていた本。まぁ、そうなんですよ。本音で語ることの重要性。めっちゃ重要。でもできないのよ。日本人。

一兆ドルコーチ。最高。

偉大な組織の最小抵抗経路 リーダーのための組織デザイン法則

偉大な組織の最小抵抗経路 リーダーのための組織デザイン法則

個人的には何も学ぶことがなかった本。1回読んでお蔵入り。学習する組織のピーター・センゲの友達が書いてるって書いてあったから読んでみたけど、微妙。

大規模スクラム(LeSS)の誕生前2008年ごろ同じ著者、グレイグとBassに書かれた良書。でもScaling Leanのほうが響いたな。 Avoid ... Try... で記載されているのは、あくまでガイドだからかな。

新インナーゲーム (インナーシリーズ)

新インナーゲーム (インナーシリーズ)

個々人に対してどうやったら良いコーチングができるのかな、というところで読み進めた。良書。 なんというか、例えば、テニスプレーヤーをコーチするときに、『ボールをよく見ろ』ではだめで。 『ボールがネットを超すときに、ボールの縫い目はどの方向を向いていたか?』という問いが、本当の集中力を必要とさせる問いであると。 確かに。
それをビジネスの現場ではどうするのか、考えをくれた一冊。

グループ・コーチング入門 (日経文庫)

グループ・コーチング入門 (日経文庫)

グループコーチングという単語では、ではおそらくこの一冊しか日本で出てないのではないか。集団に対するコーチングのハウツーが記載されている。 システムコーチング(ORSC/CRR) とも違う流派ではなる。ここからインナーゲームにたどり着いた。

新版だったのだが、魅力が薄れた。初版のほうが好き。

システム・シンキング入門 (日経文庫)

システム・シンキング入門 (日経文庫)

システム思考の練習問題がたくさん載っている良書。ループ図の前提として、時間軸を考慮したグラフを考えろ、とか、ループ図のパターンを理解するにはこの本が一番良い。

DevOps関連の本ではこの一冊が一番良いのでは。定量的にどんな指標がいいのか指南されている。

The Ten-Minute Trainer: 150 Ways to Teach it Quick and Make it Stick! (English Edition)

The Ten-Minute Trainer: 150 Ways to Teach it Quick and Make it Stick! (English Edition)

半端ねぇ。シャロンさんすげぇ。

これまでの設計論とかコーディングとかをまとめたような感じでそんな新しい発見はなかった。。。まとめとしては良いかな。逆にこれまで設計やプログラミングであまり本を読んでこなかった人は最初に読むとまとまってていいのかも。

生々しくて大好き。古くからの現場ってこうゆう感じだよね。

基本は、権限を委譲するって話。

DVD付き カラダをリセット+体幹力UPのコアトレーニング

DVD付き カラダをリセット+体幹力UPのコアトレーニング

  • 作者:木場 克己
  • 出版社/メーカー: 成美堂出版
  • 発売日: 2012/05/18
  • メディア: 単行本(ソフトカバー)
半年間ぐらい週末はこれをやっているけど結構いい。とくにエキスパート体幹は結構利く。

ものすごい良かったけど、体系だってない。からまとめ書こうかと思ったけど、まとめられず。

その国に住む人は、XXX(例えば、主体性とか、危険回避性とか)の傾向が強いとか弱いとかそうゆうのが研究されていたみたい。まぁ、なんとなくわかる部分もあるけど、 一概にそのくくりに当てはめちゃうのは危険だとは思う。参考にはなる。

完全教祖マニュアル (ちくま新書)

完全教祖マニュアル (ちくま新書)

達人のサイエンス―真の自己成長のために

達人のサイエンス―真の自己成長のために

奇跡の経営 一週間毎日が週末発想のススメ

奇跡の経営 一週間毎日が週末発想のススメ

モダンサッカーの教科書 イタリア新世代コーチが教える未来のサッカー

モダンサッカーの教科書 イタリア新世代コーチが教える未来のサッカー

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

  • 作者:
  • 出版社/メーカー: 丸善出版
  • 発売日: 2019/01/30
  • メディア: 単行本(ソフトカバー)
LeSSを実践するなら読んでおかないといけないけど、実践しながら読むとまた色々と噛み締められる。バイブルですね。でも 個人的には、↓のほうがおすすめ。

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Agile Software Development Series)

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Agile Software Development Series)

  • 作者:Craig Larman,Bas Vodde
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2008/12/08
  • メディア: ペーパーバック
Be Agileって言葉が出てきた最初の本なのかな?とにかくAgile謳ってるなら必読。後のLeSSに繋がる。
Be agile rather than do agile.