Agile2017 Day 4

Agile Comference 4日目です。金曜は基調講演だけなので、通常のセッションは最終日。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

Moral Foundations Theory: to help address conflict (Linda Rising) POPULAR

今日はFearless Changeの著者、リンダライジングさんから。話を聞いてるだけで落ち着いた気分になれる、定番のセッションです。今回はコンフリクトマネジメントの話。

衝突が起きたとき、どんな対応してる？まず衝突に勝ちたいっていう思いが最初に来るのではないか。そこで「私がバカだって教えてくれてありがとう」なんて思う人はいないよね。私もそう

衝突解決で世界を飛び回る友人の話だと、衝突が起こるのは、相手が情報を持っていないからだと思って、もっと情報を渡したいと思う。もしくは理解できない「あいつら」おかしい。

 なぜ「あの人たち」はその理由に耳を傾けないのだろう？ 

ファクトより前に、聞くかどうかは感情で判断して入り。今私はあなた方がロジカルじゃないって言ってるけど大丈夫？

行動経済学における確証バイアス。全く同じ情報を得ても、全く別の取り方をする人たち

さらにバックファイア効果。事実や証拠を使って議論しても、それは相手によって減殺されて、相手の論点をむしろ強化してしまうこともある。

 

認知的不協和。自己の信念と違うとき、すごく居心地が悪い。まじ無理。(という実験結果)

懐疑的な人と皮肉屋。Fearless Changeの懐疑派代表はいい質問者。でも皮肉屋は違う。ネガティブ指向のネガティブ。枝葉末節の話にこだわって、全体を見ないので、全然助けにならない。

私としてはFearless Change を買っていただけるとありがたいわけですけど。

この中でこの中で、今日のテーマだとFear Less が最初に読むべきパターン。スティーブンコヴィーの七つの法則もぜひみんな読んでほしい。

相手(あいつら)の側に行くにはどうしたら良いか。他の人たちが、自分とは違うことを考えている、そこに飛び込むのは難しいこと。でも実は単純な話(簡単ではなくシンプル)。

ぜひ、論理的に話をしてください。聡明な方々。

もう一つ、Personal Touch パターンも大事。

新しいアイデアには様々な人が様々な反応をして来ます。これがイノベーション普及曲線。

元になったエベレットロジャーズの本は多くの実証に支えられている。

この事象自体は動かせないので、うまく利用したい。抵抗を急いで取り除こうとしない。それはあなたが進歩的な仕事をしていることへの自然な反応。多くの人は賢くて、注意深く、自分の仕事にベストを尽くそうとしているだけ。組織内の多くの人があなた達と同じ視野に立つなんてありえない。

産業革命マインドセット。イノベーターとアーリーアダプターが試し、うまくいったら他の人たちが続く。

もう一つの重要なパターンは聞く、ということ。心をオープンにするだけでなく態度も。私は十分にあなた方をリスペクトしていて、その観点をいれる用意がある

 モラルトライブ

アジャイルはモラルトライブかもね。開発者とQAとか。考え方の違いがあるもの

 それぞれの人に違いがあるので、会話が成立しないのも仕方がないこと。同じ米国でも左右に分かたれている

すぐやってみて欲しいことは。あなた自身ではなく、相手の感じる価値に注目すること。オープンマインドになるためには、まずあなたの心を開かなければ。

ボーイスカウトの世界では、まず相手が共通のものを信じているというところから始める

相手の視点に立つのは難しいことで、練習が必要。「彼女はリンダ、ちょっとアグレッシブだけど、いい人(is ok)」

まだこの戦いの勝利を諦めてない？でも、勝つことはできない。相手も困っている。

休もう！

合意できなくてもこだわらない

国の分裂を防いだヘイズ大統領の話。

たくさんのセッションがあって忙しい中選んでくれてありがとう。(大拍手)

How we grew Mob Programming, preserved culture, and maintained quality (Christopher Lucian) POPULAR

モブプログラミング発祥の地、Hunter Industries で今なお複数モブチームのマネージャーを続けるChris Lucianさんの経験レポート。１モブチームから、スケールアップした一年半くらいの経験を論文にした。

