アジャイルソフトウェア開発宣言の誤解
プロセスやツールよりも個人と対話を、 のところ、 英語だと 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 |
パソコンの奴隷・アナログ回帰・適材適所
働き方改革や最近のコロナ騒動で在宅勤務・リモートワークが流行っています。 私自身は、在宅勤務・リモートワークは好きにすれば良いと思うのですが、 在宅勤務・リモートワークをしても生産性が下がらなく、オフィスの存在が不要だという意見もちらほら聞くようになりました。 この場合、『もともとオフィスでの仕事が、オフィスというものを効果的・効率的に活用できていないのではないか』という問いにつながると思います。 オフィスでの仕事のやり方を変えれば、これまでの数倍効果的・効率的にできると思います。 現在、ほとんどのホワイトカラーと呼ばれる人たちは、パソコンを使っています。WindowsかMacかUbuntuとかですね。 オフィスに行っても、ほとんどパソコン使ってるんじゃないですか。 打ち合わせ中もパソコンをずっと見てますよね。ノートパソコン・ラップトップの蓋を閉じることって移動中くらいでしょうか。 大切な書類も、パソコンやオンプレサーバ、クラウドにあるんじゃないですか。 仕事にパソコンを使うほど、生産性は下がります。 おそらくほとんど意味のない作業です。 特にソフトウェア開発をやっている方は、 ・コードを書いて、ビルドする ・アプリをテストする 以外にパソコンを使わなくて良いと思います。 と言う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の方と話をしていて、スクラムは組織論と心理学に基づくと言われました。 もっとスクラムマスター極めたいと思ったら組織論と心理学を学べと言われ、ちょっと調べていたのですが、そもそも組織論ってどのような学問なのか調べていたら、社会学と心理学だという。 組織行動のマネジメントに載ってた。
- 作者:スティーブン P.ロビンス
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2009/12/11
- メディア: 単行本
また違うCSTの方と話をしたら、おそらくJeffとKen(スクラムの創始者)は、偶然スクラムのやり方を発見し後から理論を紐付けているのだろう、と。
でもそんな文献どこにもないから、自分で考えようと思った矢先、めっちゃいい本出た。
あやうく通信制の大学入り直すところだったよ。危ない危ない。 これで、スクラムと理論を結び付けられるかも。 スクラムすべて、つまりプロダクトオーナー、スクラムマスター、開発チームにも関連すると思ったら印をつけている。 ということで、概要レベルでの紐付けは以下。今後深堀りしていこう。2020年のテーマができた(笑
○=直接的に関係がありそう △=間接的に関係がありそう
こうみてみると、意外にも社会学の繋がりは弱い。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冊くらい読みました。進撃の巨人はクライマックス、ワンピースもあと数年で終わりそうですね。
- 作者:シェリー・ローズ・シャーベイ,Shelle Rose Charvet
- 出版社/メーカー: 実務教育出版
- 発売日: 2010/08/10
- メディア: 単行本(ソフトカバー)
- 作者:スティーブン P.ロビンス
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2009/12/11
- メディア: 単行本
- 作者:Gojko Adzic
- 出版社/メーカー: Neuri Limited
- 発売日: 2009/01/05
- メディア: Kindle版
1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え
- 作者:エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2019/11/14
- メディア: 単行本
- 作者:ロバート・フリッツ
- 出版社/メーカー: Evolving
- 発売日: 2019/09/15
- メディア: 単行本
- 作者:Craig Larman,Bas Vodde
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2010/01/26
- メディア: Kindle版
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
- 作者:マーティ・ケーガン
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2019/11/01
- メディア: 単行本
LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)
- 作者:Nicole Forsgren Ph.D.,Jez Humble,Gene Kim
- 出版社/メーカー: インプレス
- 発売日: 2018/11/22
- メディア: 単行本(ソフトカバー)
The Ten-Minute Trainer: 150 Ways to Teach it Quick and Make it Stick! (English Edition)
- 作者:Sharon L. Bowman
- 出版社/メーカー: Pfeiffer
- 発売日: 2011/01/13
- メディア: Kindle版
レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
- 作者:David Scott Bernstein
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/09/19
- メディア: 単行本(ソフトカバー)
Release It! 本番用ソフトウェア製品の設計とデプロイのために
- 作者:でびあんぐる,MichaelT.Nygard
- 出版社/メーカー: オーム社
- 発売日: 2018/03/23
- メディア: Kindle版
- 作者:L・デビッド・マルケ
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2014/05/30
- メディア: 単行本
- 作者:木場 克己
- 出版社/メーカー: 成美堂出版
- 発売日: 2012/05/18
- メディア: 単行本(ソフトカバー)
- 作者:J・モーティマー・アドラー,V・チャールズ・ドーレン
- 出版社/メーカー: 講談社
- 発売日: 1997/10/09
- メディア: 文庫
経営戦略としての異文化適応力 ホフステードの6次元モデル実践的活用法
- 作者:宮森 千嘉子,宮林 隆吉
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2019/03/08
- メディア: 単行本
- 作者:リカルド・セムラー
- 出版社/メーカー: 総合法令出版
- 発売日: 2006/01/24
- メディア: 単行本
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
- 作者:Camille Fournier
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/09/26
- メディア: 単行本(ソフトカバー)
花粉じゃばらサプリ:奇跡の柑橘ジャバラに青ミカン成分を凝縮 1本: 1か月分270粒
- メディア: ヘルスケア&ケア用品
大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法
- 作者:
- 出版社/メーカー: 丸善出版
- 発売日: 2019/01/30
- メディア: 単行本(ソフトカバー)
- 作者:Craig Larman,Bas Vodde
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2008/12/08
- メディア: ペーパーバック