らんどなテックブログ

エンジニアのいろいろ

【読書メモ】「センスメイキング――本当に重要なものを見極める力」を読んだ

年末に読んだので感想をまとめてみる

https://www.amazon.co.jp/dp/B07K9JT38M/

雑感

この本の主張をすごく大雑把に解釈すると、「データだけで分かった気になるな、知りたい物事に自ら入り込み、自分の五感で理解するべき」という風に受け取った。

この考え方は今の仕事や環境下ではある程度やれているつもりであり、そういう意味では新しい発見は少なかった。 ただ、その考え方を下支えしている理論や事例を細かく具体化してくれている本であり、そういう観点で時々読み返すといいかもしれない。

内容の咀嚼

何かを作ったり変えたりするには、現状がなぜそうなっているのか?という背景や分脈を知る必要がある。 それは文化を知るということで、そこを理解・深掘りするためには人文科学や哲学などを理解していることが有用になる、という話だった。

元々、マネージャーとして物事を理解したりメンバーを深く支えていくためには、歴史や文学など幅広い知識・教養が必要があるといいのはなんとなく感じていた。 この本を読むことで改めて、技術以外の知識(技術以外も含む知識、と言った方がいいかも)も獲得していく必要がある、というのを感じた。

いまの仕事と比較

まだまだ道半ばだが、今自分がやっているのはエンジニアとデザイナーを繋ぐルールや仕組みを作ること。 この仕事について考えてみると、今作っているものが本当に役立つものなのか?ということを考える際にこの本で言及されて内容と近いことを考えていると思う。

進めていくうえで、なんとなく役立ちそう、世の中で流行っている手法をまず導入しよう、みたいなノリで進めてしまうのはアンチパターンと思っている。 できたはいいが大して役に立たない、ということになりかねないからだ。 そうならないように、まずはエンジニアである自分から見て本当に役立つものなのか(自分が当事者の立場だったら使うのか?)を常に考え、実際に小さく使ってもらって評価する、というようなことをやっている。 欲を言えば、自らデザイナーの業務やその背景を理解し、デザイナー目線でも本当に役立つものなのか?を自分で答えられる状態になりたい。 この進め方・考え方は、「物事に自ら入り込み自分の五感で理解する」というのを意識できている点だと思う。

関連して考えたこと

この本を読みながら近しいと感じた話が一つある。 先日仕事で話題に挙がったもので、「当事者に話を聞くのではなく、当事者を観察するべき」というものだ。 当事者だからと言って課題を正確に把握・言語化できているとは限らない。 むしろ当事者故に事実を俯瞰して捉えていないケースも考えられるため、解決・改善のためには自ら観察を行い、その解決を設計するべし、という話だった。

近しいと感じた点は、この本の主張として「データを参考にするな」というものがあると感じた部分である。 「データが〇〇になっているから××である」という判断に甘えるのではなく、自ら課題や背景を理解することで真の解決を見つけ出せる、という主張があると自分は感じており、そこに上記の話と親和性があると感じた。

その他の感想

なんとなく解決するだろう、と思い込まず自分が当事者として理解する、はここ最近意識していることの一つである。 その考え方がアリストテレスの提唱する考えにまで遡ることができるのは衝撃だった。 自分にとってアリストテレスは倫理の授業のごく初期で習った哲学者であり、自分が今考えていることが遙か昔の哲学者がすでに到達していたものなのか、という点にとにかく驚いた。 歴史を学べ、とはこういうことなんだな。

あと、著者があまりにシリコンバレー式、ビッグデータ、を敵視しすぎでは?とは思った。 実際考え方のフレームワークもビッグデータも手段の一つであり、使い方次第で充分効率化できることもあるだろうと思う。 ただ、それだけを盲信して自分の目や耳で課題を捉えていないケースが多い、ということに著者は警鐘を鳴らしているんだろうな、という風に自分は受け取った。

2024年のふり返り

雑に書いてみる。 去年は結婚、家の購入、があったのでそれに比べると穏やか〜な1年。

おうちのこと

ひとまず最初の結婚記念日を迎えられたので一安心。 引き続き仲良くやっております。

おうちもカーテンレールの設置工事等が完了して腰を据えて暮らせる状態になった。 ご近所トラブルとかも無くて一安心。

それから結婚写真も撮った。 周りから撮った方がいいとは言われていたけど、夫婦揃ってやる気が出ず後回しにしていたもの。 撮影スタジオ見られて面白かったのと、家族は喜んでくれたのでやってよかったと思う。