Chrisさんは、Rakuten Technology Conference 2017 で東京に来てくれる予定で、この拡張の話と。もちろんモブの成立過程の話をセットでしてくれる予定です。

「ユーザーストーリーマッピング」のJeff Pattonさんと 

Jeff Pattonさんが短い滞在日程割いて会いに来てくれて、みんなでパシャリ

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

Agile2017 Day 3

３日目のレポートです。継続的デリバリーの Jez Humbleがキーノートに登場です。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5
 

Continuous Delivery in Agile (Jez Humble)

継続的デリバリー、DevOpsハンドブックのJez Humble の基調講演。タイトルは「継続的デリバリってすごそう (Continuous Delivery sounds great.)

継続的デリバリーとは、変化を安全に素早く継続的にユーザーに届けられる能力。

あらゆる点で継続的デリバリーによってゲームのルールが変わった。
かつての日本の製造業のよう。

ケントベックのXP、ポッペンディークのリーン、そしてUNIXが父

なぜUNIXか。

継続的デリバリーの導入が組織でうまくいかないそれっぽい理由はよく聞くけど、結局文化がクソだから

Amazonのデプロイ。11.6秒に一回デプロイ。
一方でよくあるデプロイは「投げて祈る」。

デプロイメントパイプライン。UIテストとか色々なチェックごとにコミットされる。紙でやるより全然いいよね。

米連邦政府のクラウドプラットフォーム。あらゆるものを記録する。一年半くらいでやるらしい。

コンプライアンスの規定も沢山やる。連邦政府がこんな風に動いたこと、たぶんない

以前のHPのプリンタファームウェアのプロセス。お互い信頼してないから、詳細に計画したり設計したりで随分お金と時間を使ってる。品質低いからマニュアルテストにも時間取られる。時間(サイクルタイム)も取られる。コミットまで1週間..

ハードウェアのバリエーション減らす。パッケージを単一に。継続的インテグレーション。包括的自動化。シミュレータ作る。

デプロイメントパイプライン。正しいことを簡単に

３年で効率化してイノベーションに時間がさけるように (山田日登志さんみたいだ)

経済性。この本オススメ

つぎは、大きな生命保険の事例。Too much Legacy。

カンボジアの寺院。木が生えてきて... というシステム

副社長がきて「これやって」「２年かかります」「これやって」「２年かかります」「これやって」「作り直した方が早いです」

アーキテクチャ上のアウトカム。チームはこういうことができるか？自律的に大きな変更ができる、...

NUMMI の話。GMの中では最悪の工場。トヨタとの合弁。組合はトヨタに全従業員の再雇用を要請。

途中で問題が起こったらアンドンコードを引く。人が集まる、マネージャが来る。マネージャがいうこと「手助けできることはある？」従業員がプロセスを改善する権限を持つ。build quality in

ジョンシュックの論文

複雑なシステムを作ってて、状況も違うので、プラクティスはコピーできない。

豊田喜一郎 : 設計盗まれても、私たちは学んでいるからさらに先に行く

DevOpsの原則

大野耐一

バカとは戦うな、もっと素晴らしいものを作れ

で、後半は、ソフトウェア業界の女性の比率が低いことに関する問題提起をしていた。医療や法律の修士は増えているのに、コンピュータサイエンスだけ80年代から女性比率が下がっている。なんでか。80年代にTVゲームは男の子のおもちゃというキャンペーンが行われたせいかも、というような話。

NASAのマーキュリー計画の裏にいた女性の映画「Hidden Figures」の人。

女性が劣っているということも科学的にない、というか個人差に比べれば、誤差の範囲内。

どうしてそこを気にするかというと、技術職は給与も高いし、社会的に大きなインパクトがある。人が足りないなら採用してない50%の人を無視してないで。多様性のあるチームのほうが成績いいというデータもあるし、女性起業家のほうがROIが高い。

じゃあ、なにができるか？性別や人種による差をなくそう。採用や評価の際にバイアスがかかってないかチェックしよう。

The Power of Play - Coaching Teams to Play at Work (Laura Powers) POPULAR

ちょくちょく会ってたんだけど、セッションに参加するのは初めてのLaura Powersさん。今回は仕事の中でのPlay(遊び)の重要性について。遊び心大事だよね。

