色んな事を書く

シンプルさを極めたエンジニアになりたい

【読書メモ】データ指向アプリケーションデザイン

5 章 レプリケーション

レプリケーションの目的は

  • データを地理的にユーザの近くで保持しておくことでレイテンシを下げる
  • 一部に障害があってもシステムが動作し続け可用性を高める
  • 読み取りのクエリを処理するマシン数をスケールアウトし、スループットを高める

リーダーとフォロワー

レプリカとはデータベースのコピーを保存する各ノードのこと。全てのレプリカにはデータベースのコピーが行きわたっている必要がある。そのための仕組みがリーダーとフォロワー。

  1. レプリカの一つはリーダーと呼ばれる。書き込みリクエストは必ずリーダーに送られる。リーダーは新しいデータをローカルに書き込む。
  2. 他のレプリカをフォロワーと呼ぶ。リーダーはローカルに書き込むとその変更データを各フォロワーに送信する。各フォロワーは受け取ったデータを順番にローカルに書き込む。
  3. クライアントがデータの読み取りをしたい場合は、どのレプリカから行っても良い。ただし、書き込みはリーダーのみ行える。

Cosmos の物理パーティションは最低でも 1 つのリーダーと 3 つのフォロワーにより構成されている。コンテナがどれほど小さくでも、物理パーティション一つに付き最低でも 4 つのレプリカを持つ。そのうち 1 つがリーダーで、残り 3 つがフォロワーとなる。このレプリカのまとまりをレプリカセットと呼んだりする。

5 つの一貫性レベルがあるが、あれはレプリカセット内での話か?もちろんリージョン跨いで分散されるものだろうけど。

Cosmos DB は同一論理パーティションであればトランザクション処理が行えるが、それって

って理由なのじゃなかろうか?論理パーティションキーから物理パーティションを逆引きも出来るから異なる論理パーティションでも可能かもしれないけど、SDK 側でそのチェックやると実行時エラー置きまくって使い勝手悪そう...。アプリ側で考慮すると複雑化するし、そもそも意識する必要ないものだし?

learn.microsoft.com

リーダーは変更データを各フォロワー向けに送信するとあったが、これは Change Feed の仕組みと関係あったりするのかな?この辺の解像度を上げるのは別でやる必要がある。

learn.microsoft.com

SQL Server には Always On availability group というものがある。この辺は Hyperscale と関係してんのかなぁ。これも別でやる。

learn.microsoft.com

レプリケーションは同期でやるのか非同期でやるのか問題。同期でやるメリットは、常にリーダーとフォロワーの間で読み取れるデータが一致する事。一貫性が保たれるというわけですな。非同期でやる場合はフォロワーが壊れてもリーダーへの書き込みは成功する事。可用性が高まるという事ですな。CAP 定理の話だね。

この本では一つのフォロワーを同期的に更新し、残りのフォロワーを非同期にする方法が紹介されていた。同期的に更新していたフォロワーが壊れると、非同期でやっていたフォロワーをどれか一つ同期的に変更する。これで一貫性と可用性のバランスを取る。この方法は準同期型 (semi-synschronous) って呼ばれてるらしい。

Azure Storage はチェーンレプリケーションが採用されている。これは同期型の発展形。

https://sigops.org/s/conferences/sosp/2011/current/2011-Cascais/printable/11-calder.pdf

http://www.umbrant.com.s3-website-us-west-1.amazonaws.com/blog/2016/windows_azure_storage.html

チェーンレプリケーションっていうのは、書き込みリクエストと読み取りリクエストを受けつけるノードを分け、レスポンスを返すノードを一つにするもの。書き込みはHEADから始まり、差分を全ノードに順番に送る。TAILがその差分を受け付けると、そのままレスポンスを返す。同期的なレプリケーションは書き込みリクエストを受け付けたノードが、レプリケーション先のノードからACKが返ってくるのを待機している。チェーンレプリケーションは ACKは非同期で返すからスループットが良いって事なのかな?