友人のこと

友人が行ってるので真似してみた全身脱毛も一区切り。 本当はもっと継続した方がいいんだろうから、気が向いたら再開する。

友人に子供ができた&家を購入したとのことで遊びにも行った。 家の凝り方もいろいろあるんだなぁってのが分かって面白。

久しぶりに友人と旅行にも行った。 友人が育休明けに妻からプレゼントしてもらった機会とのこと。 久々に北海道行けて楽しかった。 し、やはり北海道はご飯が美味しい。

バドミントンをやってるんだけど、その友人の誘いで静岡にキャンプへ行った。 知人のお子さんが珍しく自分になついており、子供と遊ぶ貴重な機会になった。 外で肉を焼けばそれだけで美味しい。

仕事のこと

ざっくり言えばエンジニアとデザイナーを繋ぐための色んな整備をやっている。 やりたいことが進まないな〜ってことで自発的に動いていったんだが、その辺りが評価された模様。 多分仕事で始めて表彰というヤツを受けた。 嬉しいものだ、またもらえるようにやっていこう。

マネジメントをするかもっとコード書くか?みたいなところでうっすら迷いもあったが、必要なことを必要なだけやる、という感触でひとまずは落ち着いている。 とは言えもっと遊びで技術に触れる機会は考えてもいいかもしれない。

ゲームのこと

いまやってるもの

クリアしたもの

ふり返ると案外少ないな。 一応ソシャゲもチマチマやっているものがいくつか。 社内ではポケポケも流行ってるし。

その他のこと

iPhone を買い換えた。 2年半くらい使っていた SE2 から Pro Max へ。 先代はバッテリーもへたっていたしもっさりしていたけど、それが全部解決で快適。 思いのほかでかいのでポケットに入れにくいのは難点。

営業電話を受けてプロバイダーを変えてみた。 一応特典で安くなったからいいけど、段取りの悪さとかであんまり体感よくなかったのでまた乗り換えを考えたい。

来年のこと

お仕事系の読書習慣が薄まってるのは反省点かも。 月1冊、とか決めてやっていきたい。 ひとまず年末年始で何かしら1冊読むつもり。

あとジワジワ体重が増えているのも問題。 体組成計を手に入れたので、食事の見直しから始めている。 こっちも習慣化して改善していきたい。

【読書メモ】あなたのチームは、機能してますか?

こんちは、じぬです。 いつもタイトルを 書評 にしてたけど評するってほどじゃないなって気付いたので 読書メモ にした。 読んでみて非常に良かった本だったため、いつも通り感想をまとめていく。

あなたのチームは、機能してますか? | パトリック・レンシオーニ, 伊豆原弓 | 実践経営・リーダーシップ | Kindleストア | Amazon

良かったフレーズ

  • p.68 信頼を気付く唯一の方法は、完全無欠でありたいという気持ちを克服すること
  • p.92 政治的とは、自分がどう考えるかではなく相手にどう反応して欲しいかで言葉や行動を選ぶこと
  • p.102 合意しなくても責任を果たせ
  • p.140 個人の問題よりチームの結果を優先させること。あなたたちの第一のチームはこのチームなの
  • p.151 追求しないことは信頼ではない。信頼とは、追求されたときに相手が真剣に考えているんだと理解できること
  • p.151 とにかく追求することが大事、絶対に遠慮してはダメ
  • p.186 幹部会議の時に9人もいるため実のある円滑な議論ができなくなってきた
  • p.192 健全な衝突が無いと、メンバーは真に意見を出せず決定に対して責任感を持てない
  • p.192 責任を持てなければ、チームのためにならない行動をとったメンバーに対して毅然と接することができない(説明責任の回避)
  • p.197 信頼関係とは弱みを見せられること。弱みとは、能力不足、対人関係の欠点、ミス、助けを求めること
  • p.198 信頼があれば、やるべき仕事にエネルギーを集中できる
  • p.205 時間がかかるからと衝突をさける事があるが、それは次回の会議で再発するのがオチである
  • p.208 時にリーダーは衝突を掘り起こす役割を担う必要がある
  • p.209 衝突に対してメンバーから不快感が出ている場合は、それでもこれは必要なことだときちんと伝える。これが必要で生産的な活動だという自信に繋がる
  • p.209 衝突に特化したツールとしてトーマス・キルマン衝突モデルがある
  • p.209 衝突は自然な解決に任せることが重要だが、リーダーから見るとそれは失敗のようにも感じるためかなり難しいことでもある
  • p.211 完全な合意を目指す必要は無く、きちんとそれぞれの意見が考慮されたことが伝われば十分である
  • p.211 決定が正しいと確信できるまで待つという姿勢は、無気力さや自信のなさをチームに伝えてしまう
  • p.214 最悪の敵はあいまいさである。期日などを明確に決めることで仕事への責任感が生まれる
  • p.215 リーダーは決定が間違っていても動じないこと。グループで議論を促し、チームで決めたスケジュールの徹底を求めることが必要
  • p.225 リーダーは誰よりも結果を重視して行動することが必要。そうしないとメンバーが同じように行動をとることはない