昔シリコンバレーのHPに務めてて、すごくハイパフォーマンスなチームというのを体験した。その頃読んでたのはこの本。

で、その頃のオフィスってこんな感じ。

しばらくハイテク業界から離れてて、ひさしぶりに戻ってみたらこうなってた。

遊び心に溢れたオフィス。ドリンクもある。

なぜ遊びが大事かというと、コミュニケーションを促進するから。一年分の会話より、一時間一緒に遊ぶほうが、相手のことを知れる。

Playという本をおすすめしたい。

なんで遊びなのか？子供のためのものじゃなくて大人も遊ぶ！

遊びって、創造性、イノベーションを求められる問題解決。適応性も必要。

動物は遊ぶ。

人間も遊ぶ。大人だって。

ある企業のマーケティングチームのワークショップ。この人達みんな経営陣。

モブプログラミングの現場見たことあるかもしれないけど、あれも遊んでいるようにみえるよね。

遊びとは、日常を抜け出した活動。完全に熱中し、集中する。自分たちの空間と時間で。

遊びにもいろいろある。チームビルディングとか、シリアスプレイとか。

 ここからはレゴを使ったワークショップ。この本をベースにしてるよ。

 ということで楽しくやりました。

 

Fluent in Team Culture: The First Shift in Achieving Agility (Diana Larsen, Bonnie Aumann) POPULAR

Diana Larsen 初参加。

組織は複雑適応系。

複雑適応系の場合はパターンが有効(雑な説明ですみません)。

複雑適応系では、チームのメンバーは全体性を意識して動かないといけない。

アジャイルをはじめ、いろんな方法論があるけど、組織に合わせるのが難しい。そこで「Fluency」というアイデアに行き着いた。コーチはどのくらい流暢さを求められるか。チームはどうか。一からアジャイルを始めると、まあまず先にコードは書けないといけないけど、まあ出荷できるような状態なら、次に必要なのは、ナレッジワーカーとしての働き方へのシフト。これが最初のシフト。

チーム文化。組織やビジネスにとって価値のあるものを作る。多くの組織にとってアジャイルが求められるのはここで、チームがコミュニケーションをしっかりしてものを作る。満足させるものを作る。

それができるようになると、次のシフトが必要になる。チームのスキルのシフト。価値を素早く届けられるようになる。多くの組織では、これが本当に求められていること。チームの働く場所を整備して、環境を作る。メンバーは非常に高いスキルを持って、継続的デリバリーを行う。

一部の企業では、さらに価値を高めるために他の人たちとの関係性を見直したくなる。顧客との関係も見直す。これが次の変化。価値の最適化。価値を生み出すのはチーム。

さらに、ほんの一部のチームは、プロダクトだけでなく組織全体の変化に寄与することになる。これが4つ目のシフト。組織文化のシフト。

(ここでトイレに抜けてる間にワークが始まってしまっていたので、そそくさと退席。)

Agile Product Thinking: Stalwarts talk with Jeff Patton (Jeff Patton) POPULAR

満席で追い出されました。ジェフとは話せたからいいや。

 ということで三日目終わりました。

あと一日半くらい。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

Agile2017 Day 2

昨日に引き続き Agile Conference の記録を日記にしとこうと思います。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5
 

High Performance via Psychological Safety (Joshua Kerievsky, Heidi Helfand) POPULAR

Modern Agile で再ブレイク中の皆さん大好きジョシュアですが、SFAgile という2011-13年くらいにやってたカンファレンスで２年連続でキーノートやってて、ベイエリアのアジャイルコミュニティではもともと人気者な気がする。

今回は Modern Agile から心理的安全のセッション。心理的安全を確保すると、生産性が上がるというのがタイトルなんですけど、その時点ですでに納得なわけです。逆に心理的安全がないといかに無駄な説明が増えたり足引っ張られたりして生産性が下がるのがよく分かるので。

で、デミングの言葉から。「安全を感じないところで、ベストなパフォーマンスを出せるやつなんかいねーんだよ。」

「企業にとって長期的に一番いいのは、修繕とオーバーホールのために生産を一時的にやめること。そうすれば私の日報のいらなくなるし、私も失業する。」

コンサルタントの仕事の重要なところは、自分が抜けても大丈夫にしとく(相手が自らやったような気になってもらう)ことだというのを聞いた気がします。 

