#今日の30分 ログ

ツイート

ピープルウェア

#今日の30分 +5分。「ピープルウェア」読了。組織の学習能力、コミュニティ作り、混乱の導入、働き方の多様性の話。コミュニティ作りのあたりで「一般的に適用できる作り方などない」と断言しているのが好き。時間をかけ、状況を見つつ、少しずつ形作っていくしかない。コミュニティだしね。

— ざっきー dev (@zakky_dev) June 24, 2019

ピープルウエア 第3版

Team Geek

#今日の30分 +1分。「Team Geek」流し読み47ページまで。本のミッションステートメントとかがいきなり打ち出されていてちょっと面食らう感。目的の明示と期待マネジメントがはっきりしている本は珍しい気がする。流し読んだ感じも、自分の態度を変えるのに必要な情報がありそうで良いね。 pic.twitter.com/jH9GTxGFlB

— ざっきー dev (@zakky_dev) June 24, 2019

#今日の30分 +1分。「Team Geek」流し読み131ページまで。コミュニケーション、リーダーシップ、有害な態度への対処法の話。この本、一冊全部心理的安全性の話をしているのでは。そりゃこの単語を使う前に読めと言われるわけだ。本来目指していたものを知るのには本当に良さそうな感じ。

— ざっきー dev (@zakky_dev) June 25, 2019

#今日の30分 -10分。「Team Geek」流し読み終わり。組織を変える話と、ユーザーとの関係の話。組織を変える話はFearless Changeとか組織パターンとか、他の本を思い出しそうな内容。プランBとして逃げるという選択肢を提示しているあたり面白いね。正しい方針だと同意する。明日から本読みだ。

— ざっきー dev (@zakky_dev) June 27, 2019

#今日の30分 +6分。「Team Geek」28ページまで。チームで働く理由と、HRTの内面化の話。どの話も刺さって痛い。特にエゴのあたりとかが効いた。HRT、どれも欠けてるなあ……相手を見ていない、という話に結局落ち着くのかね。少しずつでも良くしていきたい。自戒。

— ざっきー dev (@zakky_dev) June 27, 2019

#今日の30分 -3分。「Team Geek」39ページまで。チーム文化の話。タックマンモデルのことを思い出したり、ティール組織のことを思い出したりと興味深い。新参者が入ってきたときは一時的な混乱が発生する。流されるか、文化を保つか。良い文化は保ち、害は排除する。

— ざっきー dev (@zakky_dev) June 29, 2019

#今日の30分 +4分。「Team Geek」53ページまで。コミュニケーションの話で、何故するべきなのか、守るべき原則、方針の同期、日常的な議論をどうするか、という話。コミュニケーションは作っているものが正しいかを検証するために使う、という話が体感と一致する感じ。

— ざっきー dev (@zakky_dev) June 30, 2019

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • 全滅
• Dockerの本を買う
  • おすすめされた本を購入

今回の追加活動

• 「今日の30分」とは別枠で本を読む。
• 仕事で30分刻みの行動記録を残し、観察する。

「ピープルウェア」243ページまでの読書ログとふりかえり #今日の30分

ツイート

#今日の30分 「ピープルウェア」140ページまで。世代による考え方の違いと、退職のコストの話。世代のあたりの話で、フロー状態を維持するために継続的な注意の分散を避ける話が出た。このあたりの話を見ると、生産性的には正しいけれど、モチベ的にはどうなんだろうなあ、と思うことがある。

— ざっきー dev (@zakky_dev) June 17, 2019

#今日の30分 -1分。「ピープルウェア」160ページまで。人的資源の話と、「チーム」の話。ブラックチームの話は他の本にもあった気がするけど、どの本だったっけな。どうにも好きになれないけれど、強力で効果的。バランスは必要だけど、もっとドライに考えられるようになるべきか……。

— ざっきー dev (@zakky_dev) June 18, 2019

