「NO HARD WORK!」

NO HARD WORK!

最初にまとめ

こりゃすごい会社だわ。確かにこういう会社があっても良いと思う。サラリーマンとして、ちょっと憧れてしまう素晴らしい文化だと思う。 でも、おそらく相当優秀でかつモラルの高い人達だけが入れるような会社なのだろうなと。そうでない人たちの集団では成立しないのではないかと思います。

あと、こういう会社を目指して失敗した人たちが、世の中にはそこそこあるのではなかなと思う。

全体的な感想としてはそんな感じではあるけど、頑張りすぎてはいけないという点については参考にスべきものがあった。

会社について

  • Calmであることが重要
  • 目標は作らない
  • 会社に長期計画を作らず、6週間ごとに計画を決める
  • 社員のカレンダーを共有しない
  • 給料の交渉はない
  • 週40時間労働、夏は週休3日にして32時間
  • 休暇の旅行費用を最大5千ドルまで会社が負担

プロダクトについて

  • 新しいバージョンをリリースするときも古いバージョンを維持し、ユーザーに選ばせる
  • 利用料を上げる時でも、既存のユーザーに対しては古い利用料で使い続けることができるようにした

働き方について

  • チームは3人がベスト
  • Noを正しく使うべき。そうでないと損をする。

「スクラム現場ガイド」

スクラム現場ガイド

最初にまとめ

スクラムを導入したときに、まさに現場でぶち当たる問題とその対処方法が紹介されている。そういう意味では中級者〜上級者向けの本だと思う。

いくつかの本でスクラム開発は「守破離」が肝だと解説されているが、その「破」や「離」にあたるさまざまな応用的なテクニックが紹介されていて、ぜひとも取り入れたいと思った。

Part1 準備

第3章

コアチームメンバーとチームコンサルタント

コアチームメンバー:1つのプロジェクトに、フルタイムでコミットするメンバーで、機能横断的な役割を担う

チームコンサルタント: 複数のプロジェクトにまたがって専門的な領域を担当する。

コアチームメンバーというのはなかなかおもしろいというか、現実にもこういった、あの人のあのスキルがほしいな、という時はある。なんとなく理想論のように聞こえるけど、多分そうではない。ただ実際に導入する場合にはいくつか制限の中で運用することになる。 複数プロジェクトに関与するということは、

  • ある特定の問題を解決する
  • あるスプリントだけ、時間を決めて参加する

というような働き方になるので、あまり時間が求められるようなシーンでは難しくなりそう。

  • 比較的やることがはっきりしていて、いつまでにコレをお願い、と言えるようなタスクに向いているかも
  • 時間や内容次第では、コアチームメンバーとペアワークするだけでも良さそう

スクラムイベントには基本的に参加してもらうので、そういう点でのオーバーヘッドは出てきそう。あと、チームコンサルタントが毎回使う時間が違うので、チームとしてのベロシティの実績値にも影響がでるかもな。

第4章 ベロシティの計測

基準ストーリーから近似値を得る

基準とするタスクを分解し、それぞれ作業時間を予測して、合計時間をポイントにする。3つくらいのストーリーで行えばもう少し正確になりそう。

チームの稼働時間

一週間あたりに使える時間をどれだけとするか、チームの稼働時間をメンバーごとに最大時間、最低時間を決める。 しかし、これだと人のスキルとか習熟度によって結構違うんだよなと。

このあたり、初回のベロシティを”わからないなりに見積もる方法”についてこうやって書いた本は、これまで読んだものの中にはなかったが、やってみる価値はありそうだなと思った。

第5章 スクラムの役割

プロダクトオーナー・スクラムマスター・チームメンバーを兼任してはいけない。 当然だけど。当然だけどね。。

第8章 専任スクラムマスターの利点

  • 障害を取り除く、問題を解消する
  • 争いや言い合いを収める
  • チームの心のケア
  • パフォーマンスの報告
  • 各イベントにおけるファシリテーター
  • 必要なら手伝う(それ専任じゃないじゃん)

