会社のタスクでミドルウェアの状態を取得し、Log Analytics へ書き込む事で可観測性を高めよう！、ということをやりました。その時に得た知見や手順をまとめておこうと思います。
大前提として、以下の要件のもと開発を行っています。
論理的に正しいことは星の数ほどある
何かしらの選択をする時に、論理的に正しい選択って複数ある。じゃあその中での最適解になるものは何だろう？それは論理的思考能力だけでは導かれない。論理的に正しい答えではなく、「ある前提におけるベストな答え」が求められている、と。
なるほどなぁ、すげぇわかる。実装という作業をとっても様々な選択肢とトレードオフがある。僕はよく設計や実装は「何かしらの解決策を説明するものと」と考えている。それはつまり「解決者が対象の問題をどのようにとらえたのか」を表していると思っている。なので解決者の数だけ実装の種類があると思う。「解決 (仕様を満たした実装)」が出来ているのであれば、それは論理的に正しいのだけれども、そのうえで何がベストな選択になるのかは考えたい。そのためにクリティカルシンキングが使えるんだろうな。
最適解を考え、行動し、結果を得る事を目的とする
実装で得たい結果をどこに置くかって事に繋がりそう。
それぞれがトレードオフになるとは思わないけど、まず何を得る事を前提に置くのかってところがスタートだな。
自ら主体的に前提を把握し、その前提から考えられる問題そのものを再定義し、仮説を設定したうえで、解決に向けた行動をとる
難しい、何を言ってるか今は理解できていない。
クリティカルシンキング=主体的な課題設定力(気づき)+ロジシン(論理的思考力)
例えば「雨が降れば電車が遅延する」ことを論理的に正しいこととする。ロジカルな人はこの解を導けるかもしれないが、行動には移さない。クリティカルシンキングの人は雨が降れば電車が遅延するので「一本前の電車に乗る」zという行動に移す。電車遅延により遅刻の可能性があるということを主体的に課題設定し、皆生するための行動である。
同じことを繰り返しその凌ぎの対応をするのではなく、主体的に課題を設定し気づきを得る事が大切。そのサイクルを繰り返す事で成長にも繋がる。気づきや洞察をへ、行動に繋げていく。
批判はするが、それを解決するために行動には移さない人たちのこと。周りがどういう環境であれ、最終的により良くするにはどうすれば良いのか考え行動するようにしなければならない。主語を常に自分にする。
前提を仮設でおき、その仮説に基づいて自ら課題設定をして回答を論理的に導く
これが出来ないと話にならない。
正しい答えを出すことと、それに沿って実践することは別問題
正しい答えを出すことを「設計」、実践することを「運用」とする。多くの場合、運用自伝でうまくいかない事が多い。うまくいかない時に前提のせいにするが、前提を深ぼれば対策できることはいくらもある。
正論的に正しいことは言ってもそれを実践できるかは別問題。「早起きした方がいい」とかそんな感じね。そうなんだけど、じゃあどう実行するの？どう習慣化させるの？みたいなところまで考えて実践できるTODOにまで落とし込まないといけない。思考停止すんな。
変化することを敬遠する人がいるけど、それは本来人間の脳にプログラムされた本能のようなもの。人間が新たに変化を求められるような場面とは、これまでに体験したことのないような状況だと思う。そういう場面だと、過去の自分の経験と紐付けてその状況から逃れるようになっているんですって。
だから「前も乗り切ったのだから今回も行けるはずだ」みたいな根性論が登場してしまうのかなぁ。本来は「楽に攻略するためにどうすれば良いか」を考えた方がいいと思うけど。こういう人間の脳のプログラムも思考停止、クリティカルシンキングを阻害する要因になりうるね。
謙虚さ無くしてクリシンなし
批判的な思考というのは自分の考えや行動に対して批判的になろうってこと。脳のプログラムに抗うにはそれを習慣づけるしかない。まずは傲慢や思い込みを捨てるところから。
何が思い込みだったかって失敗してからじゃないと気付けないのが辛い。「考慮できていませんでした」みたいな意識外からの敵って大抵は問題になってから気づく。だからアンラーニングや学び直しを大切にしてるつもりだけど、限界あるかもなぁ。
「性善説だが、人間は弱い」＝だから、安さにながされてしまいやすい
組織を運営する上では上記の前提を置くといい。仕組みやルールを作るのは安さに流されてしまうので、最低限の決まりを作っておきましょうってこと。
友達が言ってた「仕組みは人を守るためのもの」ってのがあるんだけど、同じことが言えそう。仕組みだルールが先行すると、どうしても人に対する不信感があるのか？と思ってしまいがちがけど、実際はそんなことなくて、人を守るためにあるんだよね。
課題を解決するためのステップ
ざっくりとこんな感じかな？求めている結果が得られない時はどのステップから見直すべきか考えた方が良い。また、どこに到達するための作業か？を見失うと正しく課題解決できていないことに気づけなくなるかもしれない。
何を課題とするのかは価値判断基準が必要となる。例えば新入社員のうちに「給料をもらいすぎ」と課題を定義するのか「知識のキャッチアップが追いつかない」とするのかは人と状況によって異なる。定義する課題が異なれば得られる結果も違う。
解決策の話で言うと、論理的であるかと最適であるかは全くの別物。最適であるものを導かないといけない。
常に主体的に物事を考えて動く視点を持たない限り、与えられた課題以外の課題を自らの意思で認識・定義し、その解決に向けて取り組む、という自律的な動きはできない
真理。求めていた解答。あとは主体的に物事を考えて動く視点をどうやって持つか、精度高い課題をどう定義するか、を実践していきたい。
トリガー効果とは。
ある一部の情報だけどパターンを認識するもの。相手の姿形で強盗だ！と認識するようなもの。これが悪い方向に働き、思い込みを発動してしまうこともある。
これが原因でインプットが単純化されることもある。物事の曖昧な部分が排除されて、重要な事が見落とされてしまったりとか。
これを防ぐためには「前提」を常に変化させる事が大切。水平思考と呼ばれる、思考の寄り道をすれば良い。目的に対して一直線で考える論理的思考とは異なる頭の使い方。思考の寄り道をするためにはいくつかツールがあるのでそれが次章で紹介される。
自分の感情を捨てて、現象を 100% 受け入れる
前提を疑うためのコツ。感情論的に「あの人はこうだ」みたいな決めつけをして勝手に前提を作るのは良くない。本質的な解決策から遠ざかってしまう。人間の感情をないがしろにするという話ではないと思っている。
認識の不協和ってのもあったけど、人間は自分にとって安定する物事の捉え方を無意識にしているらしい。よくある自分の見たい世界を見ているよねって話。だからこそ感情的になってしまわないようにすることが大切。
実現可能性について忘れる
これも前提を疑うためのコツ。例えば「スーツが着られない」ため「痩せる必要がある」みたいなもっともらしい論理を考える。この場合にも「着られるスーツを買う」という解決策もあるかもしれない。その場合に必要な前提は「買うための予算がある」だが、これを満たせない時には「金銭面」に課題があるかもしれない。どんな前提であれば解決策が成り立つのか考え、本質的な課題に着目する。
そうなる状況は避けたいが、そんなことは滅多に起こらないだろう、という考えは危険
これやってしまいがちだなぁ。「起きる可能性」ではなく「起きた時のインパクト」で考えるべき。それも思考停止にならず前提を疑えるようにならないと出来ない頭の使い方。物事を単純化する癖があると、クリティカルシンキングは出来ない。
6~9 章で前提から最適解を導き出すためのプロセスが紹介されていた。
ものさしが複数ある時代
ものさしを複数持つとは、自分自身のあらゆる価値や強みに気づくために様々な視点から見ていこうってことかな。そういう視点こそがメタなものとも言えそう。
では今のあなたにとってのペインポイントとは何でしょう？
ここでいうペインポイントは自分自身の悩みという意味。自分が求めているのはちょっと違くて、理想の状態に近づくために今足りていない部分、っていう意味のペインポイントが欲しい。
ペインポイントを知るためにはとにかく外の世界に出てみる事をお勧めされている。そうすることで新しいものさしが見つかり自分自身をメタに見る事が出来るようになる。これは自分にも有効な手段な気がする。
失敗を失敗とみなさないのは「意思」による
「失敗をしたことがない」というのは周りから見たら「失敗」と思われるような事象でも「失敗」と捉えないようにするということ。これは「意思」でコントロールすることができる。事象を自分にとって都合の良いように解釈して、メンタルなりパフォーマンスなりを安定化させようねってこと。
人が重要な選択や判断を間違えるのは、必ず「余裕」を失った時であると考える
これは確かにそうかも。「余裕」というのが何に対してなのかは人によって違う。時間なのかお金なのかとかとか。
余裕を失うとなんで間違えてしまうのだろう。「とりあえず前進する」「とりあえず何かする」を優先してしまうのかな？「余裕」のない状態からいち早く脱するために、本来の道筋から逸れてしまっても気づけない、みたいな？
弊社ではインシデントの指揮者と担当者を分けてるのだけど、こういう理屈なんだろうな。どれだけ頭た良かったりスーパー強いエンジニアであろうとも、余裕がなくなる状況はある。インシデント対応などセンシティブな仕事ではそういうのを防ぐために役割を分けるってのがあるかもしれない。集中する領域を絞って最速を目指す、ってのもあるかもしれんけど。
ま、この章で言いたいことは失敗を犯してしまうのは「余裕」のない状態だと仮定して、なるべくその状態を防ごうねってこと。自分がどんな時に余裕がなくなるのかに気づくためにメタに思考しようってこと。また、自分に限らず余裕がなくなりがちな仕事に気づいたら、インシデントのように担当者を分けるようなアプローチを提案しても良さそう。
外からどう見られるかを気にしたり、評価されることを気にしたりするために、自分の行動を自分で縛ってしまう
自分は他人と比較をしないほうの人間かなと思ったけど、多分そんなことない。いつも「自分より優秀な人はいる」と考えてしまう。
この本では他人と比較する事で悲観的になったり悪い精神状態になってしまうことをやめようやって言ってる気がする。その文脈だと自分の比較はそない悪いものでもないと思う。なぜ比較するかというと、地に足を付けもっと上を目指すために成長を続けるため。前向きに働いてはいる。
ただ、自分の行動に制限をかけている節はある。登壇とか苦手だしね。解決抱くとしては、OK と思えるラインを自分で定義してしまうという事。これだけで登壇にまで行けるかは怪しい。
なにをもって仕事を成し遂げたとみなすかは、自分で定義する。
仕事が楽しいと感じられないなら自分で楽しくしてしまえばいい。仕事に対して自分なりにエッセンスを加えていこう。そのためには自分が何に対して喜びを感じるのか知らなきゃダメだよね。それってメタな視点がないとダメだよね、ってことかな。
自分の場合は「今まで理解できていなかったことが理解できた」「知らなかったことさえ知らなかった領域を知る」の2点が大きい。そのためにタスクをこなす時は必ずマインドマップ的なものを書いている。そのタスクをこなすのに必要な知識を並べて、そこから派生させて自分の理解している事や理解できていないことを並べる。んで、タスクをこなしながら身に着けていく。その中で「知らなかったことすら知らなかった領域」を見つけられたら超ハッピー。
あとは本で得た知識を実践してる時も楽しい。マインドマップも「世界一流エンジニアの思考法」から連想したやつ。自分の理解度を意識して並べてる。
大切なのはこういう過程の中で自分の特性や強みに気付きオリジナリティを見つける事だと思うの。今の自分は「担当しているプロダクトのこと (採用技術に関する深い事・仕様・課題とその解決策のアイディアなど) について質問するとなんでも答えられる人」を目指している。
「相手をどれだけいい気分にさせられるか」が価値になる
高度情報化社会において一人の人間の脳では処理できる量に限界がある。どうしても人の力を借りないといけないよね。これが苦手なんだよなぁ。
どうしても人間関係のベースを Give & Take で考えてしまう。おれに何のメリットがある？が基盤にある。そんな人に情報なんて集まるわけなくない？Give & Give がちょうど良いかもしれない。
後半は課題に対するアンテナの話。現代社会人の課題の認知やビジネスを行う上で顧客に課題を認知してもらう、ってアプローチが大切だよねってことかな。これは組織活動をどう推進していくか、みたいなことに繋げられそうだけど、今必要としているものではないかなぁ。
視点を変えるために主語を変えるってコツはすぐに使えてインパクトもでかい感覚がある。特定個人ってよりも、立場を表すラベルを主語にするとよさそう。PdMやアーキ、などなど。
マネージャーに向いてる人とは、メンバーと競争しない人。メンバーにコテンパンにされ、それを喜ばしく思える人。
これだけ見ると全くマネージャーに向いてない（笑）自分の技術に対してプライドがあるんだよな。後輩の成長を喜ばしくも思いつつ、心のどこかでおれのほうが強い・負けたくない、って感情がある。自分より優秀な人はいると認めつつ、でも負けたくないと思ってしまう。こういう性格がここ10年くらい自分の強力なエンジンになっているので、まだ見直さなくていいかなと思っているけど。
論理的思考の基本
帰納法は複数の前提から一つの結論を論理的に導き出す思考法。この時の結論は推測になる。複数の前提から導き出すということは、前章で話した「グループから要約メッセージを探す」ために使えそう。
前提には「同じ種類の考え」が並ぶ。「同じ種類の考え」とは、
の 3 パターンがある。それぞれの考え方で推測できるものが変わる。正しく結論を推測出来ているかどうかは、結論と前提を接続詞を使って繋げて読んでみると良い。「なぜならば」や「具体的に言うと」のような接続詞で繋げられないなら、構造を誤っている可能性がある。
また、同じ接続詞で繋げられる前提は同じグループに分けられる可能性がある。
演繹法とは、絶対に決まっている前提を基に結論を導き出す考え方。例えば、「馬は哺乳類だ」「哺乳類は心臓が一つある」という前提から「馬の心臓は一つだ」のように考える。
ビジネスの世界で絶対に決まっている前提というのがあまりないので帰納法が使われることが多い。正しいと思っている前提も実は間違ってしまっていることもある。例えば、過去は成り立ってはいたが現代では成り立たないようなもの。
演繹法では前提を「本当に正しいと言えるのか」と自問するのが良い。
ピラミッドはトップダウンで考えるくらいがちょうどよい。トップダウンで考えるということは、読み手の Q を想像し、主メッセージを仮置きするという事。そうしておけば根拠を集めやすい。集めたうえで主メッセージが誤っていれば修正すればよい。考える過程ではトップダウンとボトムアップを行ったり来たりするのが良い。
ピラミッドの縦は「論理の帰結」を表し、横は「論理付け」を表す。
OPQ 分析により読み手の目的を明らかにするところから始まるのだけど、これはテクニカルライティングでどう応用出来るのだろうか。この書籍では何かしらの調査依頼があって、その報告書としての文章をまとめるシナリオが想定されている。でもエンジニアってそういうパターンあまりないかもなぁ。
例えば、インシデントの影響範囲を知りたい、プロダクト改修の影響は範囲を知りたい、とかはまぁあるだろう。でも直近抱えているのは要求定義と要件定義のライティングで、それって誰かに依頼されてやってるわけではないからなぁ。
アーキに共有する内容としては、
この辺が伝わればよかろうと思ってやっているが、果たしてどうなのだろう。これらをピラミッドの構造のように分析できていると思ったことはない。開発プロセスの各段階で要求される成果物に対する目線合わせをしてくださいって事なのかもしれない。
「しりてが」接続詞は意識的にやめる。
普段から大なり小なりの調べ物はしているので、OPQ 自体は無意識にやっているはず。あとはこれを人に伝えるって事を目的に実践してみたいな。ブログなり技術調査なりで。
Database に接続する時に SqlConnection を使っていたんだけど、
みたいなが疑問が出てきたのでまとめる。
をベースに色々試していく。
The pooler maintains ownership of the physical connection.
pooler と呼ばれるオブジェクトが物理レベルでの接続を管理している。接続の生成や破棄は全てこのオブジェクトがやっているのだろう。ここでいう物理接続とは何なのだろうか。
Closed method が呼び出されても、実際には接続を閉じるわけではなく Pool に返しているだけ。んで次に Open が呼び出された時に Pool 内の Active な接続を Pooler くんが渡してくれますと。って事は同じ接続文字列を使うと、Pool 内の接続を使いまわしてくれるって事だと思う。
var connectionString = "Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=user;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False"; using (var connection1 = new SqlConnection(connectionString)) { await connection1.OpenAsync(); connection1.ClientConnectionId.Dump(); connection1.WorkstationId.Dump(); } using var connection2 = new SqlConnection(connectionString); await connection2.OpenAsync(); connection2.ClientConnectionId.Dump(); // Dispose してるから1 と一緒 connection2.WorkstationId.Dump(); using var connection3 = new SqlConnection(connectionString); await connection3.OpenAsync(); connection3.ClientConnectionId.Dump(); // 2 が開きっぱなしなので 1, 2 と異なる connection3.WorkstationId.Dump();
同じ接続文字列を使って SqlConnection を生成するサンプルコードを書いてみた。
ことがわかった。この例でいうと同じ Database に対する接続は 2 つ作られている。丁寧に Dispose していると同じ接続文字列であれば物理レベルでの接続を使いまわしてくれるって事が分かった。
If Min Pool Size is either not specified in the connection string or is specified as zero, the connections in the pool will be closed after a period of inactivity. However, if the specified Min Pool Size is greater than zero, the connection pool is not destroyed until the AppDomain is unloaded and the process ends. Maintenance of inactive or empty pools involves minimal system overhead.
Pool には寿命があるみたい。MinSize を 0 以外に指定して再生成のコストを安くするのか、一定期間使われない接続は破棄してリソースを節約させるのか、どっちを取るかって判断をしていくかなぁ。
The connection pooler removes a connection from the pool after it has been idle for approximately 4-8 minutes, or if the pooler detects that the connection with the server has been severed. Note that a severed connection can be detected only after attempting to communicate with the server. If a connection is found that is no longer connected to the server, it is marked as invalid. Invalid connections are removed from the connection pool only when they are closed or reclaimed
当たり前かもだけど、切断されたら Pool からは排除されるみたい。しかしアイドルタイムが 4-8 分に達して場合ってのが意外と長かった。
Sever されるのって接続文字列で指定した Connection Timeout の時間が経過した時かと思ったけど違った。SQL Server のタイムアウトには複数種類があって、接続文字列で指定するやつは接続の試行時でのタイムアウトのこと。この記事が分かりやすかった。
https://ichiroku11.hatenablog.jp/entry/2016/02/25/213502
This is also a side-effect of the application design. There is a relatively simple way to avoid this side effect without compromising security when you connect to SQL Server. Instead of connecting to a separate database for each user or group, connect to the same database on the server and then execute the Transact-SQL USE statement to change to the desired database. The following code fragment demonstrates creating an initial connection to the master database and then switching to the desired database specified in the databaseName string variable.
テナント毎に専用の Databse を作って提供するように設計されたアプリケーションだとどうしても接続の数は増えてしまう。そういう場合に行えるチップスって感じかな。
var connectionString = "Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=user;Integrated Security=True;Connect Timeout=1;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False"; var adminConnectionString = "Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=admin;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False"; using (var connection = new SqlConnection(connectionString)) { await connection.OpenAsync(); connection.ClientConnectionId.Dump(); } using (var connection = new SqlConnection(adminConnectionString)) { await connection.OpenAsync(); connection.ClientConnectionId.Dump(); }
この場合それぞれ違う ID が出力される。じゃあ SQL で table を切り替えるようにしてみるとどうなるか。
var connectionString = "Data Source=(localdb)\\MSSQLLocalDB;Integrated Security=True;Connect Timeout=1;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False"; using (var connection = new SqlConnection(connectionString)) { await connection.OpenAsync(); var command = new SqlCommand("USE etl", connection); command.ExecuteNonQuery(); connection.ClientConnectionId.Dump(); } using (var connection = new SqlConnection(connectionString)) { await connection.OpenAsync(); var command = new SqlCommand("USE publishing", connection); command.ExecuteNonQuery(); connection.ClientConnectionId.Dump(); }
こうやって table を切り替えると ID が同じになる。Database が多すぎて Pool が枯渇するって課題が見えてきたら使えるかもしれない。
https://www.amazon.co.jp/dp/4873118646www.amazon.co.jp
続きを読む