#今日の30分 +3分30秒。「ピープルウェア」174ページまで。チームを壊す原因9種の話。見覚えのある話がちらほらと。割と納得感がある。作業場所の分散のあたりは難しいよなあ……リモートワークとか、思いっきり作業場所が分散してるし。いやまあ、本で示されている状況とはかなり違うけど……。

— ざっきー dev (@zakky_dev) June 19, 2019

#今日の30分 -4分。「ピープルウェア」191ページまで。チーム内の競争、小さな成功体験を積む、信頼関係の話。Fearless Changeを思い出す感じだなー。成功体験は団結を促す、って話はよく聞く。成功はすべてを癒す、という話もこれの一種だろう。だから細々と成功体験を積み上げるといいのよな。

— ざっきー dev (@zakky_dev) June 20, 2019

#今日の30分 +4分。「ピープルウェア」210ページまで。マネージャの役割の話と、自動化の弊害、そして方法論の採用について。自動化の弊害のあたり、これはドメイン知識不足で自動化やっても意味ないぞ、という話だな。使えないゴミにしかならない。別に自動化が悪いわけでなく、やり方が悪い。

— ざっきー dev (@zakky_dev) June 21, 2019

#今日の30分 -6分。「ピープルウェア」224ページまで。リスクマネジメントと会議の話。リスクマネジメント、考えたくもないことを考え、それ自体に備える、という話か。インセプションデッキにある「夜も寝られなくなる問題」はこれにあたるね。先んじて想定することで、対処を前提に計画できる。

— ざっきー dev (@zakky_dev) June 22, 2019

#今日の30分 +6分。「ピープルウェア」243ページまで。時間の無駄、メール、変化の話。コンテキストスイッチの切り替えに伴う時間の無駄や思考負荷、最近実感することがある。体感では切り替えに5分程度奪われている気がするんだよなー。フロー状態の維持を重要視するなら、これはよくない状況だ。

— ざっきー dev (@zakky_dev) June 23, 2019

ピープルウエア 第3版

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • 「キャズム」KindleでNo.2083まで
• Rubyを毎日1時間程度学ぶ。
  • -
• Docker勉強用の本とかドキュメントを探して欲しいモノリストに登録しておく。
  • Amazonの欲しいモノリストに追加済み
• 積読リストの優先順位並べ替えをする。
  • Amazonの欲しいモノリストを並び替え済み

懺悔

私はブログを書くことを3日サボりました。懺悔します。

今回の追加活動

• 「今日の30分」とは別枠で本を読む。
• Dockerの本を買う

「ピープルウェア」126ページまでの読書ログと今週のふりかえり #今日の30分

ツイート

#今日の30分 -2分。6/10分。「ピープルウェア」20ページまで。プロジェクトの失敗原因が社会学的要因、人の関係に依るものだと言う話。ムチで叩いても生産性は上がらず、むしろ悪影響が多い。一時的には上がるかもしれないが、バーンアウト症候群でトータルではマイナスになりがち。

— ざっきー dev (@zakky_dev) June 12, 2019

#今日の30分 +3分。6/11分。「ピープルウェア」38ページまで。品質、スケジュール、そして生産性への影響の話。直感と反する話が多くてとても面白い。品質を犠牲にしても、スケジュールを決めても生産性は上がらない。あと7つの錯覚の話、これVSM作ってROI考えろって話でまとめられそう。

— ざっきー dev (@zakky_dev) June 12, 2019

#今日の30分 6/12分。「ピープルウェア」59ページまで。オフィス環境が与える生産性への影響の話。開放型オフィスをひたすらこき下ろす感じの内容だな……。言わんとすることは単純で、要するに集中力をかき乱す要因が多いと生産性落ちるよ、という話。開放型オフィスだと雑音とかで乱されるよね、と。

— ざっきー dev (@zakky_dev) June 12, 2019

#今日の30分 -10分。「ピープルウェア」70ページまで。早めに切り上げて早めに寝ることにした。オフィス環境の話と生産性の計測の話。オフィス環境の話はまあ、昨日まで読んだ部分にあった広めの作業スペース、個室、静かさが必要だ、という話。与えないとそういった場所を探してそこで作業を始める。