これまでどの本をみても「障害を取り除く」について抽象的な書き方しかされてなかったけど、それはなぜなら、とにかくチームのアウトプットを低下させる「すべて」が対象であるからなんですね。本書には少し例が書かれていました。ミーティングに遅刻する人の対応、他チームとの折衝、メンバーの病気による離脱、マネジメントとうまくやる、などなど。

第2部 現場の基本

第9章 エンジニアリングプラクティスにおける重要性

前述の話と合わせると、スクラムマスターとかチームコンサルタントのメンバーがペアプログラミングに参加するのは良いかもしれない。 スクラムマスターはリーダー的な立場の人になることが多いし、チームコンサルタントはその分野の熟練者を育てるという目的を達成できる。

第11章 リリースプランニング

  • 完全な機能の一覧と完成日を両方決めてしまうのは無責任である

プロダクトオーナーは、どちらか一方を固定し、状況に合わせて調整するべきだと。両方を固定してしまうと、多分開発チームは保守的な見積もりをすることになり、みんなが損をする。

良いスクラムチームは、完成日に、最小の予想と最大の予想の間のどこかに落ちるようにリリースすることになる。

第16章 ふりかえり

  • プロダクトオーナーは参加しないほうが良い
  • ふりかえりの内容は参加者以外見えない形に保存しておくのがよい

なるほど、可能な限り正直なコメントを言える場にすることを重視するということですね。スクラム開発の効率を上げるのが目的なので、変な気遣いをスべきでないと。だとすると、場合によってはメンバーを絞るセッションもあったほうが良いかもしれない。例えば協力会社のメンバーを入れる場合と入れない場合とか。

ふりかえりは基本的にすべての人が参加すべき、というのが原則だと思うので、これは応用編あるいはオプション的なアイデアのように思う。守破離でいう「離」になるのかも。

  • クロージングでスプリントに点数をつけてもらう

不満があるがふりかえりの場でそれを言えなかった人をあぶり出し、なにか問題がないか、ミーティングのあと個人的に質問する。特に日本の文化にこれは合いそうだと思った。

  • ふりかえりはスプリントに限らない

大きいリリースがあったあとや、顧客など複数のチームを巻き込んでおこなうなども有用。

第3部 救急処置                                                                                                                                                                                                                                                                                                                                                                                                                  

第18章 第4の質問

  • 「今回のスプリントゴールをチームで達成できる自信はどのくらいありますか?1〜10で答えてください」

一部のメンバーだけが気になっている細かい事象が後で発覚しないように、なるべく早く拾うための施策。あとは、自分の経験からだと、自分には危機感が結構ある一方で、他のメンバーがあまり危機感を感じてないみたいなことがあり、そういった状況を共有するのにも良いかもと思った。

第4部 上級サバイバルテクニック

第23章 維持可能なペース

  • イテレーションを短くし、バーンダウンチャートを監視し、だいたい85%くらいの力で働くようにコミットする

100%以上頑張っちゃいそうな日本人です。

29章 巨大なバックログの見積もりと優先順位付け

  • すべてのユーザーストーリーを壁に小さい順に並べて、ストーリーポイントが1,2,3,5,8... になる場所に線を引く。優先順位が大きいものは上に、小さいものは下に。

面白い。賢い。 出てきた数字を過信しないという前提でしっかり扱えば十分使えそうなテクニック。

あと、POがpriority付するときに理由を明確にしてもらうというのも重要。

「ザッポス伝説2.0」

ザッポス伝説2.0

最初にまとめ

顧客第一主義的にワオ!を生み出すことを理念としたザッポスという会社の思想に触れられる一冊。

サウスウエスト航空と企業文化がかなり似ているように思った。

ちなみにCEOのトニー・シェイってなくなってたのですね、、、良い意味ですごくCEOっぽくない活躍でたくさんの幸せを作った方でしたが、、ご冥福をお祈りします。