感想

ストーリー仕立てなのでサクッと読みやすかった。

ここ最近は改めて自分が何をすべきか考えることが多く、この本では特にリーダーとしてのふるまいに関する記述で気づきが多かった。 特に次に挙げる点は自分を改める良い気づきだったと思う。

結果にこだわる姿勢

前回の記事で書いたとおりチームを円滑に回すことにはこだわってきたつもりだったが、その分結果を追求できていたかというとイマイチな点があったかもしれない。別に不必要に厳しくする必要は無いが、メンバーそれぞれの成果や進捗に対して自分(リーダー)や他のメンバーが納得できるレベルまで突き詰める姿勢は改めて意識したい。

自分の成果ではなくチームの成果

正直な話、自分は割と自分自身の成果にこだわっているタイプだと思う。仕事である以上より良い評価を得たいと考えている。 ただそれが常にチームの成果と一致していたかというと自信が無い。 基本的にイコールではあるはずだが、結果論ではなく意識してチームの成果とは何か?を考え、それを目指した行動を選んでいく必要がある。 そうでないと、メンバーに対して同じ動きを期待することが難しくなってしまう。

弱みを見せる意識

これは普通にやっていたつもりだったが、最近仕事でもっとメンバーに任せちゃっていいのでは?という指摘を受けた。 言われてみると、最後は自分で解決しなければ、導かなければ、という意識はあった気がする。 勿論そういう姿勢も必要だが、メンバー自身が突破することを信じて(逆に言えば自分ではできないということを認めて)仕事を進める、というのがまだ足りていないのかもしれない。

2022年度のふり返り

こんにちは、新婚のじぬです。 期も変わったので、去年の入社から何をやってきたかふり返ろうと思います。

チーム組成

去年の入社時に前任のマネージャーから引き継ぎ、エンジニアチームの組成を担当しました。 基本的に自走できるメンバーばかりでしたが、新規メンバーも複数いるタイミングだったので、上手く連携できる環境作りを心がけました。 やったことは、一言で言えば雑談する機会作りです。 フルリモートの環境では何気ない情報共有の機会が少なくなってしまうため、なるべく気軽に話ができるよう定例ミーティングを設置しました。 ミーティングは多すぎると効率が下がるので難しいですが、リモート環境ではやや冗長な頻度で行うべきというのが所感です(議題がなければ早めに解散することもあります)。 今のところ、1時間ずつ週3回ほど定例ミーティングがあります。

参考にした記事⇒「帰りの会」というリモート雑談の形 - maru source

初期は会話を促したり必要性を認識してもらうために自分でファシリテーターをやりましたが、ある程度軌道に乗ったあとは交代制にしました。 チームメンバーの参加しているという当事者意識を高めることが目的でしたが、それ以外の利点として、自分がいなくてもミーティングが実施されるという事実が精神的な負担を軽減してくれました。

これ以外にもバックログの棚卸しや、普段はそこまで詰められていない議題を集める月1の定例など、いろいろな角度からコミュニケーションが発生するよう意識しました。

課題の収集・検討フロー

元々プロダクトを使い込んでいるメンバーも多く、改善アイデアが Slack 等で挙がることがちょくちょくあります。 それらを放置するのはプロダクトとしても勿体ないし、放置が続くと提案してくれるメンバーのモチベーションも下がってしまいます。 そこでマネージャーメンバーの定例アジェンダとして、それらを拾い上げることを徹底しました(そもそもこの定例設置も担当していました)。 議論が落ち着いたものについては全体に周知をするなど、意見を挙げてくれたことが無駄だと思われないようにしました。

チーム間の情報共有機会を設置