Chain replication : how to build an effective KV-storage (part 1/2) | by Anton Zagorskii | Coinmonks | Medium

フォロワーのセットアップはある時点のスナップショットの適応と、それ以降の変更の要求により行う。だいたいはストレージの機能として用意されてるんじゃないか?増分バックアップとかに似た考え方かも。ストレージ自体を別者に置き換えるとかなら、スナップショットを適応して W write をするとかあるなぁ。

ノード障害への対応

  1. フォロワーの障害: キャッチアップリカバリ
  2. フォロワーはローカルにリーダーからの変更通知の処理結果と、どこまで処理したのかの情報を持っている。それ以降の情報を障害からの復旧時にリーダーに要求すればよい。
    1. リーダーの障害: ファイルオーバー

KQL メモ

KQL を書くことが多くなってきたので自分用のメモを残しておきます。構文とか便利メソッドのまとめ集です。基本的には公式ドキュメントにあるものを色々試した結果を載せていきます。

クエリの対象は Azure Function の実行ログとしています。

一分単位で Error Log の件数を集計し、折れ線グラフにする

requests
| where customDimensions['LogLevel'] == 'Error'
| summarize count() by format_datetime(timestamp, 'yyyy/mm/dd hh:mm')
| order by  timestamp
| render timechart 

where の代わりに filter でも同じことが出来ます (filter customDimensions['LogLevel'] == 'Error')。

format_datetime で datetime 型の値のフォーマットを決めています。

format_datetime() - Azure Data Explorer & Real-Time Analytics | Microsoft Learn

render operator ではグラフの種類を入力します。timechart は折れ線グラフで、必ず datetime を x 軸に指定しなければいけません。既定の値は table で KQL の結果が表になっているのはこのためです。

render operator - Azure Data Explorer & Real-Time Analytics | Microsoft Learn

【読書メモ】自分の意見で生きていく

1 章 意見とは何か

意見とは「正解のない問題」に対して自分なりの考えを持つこと。「正解のある問題」には意見は持てない。正解か誤答しかない。

正解のない問題とは、「開発生産性を高めるにはどうすれば良いのか」といったようなもの。こういった類の問いは答えがないので、調べても意味がない。自分の頭で考え意見を出す必要がある。

正解のある問題とは、「1+1=2」といったようなもの。こういった類の問いは調べることで答えを見つけ出す必要がある。

正解のない問題には正解のある問題が前提となっている場合がある。仕様や制限といったものも該当しそう。論理的に正しい、というのも正解になると思う。

こういった材料を調べ、最終的な自分の意見は自分の頭で考える必要がある。

問へ向き合う最初の一歩目は正解があるかないかを見極めること。どこまで歯応えがあり、どこからが答えがないのか見極めること。アプローチが異なるため。

意見には正解がないので、正しい誤りを議論するのは時間の無駄。ただし、意見の前提となっている正解のある問題には誤りが存在する。意見を正しく導くには、正しい情報を集める事が必要なのだと思う。

2 章 反応だけではだめな理由

反応には価値がないからだね。意見にするためには自分の立場を明確にしないといけない。

3 章 SNS 時代に自分を創る

そもそも不特定多数の人間に認めてもらいたいという欲求がないので、承認欲求のために SNS ~という入りが近い出来ない。

という風に読み替えてみる。

発信すべき内容や情報がどれほど有益化はあまり関係がない。大切なのは「その人がどんな人なのか」が明確になる内容であること。読み手に解釈をゆだねるようなものはダメなんだろうな。セルフブランディングって感じ。

発信プラットフォームは絞った方が良い。Youtube のコメント欄、X での投稿、ブログのポストなど散らばっていては全部自分のものであるという判定をしてもらいにくい。X をベースに色々なメディアを使い分けるのがよさそう。

4 章 生きづらさから脱却しよう

生きづらさの原因が「本来答えのない問題 (生き方など) に答えを定義されてしまう」や「他人の意見を正解と思い込み、それと異なることが恥ずかしいと感じてしまう」ということにあるのではないかという事。