職場にはびこる恐怖に対処する本はこれ。

信頼が欠如すると悪循環が起こっていくと。

よくない仮説 -> 自己保身に走る -> 見える形での攻撃的な行動 -> ... 

ワークショップ。「他の人から見て、無知/無能/ネガティブ/破壊的な人と取られないように、あなたの行動を変えたことはありますか？」

あ、これワークのとき意味取り違えてたな。隣りにいた高橋陽太郎さんと噛み合わなかったのはそういうことか...。ごめんなさい。シルク・ド・ソレイユのチケットに集中して話を聞いてなかった...。

MTTCR (平均紛争解決時間)

昨日思いついたって言ってたがまあ冗談でしょ。

修繕です。問題が起こったときに、どのように組織が反応できるかというのは、大きな指標ですね。心理的安全がないと、「問題には気づいているけど、どう直していいのかわからないので、黙っておく」という行動が多くなります。逆に言うと、つぎのジョセフ・グレニーの言葉「組織の健康状態は、あなたが感じたタイミングから、組織で議論されるタイミングまでの経過時間で計測される」ということです。思ったらすぐ言える関係性や余裕が非常に重要ということ。

マネージャーは部下の衝突を解決するためにどんなコーチングができるか？

共感のトライアングル。私、あなた、関係。(そのうち調べたい)

心理的安全があるミーティングの原則。

みんなの貢献を促す。他の人の話に耳を傾ける。話の内容を復唱する。支配や中断を避ける。気配り、好奇心、決めつけない。

ということで、おなじみGoogleの図です。まずは心理的安全ありき。

モブプログラミングについて質問攻めの会

お昼に、Hunter Industries のモブ軍団のマネージャーの Chris Lucian が通りかかったので、みんなで質問攻めにしました。今週一番価値ある会になったんじゃないかという気がする。

で、同じくHunter の William Larsen と母上の Diana Larsen (アジャイルレトロスペクティブズの人) とパシャリ

How to go from Zero to Sixty in 19 years - Accelerated learning on the path to Agile (Woody Zuill) Popular

午後は、Mob Programming の伝道師 Woody Zuill の話を聞きました。といってもモブの話ではなく、人生の話。巷では、業務時間に勉強するかどうかというエントリが流行ってますが、なにを言っているんだお前は、という気がします。

まあ、勉強だったり技術習得は投資なわけですが、じゃあどうやれば成功できるか？っていうと、ファンドマネージャとしての力量が問われるわけです。

しかし短期的には成績に差が出るものの、

つぎの期を取ると、所詮ランダム。賢くて勝ち続ける人なんていないんです。

確証バイアスにすぎないわけです。

 偶発性。思ってもみないことに出会うのが人生。

他の人の事例を聞いたって真似出来ないし、勇気をもらうことくらいしかできない。

意図的に失敗して、失敗から学ぶ。

小さなステップで、学びながら進む。学んだことで、目標も変わるかもしれない。

つぎの一歩を決めるときには、より可能性が広がる方へ。新しいドアを開く。

よいメンターを探す。でもみんながメンターなんだよ。

古い本だけど、これ知ってますか？いかに考えるか。

みんなでうまくやっていく方法を学ぼう。

これが Hunter Industries の最初のモブチームだそうです。初めての見学のお客さんを受けてみんなで撮った写真。

まとめ。色々話してました。

記念写真パシャリ 

２日目は以上。スーパーでビール買ってきて軽く飲みました。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

Agile2017 Day 1

最近ほとんどSNSばかりでブログを書いておりませんが、今年も Agile Conference に参加しております。2009年からなのでもう８回も参加したらしいです。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

初日は基調講演から始まって90分の並行セッションが３つという構成です。

オーガナイザーからの説明とか。

リーダーシップに関する基調講演。潜水艦のマネジメントだった経験を踏まえて、マネジメント層の重要さとか、心理的安全とか自律性の話をしていました。

基調講演の後は、アジャイルコーチのスコアカードの話に参加。メトリクスを取ろうという話でした。

Productivity, Predictability, Responsiveness, Quality, Agile Maturity/Fluency, Business Outcome, Happiness という観点でメトリクスを出す。Rally(プロジェクト管理ツール)から取れるものと、アンケートやインタビューで。

