Book

先週の 1 on 1 で上司から「増田さんには合わないと思いますが(^^;」という但し書きの上で紹介されたので、逆にやる気を出して読んでみた。 確かに反論したい箇所は多々あるものの、その主張の根本を辿るとそうでもない気はした。むしろ合うかもしれない。 想定読者を読み誤っていた 全体的にリーダー（マネジメント）視点で書かれているので、プレイヤー視点で読むと、誤解が多く非常に良くなかった。← 最後まで誤解してた人 P11 この本は、そんな識学のメソッドを元に、「若手リーダー」に向けてマネジメントのノウハウを伝えるものです。 初めて部下やスタッフを持つような人、いわゆる「中間管理職」を想定しています。 最初ここを流して読んでしまったけど、この前提を忘れて読み進めたので最後までヘイトが溜まってしまった。 特に「プロセス（過程）は評価しない」には嫌悪感さえ覚えた。プレイヤーがプロセスを軽視して良いわけがない。業務の属人性が高まるし、再現性の低いものばかりできる。そんなものはプロフェッショナルの仕事ではない…と。 P173 そこでのひとつの結論は、「 プロセス（過程） は評価しない」ということ ここでさらにヘイトが溜まったけど、、（続く）ｗ P214 そこで重要なのが、第４章の「プロセスに口を出さない」ということでした ここで、逆説的にはプレイヤー視点ではプロセスが大事と言っていることに気がついた。💡 ※ これ、解釈が間違っていたら前提が覆るね (^^; P220 プレーヤーだった頃の自分を、部下たちがはるかに超えていく瞬間 。 ぜひ、それを体感していただきたいと思います。 はい、完全なマネージャー向けの本ですね。失礼しました…。 [2023-03-26-1] にも書いたけど、今は自分含めた４人チームのリーダーを任されたところで、且つ自分以外は業務委託の方々なので、想定読者ど真ん中ではなさそうだった。 エンジニア組織に合うのだろうか？ これは最後まで疑問だった。営業組織向けの本かと思っていたら、、、 P189 デザイナーやエンジニアの世界では、部下に対して、「上司が納得したらＯＫ」という設定をすることもあるでしょう。 ここでズッコケてしまった。うーん、大企業ならあるのか…？ まだ私に前職までの、スタートアップでのウェブプロダクト開発の空気感が残っているので、賛同し兼ねてしまう。これからあるのかあ…。🌀 肝心の感想 事実に対して淡々とフィードバックする。プロセスは見ない、結果だけにフォーカスする。 上司（≠プレイングマネージャー）と部下という関係なら、とても良いし、理想的とさえ思った。 本の中では 1 on 1 を否定していたけど、まさに [2023-03-26-1] の『ヤフーの１ｏｎ１ 』と同じことをしている。作者の方はダメな 1 on 1 しか見たことがないのかも。 まとめ そういうわけで、マネージャー向けには良い本だと思う。ボリューム少ないのも良かった。２時間ちょっとで読めた（重要）。 自分用読書メモ いいリーダーの言葉は、 「時間差」 で遅れて効いてきます。 これはそうかもね。最近小さく実感したところ（自画自賛）。 識学では、組織の成長スピードを考えたとき、「ピラミッド構造が最適であり、最速である」と考えます。 まだ自分の中で結論が出てないけど、条件付きで Yes かもしれない。 [2021-03-13-1] でも思ったんだけど、スタートアップのような能力密度の高い組織では成り立たない可能性があるから。 大阪市のような普通の人が多そうな組織で成り立つのだと思う。大企業もそうだと思う。 「この仕事はＡさんに任せた。契約に結びつけてください」 「来週の火曜の 15 時までに資料をまとめておいてください」...

数年ぶりに 1 on 1（をやるほう）をやることになったので、『ヤフーの１ｏｎ１ 』という本を読んでみた。 なぜこの本を選んだのかと言うと、前職で 1 on 1 をしてくれていた @meihong の記事 👇 で紹介されていたから。 🔗 コミュ障が1on1をやり始めたので参考になりそうなことを書いておく ※ この記事は自分の中でちょっとしたバイブルになっていて、必要な時に読み返しています。 もうひとつの『HIGH OUTPUT MANAGEMENT』は大事に積みました。(ｱｶﾝ 😅 感想 第１章がマンガでの事例で始まるので、読み始めが楽。ボリュームも大きくなく、流し読み程度だけど１時間 x ２日で読み終わった。 全体的なキーワードは「アクティブリスニング」と「信頼関係」だと理解した。 「アクティブリスニング」は「傾聴」と訳されることが多いが、日本語だと真剣に黙って聞くというイメージが強いため、ヤフーでは「傾聴」ではなく「アクティブリスニング」を使っているそう。 うなずいたり、相槌を打ったり、相手が発したキーワードを繰り返したりするため「傾聴」とは異なる。そうすることで、相手の頭のなかの今まで動いていなかった一部分を動かすことができるとのこと。出来る気はしていない…。 ありがちな失敗として、上司がアドバイスしようと思うがあまり、「どういうふうに進めたいの？」「誰かに相談した？それは誰？」などと自分の理解のために質問をしてしまうこと。それでは部下から上司の依存が強くなってしまうだけ。まあそうだよね。 「信頼関係」は一朝一夕で出来るものではないので、会社からの支援と、上司の日々の行動が重要だと思った。 個人的には「いつも気にしているよ」というメッセージもしくはシグナルを投げかけるようにしている。 具体的には、Slack の活動は見えるものは全部読んで、絵文字リアクションを適宜付けている。GitHub の活動も全部読んで、こちらも適宜絵文字リアクションを付けている。それらを朝会などで必要に応じて伝えている。どれも上司（リーダー）だからやっている訳ではなく、今までもやってきたことを意識づけしただけ。 現実にはそのメッセージも限界はある気はするので、まだまだ悩み中。🌀 まとめ ここまで書いたけど、今回私が始めた 1 on 1 は「上司と部下」ではなく、自分含めた４人チームのリーダーとメンバーなので、そのままでは使えない。例えば中長期にキャリアのことを話して欲しいなど。 とは言え、知識の整理や、心の拠り所にはなったので、実践や他のインプットも含めてやっていきます。 自分用読書メモ 1 on 1 では、考えを深めるツールとして「言い換え」をよく使う。 へー ヤフーでは、「アサインよりチョイス」と言っています。 めちゃめちゃええやないか。。。私もアサインという言葉は好きではない。 日本語での会話は、主語を省略することが多いので、カギとなるセンテンスでは、あえて主語を明確にすることによって、それが部下の本音なのかどうかを確認しています。 細かいけど重要なテクニック 傾聴するとは、真剣に聞くことではないと思っています。むしろ、話の中身はまったく頭に入れず「へえ」「そうなんだ」と返事をしていれば、話している側は勝手に内省を深めていくこともある。 面白い。 しかし、あまり間隔が空きすぎるのは望ましくありません。最低でも３週間に１度は行うようにします。 ですよね。私の場合だと 1 on 1 の相手とも話して、一旦２週間に１度にしました。 Q10. １ ｏｎ １で知りえた部下のプライベートな話は、どの程度周囲と共有してもいいのでしょうか？ A. 共有してはいけません。 ですよね。😅 私は第一回の 1 on 1 の時に、前提のひとつとしてお伝えしました。

訳者である岩瀬さんのツイートをたまたま拝見し、ちょうど先月入社した会社の部署で大きな課題だと感じていたところだったので、購入して斜め読みした。 loading... 本書の対象者は、ドキュメントを書くエンジニアやテクニカルライターではあるけど、ユーザー向けドキュメントのようにある程度の規模が想定されているように思う。 私が感じた課題はもっと原始的で、GitHub リポジトリに README.md がなく、どのような README.md を書けば良いか伝える方法を模索していたので、本書がど真ん中だったわけではなかった。 ※ 今は、既存ドキュメントへのリンクを張るくらいで良いので、まずは README.md を作るようにチームメンバーなどに伝えている。でもその先が難しい…。 ただ、最後の付録Bに出てきた「README チェックリスト」はチームメンバーへの説明のヒントになるかもしれない。良さそう。 ちなみに自分がドキュメントを作る時はこんな流れ。これでは伝わらない。😅 概要や書きたいことをとりあえず書いてみて、あれこれ並べる やっているうちに見出しが見えてくるので、文書構造を作っていく 文書自体はできるだけリストではなく、パラグラフ記法 [2021-11-29-1] を使います 詳細化したり、逆にバッサリ削除して、完成に近づけていく 読み手目線で書くだけではあるのだけど、それが難しいのだよね。書いたその日じゃなくて、次の日の少し冷静になった頭でもう一度読むなどの細かいテクニックはあるのだけど。 ドキュメントライティングに課題を感じている人は、何かのヒントになるかもしれないので読むと良いかも。

[2022-03-06-1] にも書いたとおり、佐々木俊尚さんの Voicy をなんとなく毎日聞いています。Web3 関係の本を出したということで、なんとなく買って読んでみました。それについての読書メモ。 「現在のウェブ３は、単なる権力奪取ゲームにすぎないと断言してもいいと考えている」には完全に同意。歴史好きの私としては、似たようなことが形を変えて螺旋状に続くと考えているので、ユートピアは来ないと思っています。 他もだいたい同意なんですが、自分の認識不足のこととしては「Zoom が平板な画面を並べているだけの二次元のオンラインミーティング」で「平面で全員が並んでいる」ということ。深く考えていなかったけど、現実のミーティングを再現しきれてなかったですね。 メタバースが究極的に進化すると、現実世界のミーティングや飲み会との差が少なくなるのかなと思いました。どの程度少なくなるのかは、とても興味があります。帰省とか楽になると良いな。 現時点では胡散臭く進化も不十分な Web3 やメタバースだけど、距離に関係する課題を解決できると良いですね。 ちなみに、人と人のあいだの距離は４つに分類できるそう。 密接距離 ↑ 近い 個体距離 メタバース 社会距離 例: Zoom 公衆距離 ↓ 遠い 他も Web3 のトークンエコノミーとは贈与経済ではないか？という話も興味深かったです。貨幣経済が「等価」という概念を生んでしまったことで、人間関係を持続させる手立てをひとつ失ってしまった。「貸し借り」を意識しづらくなる。なるほどね。

Python は今まで雰囲気で読んでいて、データまわりだとちょいちょい出てくるので購入した。購入したと言っても ￥250 と破格な上、kindle unlimited だと無料。 63 ページと短いので 1 時間もかからずに読めた。 プログラミング経験者がなる早でつまみ食いするには良いかも。さすがにもう変数の説明から読むのはしんどいからね。デコレータや引数や戻り値の型指定など、書かれていないことはあるけど、必要あれば起点に深堀りすればよい。 こういうさくっと読める本好き。

読もうと思ったきっかけは忘れましたが、[2020-12-20-1] の『データマネジメントが30分でわかる本 』のゆずたそさんが共著者だったのもあって購入しました。 この 2 年半、ひとりで広告データ基盤を作ってきた答え合わせや整理が出来た気がしました。 例えば、用語としては知っていたデータレイク、データウェアハウス、データマートが、自分が作ったデータ基盤にも当てはまっており、それほど変な設計ではなかったこと。 loading... 今の会社のデータ活用成熟度が、どの程度なのかも分かりました。（レベル１でした） ついでに Airflow がよく使われていると知ったので、ローカルの Docker 環境と GCP の Cloud Composer を少し使ってみるなど。 https://github.com/masutaka/trial-airflow ひとりもしくは少人数で日々奮闘している人こそ、読むと発見がある本かも知れません。

本日発売とのことで、自称 Looker エバンジェリスト としては放ってはおけず、購入してザッと流し読みしました。 初心者向けの本ではありますが、LookML 開発者、ビジネスユーザー、Looker 管理者、いずれのロール向けではあります。これだけ網羅的に書くのは大変だったのだろうなあ。 Looker の導入を検討する人向けかな？ ここまで親切な Looker の情報、特にスクリーンショット付きの LookML 開発の情報は少ないので、導入を検討する人には大きな助けになると思います。 Looker の学習用教材としても良い 初心者向けの Looker 学習用教材としても良いと思います。 でも「これから導入するからみんなで読みましょう」というより、すでに Looker が導入された環境に、後から入る人向けかな？ 導入時には Jumpstart もしくは Rapid deployment のプログラムを受講するはずですからね。受講は任意ですが、受講した身からすると必須という実感があります。 まとめ Looker 本は日本初だと思うので、Looker を愛する者としては素直にうれしいです。😂 P.S. それにしても LookML の ML が Markup Language の略 (P29) とは全く考えたことがありませんでした。← そこ？🙄 追記(2023-03-18): LookML の ML は何の略？ LookMLの紹介 | Looker | Google Cloud LookML は、Looker Modeling Language の略です。 現在は（？）Markup Language ではなく Modeling Language みたいです。執筆当時から変わった可能性はあります。

しんゆうさんのこのツイートを見てから、すぐ買って少し読んで、半年くらい放置していました。💦 loading... 数日前に 👇 のツイートを社内の Slack で紹介したら、「インテリジェンス」の定義自体存在しないような、バラバラのような気がしたので、今日気合い入れて一気読みしました。結果的に読むタイミングは、今で良かったかもしれません。 loading... インテリジェンスとは何か ひょっとしたら聞いたことがない人のほうが多いのかしら？ 聞いたことがある人も、スパイや諜報などのイメージで、自分とは関係ないと感じる人が多いのかもしれません。 国家レベルでのインテリジェンスの定義は置いといて、企業という現場では以下のような定義になるそうです。特別なものではありません。 P9 インテリジェンスとは、企業が戦略を立案・実行するために必要な知識である。 ビジネス・インテリジェンスと呼ばれるのかな。 社内で共通言語や共通課題を作るために、第１部「インテリジェンスとは何か」と第２部「インテリジェンスの創造と管理」くらいは読み合わせたほうが良いかもしれません。 インテリジェンスの定義は広範囲に及ぶため、私が今所属している会社の場合、関係するのはこの本の定義のごく一部です。 個人的に気になった箇所 P67 逆に言うと、カスタマーの最終的な目標は、特定のインテリジェンスを得ることではない。インテリジェンスを得ることで、判断・行動し、自らの利益を養護・増進することなのである。 インテリジェンスの世界でも「なぜやるのか？」という Issue が必要だと理解した。 P90 以上をまとめると、結局重要なのは、カスタマーと情報サイドの間の距離が「遠い」とか「近い」とかいうことではなくて「情報サイドが、カスタマーの利益を充分に理解しているかどうか」だということになる。 カスタマー（依頼者）と分析者の間には、上下関係はないということ。 P110 「機密情報に頼らなくても、公開情報を丹念に分析すれば、実態の九割は把握できる」といった議論がその例である。 これは懐かしい。昔 SAPIO を定期購読していた時、これを知った記憶。インテリジェンスという概念もその時知った。 P151 米国の CI (Competitive Intelligence) と呼ばれる企業にとってのインテリジェンスの世界では、情報サイドの人間が、戦略や戦術の立案・実行の機会に立ち会うことが奨励されているのだ。 これは分かる。Looker 等でデータ整備する時もそれ以前も、出来るだけチームに飛び込んで、空気感を掴むようにしていた。 P151 このようにあらゆる特定の制作や企業戦略・戦術を相対化出来るほどに、カスタマーの利益を理解できるような人材を育成することが、最も重要なのである。 インテリジェンスの文脈だと目的が「カスタマーの利益を理解するために」になるが、インテリジェンスでなくてもそうだよね。 P152 日本に限ったことではないのだが、インテリジェンスを専門としている人間は、カスタマーに対して、コンプレックスを感じやすい。またカスタマーは、全てがそうではないが、情報サイドに対して高踏的な態度を取りやすい。 なんとなく分かるかな。だからこそ情報サイドの人間は、ある程度の勇気を持ってコミュニケーションすることが重要。プロダクトオーナーとソフトウェア開発者の関係とも似ている。 P217 そこでヘリングは、能動的モードを考案する。つまりＣＩ部門が戦略を策定・執行する者に定期的にインタビューを行い、彼らが適切なリクワイヤメントを自ら発見できるように手助けするのである。これがヘリングのＫＩＴプロセスだ。 「質問待ってます」みたいな受動的モードがうまくいかなくて、能動的モードに移行するのよく分かる。インタビューの例は P220 にある。 P230 （二）意思決定への関与 情報サイドは意思決定に関与すべきでないと明言している。 P246 両者の対話の段階に入った瞬間に、「リクワイヤメントの伝達」は「リクワイヤメントの創出」へと変化し「鶏と卵」の問題は回避し得るかに見える。しかしその代償は、図に描かれている通り、インテリジェンスの客観性の低下である。 確かに「インテリジェンスの客観性の低下」は警戒したほうが良い。P249 に解決策あり。

私が所属しているフィードフォースでは、毎月 FFLT という LT 大会があります。 最近久しぶりに参加していて、昨日は本当に久しぶりに LT をしました。久しぶりすぎて LT が 5 分であることを気にかけなかったという…。いや、もちろん覚えてはいたのですが（汗）。 お題は [2022-03-06-1] や [2022-03-30-1] でそれとなく書いていた「Kindle 本を聴く」方法です。 すべてのケースに合うわけでも、ベストな方法でもありませんが、集中力が必要で眠くなりがちな本を読むという作業を省エネ化出来たことは、自分にとって価値あるものでした。 まだまだ最適化が必要なので、やっていきます。

購入から６年半以上。下巻の途中で数年止まっていましたが、今月えいやっと読み終えました。 ※ 正確に書くと、Kindle 本をオーディオブック化して聴き終えました。 上巻はもはや覚えていませんが、全体を通して覚えていることは「人種間に能力の優劣などなく、地理的環境的なアドバンテージが文化的な発展の違いに繋がった」ことです。 例えばユーラシア大陸は横に長いため、作物や技術が伝播しやすいです。緯度が変わらないため、気候が似通っているからです。しかし、南北アメリカ大陸やアフリカ大陸は縦に長いため、ユーラシア大陸に比べて伝播が遅かったり、途中で止まったりします。こちらを知れただけで読んだ価値がありました。 下巻の最後では、なぜヨーロッパの国々はアメリカ大陸やアジア諸国で植民地支配が広がったのに、中国はそうでなかったのかという興味深い話が解説されていました。 ヨーロッパは国の数が多く競争が激しいため、新しい技術が開発されたら取り入れざるを得ず、ある国の支援が得られなくても他の国でなら可能（コロンブスの話）という事情が生まれるそうです。 一方で中国は１つの王朝が統一しているため、例えば外洋航海の禁止という決定事項が中国全土に浸透し、その決定が愚かだったかの検証さえ出来なくなってしまったそう。 Kindle 本をオーディオブック化するスキルを身に付けたので、これからもジャンジャン読んで聴いていきます。 P.S. これから読む予定。 日本の地理学は『銃・病原菌・鉄』をいかに語るのか―英語圏と日本における受容過程の比較検討から―