答えの無い問題に対して、答えを定義してくれる人が現れると安心するって側面もある。

「なぜ?」と良く人に問うのだけど、問い方を変えたほうが良いかもしれない。私の根底には「どうしてそういう意見を持ったのか教えてください」というのがあるが、他の人が「正解と違っていることを言ったから問い詰められている」と感じてしまうとやばい。「素晴らしい意見ですね!ぜひその意見に至った過程を教えてください!」みたいな聞き方をすると気持ちいかも。

他人に認めてもらう事の前にどんな自分を認めてもらいたいのか考えよう。そのために自己認識を高めていこう。いくら他人に認められても、それが自分の自己認識と異なっていればつらみが生まれる。

5 章 リーダーシップの最初の一歩

リーダーシップの第一歩は自分の意見を持つこと。集団やコミュニティに属している以上は何かしらの自分の意見を持つべき。言われたことをやるや常に誰かの意見に賛成ではその人がその集団に所属する価値がなくなってしまう。何事においても自分なりの意見を持つことが大切。

自分の意見を考える訓練としては、今の自分には関係のない題材のほうが良い。いざ当事者として何かを考えないといけなくなると、状況を冷静に見られない可能性があるため。関係ないようなことは冷静に情報を集め、複雑にしすぎずに考えることが出来る。

知識がないから意見が言えない、違うと思う。でも絶対にこれだと言いきれる意見を持つにはそれなりに勉強は必要だと思う。勉強して空じゃないと意見は言っちゃいけないとかじゃなくて、自分の意見に自信を持つための勉強は必要だよね、とは思う。でないと議論にならん。

議論をするためにはまず全員の意見が出そろう必要があると言っている?反応として紹介されているコメントも誰かの意見を深ぼっていくためのものじゃないのと思ったけど、どうなんだろう。質問も反応なのであれば、反応のない議論はないだろうね。各々が意見を主張しかしない場だと何もまとまらんだろう。立場を明確にしたうえでってのが大事なんでしょうね。

お互い気持ちよくコミュニケーションをとるために反応ばっかするなよって事かな。会議を開いている以上結局やりたい事は何かをよりよくすることで、そのためにみんなリーダーシップを持ちましょうって事かな。

意見が言えないのは思考をしていないからね。試行がまとまらないというのも含まれると思うけど。特に色んな事を知りすぎると足踏みが遅くなってしまう事ってあるから、そういう人は考える事が多すぎて意見にするまで時間がかかっているのではないだろうか。それでも意見を出せと言われればフィーリングで出せるんだけどね。

6 章 オリジナルの人生へ

時代は変わったんだね。

Log Ingest API を使って Log Analytics のカスタムテーブルへ書き込む

会社のタスクでミドルウェアの状態を取得し、Log Analytics へ書き込む事で可観測性を高めよう!、ということをやりました。その時に得た知見や手順をまとめておこうと思います。

大前提として、以下の要件のもと開発を行っています。

  • Azure Function で定期的に対象ミドルウェアの状態を取得する
  • 取得した状態を Log Analytics のカスタムテーブルに書き込む
  • カスタムテーブルへの書き込みは Log Ingestion API を使う
  • Dashboard を作成し、監視が出来るようにする

目次

  • 目次
  • Azure Monitor
    • Azure Monitor について
    • Azure Monitor Logs について
    • Log Analytics について
  • Log Analytics のカスタムテーブルへログを書き込む方法
    • データコレクションについて
      • DCE (Data Collection Endpoint)
      • DCR (Data Collection Rule)
    • 書き込むための API
      • Log Ingest API
      • Data Collection API
    • Azure Function から Log Ingest API を使って書き込みを行う
続きを読む

【読書メモ】クラウドアプリケーション 10 の設計原則

1 章 全ての要素を冗長化する

