00:02
こんばんは、2024年4月11日の夜です。
今日は木曜日なんですが、先ほど少しお酒を飲んでですね。
昨日も実は、会社の前社でイベントがあって、最後に集まって、会社のオフィスでいろんな人と、また電車が来てですね。
そうそう、昨日もオフィスで市販機ごとに閉めると言いますか、その状況を前社で報告するミーティングがあるんですけど、
それのタイミングで、それが終わった後に夜懇親会というか、オフィスで食事を用意してくださって、食べたりして、
会社の同僚の皆さんと話す機会があって、いろいろ話し込んだりして、ちょっと遅くなってしまって、
今日もちょっと、いつもよりもそんなに遅くはないんですけど、お酒を飲む機会があって、
昨日も金曜日っぽい感じだったし、今日も金曜日っぽい感じだったし、今週はそういうのが続いていますね。
今日は何の話をしようかなと思うんですけど、一つ仕事の中でよくわからないアプリケーションの挙動があって、
それの原因を探っていくみたいな機会があったんですよね。そういう機会ってソフトウェアエンジニアをしてたらよくあると思うんですけど、
一番最初に対峙するときって、それを再現できるかどうかわからないこともありますし、
本当に何でそうなのか全然よくわかんないっていうことがあると思うんですよね。
そもそもその機能を知らないとか、自分が全て作ったプロダクトではないってことは多々にあると思うので、
その機能ってまずは何ですか?どういうふうに使えるんですか?どういうふうに構成されてるんですか?どういうふうに動くんですか?
どこから始まるし、でも何か動いてないみたいなことがわかって困ると言いますか、どうにくれるってことがよくあるんですよね。
そういうのって最初どう取っつけたら、どうやって対峙したらいいかわかんないんですけど、
仮説を立てて、こうじゃないかっていうふうにいくつかステップを進めていくことで、意外と解決できちゃったりすることもあるんですよね。
03:02
もちろんたまには全然わかんないものもあるんですけど、そういうのに出会ったときに思い出すのは、
ルイ上山さんっていう方が全然直せるかどうかよくわかんないパークに出会っても、めっちゃ頑張ったら気づいたら直せて、すごいみたいなことをウェブ上でおっしゃってるのを思い出して、
全然自分がやってるのは、コンパイラーとかリンカみたいな情報変換した後に、どこで何が起こってるかよくわかんない状態でやるようなもののデバッグでもないですし、
コンカーレンシーに関するバグみたいなのもあんまり扱うことはないんで、それに比べたら多分ずいぶんシンプルな問題であるんですけど、
でも自分からしたらと言いますか、実際対峙してみたら何でこれ起こってるのみたいなことが意外とわかったりして、
だからそういう直感的にわかんないみたいなのは、もちろんあるんですけど、そういう感情とか抜きにとりあえずやるっていうのは結構あるなと思いました。
社内では結構、今オープンテレメトリを使ってログをトレースできるようにしましょうみたいなことを結構導入されていて、
それ結構強力な武器になるんですよね。
アプリケーションが実行した後に、特定の再現させたいリクエストの中でどういう挙動が起こってたのかっていうのを追えるツールの一つになっていて、
それはすごい強力だなというふうに、今日あるために感じました。
そうですね、それが今日あったことですかね。
もう一つ全然違うんですけど、そういうのも含めてソフトウェアの開発って結構不可欠性を含んだものというのはよくあると思うんですよね。
とあるプロジェクトとかで、半年かかりますか1年かかりますっていうものもあるかもしれないし、最初はどれくらいかかるかよく分からない。
3ヶ月とか1ヶ月で終わるかもしれないけど、1年かかるかもしれない。
よく分からないみたいなものも時にはあると思うんですよね。
そういうのも早い段階でどれくらいの規模だろうって当たりをつけることはできますけど、具体的にやっていくにはどう進めていいか分からないみたいな。
そういう問題が時折あると思うんですよね。
そういうものを実際に実現するから価値になると思うんですけど、一方で不可欠性のたくさんある問題に対してどう対峙するかっていうのは一つトピックとしてあるなと思っています。
基本的な戦略としては不可欠性の高いものを分解して潰していくっていうのが戦略になるとは思うんですけど、
一方で個人とかチームが破壊きれない不確実性に対峙したときとか、どうとっついていいか分からないっていうときになったときに対処できないと言いますか、不確実性を潰しても潰しきれないとか何も進んでないわけじゃないんだけど、
06:18
あんまり進んでるようには思えなかったりとか、行ったけど戻るとか、不確実性が高いっていうのはそういう状況だと思うんで、やってみたけど全然ダメだとか、そういうことがたくさん起こるときがあると思うんですよね。
不確実性の高いものを下げるっていうのは基本戦略の一つだけど、一方で不確実性の高いものばかりやっていてもしょうがないっていうシチュエーションがあって、
不確実性の高いものをやるっていうのと、一方でこれは絶対やったほうがいいだろうっていうところの足場を固めるっていう、その両方をやらなきゃいけないと思うんですよね。
それは使い分けなきゃいけなくて、やったらいいこととか、これは不確実にやらなきゃいけないだろうってことはやっていく。
そうするとそれ以外の箇所の不確実性が下がるっていうことがあるんですよね。
なんかそれ結構不思議なもので、実は私はどこかで不確実性のもぐらたたきをしてるみたいな話をしてたんですけど、それは実は正確ではなくて、
不確実性の高いものを潰すだけじゃなくて、不確実性の低いものを倒すことで他の不確実性が全体的に下がるっていうことが起こって、
それはうまく使い分けなきゃいけないなっていうのを結構最近感じていることだったりします。
一方でそれも要はバランスっていうと、要するにすごい大事なんですけど、やっぱりやってみて分かることがすごいあるんで、
そこをちゃんとフィードバックに生かすみたいな経験を個人とかチームにフィードバックするみたいなのがすごい大事だったので、
そういう仕組みができた上じゃないとか期間を決めて、それのフィードバックがある状態じゃないとやっぱりうまく回らないなと思うので、
難しいですね。それではまたお会いしましょう。
