こまぶろ

技術のこととか仕事のこととか。

『なぜ、わかっていても実行できないのか』を読んだ

ジェフリー・フェファーとロバート・I・サットンの『なぜ、わかっていても実行できないのか』を読んだ。これも以前のメモの微修正だけど、メモを読み返しているともう一回読んでもいいかなと思った。

なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント

なぜ、わかっていても実行できないのか 知識を行動に変えるマネジメント

 

 

原題は"The Knowing-Doing Gap"ということで、知識が行動に結びつかないということに対してメスを入れている本。原因としては、

  1. 問題を話し合っただけで仕事をした気になる
  2. 過去のやり方にこだわりつづける
  3. 部下を動かすために恐怖をあおる
  4. 重要でないことばかり評価している
  5. 業績を上げるために競争させる

の5つに分けて議論されている。

 

発言の多さとリーダーシップ

発言の多い人ほど影響力が強く、ステータスが高く、リーダーにふさわしいと思われている。男性マネジャー諸氏を押しのけて部長に抜擢された女性に、その理由をたずねたことがある。冗談めかして彼女はいった。「私がおしゃべりで、ほかの人にしゃべらせないからでしょう」。はからずも、この言葉はグループ・ダイナミクスの原理を表している。発言が多いことと、相手の発言をさえぎることが、グループの人間関係に大きく影響する。(55)

自分が多弁な方なので、非常に納得がいく。見る目のある人は発言の量で評価したりはしないだろうけれど、ぱっと見て発言が多い人は「バリュー出してる」ように見えがちだろう。リーダーシップとは別の文脈だが、会話が多い会が必ずしも盛り上がっている訳ではないというのも思う。

 

経験と行動

むやみに経験に頼る体質では、知識を行動に移せない。なんらかの変化を起こすのは不可能だ。記憶を頼りに、何も考えずに行動するからである。それが意味のある行動かどうか、疑問ももたない。たとえ疑問を感じても、反対の声を上げたり、別のやり方を提案したりする勇気はない。(78)

古いやり方に固執する組織というのはよく聞くが、ここで言われていることはそれとはまた別の、しかし納得のいくことだ。思いつきでしか新しい行動が生まれない組織というのはよくある。それが経験をきちんと消化することすらできていない場合の方が多そうだが。

 

恐怖によるマネジメント

逆境時に恐怖心を追放する方法

  • 予測……何がいつ起こるか、当事者にできるかぎり十分に知らせる。
  • 理解……なぜそういうひどい行動が必要か、詳しく説明する。
  • 自制……何をいつ、どのようにして起こすか。できるかぎり自分の力でコントロールさせる。自分の運命は自分で決定させる。
  • 思いやり……直面している混乱や苦しみ、金銭的な重荷などに、思いやりを示す。

(142)

部下を動かすために恐怖を用いるな、と説く章の末尾の記述。閉鎖することが決まった工場の閉鎖間際の業績が、通常想定されるように悪化しなかったケースの話は印象的。たとえ敗戦処理でも、前向きに仕事をさせることができれば全く違ってくる。

 

内製化

アウトソーシングやパートタイマー(賃金は低く、諸手当もいらない)を使って、経費を削減することの、何が問題なのか?まず、「重要なエレクトロニクス関連部品を外注する」と、「HPはもはや社内でフィードバックを行う機能を失ってしまう。フィードバックによって、生産力、品質、欠陥、コストなど、ハードウエアの設計について貴重な情報が得られたのだが」。設計と生産が分離するので、しだいにハードウエア設計の高い能力まで失うことになる。(151)

書籍の中の重点は、このあとに続く「雇用機会の確保より、コストや収益、効率などを優先するというメッセージが社内に伝わる」ことの害悪にあるが、内製化が叫ばれるソフトウェア業界の人間としては上記を引いておきたい。

 

個人の行動を評価すること

多くの企業が使っている評価システムには、暗黙の行動モデルがある。それは、人間を経済的な要因で動くばらばらの個体と考え、社会的な生物という面を無視している。評価が個人的に行われるのも、人を個別にとらえている証拠である。評価方法では、①個人の成績は個人の決断や行動の結果だとし、②決断や行動には個人のコントロールと判断力が働いていると考える。したがって、成績は個人のものとみなしている。(163)

本当に評価すべきものを見つけられず、仕方なく個人を評価している企業もあるかも、ということは考えてみてもいいのかもしれない。上記の引用が載っているのは「重要でないことばかり評価している」と題する章である(原題は不明だが)。

 