ザッポスのコアバリュー

  1. サービスを通してワオ!という驚きの体験を届ける
  2. 変化を受け入れ、変化を推進する
  3. 楽しさとちょっと変なものを創造する
  4. 冒険好きで、創造的で、オープンマインドであれ
  5. 成長と学びを追求する
  6. コミュニケーションにより、オープンで誠実な人間関係を築く
  7. ポジティブなチームとファミリー精神を気づく
  8. より少ないものから多くの成果を
  9. 情熱と強い意志を持て
  10. 謙虚であれ

意外と普通なものが並ぶ中、3の「楽しさとちょっと変なものを創造する」だけは面白いなと。 これを設立後7年経った2006年に導入して、価値観と合わない人は退職金を受け取って辞めたらしいです。

ダウンストリームインパク

サウスウエスト航空も含め、こういう顧客第一主義で、「ちょっとやりすぎなんじゃないか」と思わせるような会社が儲かっているのはなぜか?と疑問がわきますが、答えは本書の中にあります

問題を経験した人のほうが、継続して利用する傾向が見られることです。例えば、2017年のクリスマスに、注文に師匠が生じて返品した人や、私達が返金を申し出た人を追跡調査したところ、私達のサイトを再び訪れて、さらに多くの買い物をした人が、平均的な子役よりも多くいました。

まさに「損して得取れ」というというころでしょうか。しかも今はSNSの時代です。ワオを感じた人が、体験したことを美談として拡散してくれます。(自分の承認要求を得るため、というおまけ付きですが、拡散すると嬉しいという目的は一緒なので問題なし)つまり企業の「生涯ファン」になってしまう。仮にやりすぎと思える行為を投資と考えたとしても決して高くないと。

このように、何かしたら、12ヶ月後、18ヶ月後、更にその先に顧客はどのように振る舞うかを数値化したものを「ダウンストリームインパクト」と呼ぶそうです

ハーバードに入るより難しい会社

スタートアップと聞くと、例えばGAFAのように人の採用のハードルがかなり高くて、かなりのレベルの実力を求められるというイメージがあります。ザッポスもきっと同じような感じなのでしょうけど、本書を読み限り、基準が必ずしも実力や学歴ではなさそう。入社希望者の人間性がかなり重視されているように思いました。一言でいうと、「思いやりがあって、変化を起こしたいと思うひと」らしいです。

  • 経歴は関係ない
  • 大学に通ったことのない人が、電話オペレーターとして入社し、マネージャーを経て財務部門に異動したりする
  • 90日の社内インターン
  • バンドマンがコアバリューを歌う動画を撮って応募したら電話オペレーターとして採用され、ファンジニア(楽しさのエンジニア)に

などなど

ラクラシー

自己組織化するためのガイドラインとして、ホラクラシーという考え方をとりいれているらしいです。

  • 社員は複数の「サークル」に属し、複数のロールを担う
  • サークルのボスは「リードリンク」と呼ばれる
  • 民主主義的な意思決定
  • 殆どの決定はガバナンスの鎖を上位にたどる必要はない

面白いと思う一方、従来型の組織と本質的な違いはどこにあるのだろうか。それに、他のサークルと相反することをやったりとか、全く同じことをやったりとかしてしまいそうな気もするが、どのように管理されているのかな。 という疑問はおそらくコレを読めばかいてありそう。日本の(古い)企業文化にはすっげーなじまなそう。


本書は、エピソードを紹介する前に、社員の名前と一言紹介文のようなものがついているが、面白かったのを取り上げてみる

ホリーデラニー CHRO(最高人事責任者)

40歳で初めてタトゥーを入れた


ローレンベッカー コミュニティチーム

ザッポスに来る前は、ボートの底からフジツボを削り落とす仕事をしていたよ


ジョンバンチ 組織体制、CEOのアドバイザー

現在67歳。しょっちゅう頭をどこかにぶつけている

「インプット大全」

インプット大全

最初にまとめ

著者が実践しているいろいろなインプットの方法を紹介する本。 他人の勉強方法を学ぶのはおもしろい。 一番刺さったのはChapter1かな。