Productivity(生産性)の例。緑がストーリー数、黒がバグ対応数、青が合計。

カンバンとスクラムを混合してるのでサイズ見積もりはなく件数だけとってる

この例ではより安定してきてる。

これはPredictability(予測性)の例。
下側の時は着手数の方が多い状態。上側は完了数が上回ってる状態。WIPを制御することで徐々に上になる。こうすることで、「タスクが山積みなんでいつ終わるかわかりません」状態を回避できるようになる。フローの効率化。

ここで会場から質問。「Weって言うけど誰？誰のためにデータ取ってるの？コーチやコンサルタントのため？チームのため？」

どっちのためでもある、というような回答だったと思います。（メトリクス系のとき、この点がいつも焦点になる気がします。マネジメントに管理しやすい数値を渡したいだけなら、それチームのためじゃないじゃん説。いやマネジメントが管理しやすければチームもやりやすいでしょ、という立場はあると思いますが、チームとの信頼関係次第かな。業務知識のないマネージャーさんに操作しやすい数字をあげても、いい方向には使えなかったりするでしょうし。）

このあと質問ラッシュになってました。

Agile Fluency / Maturity つまりアジャイルがどれくらい出来てるか、はインタビューでトルっぽいです。ダイアナ・ラーセンとかがやってる、Agile Fluencyのモデルを参考にしている模様。

Jonathan Rasmusson : 7 Sources of Waste

「アジャイルサムライ」の著者で今はSpotifyでエンジニアしているジョナサンのセッションに参加。Pragmatic Bookshelf から新しい本が出てます。

テスト自動化の７つのムダ ... ３つは技術面、４つは文化面。

#1 スローテスト
まず見つけるのが難しい
すべてのテストが暴動ではない 1000ms 100ms 1ms
スローテストは生産性キラー

#2 Flaky Test
100%の信頼性で動かないテスト。
つまりテストの結果が揺らぐのは辛いってこと。
これ1月にMicrosoft行ったときにBingのUIテスト自動化の人も同じことを言っていた。
なるべく各環境(ロケールとかブラウザとか)で揺らがないような書き方を探すんだそう。

Kent Beck はそんなテストは消せと言っている。

#3 Premature Hardening

バグを取りきる前にUIテスト(自動化)に入ってはいけない。

こっから文化

#4 Lack of Language and Framework
共通言語(結合テストがなにを意味するかとか)がないと辛い。テストのフレームワークが統一できてないと辛い

#5 Lack of Skills

必要なスキルがないと辛い

#6 Artificial Separation of concern

責任を変に分割してると辛い (開発者とQAとか)

一つの作戦はテスト中の列をタスクボードから削除。

#7 Lack of perspective

しかし観点は必要なのだ。

最後にSpotifyの話

ダッシュボード作って常に見えるようにしている。テストコケてないかとか、各種メトリクス。

チーム(Squad)によっては専任のテスト自動化のロールの人がいる。例えばクルマのメーカーとの共同プロジェクトですごい短い期間でクルマ(TeslaとかBMWって言ってた)でSpotifyの音楽を流せるようにしたんだけど、こういうテストは専門家がついた。

生産性向上のための専任チームがいる。これはプロセス改善するという意味ではなくて、技術的に解決する人たちという意味だと思う。DevOpsとかツール整備とかそういう感じだろう。

毎週リリース。これはきついけど守っている。ユーザーからフィードバックもらうためには必要なこと。毎週機能をリリースする。

テストエンジニアの社内認定試験を作った。(このへんは How Google test に近いな)

ということで、本を出したので読んでね。(日本語版は９月にオライリージャパンから出版予定だそうです。)

よいまとめであり、かつSpotifyの話が聞けてすごく勉強になりました。

昼ごはん食べたときに「タフクエスチョン用意しといてね」と言われたので質問。

「こういう話って、非エンジニアの偉い人に説明するの大変じゃん？どうしたら良いと思う？」

答え「わかんね。カナダのエネルギー系のプロジェクトのときは、お金に換算して説明してた。Spotifyはファウンダーがエンジニアで、もともと技術的解決をする仕事をしてて、その３つの柱の一つがSpotifyだった...」