立ち入り検査

書類で査定することを、フィードバックだと勘違いしているリーダーが多い。「査定用紙に書き込むのは〈立ち入り検査〉であって、フィードバックではない」とケリー・アランはいう。……「立ち入り検査に頼ると、コストはかさむし、長期的には何も改善しない。組織の競争力は落ちるばかりだ。このことを私たちは歴史から学んできた」(171)

「○○は〈立ち入り検査〉であって、フィードバックではない」ってフレーズ強い。「品質管理の人間どもにぶつけ(ry」って人は多いのではないか。以前にも引用したが、ケント・ベックエクストリームプログラミングに、「エンジニア部門とは別に品質管理部門を設けても敵になるだけで品質は良くならない」という話が出ていたのは強烈に印象に残っている。

 

意識調査の意義

調査をするだけでは特別な価値はない。調査を行なっている会社は山ほどあるが、その結果は活かされていない。インテュイットの従業員と会社の価値観が、調査結果を活かしているのだ。けれども、会社の実践を評価する手段がなければ、総合的な文化や価値観は行動に結びつかない単なる善意に終わってしまう。価値観、文化、従業員の質などが知識や目的意識を培い、それを行動に移すのを意識調査が助けているのである。(174)

活かされる未来の見えない意識調査にうんざりしている社員のみなさんこんにちは。以前、自社でも意識調査をしようという話が持ち上がったけど、行動に移す体制が整えられそうにないなと思っていたら結局やっていない。メトリクスとるのも同じだと思う。

 

競争と組織文化

協調性を重んじる社風を真剣に守るために、ときには雇用ではなく解雇もしなければならない。才能はあっても、競争心が強すぎたり、この主張が強すぎたりして、会社の文化に合わない人には、辞めてもらうことだ。それには、断固たる決断や実行力が必要になる。(210)

この本は、投資銀行の競争文化に対してかなり批判的な態度。社内で競争をするとノウハウの伝達等に対する障害となるというような話で、外との競争については否定はしていないが、業界全体でパイを食い合うというのもあるわけで、競争というのはなかなかに扱いづらい。

 

まとめ

冒頭で氾濫するビジネス書について皮肉っていたのが面白かったが、この本で得た知識をどのように組織活動に活かしていくのかというとそれもまた難しい。アンチパターン集なので、「あ、うちの組織今ダメだ!」と認識することにまずは活かしていくべきものか。

Clean Coder を読んだ

Robert C. Martinの『Clean Coder』を読んだ。読んだのはだいぶ前。引用メモが残っていたので記事に。

 

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

 

 

実践し続ける、学び続ける

おおアーキテクトよ、コーディングをやめてしまうとはなにごとだ。すぐに自分たちが重要ではなくなったことに気づくだろう。おおプログラマよ、新しい言語を学ばないとはなさけない。いずれ自分が業界から取り残されるのを目の当たりにすることになるだろう。おお開発者よ、新しい規律や技法を学ばないとはふがいない。いつか同僚に置いていかれることになるだろう。(42)

これは訳者が工夫したのだろうか・・・。新しい言語を学ぶ、というのは『達人プログラマー』でもアツく推奨されていたが、仕事で使わないものを自力で学ぶのはモチベーション的にも機会的にも難しいなぁと感じている。あと、「学ばない人間を置いていく同僚」がいない環境は本当にダメ。

「ノー」と言う

プロは権力者にも真実を伝える。プロはマネージャに「ノー」と言う勇気を持っている。どうすれば上司に「ノー」と言えるのだろうか?なんたって上司だぞ!上司の命令には逆らえないんじゃないのか?それは違う。プロなら違うんだ。奴隷は「ノー」と言うことを許されていない。労働者は「ノー」と言うことをためらうだろう。だが、プロは「ノー」と言うことを期待されている。実際、優れたマネージャは「ノー」と言ってもらいたがっている。それ以外に何かを成し遂げる方法はない。(49)

「上司が余計な仕事を取って来やがる」という愚痴はしばしば耳にする。そこに「ノー」と言ってやるのがプロなのだ。しかし上司が「ノー」と言ってもらいたがる「優れたマネージャ」である保証はないのである。ダメなマネージャがのさばる会社からは、プロがいなくなっていくことになるのかもしれない。

「試しにやってみる」の甘え

試しにやってみるというのは、力を温存していたと認めることだ。試しにやってみるというのは、温存しておいた力を使えば目標が達成できると認めることだ。さらに言えば、温存していた力を使って目標を達成すると約束することだ。つまり、試しにやってみるというのは、成功を約束すると言うことなのだ。「試しに」やってみて、望ましい成果につながらなかったときは、失敗したということになる。(55)

この次の章(「イエス」と言う、ことについて議論されている)に寄稿されているロイ・オシェロフの「約束の言葉」(オシェロフ自身の『ELASTIC LEADERSHIP』で「コミットメント言語」として紹介されている)との関係で、上の記述を読んだ。原書あたっていないが、おそらくtry doing(できることを、実際にやってみる)なのだろう。日本人が「やってみます」というときのニュアンスは、try to do であることもあるような気もする。try doingの場合は、とにかく成果物を一度提出するから、そこで判断してください、という感じ。

早すぎる詳細化

ビジネスもプログラマも「早すぎる詳細化」の罠に陥りがちだ。ビジネスは、プロジェクトを承認する前に、これから手に入れるものを正確に知りたいと思う。開発者は、プロジェクトを見積もる前に、これから開発するものを正確に知りたいと思う。どちらもできるはずのないことを詳細化しようとして、コストを無駄にしているのだ。

詳細化されていたと思ったら、あとからコロコロ変わるんですよね。顧客の目があらかじめ入っていないときは特にそうなんだろう。ちなみに、不確実性ということについては、広木大地さんの『エンジニアリング組織論への招待』で、焦点を当てて論じられていた。意思決定を遅延させることによってコストを減らせないか?

緊急時に規律をやめてはいけない

緊急時になれば、自分が何を信じているのかがわかる。規律を守っていれば、その規律を本当に信じていると言うことだ。逆に言うと、緊急時に普段の行動を変えてしまえば、その行動を信じていないと言うことだ。平常時にTDDの規律を守り、緊急時にそれを守らないとすれば、TDDの効果を心から信じていないということだ。平常時にコードをクリーンに保ち、緊急時に乱雑にするのであれば、乱雑が速度を落とすことを信じていないのだ。平常時にペアを組まず、緊急時にペアを組むのであれば、ペアのほうが効率的だと信じているのだ。緊急時に安心して守れるような規律を選ぼう。そして、それを常に守ろう。規律を守ることが緊急時から逃れる最善の方法である。ピンチに陥っても行動を変えてはいけない。規律が最善の方法であれば、緊急時になっても守るべきである。(156)

この部分は実際のところどうなのか(『ELASTIC LEADERSHIP』のいう「サバイバルモード」「学習モード」「自己組織化モード」の分類とはどのような関係に立つか?)。とはいえ、ペアでやった方がミスが少ない、と考えて普段ペアプロやっている人が、障害対応で単独プログラミングしてバグを仕込む、とかは実際にありそうな話。

職人気質

我々は「職人気質」という言葉の意味を考える段階に来ている。これはどういう意味だろうか?その意味を理解するために、「職人」という言葉について考えてみたい。この言葉からは、熟練の技・品質・経験・能力などが思い浮かぶ。職人とは、急がずにすばやく仕事をして、適正な見積もりでコミットメントを果たす人のことだ。職人は、「ノー」と言う場面を知っているが、できるだけ「イエス」と言おうとする。職人は、プロである。

職人気質とは、職人の持つ考え方である。職人気質は、価値・規律・技術・態度・解答を運ぶミーム(情報遺伝子)である。

だが、職人はどのようにこのミームを身につけたのだろうか?どのようにすれば、このような考え方を手に入れることができるのだろうか?

職人気質のミームは人から人に伝えるものである。年長者から若者たちへと教え伝えられる。仲間同士で交換する。年長者が若者たちを観察するなかで再発見する。職人気質はウィルスのように精神に伝染するのだ。他者を観察してミームを手に入れることで、それを自分に根付かせることができる。

職人になれと誰かを説得することはできない。職人気質のミームを受け取れと説得することもできない。議論をしても効果はない。データは重要ではない。事例は無意味だ。ミームの受け入れは、論理的ではなく感情的なものである。非常に人間的なものなのだ。

職人気質のミームを身につけてもらうにはどうすればいいのだろうか?ミームは伝染することを思い出して欲しい。ただし、観察できなければいけない。つまり、ミームを見える化すればいいのだ。そのためには、自分がロールモデルとして振る舞えばいい。自分が職人となり、職人気質を見せてやるのだ。あとはミームがやってくれる。(179-180)

職人気質のミームがそもそも存在しない組織には、まず職人気質を身につけた人が必要なのかな、と思う。その最初の一人を得るためには、採用するか、外に一度出して感染させてから内に戻す、ということしかないだろう。

感想

みんな大好きボブおじさんの本。ジョークに満ちていて面白いし、やや過剰では・・・と思うくらいに要求が高くはあるものの、非常に重要なことが散りばめられている。この本を読んで「うるせえ」としか思えなくなったらプログラマとしては引退した方がいいのかもしれない。

XP祭り2018とその前夜祭(第2回enPiT-Proスマートエスイーセミナー)に参加した

9月8日(土)に早稲田大学で開催された「XP祭り2018」に参加した。Regional Scrum Gathering TokyoもAgile Japanも参加できなかったので、自分にとってはアジャイル関係で初めての大規模カンファレンスへの参加となった。

また、前日には同じ会場で「前夜祭」として「第2回enPiT-Proスマートエスイーセミナー: アジャイル品質保証と組織変革」も開催された。こちらにも参加した。

イベントの内容について細かく書くことはせず、面白かったことや印象に残ったことをいくつか書いておきたい。参加したセッション、ワークショップすべてに言及するわけではないということ、そしてそれは言及のないものに対する低評価を意味しないということを断っておく。

前夜祭:スマートエスイーセミナー

アジャイル品質保証と組織変革」というテーマに惹かれて参加した。「アジャイル」や「組織変革」が身近なキーワードであるのに対し、「品質保証」はどこかよそよそしい言葉である*1。これらが結び付くときにどういったことが語られるのかに興味があった。

品質保証とアジャイル

品質保証とアジャイルと組織変革というと、思い出す『エクストリームプログラミング』の一節がある。

品質部門を別に設置すれば、エンジニアリングにおける品質の重要性が、マーケティングや営業における品質と同等だというメッセージを送ることになる。エンジニアリングで品質に責任を持つ人がいなくなる。すべては他の誰かの責任だ。開発組織のなかにQA部門を設置したとしても、エンジニアリングと品質保証が別々の並行した活動であるというメッセージを送ることになる。品質とエンジニアリングを組織的に分離すれば、品質部門の仕事は建設的なものではなく、懲罰的なものとなってしまう。
ー『エクストリームプログラミング』128ページ

セミナーでは「品質部門を別に設けるな」ということが言われることはなかったが、上記のものと近い問題意識に基づく話が多くあったように感じた。永田さんが懇親会で仰っていた「QAは品質についての情報を開発チームに提供することで貢献する」というのもそうだし、Yoderさんの紹介していたパターンにも「障壁の解体」や「アジャイルプロセスへの品質の組み入れ」などといった話が出ていた。

Linda Rising さん

『Fearless Change」の著者であり、近頃よくそのモノマネを聴く機会があるLinda Rising さん。この日も、永田さんのお話の中に登場してきた。Agile Japan 2011の基調講演で来日された際に、永田さんが「QAとしてどう開発者チームに関わればよいか」と相談したところ、"Stealth"というキーワードをくれたと。開発者にとって見えにくい、邪魔にならない存在となり、まずは静かに観察することが大事だという話だったと記憶している。更に、2000年に出版された書籍のなかで既に「QAを早くから巻き込め」という趣旨のことを述べていたそうで、その先進性に永田さんは唸っていた。

The Pattern Almanac 2000 (Software Patterns Series)

The Pattern Almanac 2000 (Software Patterns Series)

XP祭り2018

t-wadaさんの基調講演

テスト駆動開発』の「付録C」は一度読んでいて、しかも2017年12月にt-wadaさんのお話を聴いたのは僕にとってはとても印象深い思い出となっているので、基調講演の内容はある程度は既知だった。しかしそれでも新たに得たものは確かにあった。

一つは、歴史について。今回の歴史についての語りは書籍よりも幅広く、wikiやパターンにも言及する、TDDの歴史に止まらないものであり、半ば「うっとり」しながら聴いた。学生時代に聴いた「国法学」の講義を思い出させるような、t-wadaさんの広い知識と語りの上手さが存分に発揮された上質なものだった。

もう一つ印象に残ったのは、DHHの「TDDは死んだ。テスティングよ栄えよ」によって批判されたTDDの教条主義化に関連して、t-wadaさんが自らの責任に言及したことであり、そのときのt-wadaさんの表情、声のトーンだ。別の文脈で「Uncle Bobは過激なことを言って世の中を前に進めるタイプのプロレスラー」という発言をされていたが、t-wadaさん自身がこの種の存在になることについて苦悩しているような印象をもった。

「ポジティブふりかえりマッピング

川口さんが急遽代打で開催されたワークショップ「ポジティブふりかえりマッピング」に参加した。ふりかえりをするときのフレーミングとして、プロジェクトについて他の人に「どうだった?」と聴かれたときに"It was great because..."と答えるとしたら、というものを紹介していただいたのだが、この英語の部分を川口さんがLinda Rising 風で2回実演してくださった。文化の違いの話を添えて、単なる笑いどころで終わらせないのがさすが。

また、アジャイル宣言がどのようにして生まれたのかという話を聴くことができた。集まった17人がインデックスカードに大事だと思う価値をそれぞれ書き出していったという話だ。t-wadaさんが好んでされる「Kent Beck と Eric Gamma が機内でペアプロしてJUnitができた話」と似たような面白さがある。

kawaguti.hateblo.jp

2日間を終えて

セミナーは、普段参加している勉強会とはかなり雰囲気が違っていたが、QAというあまり縁が深くない文脈の話を聴くことができてよかった。自社の開発における品質についても、人的な面と技術的な面の両方でもっと取り組めるものがあると感じた。

XP祭りは、普段参加しているイベントよりも更に一段上の熱気があり、登壇者も参加者も心から楽しんでいる場だというのが伝わってきた。ああいう場を作ることができるのは「コミュニティ」の素晴らしさなのだと思う。

そして、忘れてはならないのはスタッフの方々の献身だ。日頃から無料の勉強会にたくさん参加させてもらっている身であるから、何がしかの形でこれから自分も貢献していかねばとの思いを強くしたXP祭りだった。

エクストリームプログラミング

エクストリームプログラミング

*1:品質は、ソフトウェア開発者として、当然、自らの責任の範囲内のものだという意識を持っているが、「品質保証」は「開発者とは別の誰かの仕事」につけられた名前だという印象がある。

8月の行動履歴を雑にまとめておく

8月が終わってしまった。

このところ、どうにも抑制の効かない日々を過ごしていて、今週はブログも書けずにきてしまった。最低限のふりかえりをすることで、継続するという意気だけは示しておきたい。公私ともにやや慌ただしくなってきているので、今週は立て直しの週にしたい。

イベント参加とブログ執筆

日付 参加したイベント/執筆した記事 分類
1(水) 第20回 Scrum Masters Night! - connpass イベント
4(土) 第1回 Dockerハンズオン 初心者・中級者編 - connpass イベント
5(日) Connpass APIをLambdaから扱う〜Lambdaの非同期呼び出しによる分散処理〜 - こまどブログ ブログ
9(木) 逆境から新規事業をスタートアップする「仮説検証型アジャイル開発」の実践 - DevLOVE | Doorkeeper イベント
12(日) GitHubに草を生やして100日の節目にアウトプットをふりかえる〜ブログ・登壇・GitHub〜 - こまどブログ ブログ
17(金) 【2018年8月】ガオ流ファシリテーション基礎講座 - connpass イベント
18(土) カイゼン・ジャーニー・カンファレンス - DevLOVE | Doorkeeper イベント
19(日) 「充実とは価値観が満たされた状態である」? - こまどブログ ブログ
19(日) Scalaに入門してみることにした - こまどブログ ブログ
23(木) きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質 - connpass イベント
26(日) なぜ僕は「アジャイルを!」と叫ぶのか〜「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」に参加して - こまどブログ ブログ
26(日) 2018年8月23日「第133回白熱塾 きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」に参加した - こまどブログ ブログ
28(火) Meetup in Tokyo #44 -Agile2018 Conference 報告会- - connpass イベント

雑感

  • 勉強会参加しすぎ?
    • とはいえ得るものはその度にある
    • 人と出会える機会は代え難い
  • 「技術」が広すぎ?
    • 自分が身に付けたい技術はどのような「技術」か?
    • エンジニア組織に拘る理由はあるのだろうか?(懇親会で出会った方からの示唆)
  • 草を生やすことに拘るのを止めたらコード書かなくなってしまった
    • 業務でもコードを書かない時期が続いていて関心が薄まっている
    • 目的がないのでモチベーションが出ずに結局途絶した
    • Udemyの講座のコードがうまく動かずに止まってしまった
    • Scalaのテキストは読んでいるけど難しくてコードをバリバリ書くところまでいかない
  • 当たり前のことを粘り強くやろう
    • 人と話をすると、自分が意識的に避けている事柄の存在に気づく
  • 読みたい本がたくさんある
    • 身の入る時期にたくさん読んでおいた方がよいかも
    • 技術の勉強をするのが億劫な自分を常に感じる
  • 自分は何をしたいのか?
    • 一緒にいる人たちと楽しく過ごしたい
    • そのための手段として何を自分の武器にするか

今月のツイート選

2018年8月23日「第133回白熱塾 きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」に参加した

8月23日の夕方から、「きょん、やっとむ、ryuzeeらと語るアジャイル開発の本質」(@デンソー東京支社)に参加してきた。

connpass.com

錚々たる登壇者の方々であることに加え、Connpassで参加者として登録している方の中にも単独でメイン登壇者が務まる方が複数いらっしゃる豪華イベント。テーマとしても、「本質を理解しないままのアジャイル開発に挑む危うさ」というもので、どんな話がされるのだろうと期待を膨らませながら当日を待っていた。

各登壇者の発表資料&参加者の方によるグラレコ

各登壇者ごとに簡単な紹介と発表資料(きょんさんは未公開)をまとめておく。内容については、共同主催のクリエーションライン社からレポートが出ているので、そちらをご参照ねがいたい。

また、参加されていたgaoryu*1@DiscoveryCoach)さんと渡部そば(@sobarecord)さんがグラレコ(Graphic Record)をされていたので、ご紹介させていただく。