クラウドサービスの利用者であり提供者であるので、色んな角度で物事を見られる。 普段意識していないだけで実態は物理的な機器だし。

そもそも Azure にはリージョンを指定出来るものと出来ないもんがありそう。

  • 指定出来る -> リージョナルサービス
  • 指定出来ない -> 非リージョナルサービス
    • ex. Entra ID

非リージョナルサービスの爆発範囲は最悪のケースで全世界に及ぶ。

過去 Entra ID にも障害があり、それからは独立したバックアップ認証サービスを作り運用しているみたい。

Azure AD の耐障害性を高める取り組み | Japan Azure Identity Support Blog

【読書メモ】クリティカルシンキングの教科書

動機

  • 「考慮不足であった」「認識出来ていなかった」といった類のミスを未然に防ぎたい
  • 誰も認知できていない解決が必要な課題を定義し、プロダクトをより良くしたい
  • それらのために、ロジカルシンキングクリティカルシンキングを意識的に使い分けるようになりたい

1 章 クリティカルな思考とは

論理的に正しいことは星の数ほどある

何かしらの選択をする時に、論理的に正しい選択って複数ある。じゃあその中での最適解になるものは何だろう?それは論理的思考能力だけでは導かれない。論理的に正しい答えではなく、「ある前提におけるベストな答え」が求められている、と。

なるほどなぁ、すげぇわかる。実装という作業をとっても様々な選択肢とトレードオフがある。僕はよく設計や実装は「何かしらの解決策を説明するものと」と考えている。それはつまり「解決者が対象の問題をどのようにとらえたのか」を表していると思っている。なので解決者の数だけ実装の種類があると思う。「解決 (仕様を満たした実装)」が出来ているのであれば、それは論理的に正しいのだけれども、そのうえで何がベストな選択になるのかは考えたい。そのためにクリティカルシンキングが使えるんだろうな。

最適解を考え、行動し、結果を得る事を目的とする

実装で得たい結果をどこに置くかって事に繋がりそう。

  • 拡張性
  • パフォーマンス
  • 保守性

それぞれがトレードオフになるとは思わないけど、まず何を得る事を前提に置くのかってところがスタートだな。

自ら主体的に前提を把握し、その前提から考えられる問題そのものを再定義し、仮説を設定したうえで、解決に向けた行動をとる

難しい、何を言ってるか今は理解できていない。

クリティカルシンキング=主体的な課題設定力(気づき)+ロジシン(論理的思考力)

例えば「雨が降れば電車が遅延する」ことを論理的に正しいこととする。ロジカルな人はこの解を導けるかもしれないが、行動には移さない。クリティカルシンキングの人は雨が降れば電車が遅延するので「一本前の電車に乗る」zという行動に移す。電車遅延により遅刻の可能性があるということを主体的に課題設定し、皆生するための行動である。

同じことを繰り返しその凌ぎの対応をするのではなく、主体的に課題を設定し気づきを得る事が大切。そのサイクルを繰り返す事で成長にも繋がる。気づきや洞察をへ、行動に繋げていく。

ピーターパン症候群

批判はするが、それを解決するために行動には移さない人たちのこと。周りがどういう環境であれ、最終的により良くするにはどうすれば良いのか考え行動するようにしなければならない。主語を常に自分にする。

前提を仮設でおき、その仮説に基づいて自ら課題設定をして回答を論理的に導く

これが出来ないと話にならない。

正しい答えを出すことと、それに沿って実践することは別問題

正しい答えを出すことを「設計」、実践することを「運用」とする。多くの場合、運用自伝でうまくいかない事が多い。うまくいかない時に前提のせいにするが、前提を深ぼれば対策できることはいくらもある。

正論的に正しいことは言ってもそれを実践できるかは別問題。「早起きした方がいい」とかそんな感じね。そうなんだけど、じゃあどう実行するの?どう習慣化させるの?みたいなところまで考えて実践できるTODOにまで落とし込まないといけない。思考停止すんな。

2 章 クリティカルな思考を邪魔するもの