メンバーが増えたことで並行開発ラインが増え、情報のキャッチアップが難しくなっていきました。 チャットを注意深く追えば拾うことはできますが、全員がすべてのチャットを追うのは効率的とは言えませんし、そもそも全体把握に対するモチベーションもメンバーごとに異なります。 そこで開発チームを横断して情報を拾えるように、任意参加の確認会を設置しました。 このミーティングに参加していれば、ある程度の概要までは拾えるようにしています。 その上で詳細まで把握したいメンバーは、仕様書やチャットを追ってもらっています。

コミュニケーションのハブ

主にチャット上のコミュニケーションで細かい混乱が起きた際はいち早く反応することを意識しています。 例えばスケジュール決めなど、特定の主導者がいない部分は意識して関わっています。 目的の一つは開発メンバーが目の前の課題に集中できるようにすることで全体のパフォーマンスを向上すること、もう一つは自身がコミュニケーションハブになることでプロダクトに関する課題をより深く理解することです。 特にマネージャーは、実績の積み上げによるメンバーからの信頼構築が大事だと思いますので、そういう目的でもややこしい部分は積極的に関与・解決できるようにしています。

ピープルマネジメント

1on1 などメンバーのフォローを行いました。 月並みですが、なるべくメンバーの意見や意思を引き出すように傾聴を心がけています。 自分はいつも Google Document で会話ログを共有しており、きちんと意図をくみ取れているかを示すようにしています。 副次的な効果として、取り組んだことふり返りがしやすく、メンバーが評価ふり返りを行う際の参考になっているようです。

プロジェクトマネジメント

いくつかの取り組みでプロジェクトマネージャーを担当しました。 Slack コミュニケーションで完結するのが1番スマートとは思いましたが、キャッチアップの負担を考えて定例ミーティングを行っています。 開発が軌道に乗ると細かいすり合わせも多いので、直接のコミュニケーション自体は必須かなとは思っています。 なるべくスムーズになるよう、バックログ整理や議事録まとめなどを行っています。

まだできていないこと

ベロシティや 4 keys など、チーム状態を定量化することはまだできていません。 ちょうど今はメンバーが増える中で新しい組織を模索しており、それと合わせて長期的にチーム改善を継続できるような指標も定義していく必要があります。

また、昨年度はいくつか定期ミーティングを設置しましたが、それらが本当に適量かは測り続ける必要があると思います。 作業時間が減り過ぎていないか、メンバーのモチベーション低下に繋がっていないか、という点は定性・定量それぞれの観点で把握するべきです。 現状ではヒアリングなどを行っていますが、チャットコミュニケーションの量など定量的な指標計測も今後の課題だと思います。

コミュニケーション創出やプロジェクトマネジメント、ピープルマネジメントなど、まだまだ言語化できるほどノウハウを得られていないというのは今後の課題です。 いろいろとアクションは起こせたつもりですが、ふり返りや、成果に再現性を持たせるための知見獲得は次の目標です。

【書評】新1分間マネジャー

読んだ。良かったので感想。

Amazon.co.jp: 新1分間マネジャー eBook : ケン・ブランチャード, スペンサー・ジョンソン, 金井 壽宏, 田辺 希久子: 本

雑感

マネージャーとしてメンバーとコミュニケーションする際に意識するべき事が具体的に挙げられていた。 1on1 をやる時など、細かいところで真似してみようと思える点が多々あった。

気に入ったフレーズ

第2章

  • 何を目標とするか、優れたパフォーマンスとは何か、を自身もチームも理解している状態を作ることが優れたマネージャーには必要
  • マネージャーがやるべきなのは「正しいやり方をしているところ」を見つけること
  • メンバーが称賛を自ら勝ち取ったと思いそれが自信になる、それが重要
  • マネージャーはミスを指摘したあと時間をおく、この時間でメンバーは自分のミスやその影響についてきちんと思考することになる
  • 1分間修正はなるべく早く行う

第3章

  • 目標と現状が一致しているかを考える
  • 称賛には根拠と、心からのものであるかが重要
  • 最初は、メンバーが「概ね正しい」ということを受け入れる
  • 最初は1分間称賛をするべき対象がないか常に注意しておく
  • 目的は自信をつけさせること、だから1分間修正の後半では必ず褒めることが重要
  • 最初に厳しく、後半にやさしく、という順番

第4章

  • 自分をさらけ出し、どんなマネージャーであるかをきちんと伝えること、自分も間違えることがある人間であること、それらをまず認めること