まあ、そういう時代かなーと思う。 

最後に日本人とパシャリ

で、このつぎのセッションが David さんの非エンジニア向けにクリーンコードを説明する方法のセッションでした。熱く語っていた。

※ Agile 2017 日記のリスト -> Day 1 | Day 2 | Day 3 | Day 4 | Day 5

Joy, Inc. のジグソー法ワークショップ

Developers Summit 2017 でやった、Joy, Inc. のジグソー法ワークショップの資料を公開しました。Joy, Inc. は2000年代初めからアジャイル開発とデザイン思考を取り入れて顧客を巻き込んだ受託開発を行っている、メンローイノベーションズ社の取り組みについて、ファウンダーであり現職のCEOであるリチャード・シェリダン自らが描き下ろした本です。米国のアジャイルコーチの多くが見学ツアーに訪れる、活きた実例であるメンロー社の徹底した顧客志向の文化に触れることができます。

書籍の無料お試し版(電子版、固定レイアウトのみ Kindle  Kobo ほか)がありますので、購入前の方でもこのワークショップを行うことができます。イベントなどでワークショップを行うこともできますので、お声掛けいただければ幸いです。

ジグソー法の読書会への適用は教育心理学概論読書会で試みられ、知識構成型ジグソー法 | 東京大学 CoREF を参考にさせていただきました。この場を借りてお礼を申し上げます。

speakerdeck.com

無料お試し版で公開されている部分 

以下の４つの部分を無料版に入れていただいております。開発者、プロマネ、UX/要件定義担当にとって興味がありそうな部分を抜き出しました。ワークショップではこのうち３つを使いました。

1. 喜び？ご冗談でしょう  P.7-12 

2. 頭は二つ … コンピュータは一台 (ペアプログラミング)　P.62-69

3. プロジェクト計画折り紙　困難な選択をつきつける (プロジェクト計画)   P.98-103

4. そこにある断絶 (ユーザーエクスペリエンス/デザイン思考) P.138-146

 

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジグゾー法ワークショップの模様

100名超え、かつ、短時間のワークショップでしたが、みなさん楽しく議論ができたようです。無料お試し版は、ジグソー法型の読書会をやってみるのにも最適な分量を考えて作っていますので、ぜひ試してみてください。いろいろな本でジグソー法を使った読書会をやっていますが、どの本もどの回も満足度は高いです。

永瀬さんの実況解説付きビデオはこちらです。

Joy, Inc.Jigsaw Reading at Developers Summit 2017

Joy, Inc.Jigsaw Reading at Developers Summit 2017

Joy, Inc.Jigsaw Reading at Developers Summit 2017

ジョイ・インク 役職も部署もない全員主役のマネジメント [ リチャード・シェリダン ]

人付き合いの話

周りの目が必要以上に気になってしまう人がいます。たぶん生まれ持ってしまったか、家庭や社会の環境との付き合いで長い時間をかけて作られてきたそうした感覚なのだろうと思います。もし生存のために必要に迫られて獲得した能力だとすれば、急に変えるなんて難しいでしょうね。

私ももちろん相手が自分をどう思っているかは大変気になります。ものを教えたり、アドバイスするようなことを仕事にしてしまっているこの数年は特にそこは重要になりました。しかし相手の心なんてどうあってもコントロールできない。ストレスがある環境下でパフォーマンス出せるほど、人間がうまくできてないし...。どうするか....。

で、私なりにいくつか心がけていることを書いてみます。

なるべく攻撃してくる人や話が合わない人とは付き合わず、認めてくれる人とだけ付き合うようにしていけるといいなぁと思います。生きて行くために何人と付き合わなければならないかは、職業にもよると思うけど、実はそんなに多くない(かもしれない)。まあ、挨拶もするし、用があれば会話もするけど、仕事はしないと決めてしまうんです。すでに仕事を始めてしまっていたら、この仕事を最後にする。終わるまでは我慢する。早く終わらせる。

認めてくれてるけどある部分でいじってくる人は、単に気にしてることに気づいてないだけなんで、うるせーそこ気にしてんだよ、って言えばもう言わなくなることが多いかなと思います。