変化することを敬遠する人がいるけど、それは本来人間の脳にプログラムされた本能のようなもの。人間が新たに変化を求められるような場面とは、これまでに体験したことのないような状況だと思う。そういう場面だと、過去の自分の経験と紐付けてその状況から逃れるようになっているんですって。

だから「前も乗り切ったのだから今回も行けるはずだ」みたいな根性論が登場してしまうのかなぁ。本来は「楽に攻略するためにどうすれば良いか」を考えた方がいいと思うけど。こういう人間の脳のプログラムも思考停止、クリティカルシンキングを阻害する要因になりうるね。

謙虚さ無くしてクリシンなし

批判的な思考というのは自分の考えや行動に対して批判的になろうってこと。脳のプログラムに抗うにはそれを習慣づけるしかない。まずは傲慢や思い込みを捨てるところから。

何が思い込みだったかって失敗してからじゃないと気付けないのが辛い。「考慮できていませんでした」みたいな意識外からの敵って大抵は問題になってから気づく。だからアンラーニングや学び直しを大切にしてるつもりだけど、限界あるかもなぁ。

性善説だが、人間は弱い」=だから、安さにながされてしまいやすい

組織を運営する上では上記の前提を置くといい。仕組みやルールを作るのは安さに流されてしまうので、最低限の決まりを作っておきましょうってこと。

友達が言ってた「仕組みは人を守るためのもの」ってのがあるんだけど、同じことが言えそう。仕組みだルールが先行すると、どうしても人に対する不信感があるのか?と思ってしまいがちがけど、実際はそんなことなくて、人を守るためにあるんだよね。

3 章 主体的に考えるということ

課題を解決するためのステップ

  1. 課題を認識する
  2. 課題に対する解決策を論理的に定義する
  3. 解決策を実施する

ざっくりとこんな感じかな?求めている結果が得られない時はどのステップから見直すべきか考えた方が良い。また、どこに到達するための作業か?を見失うと正しく課題解決できていないことに気づけなくなるかもしれない。

何を課題とするのかは価値判断基準が必要となる。例えば新入社員のうちに「給料をもらいすぎ」と課題を定義するのか「知識のキャッチアップが追いつかない」とするのかは人と状況によって異なる。定義する課題が異なれば得られる結果も違う。

解決策の話で言うと、論理的であるかと最適であるかは全くの別物。最適であるものを導かないといけない。

常に主体的に物事を考えて動く視点を持たない限り、与えられた課題以外の課題を自らの意思で認識・定義し、その解決に向けて取り組む、という自律的な動きはできない

真理。求めていた解答。あとは主体的に物事を考えて動く視点をどうやって持つか、精度高い課題をどう定義するか、を実践していきたい。

4 章 正しい課題設定と問題解決のための創造的思考

トリガー効果とは。

ある一部の情報だけどパターンを認識するもの。相手の姿形で強盗だ!と認識するようなもの。これが悪い方向に働き、思い込みを発動してしまうこともある。

これが原因でインプットが単純化されることもある。物事の曖昧な部分が排除されて、重要な事が見落とされてしまったりとか。

これを防ぐためには「前提」を常に変化させる事が大切。水平思考と呼ばれる、思考の寄り道をすれば良い。目的に対して一直線で考える論理的思考とは異なる頭の使い方。思考の寄り道をするためにはいくつかツールがあるのでそれが次章で紹介される。

5 章 想像力・発想力を伸ばす思考ツール

  1. ブレスト
  2. マインドマップ
  3. ウィッシュフルシンキング
  4. ランダムエントリー
  5. メタフォリカルシンキング
  6. 6 色ハット問題
  7. SCAMPER
  8. アトリビュート・リスティング
  9. アサンプション・スマッシング
  10. フォース・ルール
  11. サーチ & リプライ

6 章 前提を疑う

自分の感情を捨てて、現象を 100% 受け入れる