— ざっきー dev (@zakky_dev) June 13, 2019

#今日の30分 +5分。「ピープルウェア」91ページまで。仕事時間とオフィス環境設計の話。作業時にはフロー状態になっている必要があり、途切れ途切れでは何も終わらせられない、という前提。まあ数分ごとの割り込みとか入ると確かに集中できないんだけど、どうにもモヤモヤするなー。

— ざっきー dev (@zakky_dev) June 14, 2019

#今日の30分 「ピープルウェア」112ページまで。オフィス環境を育てる話と、採用の話の前段として、企業がハマりがちな均質性を重視する風潮の話。ここでも出てくるアレグザンダー氏。原典を読めと言われている気分になってくる。それだけ強い影響を与えた、ということなんだろうけど。

— ざっきー dev (@zakky_dev) June 15, 2019

#今日の30分 -1分。「ピープルウェア」126ページまで。リーダーシップ、採用、多様性の話。採用の話で「適性検査を採用に使うべきではない」って言うあたりが面白い。確かにその意図で適性検査を使っている場合、採用で使っても意味が薄い。数年で離れることが前提ならありなのかも？

— ざっきー dev (@zakky_dev) June 16, 2019

ピープルウエア 第3版

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • -
• Rubyを毎日1時間程度学ぶ。
  • -
• 毎朝「やることリスト」を作る。
  • 全滅
• Docker勉強用の本とかドキュメントを探して欲しいモノリストに登録しておく。
  • 未調査

雑感

月曜日あたりから体調が悪い。今もまだ喉の調子が悪く、咳が出る。 熱は下がったので、数日様子を見て、咳が続くなら病院行き。

今回の追加活動

• 「今日の30分」とは別枠で本を読む。
• Rubyを毎日1時間程度学ぶ。
• Docker勉強用の本とかドキュメントを探して欲しいモノリストに登録しておく。
• 積読リストの優先順位並べ替えをする。

#今日の30分 ログ

ツイート

組織パターン

#今日の30分 +5分。「組織パターン」352ページまで。QPWのケーススタディから考える組織パターンの話。これまで読んできたパターンや研究手法などを参考に、QPWの現場を見直している感じ。コードレビューがほとんどなかった、とかのあたりはちょっと驚きだし、よくできたなー、と思う。

— ざっきー dev (@zakky_dev) 2019年6月3日

#今日の30分 -3分。「組織パターン」361ページまで。とあるチームのケーススタディから考える組織パターンの話。組織パターンの基礎となったチームの研究結果らしく、明示的に名前を出してはいないが、本文で紹介されていたパターンっぽい動きをいくつか説明している感じ。

— ざっきー dev (@zakky_dev) 2019年6月4日

#今日の30分 +11分。「組織パターン」読了。補遺を一気に。本文中で紹介されたパターンの要約リストと、元ネタになったパターンの要約紹介。レビュー会を開く、短期間の計画を複数立てる、あたりはよく見る気がした。元ネタのパターンで印象深いのは「業務的な目的を構築せよ」かなー。

— ざっきー dev (@zakky_dev) 2019年6月5日

組織パターン (Object Oriented SELECTION)

ピープルウェア

#今日の30分 +5分。「ピープルウェア」の目次を読みつつ、気になる単語やらなにやらをメモ。本当はあとがきまで読みたかったけど、思っていたよりピックアップに時間がかかってしまった。得るものが多いといいな。とりあえず明日はあとがきを読んでから流し読みして、今日のメモを補完。 pic.twitter.com/jlKEHhZYSx

— ざっきー dev (@zakky_dev) 2019年6月5日

#今日の30分 「ピープルウェア」流し読み91ページまで。オフィス環境が生産性と人間に対してどのような影響を与えるか、という話。電話の音が集中をかき乱す話とかあって、深く頷く。ここまで流し読んだ感じ、ちょっと内容が古い気がしないでもない。面白そうなんだけど、ここから先はどうかな。

— ざっきー dev (@zakky_dev) 2019年6月6日