【書評】エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

会社で議論を進めていく上で、「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」を改めて目を通そうということになった。 もちろん書籍は知っていたが、恥ずかしながらきっちり読み切ったことがなかった。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地 |本 | 通販 | Amazon

気になったフレーズ

Chapter 1

  • 曖昧さを減らし、具体性や明確さを増やしていくことがエンジニアリング(が成すべき事)
  • 本質的に分からないのは未来と他人
  • どんなに自分が正解だと思ってもそれは本人の認識においての話であり、他人(の認識)においては正解とは限らない
  • 自分や他人がどんなときに論理的でなくなるのかを知っておく、それが論理的思考の盲点を知るという考え方
  • 怒りを知るとは、自分にとって大事なもの、自分を構成するもの、その延長にあるもの、を知ること
  • 怒りとは悲しみであり、その感情を伝えることが大事であり、正当性だけで相手を変えることはできない
  • 相手の感情(やる気など)といったコントロールできないものを制御するのではなく、仕事に対する行動を観察してよりよい行動に変わるよう導くべき

Chapter 2

  • 人は無意識に思考の範囲を狭めてしまう、それはその閉じた世界が心地よいから
  • 悩むとは何をすべきか分からないこと。これを明確にすれば考えるフェーズに進める。ここに導くのがメンターの仕事
  • 相手に共感し、相手の思考を可視化し、相手の盲点を探索する。そうして相手の思考に余力を作るのがメンターの仕事
  • メンターは意図的に自己開示を行い、フィードバックを受けやすい状態を作る必要がある

Chapter 4

  • ベロシティの悪いチームを外から改善しようとするのは間違い、当人たちが問題に気づくようにメンタリングするべき
  • 分からないものをどうやって分かるべきか、分かったら何ができるのか、それらを自発的にできるようになるのが自己組織化された状態

Chapter 5

  • 権限が明示的でない状態は最も不自由な状態
  • 技術的負債は新たな機能があるときに現状との差分として始めて存在する概念
  • 技術的負債という考えは、エンジニアチームと経営者のコミュニケーション齟齬を表現する必要性から生まれた
  • 例えばエンジニアチームが社内 SIer のように振る舞うのは一見合理的にも見えるが、本来内製化で避けられるコミュニケーションコストを再度抱えることになってしまう
  • ビジネスが進行すると専門チームを作り知の深化に向かいがちだが、これはイノベーションを起こす力が弱まるリスクがある

感想

いくつかマネジメントの本を読んでいれば知っている概念はあるが、それらを理論づけてまとめてくれている。 特に Chapter 1、2 の理論寄りの章は気になる記述が多く良かったと思う。

以前読んだときに読みにくかった記憶があったが、ある程度の理論や実践を経たいま読み直せたのはちょうど良かったと思う。 業務としてはチームと組織それぞれの観点を持ちながらビルディングを行うフェーズと認識しており、その観点では Chapter 3 のアジャイルや Chapter 5 の権限委譲の観点がとっかかりになるのでは、と感じた。

【書評】ゼロから学べる! ファシリテーション超技術

最近ミーティングを仕切ることがちょっと増えたので1冊読んでみた。

本格的な議論に慣れてない、あるいはそこまで顔なじみでないメンバーとのミーティング向けかなという印象で、自分にぴったりという本ではなかった。 ただ要所要所で参考にしたい記述があった。

ゼロから学べる! ファシリテーション超技術 | 園部浩司 | ビジネス・経済 | Kindleストア | Amazon

なるほど、となったところ

  • アジェンダはあらかじめ考えておく、どういう流れでどういう時間配分をするかを決めておく
  • まず現状の不満、次にあるべき姿を洗い出す。その差に注目すれば課題が見えてくる
  • アウトプットはそこに対する問いで決まる、それを考え導くのがファシリテーターの責任
  • KJ 法では7〜10くらいのカテゴリ分けが望ましく、そうならない場合は整理の基準を見直す(議題が複雑すぎる、とかではなくやり方次第で解決できる)
  • 課題の整理と課題の議論は時間を分ける

分かっているつもりだけど自戒

  • 仮に積極性が薄いなら、会議に自然と参加しやすい仕組みを作る(みんなで付箋を出す、とか)
  • 納得感を作るには意見を聞いてもらえたと思ってもらうことが大事
  • 聞いてもらえる、という信頼感が大事