前提を疑うためのコツ。感情論的に「あの人はこうだ」みたいな決めつけをして勝手に前提を作るのは良くない。本質的な解決策から遠ざかってしまう。人間の感情をないがしろにするという話ではないと思っている。

認識の不協和ってのもあったけど、人間は自分にとって安定する物事の捉え方を無意識にしているらしい。よくある自分の見たい世界を見ているよねって話。だからこそ感情的になってしまわないようにすることが大切。

実現可能性について忘れる

これも前提を疑うためのコツ。例えば「スーツが着られない」ため「痩せる必要がある」みたいなもっともらしい論理を考える。この場合にも「着られるスーツを買う」という解決策もあるかもしれない。その場合に必要な前提は「買うための予算がある」だが、これを満たせない時には「金銭面」に課題があるかもしれない。どんな前提であれば解決策が成り立つのか考え、本質的な課題に着目する。

そうなる状況は避けたいが、そんなことは滅多に起こらないだろう、という考えは危険

これやってしまいがちだなぁ。「起きる可能性」ではなく「起きた時のインパクト」で考えるべき。それも思考停止にならず前提を疑えるようにならないと出来ない頭の使い方。物事を単純化する癖があると、クリティカルシンキングは出来ない。

7 章 前提を具体化する

8 章 前提からシナリオ化する

9 章 シナリオを評価する

6~9 章で前提から最適解を導き出すためのプロセスが紹介されていた。

【読書メモ】メタ思考

動機

  • 自分自身が気づいていない領域に気づけるようになり、知識の幅を広げたい
    • 何かを得るための一歩目は、得ていないもの・得るべきものの存在に気づきこと、みたいな
  • 当たり前に思っていることに気づき、それを疑えるようになりたい
    • プロダクト開発において「その仕様に気づけなかった」という事象を減らすための切り口にしたい
  • 誰もが「課題」捉えていない事を課題と定義出来るようになりたい
    • 解決可能かつ解決する意味があるってのは前提

1 章 正解にとらわれない観察力

ものさしが複数ある時代

ものさしを複数持つとは、自分自身のあらゆる価値や強みに気づくために様々な視点から見ていこうってことかな。そういう視点こそがメタなものとも言えそう。

では今のあなたにとってのペインポイントとは何でしょう?

ここでいうペインポイントは自分自身の悩みという意味。自分が求めているのはちょっと違くて、理想の状態に近づくために今足りていない部分、っていう意味のペインポイントが欲しい。

ペインポイントを知るためにはとにかく外の世界に出てみる事をお勧めされている。そうすることで新しいものさしが見つかり自分自身をメタに見る事が出来るようになる。これは自分にも有効な手段な気がする。

2 章 思い込みから自由になる思考法

失敗を失敗とみなさないのは「意思」による

「失敗をしたことがない」というのは周りから見たら「失敗」と思われるような事象でも「失敗」と捉えないようにするということ。これは「意思」でコントロールすることができる。事象を自分にとって都合の良いように解釈して、メンタルなりパフォーマンスなりを安定化させようねってこと。

人が重要な選択や判断を間違えるのは、必ず「余裕」を失った時であると考える

これは確かにそうかも。「余裕」というのが何に対してなのかは人によって違う。時間なのかお金なのかとかとか。

余裕を失うとなんで間違えてしまうのだろう。「とりあえず前進する」「とりあえず何かする」を優先してしまうのかな?「余裕」のない状態からいち早く脱するために、本来の道筋から逸れてしまっても気づけない、みたいな?

弊社ではインシデントの指揮者と担当者を分けてるのだけど、こういう理屈なんだろうな。どれだけ頭た良かったりスーパー強いエンジニアであろうとも、余裕がなくなる状況はある。インシデント対応などセンシティブな仕事ではそういうのを防ぐために役割を分けるってのがあるかもしれない。集中する領域を絞って最速を目指す、ってのもあるかもしれんけど。