#今日の30分 「ピープルウェア」流し読み180ページまで。明日には流し読み終えるかな。オフィスの作りの話と採用の話とチームの話。チームの話のあたりが面白そうだなー。多分一番身近だからなんだろうけど。チーム殺しの秘訣のあたりとか、やっぱ気になるトピックだ。

— ざっきー dev (@zakky_dev) 2019年6月8日

#今日の30分 +3分。「ピープルウェア」流し読み終わり。組織文化の話がメインな感じ。飛び交いまくるメールの話とか、守りの姿勢の話とかが気になるかな。後になって「自分はちゃんと責務を果たした」と言い訳できる状況を作っておかないと行けない環境はしんどい、みたいな話なんだろうか。

— ざっきー dev (@zakky_dev) 2019年6月9日

ピープルウエア 第3版

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • 「キャズム」KindleでNo.1926まで。
• Rubyを毎日1時間程度学ぶ。
  • -
• 毎朝「やることリスト」を作る。
  • 全滅

雑感

仕事を鑑みて、朝からの活動に切り替える。

今回の追加活動

• 「今日の30分」とは別枠で本を読む。
• Rubyを毎日1時間程度学ぶ。
• 毎朝「やることリスト」を作る。
• Docker勉強用の本とかドキュメントを探して欲しいモノリストに登録しておく。

「組織パターン」325ページまでの読書ログと今週のふりかえり #今日の30分

ツイート

#今日の30分 -4分。5/27分。「組織パターン」294ページまで。「チームごとのサブクラス」、「ファクトリの階層」、「パーサービルダー」。んー、どうにも「ファクトリの階層」パターンがピンとこない……どんな感じかイメージできない。案外当たり前にやっていることかもしれないけれど……。

— ざっきー dev (@zakky_dev) May 28, 2019

#今日の30分 +5分。5/28分。「組織パターン」303ページまで。組織改善の原則の話。ここまでに見てきたパターンはあくまでも促進剤であり、とりあえず適用すれば良くなるものではない。まずは組織を観察し、原則に従いつつ、徐々に適用して変えていく。

— ざっきー dev (@zakky_dev) May 28, 2019

#今日の30分 -5分。「組織パターン」308ページまで。組織にパターンを適用するより前に考えるべきことの話、かな。闇雲にパターンを適用しても効果がでない。実際に適用したとき、もしもうまく行かなければこのあたりを考えてみるのも良さそうな感じ。

— ざっきー dev (@zakky_dev) May 29, 2019

#今日の30分 -4分。「組織パターン」314ページまで。組織を漸進的に成長させる話。事前の包括的な設計ではなく、パターンを適用し、変化を観察し、次の手を考える。反応と適応。一気に変化させたり、反応を観察せずに計画通りに進めようとするとうまくいかない。変化させられることは厭われる。

— ざっきー dev (@zakky_dev) May 30, 2019

#今日の30分 +1分。「組織パターン」319ページまで。パターン適用時の一般的なルールの話。対立より共働を選ぶ。コンテキストを深く分析する。組織は人が形作る。権限は不足する。集団で取り組む。パターンの選び方。そしてマネージャの影響力について。

— ざっきー dev (@zakky_dev) May 31, 2019

#今日の30分 「組織パターン」325ページまで。組織学習の話……だと思う。正直よくわからなかった。読み返したほうがいいかも。組織の効率性を考えたとき、プロセスはさほど重要ではない。重要なのは組織としての学習であり、学習効率になる。プロセスは学習の結果得られたものから導出される。

— ざっきー dev (@zakky_dev) June 1, 2019

#今日の30分 +2分。「組織パターン」325ページまで。341ページまで。組織内のロールの話、研究手法の話、そしてQWPのケーススタディ。こういったことを調べようとしたとき、ロールに着目する理由、やっぱこうなるよなー。個人ではなく役割に着目しないと、実態が見えてこない。

— ざっきー dev (@zakky_dev) June 2, 2019

組織パターン (Object Oriented SELECTION)

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • -
• Rubyを毎日1時間程度学ぶ。
  • 「プロを目指す人のためのRuby入門」読了。