はっきり悪意を持ってる人は、意外とその人の状況も危うくて、嫉妬してたりするケースが多いので、距離をとっておいて憑き物が落ちるのを待つしかないかな。もう仕事に絡んでめぐりあうことはないでしょうけど。

....などなど。

相手の期待に"ある程度"応えていくことが、仕事というものの本質なので、「お前には期待しない」って思ってる人とは成立しないわけです。お金にならない。

一方、相手の期待に応えようとするだけでは期待を越えることができません。儲からない。

一緒にできる人は仲間として、そうでない人はお客様として、うまいこと付き合っていけるといいのかなと思います。(トヨタでは知識ある人は仲間にせよ、知識ない人は客にせよ、という言葉があると、以前黒岩先生に伺った気がします)

徒然ですみません。

ジョイ・インク 役職も部署もない全員主役のマネジメント

以前、ご紹介していた Joy, Inc. 日本語版が出版されます。邦題は「ジョイ・インク 役職も部署もない全員主役のマネジメント」です。 

ジョイ・インク 役職も部署もない全員主役のマネジメント [ リチャード・シェリダン ]

メンロー・イノベーションズ (Menlo Innovations) 社の創業から、社内の文化、どのように顧客とともにソフトウェア開発を行っているかについて、創業社長リチャード・シェリダン自身の手によって書かれた本です。

イントロダクション
1章　僕が喜び（Joy）にたどり着くまで
2章　スペースとノイズ
3章　自由に学ぶ
4章　会話・儀式・道具
5章　インタビュー・採用・立ち上げ
6章　観察のもつ力
7章　恐怖と戦い、変化を抱擁する
8章　ボスではなくリーダーを育てる
9章　カオスを終わらせ、曖昧さをなくす
10章　厳密、規律、品質
11章　持続可能性と柔軟性
12章　スケーラビリティ
13章　説明責任と結果
14章　アライメントー向きを揃える
15章　問題
16章　まとめ――喜びのなかへ
エピローグ――ひらめき
お勧めの先生たち
推薦者あとがき（川鍋一朗）
本書に寄せて（ケリー・パターソン）

著者のリチャードは、1999年ごろにアジャイル(ケント・ベックのXP)と、デザイン思考(IDEO)に出会います。それらのやり方を取り入れソフトウェア開発チームを目指します。

翌日になって僕はボブのところに行き、VP職を引き受けた。立場を利用して「めちゃくちゃイカしたソフトウェアチーム」を作るつもりだとも (P.23 )

ベックのWikiを読んで数週間後、今度はIDEOという会社がナイトラインというテレビ番組で取り入れられているのを見た。(中略) 三十分間の番組では、IDEOの仕事の様子を取り上げており、それはまさにベックがエクストリーム・プログラミングとして紹介しているやり方の実例だった。ベックの手法そのままではないとはいえ、IDEOは熱意のある会社であり、密接な協調によるチームワークと顧客との素晴らしい関係性を持ち、優れたデザイン思考を持っていた。(P.25)

僕はチームのメンバーを全員集めた。十四名のソフトウェアエンジニアだ。そしてエクストリームプログラミングの話を聞かせた。彼らにとっては全く新しい考え方だ。それまでの経験と蓄積とはまったく異なる手法で、ショッキングと言ってもいい。最後に僕は聞いた。「みんな、どう思う？」

だれも、一言も言わなかった。(P.28 )

ここ二年ほど、クレアはまた別の手法を導入してきたが、失敗に終わっていた。親しみを込めて「ソフトウェア開発ライフサイクル」(SDLC)と呼んでいたが、業界では一般的にウォーターフォールと呼ばれる手法だ。このプロセスでは、中央集権的な委員会、定められた会議体、経営陣の承認、フェーズごとの審査と継続判断、委員による中間成果物の数知れないレビュー、などなどが求められる。(P.29 )

 実験が始まって三週間ほどたったとき、クレアが僕を呼び止めた。そして、まだ給料を払うつもりかと質問した。

「どういう意味だ？」僕は聞き返した。

「すごく楽しいんです。働いているように感じないんですよ。その上給料までもらっていいものか、ちょっとわからなくなって」(P.31 )