Chapter1 インプットの基本ルール

  • インプットは「量」より「質」を重視
  • 本当に必要な情報以外は捨てる勇気を

どちらも、わかっちゃいるけど難しい。

Chapter2 科学的に記憶に残る本の読み方

  • 読書は学びの最初のステップ
    • 本→動画→公演→1対1

最初のステップであるし、最初のステップでしかない。 言い換えると、本を読むだけではだめなんですね。アウトプットはもちろん、次のステップで更に学ぶことでより定着したり、実生活に活かすことができたりすると。

Chapter7 インプット力を飛躍させる方法(応用編)

  • 学びを欲張らない
    • 脳が一度に記憶して処理できる情報は3つまで

「素晴らしき哉、人生!」

素晴らしき哉、人生!

奇妙だろ?

ひとりの命は大勢の人生に影響し、 その人間が欠けると世界は一変する

-- クラレンス

人は他人と影響を与えあって、その集合で世界ができている。 だから絶望なんてしてはいけない。一生懸命生きることに価値がある。

また、利他的であれば、それはいつかかならず自分を助けてくれる。

「いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法」

いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法

最初にまとめ

「いちばんやさしい」と書いてあるが、超入門というわけでもなく、自分が過去に読んだアジャイル開発の本の中で、一番網羅的に説明されているような印象を持った。 新しい本だけあって、過去に出版されたアジャイル開発の良い本のノウハウが反映されているし、日本人が日本企業を意識して書いた本なので、表現や考え方にも違和感なく自然に頭に入ってくる。

例によって気になったところの覚書

Chapter1 アジャイル開発の世界

05 ユーザーとソフトウェアの関わり

顧客インサイトを知る

  • 重要なのは実際に顧客がとった行動とそれに基づく分析を行うこと。
    • Systems of Insightを構築

Chapter2 なぜアジャイル開発なのか

09 従来型の開発手法「ウォーターフォール

  • 非機能要件も明確にしておく

コレ忘れがちだけど大事。開発手法に関わらず。

10 顧客が本当に欲しかったもの

  • 某調査機関によると、開発したソフトウェアの3分の2の機能は使われていない

経験上、企画はいつもどんなときも、ブルーハーツの名曲「夢」を歌うものです。

あれも欲しい コレも欲しい もっと欲しい もっともっと欲しい

その結果がこれなんですな。 上で取り上げたSoIを構築することと、UX検証を行って落としていくことが重要なんですね。まあそれができる状態というのは、つまり開発済みなのですが。少なくてもバックログの順位というものを明確につけ、それを開発チームと合意することは重要と思いました。

関連記事: risingsun-system.biz

  • プロダクトを触ることで自分が表明した「欲しいもの」と「本当に必要なもの」のギャップに気づく

その通りなんだけど、ある程度は事前に気づいて欲しいところでもあるな、なんて思いました。試すのも無料ではないので。

11 ソフトウェア開発は不確かなもの

  • 現代のソフトウェア開発は急速なテクノロジーの進化や複雑化する社会情勢などからVUCAになった
    • Volatility(変動性)
    • Uncertainty(不確実性)
    • Complexity(複雑性)
    • Ambiguity(曖昧性)

なので変化に耐えうる手法が求められる。 そうだとするとウォーターフォールのような手戻りできない方法よりも、もっといつも軌道修正しやすい方法のほうが、より良いプロダクトにたどり着く可能性が高まるはず。 つまり、(細かい手法はどうあれ)アジャイルであるべき、ということになります。

agilemanifesto.org

Chapter3 アジャイル開発がもたらす変化

17 個人と対話

  • 相手の価値観を尊重し、ともに考えていく

19 顧客との強調

  • 顧客と開発側が課題を共有できていると、より本質的なアプローチが可能
  • 顧客からのネガティブなフィードバックがあるからこそ課題に気づくことができる

3つ合わせて、開発チーム以外の人たちと、この「チーム感覚」を持てたらほぼ成功な気がする。