ま、この章で言いたいことは失敗を犯してしまうのは「余裕」のない状態だと仮定して、なるべくその状態を防ごうねってこと。自分がどんな時に余裕がなくなるのかに気づくためにメタに思考しようってこと。また、自分に限らず余裕がなくなりがちな仕事に気づいたら、インシデントのように担当者を分けるようなアプローチを提案しても良さそう。

外からどう見られるかを気にしたり、評価されることを気にしたりするために、自分の行動を自分で縛ってしまう

自分は他人と比較をしないほうの人間かなと思ったけど、多分そんなことない。いつも「自分より優秀な人はいる」と考えてしまう。

この本では他人と比較する事で悲観的になったり悪い精神状態になってしまうことをやめようやって言ってる気がする。その文脈だと自分の比較はそない悪いものでもないと思う。なぜ比較するかというと、地に足を付けもっと上を目指すために成長を続けるため。前向きに働いてはいる。

ただ、自分の行動に制限をかけている節はある。登壇とか苦手だしね。解決抱くとしては、OK と思えるラインを自分で定義してしまうという事。これだけで登壇にまで行けるかは怪しい。

3 章 課題を発見していく認知力

なにをもって仕事を成し遂げたとみなすかは、自分で定義する。

仕事が楽しいと感じられないなら自分で楽しくしてしまえばいい。仕事に対して自分なりにエッセンスを加えていこう。そのためには自分が何に対して喜びを感じるのか知らなきゃダメだよね。それってメタな視点がないとダメだよね、ってことかな。

自分の場合は「今まで理解できていなかったことが理解できた」「知らなかったことさえ知らなかった領域を知る」の2点が大きい。そのためにタスクをこなす時は必ずマインドマップ的なものを書いている。そのタスクをこなすのに必要な知識を並べて、そこから派生させて自分の理解している事や理解できていないことを並べる。んで、タスクをこなしながら身に着けていく。その中で「知らなかったことすら知らなかった領域」を見つけられたら超ハッピー。

あとは本で得た知識を実践してる時も楽しい。マインドマップも「世界一流エンジニアの思考法」から連想したやつ。自分の理解度を意識して並べてる。

大切なのはこういう過程の中で自分の特性や強みに気付きオリジナリティを見つける事だと思うの。今の自分は「担当しているプロダクトのこと (採用技術に関する深い事・仕様・課題とその解決策のアイディアなど) について質問するとなんでも答えられる人」を目指している。

「相手をどれだけいい気分にさせられるか」が価値になる

高度情報化社会において一人の人間の脳では処理できる量に限界がある。どうしても人の力を借りないといけないよね。これが苦手なんだよなぁ。

どうしても人間関係のベースを Give & Take で考えてしまう。おれに何のメリットがある?が基盤にある。そんな人に情報なんて集まるわけなくない?Give & Give がちょうど良いかもしれない。

後半は課題に対するアンテナの話。現代社会人の課題の認知やビジネスを行う上で顧客に課題を認知してもらう、ってアプローチが大切だよねってことかな。これは組織活動をどう推進していくか、みたいなことに繋げられそうだけど、今必要としているものではないかなぁ。

視点を変えるために主語を変えるってコツはすぐに使えてインパクトもでかい感覚がある。特定個人ってよりも、立場を表すラベルを主語にするとよさそう。PdMやアーキ、などなど。

4 章 新時代のマネジメント作法

マネージャーに向いてる人とは、メンバーと競争しない人。メンバーにコテンパンにされ、それを喜ばしく思える人。

これだけ見ると全くマネージャーに向いてない(笑)自分の技術に対してプライドがあるんだよな。後輩の成長を喜ばしくも思いつつ、心のどこかでおれのほうが強い・負けたくない、って感情がある。自分より優秀な人はいると認めつつ、でも負けたくないと思ってしまう。こういう性格がここ10年くらい自分の強力なエンジンになっているので、まだ見直さなくていいかなと思っているけど。

5 章 視野を広げる人間関係術

6 章 ストレスをなくすシェア力