• 毎朝「やることリスト」を作る。
  • 作っているが、効果計測が難しい。また、日課的なものを毎日書くのが面倒。

今回の追加活動

いよいよ働き始める。状況が変わるため、一旦このまま。

転職します

いわゆる転職エントリです。

どこからどこへ

from: 愛知のO社
to: 東京のC社

6月から働きます。社会復帰できるか不安です。
詳細は飲みにでも誘って貰えれば答えます。あ、Ruby書くことになりました。

欲しいものリスト

転職祝いお待ちしております。

「組織パターン」282ページまでの読書ログと今週のふりかえり #今日の30分

ツイート

#今日の30分 +3分。「組織パターン」220ページまで。離れて作業する前の顔合わせ、形状は機能に従う、循環領域を形作る、作業を均等に配分せよ、複数の責務が関与する。コミュニケーションの調整の話、かなあ。強度比の考え方は面白い。ロールがわかっていれば、負荷の定量的な指標になりそうな感じ。

— ざっきー dev (@zakky_dev) May 20, 2019

#今日の30分 -3分。「組織パターン」229ページまで。「立ち話」、「ステージ同士を疎結合にせよ」、「ハブ、スポーク、リム」。後者2つはわかっている範囲が多く、慣れ親しんだパターンで解決できるときに使えるらしい。クネビンフレームワークの「単純」にあたる問題に使えそうなパターンなのかな。

— ざっきー dev (@zakky_dev) May 21, 2019

#今日の30分 「組織パターン」238ページまで。「責務を移動せよ」、「あべこべのマトリクス管理」、「冷水器」、「一つのロールに3から7のヘルパー」。ロールの負荷分散のパターン2つと、組織全体のコミュニケーション構造のパターン2つ、かな。マトリクス管理のパターンはSpotifyの例を思い出す。

— ざっきー dev (@zakky_dev) May 22, 2019

#今日の30分 「組織パターン」255ページまで。「結合によって待ち時間が減る」、「アーキテクトがプロダクトをコントロールする」、「アーキテクチャチーム」、「缶詰」、「極秘の商談部屋」。極秘の商談部屋パターン、これ、使い方間違えると危険なパターンだな。弾かれた人から不満が出かねない。

— ざっきー dev (@zakky_dev) May 23, 2019

#今日の30分 「組織パターン」267ページまで。「スタンドアップミーティング」、「ドメインの粒度に合わせて人員を配置せよ」、「アーキテクトも実装する」。個人的には「ドメインの粒度に合わせて人員を配置せよ」は「一人が多くの帽子をかぶれ」の別名がわかりやすいなー。

— ざっきー dev (@zakky_dev) May 24, 2019

#今日の30分 -8分。「組織パターン」276ページまで。「汎用的なものと個別なもの」、「複数の拠点をつなぐ標準規格」、「コードの所有権」、「フィーチャの割り当て」。んー、どうにも「コードの所有権」だけすっきりしないな……不安のほうが先に立つ。

— ざっきー dev (@zakky_dev) May 25, 2019

#今日の30分 -10分。5/26分。「組織パターン」282ページまで。「インターフェイスの背後のバリエーション」、「プライベートなバージョニング」、「緩やかなインターフェイス」。「プライベートなバージョニング」は要するにDVCS使え、という話になりそうな感じだなー。使わないと辛いよね……。

— ざっきー dev (@zakky_dev) May 28, 2019

組織パターン (Object Oriented SELECTION)

ふりかえり

前回の結果

• 「今日の30分」とは別枠で本を読む。
  • 「キャズム」KindleでNo.1296まで。
• Rubyを毎日1時間程度学ぶ。
  • 「プロを目指す人のためのRuby入門」KindleでNo.6948まで。
• 毎朝「やることリスト」を作る。
  • 引越し作業に役立った。

今回の追加活動

思っていた以上に引越し作業により動けない。そろそろ落ち着きそうだが、増やすことは無理そうなので、一旦現状維持。