22 自己組織化チームとリーダーシップ

  • サーバント・リーダーシップ:メンバーたちがビジョンへ向かうことを支援し、成長を促す。メンバーの声に耳を傾け、課題解決をサポートするリーダー

プレーイングリーダーがこれをやりはじめると、潰れてしまうので、リーダー的立場の人だけでなく、メンバー全員が持っているべき考え方なんじゃないかと思う。

23 アジャイルチームの成長戦略

  • チームに求められるスキルをそれぞれのメンバーが身につけていくことでチーム全体として成長していきます。

そうなんだけど、習得する時間がネックなんですよね。

24 筋肉質なソフトウェア

  • YAGNI(YouAin'tGonnaNeedIt)とは、「機能は実際に必要となるまでは追加しないのがよい」

すごく当たり前なんだけど、これは結構厳格に守ったほうが良いことで、ちょっと先回りのつもりで実装したりして、結局不要なものになったみたいな苦い経験を思い出されます。

Chapter4 アジャイル開発の中核にあるコンセプト

34 反復的な作成物レビュー

  • アジャイル開発の成果物は「プロダクト」と「チーム」なのです。インクリメンタルかつイテレーティブな開発を通じて、成長するのはチームでもある。

「チームの成長が成果物である」という考え方はすごくポジティブな気持ちになれる良い考え方だと思ったのでハイライト

  • 改善施策の候補は、重要度x緊急度マトリックスを用いて整理する

確かに。最近リモートでレトロスペクティブをやると、こういうマトリックス的な視点を忘れてしまって、緊急な問題しか書かないみたいになりがちだなとおもった。 緊急度の低い重要な問題にも目をつけないとですね。

Chapter5 小さく始めるアジャイル開発

36 タスクの見える化

ついついslackに残すだけにしてしまう場合がありますね。

40 ペアで作る

  • ペアプログラミングの対象はプログラミング以外にも当てはまり、「ペアワーク」と呼びます。
  • 緊急トラブルやツールの設定など1人で対峙することがつらい作業は、一緒に取り組むことで心理的障壁も下げられるでしょう。また、新しくチームに参加したメンバーの育成やベテランが持つ暗黙知の伝授など、教育に役立てることもできます。

これまでもなんとなくやっている事だけど、ちゃんと意識的に使うのはありかも。

41 やったことの見える化

  • Keep、Problemを共有し取り組むTryを決定したあと、最後にチームメンバーへの感謝を示すアクティビティです。感謝を伝えるというのは、「あなたの行動がチームにとってプラスになっている。その行動を継続してほしい」というフィードバックを行うことにほかなりません。

これは良さそうだなと思いました。チームへの貢献を目に見える形にするというのは良いことで、心理学的に言っても感謝を相手に伝えるのは、相手だけでなく自分の自己肯定感を高め、ポジティブな雰囲気にすることができる。

Chapter6 上手に乗りこなすためのカイゼン手法

46 チームの活動が形骸化し始めたら?

  • 「問題ありません」という発言が頻発したら要注意です。この発言の裏には、問題の解決を諦めていたり、そもそも問題に気づいていなかったりするケースが隠れていると考える。

すごくわかります。

  • 5本の指(ファイブフィンガー)を使って進捗状況を発言できる環境作りも対策の1つになります。

こうやって進捗状況や健康状態とかも含めて、数値化していくのは良いですね。5段階にするとみんな3にするので、「順調 or 要注意 or やばい」の3段階くらいで良さそうに思いました。

  • 問題が小さいうちに課題解決や意思決定し、進捗を妨げるものを除去していけばチームのパフォーマンスは上がっていきます。

朝会とかで早期に見つけていくのが良いですと。

  • その他マンネリ化したときの対策案
    • YWT
      • Y->W->Tの流れで、気づいた学びを次に活かすという視点
    • Fun! Done! Lean!
      • 楽しかったか、学びがあったかという視点

48 成果の停滞感に直面したら

  • モブプログラミングとは、第5章のレッスン40のペアプログラミングを複数人に拡大し、能力を結集させることによって生産性を向上させるプラクティス

おもしろそう。プログラマー+デザイナー+プロダクトオーナーでフロントエンドの実装を最適化するのとか。「モブワーク」かな

Chapter7

アジャイル開発を懐疑的に思っている人が聞いてくる質問と答え集

Chapter8 アジャイル開発はあなたから始まる

61 素直な声に耳を傾けよう

  • 巨人の肩に乗りながら、時には飛び降りる
  • アジャイル開発は「目的から考える」ことが重要。その一方で、感覚的な違和感についても逃さないようにする

この柔軟さがアジャイル開発の強いところかなと。ある程度幅をもたせることで、反対してくる人の対策もしやすい。

62 アジャイル開発の学びを深める、広げる

  • ハンガーフライト=チームや部署を横断する学び合いの場
    • アジャイル開発は失敗の歴史によって向上するものであり、自チームだけでは得られない知見をほかのチームから学び得る機会を作ることが大切

「ジョジョの奇妙な名言集 Part4-8」

ジョジョの奇妙な名言集 Part4-8

最初にまとめ

この本を読んでおもったこと。

読んでない本のセリフは「名言」とはならない(刺さらない)

やはり、言葉はコンテクストが重要なんですね。どういう状況で、どんな人間がどういう相手にどんな意図で発したか。それが薄いと伝わりません。 ということで、読んでないスティール・ボール・ランジョジョリオン編は、全然刺さらなかったので割愛します。 正直第6部ですらまだ解釈できてないのですから。。。 またそのうちSBR読みます。

第4部

もっとも「むずかしい事」は! 「自分を乗り越える事」さ! ぼくは自分の「運」をこれから乗り越える!!

-- 岸辺露伴

第4部で一番好きなキャラは岸辺露伴かもしれない

だが断る

この岸辺露伴が最も好きなことのひとつは 自分で強いとおもっているやつに「NO」と断ってやる事だ・・・

岸辺露伴

岸辺露伴といえばこのセリフ。 しかもこの時、良い関係とは言えない仗助を助けるためにNOと言ったのですよね確か。 Noと言える人になりたい。

あれ、第4部これだけ、、、 もっとたくさん名言あった気がするのだけど、、、そのうちまた本編を見直そう。

第5部

「柔ラカイ」トイウ事ハ 「ダイヤモンド」ヨリモ 壊レナイッ!

-- スパイスガール

第5部で一番好きなシーンは、このスパイスガールが覚醒し、トリッシュが人として成長する瞬間のところかもしれない。でも名言として取り上げるのはここで良いのかなぁ、、、

「覚悟」とは・・・ 犠牲の心ではないッ! 「覚悟」とは!! 暗闇の荒野に!! 進むべき道を切り開くことだッ!

-- ジョルノ・ジョバーナ

強い意思をもったジョルノらしい一言。

スゴクいい! いいビンタだ!!

-- メローネ

こはちょっと笑えてよいシーンだったな。

「結果」だけを求めていると人は近道をしたがるものだ・・・ 近道をした時、真実を見失うかもしれない やる気もしだいに失せていく 大切なのは「真実に向かおうとする意思」だと思っている

-- 警官

アバッキオの最後のシーンだと思うけど、正直記憶にはなかった。 良いこというなぁと。

第5部といえば、ジョルノがチョコラータを倒すときの無限オラオラ?も印象的なシーン。 でもどこを名言として切りとるかは確かに難しくて、やはりセリフというよりコンテクストを含んだシーンごと切り出すのがよいのかなあ。

第6部

第6部から難解すぎて、終盤のスネイル大量発生事件と、最後の輪廻転生みたいなものを表した1ページぐらいしか覚えてないっす。というか1度しか読んでないからな。あとでまた読みたい。

「ひとりの囚人は壁をみていた」・・・ 「もうひとりの囚人は鉄格子からのぞく星を見ていた」 あたしはどっちだ?

--空条徐倫

記憶にはなかったけど、またアドラー心理学とか、イソップ寓話の3人のレンガ職人の話とか、思い出した。