ある日の朝、ジェームズが興奮した様子で現れた。彼が案内してくれたのは、インターフェイス社が以前プリンタを製造していた、古い工場だった。(中略) ひらけた空間だけで、壁も、オフィスも、パーティションも、ドアすらない。巨大でオープンな、共同作業のための空間だ。いけるかもしれない！僕たちはこの場所を乗っ取ることにした。(P.32 )

この取り組みは成功し、しばらくして、業績好調の会社は2000年にシリコンバレーの会社に買収されます。しかし、インターネットバブル崩壊。親会社は経営が傾き、リチャードたちの拠点を含め全国のリモートオフィスを閉鎖、リチャードたちもレイオフされます。そこですぐ四人で、会社を興こす決断をします。それが、現在のメンロー・イノベーションズ社。15年にわたって、アジャイルとデザイン思考を通じて、ソフトウェア開発が必要な顧客に価値を与え続けてきました。

この本ではメンローで行われている、アジャイルに親しんでいる私たちにもおなじみのやり方の数々が紹介されています。デイリースタンドアップ、見積もり、計画ゲーム、見える化、コミュニケーション、採用からチームづくり、リーダーシップとマネジメントのすべて。 

そして、 私たちがUX(ユーザエクスペリエンス)だとか、UCD(ユーザー中心設計)と呼んている要件定義手法も取り入れています。

メンローで世紀の大発見をひらめいたのは、殆どのソフトウェアチームが何か基本的なことを見失っているとわかったときだ。僕たちの喜ぶべきゴールがエンドユーザに喜んでもらうことなら、そのエンドユーザーにはずっと利用し続けてもらわなければいけないのだ。ハイテク企業に限らず、ほとんどの人たちがいまだにソフトウェアには苦痛を感じている。しかし、あなたの会社と同様、ソフトウェアを使わなければ何もできない。(P.138)

このような紙ベースかつ手描きのユーザーエクスペリエンスデザインのプロトタイプは、実際のユーザーが検証する。ハイテク人類学者たちは、プロトタイプを触ってくれるユーザーを集めてくる。そしてデザイン案についての意見を求める代わりに、プロトタイプを使って何らかの作業をしてもらい、その過程を観察する。(P.150)

そして、開発の計画は開発者も顧客も巻き込んで行っていきます。「計画おりがみ」と名付けられた手法です。

計画おりがみというテクニックを使い(7章で詳細に説明する)、プロジェクトマネージャーは顧客をガイドする。計画シートの上に、おりがみで作ったストーリーカードを乗せていくのだ。計画シートもストーリーカードも、物理的な大きさにより予算と時間を示す。ストーリーカードは開発する機能を示す。必要な時間は見積もりの儀式ですでに見積もってある。計画シートの大きさは、その週に使える時間を示している。(P.99)

私たちが様々な本で読み、多くの人の話で伝わってきて、自分たちでも試してきた手法や文化の多くが、ここに結実していると感じます。そしてこの会社は、天才たちが作った「イケてるハイテクソフトウェアベンチャー」ではないんです。シリコンバレーですらない。決して手の届かない技術を使っているわけでもないんです。道具はすでに私たち、何年もかけて、十分に学んできました。この本に書いてあることで、理解できないことはおそらく一つもないでしょう。

ところで、リチャードの役職名はCEO兼チーフストーリーテラー。社長であり、また社内で起こっていることを外に伝えることを責務にしているようです。この本をはじめ、講演、社内見学ツアーを通じて、幅広く活動を行っています。いつか見学に行きたいものです。

12月19日の発売ですが、すでに一部の書店さんには先行して置いていただいています(写真は池袋のジュンク堂さん)。おそらくビジネス書の経営の棚にあります。アジャイルやソフトウェアの棚にも置いていただいているかもしれません。

 仕事やコミュニティで関わってきた、いつもの仲間たちであり、最高の先生たちと一緒に訳しました。素晴らしいレビュアーの皆さんにも手伝っていただいて、出版社の皆様の手厚い支援にも恵まれ、いつもの方法で翻訳作業が進められ、届けることができます。本当にありがたい、喜び(Joy)に満ちた一冊になりました。読者の皆さんにも私たちが感じた興奮が共有できることを大変嬉しく思います。

ジョイ・インク 役職も部署もない全員主役のマネジメント