やっとむさん

やっとむ(@yattom)さん。お恥ずかしいことに、お名前に印象がなかったのだが、「安井力」という文字列は僕の自室の中にある何冊もの書籍に見出すことができる。翻訳書を多数出しておられて、ちょうど来週『テスト駆動Python』も出版されるところとのこと。

テスト駆動Python

テスト駆動Python

きょんさん

きょん(@kyon_mm)さん。Regional Scrum Gathering Tokyoなど、スクラムのイベントでの登壇が多数あり、エクストリームなスクラム実践者として有名だ。僕は、「しがないラジオ」のsp.22にゲスト出演されていたのを聴いてショックを受けたのが初めて彼の名前を知った時だった。

shiganai.org

(2018.08.27追記

資料の公開はなされないそうです。

ryuzeeさん

ryuzee(@ryuzee)さん。吉羽龍太郎さんというと、『SCRUM BOOT CAMP THE BOOK』の共著者の一人であり、よく出回っているスクラムの図の作者であり、アトラクタに所属するアジャイルコーチだ。Ryuzee.comにはしばしばお世話になっている。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

変則フィッシュボウル

お三方の発表後、登壇者の3人+3席にフィッシュボウル形式で入れ替わりながら座った方々によるセッションが行われた。こちらについては、発表資料もなく、イベントレポートでも記述が薄いので、手元のメモから一部を記載する。自分なりに理解しながら紙に落としたので間違っているところもあると思われることをご了承願いたい。

守破離」というが、スクラムを「まず守らせる」については?

  • 「ちょっと忙しくなるとやめてしまおうとする誘惑にかられるから、何度でも同じことをいう」(ryuzee)
  • 「やりたいようにやらせてみて、うまくいかないのを笑う」(きょん)
  • 「外野がガーガー言ってくるときは黙らせる」(やっとむ)
  • (きょんさんの発言に対して)「プロジェクト、プロダクトの成功に対して金を貰っているかどうかによって言い方が変わる。貰っている場合は重大な失敗をしそうになっているのを見ているわけにはいかない。」(ryuzee)

アジャイル初心者はどうやって始めればいいか?

  • 「絶対に成功しないといけないプロジェクトで始めない。練習する。」(ryuzee)
  • 「XPの方が始めやすいのではないか。技術的な部分への言及がスクラムにはない。」(やっとむ)
  • 「信用してくれる経営陣を持つこと、それに報いる気概を持つチームになること。」(きょん)

形のある「アジャイル」の先に何があるのか?

  • アジャイルは終わらないジャーニー」(ryuzee)
  • 「Unlearnの仕方がまとまることが次のプラクティスではないか」(きょん)
    • ある仕事にしか対応できないチームになってしまった(早すぎた最適化)
    • 早すぎた最適化をUnlearnする必要がある
    • そのうえで今に最適なものをどう素早く構築するか
  • 「世の中の多くのチームは最適化にまで達していないのできょんさんの話は多くの人には関係ない」(ryuzee)
  • 大事なのはチームではなくビジネスではないのか?(司会の成迫さん)

5分でできるチームの賞味期限は30秒では?変化し続けることが大事?

  • 「構造を決定するのではなく過程であり続けることが大事」(きょん)
  • 「お金を稼げなければ意味がなく、そのためにはたくさん球を投げなければならないが、中の人は今のプロダクトで勝てるはずだと信じられないといけないのが難しい」(ryuzee)
    • チームビルディングを叫んでいる人は、当事者意識があるか?圧倒的当事者意識は?
    • SIerの場合は、アジャイルでやって何にコミットすればいいのかがよくわからないので難しいのではないか。
    • 当たり前のことができていない、規律の部分をかなり指導した。
  • 「なぜビジネスは大事か?」(やっとむ)
    • 赤福は変化ができている。ビジネスを意識するだけではできなかったことなのでは?
    • エコシステムを存続させることを意識した結果が変化できる会社のあり方なのでは

ちゃんとやれていない組織には鞭を入れる必要があるのか?

  • 「変えられない会社で頑張るより移ったり独立した方が幸せになれる」(やっとむ)
  • 「大きい会社でも味方がいれば可能性がある、ミドルレンジ以上の人のサポートが得られるか」(ryuzee)
  • 「案件単位で、偉い人が興味を持たないようなものでやればいい」(ryuzee)
  • 「間違ったスイングの方法で試み続けるよりは見学に行く、コーチを呼ぶ」(ryuzee)
  • 「現場がやらされ感をもっていてはダメ、チームを連れてカンファレンスに行ったりすればいい」(きょん)
  • 「教育を徹底的にやる、トップダウンの場合はそれができる」(やっとむ)

自動車産業でのアジャイル。高品質、大規模なプロダクションにどうやって結びつければいいのか?

  • 「機能以外のソースコードが多くなるはず、それをプロダクトバックログに入れるのかどうか。」(ryuzee)
  • 「デモやPoCのコードは捨てた方がいい」(ryuzee)
    • どの段階で使うためのものなのかによって品質のレベルが違うはず
    • 品質を後から上げるのは難しい、だから捨てた方がいい
  • 「コードを2回捨てて3回目を使う」(きょん)
    • Royceのモデル、ソフトウェアは三回作る
    • 捨てるレベルはどこか?実装、アーキテクチャ設計、基本設計?
    • 捨てるレベルをどこまでに留めるかがチームの力ではないか
  • 「プロトタイプをTDDで作っていって、プロダクトコードだけを捨てる」(やっとむ)
  • 「車も1週間スプリントで作ればいい」(やっとむ)
  • 「どっかの原野に人工の街を作って、『人を殺せる』環境を作って試験をしまくるのがいいのではないか」(ryuzee)

自動車の開発におけるテストはどうするか?

  • 「ソフトウェアの場合も、自動テスト(xUnit、Selenium)の技術が育つのには時間がかかった。車の場合でも、似たようなことが起きない限りは難しいのではないか?」(やっとむ)
  • 「網羅性を求める前に、プロダクションラインを絞った方がいいはず。部品化、標準化が必要?派生開発が多すぎるのではないか」(ryuzee)
    • CI/CDの場合は、リリースするのは一本で、顧客ごとの違いはフラグで管理
  • 「10年かかることが今できていないのは10年前に始めなかった自分が悪い」(やっとむさんに急に振られた川口さん)

なんでアジャイルコーチと偉い人しか前にいないんですか?

下記のようなツイートをしていた及部(@TAKAKING22)さんが最後の質問者として問いかけた。

  • 「僕は現場代表です」(きょん)
  • (聴衆の方を見て)「みなさん、アジャイルを現場に取り戻しましょう!」(及部)

感想

先に公開しているこちらの記事を読んでいただきたい。

ky-yk-d.hatenablog.com

*1:ファシリテーションセミナーなどを主催されている方で、先日僕もワークショップに参加させていただいた。【2018年8月】ガオ流ファシリテーション基礎講座 - connpass