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