「射撃しつつ電信」と集中力の分散
おだしょー じゃあまた別の記事いけますか。
けんえい うんうん。そうですね。15番、射撃しつつ電信ってやつが俺すごい好きで。
おだしょー どこら辺が面白かったですか?
けんえい あれですね。オフィスに来て、Eメールを10秒ごとにチェックし、ウェブをブラッシングして、請求書の支払いをやって、
作業するんだけど全然コードを書くっていうところに入れなくて、ひたすらなんかそういうちょっとやったら終わって、
Eメール見たりウェブ見たりみたいなことをして、午前中が過ぎて開発が全然進まないみたいな話があって、
すごいなんかこう親近感が湧くなって思いました。
おだしょー そんな感じなんですか、今。
けんえい 今はもうそうじゃなくなっちゃったんですけど、昔こんなことやってて、満員電車で揺られて出車して辛いなと思って、
コンビニでご飯を買ってきて、ご飯を食べて、スラックとかメッセージのアプリを読んで、
同僚とちょっと雑談して、じゃあ今日やること確認するかって確認して、またスラック見て、ツイッター見て、
なんかあれが話題になってるらしいぞとかって言うと、なんかそれを調べて、で気づいたら、あれもう12時じゃんみたいな、いう働き方をまさにやってました昔は。
おだしょー そこがこのエッセイの主題じゃないじゃないですか。
けんえい そう、主題じゃないんだけど、ちょうどそういう話をね、昔したときにその同僚に、そういうのが、
あのジョエルオンソフトウェアって本に射撃室全身ってエッセイで書いてあるよって言われて、
それ言われて、そうなんだって言って、この本買っただか、なんかたまたま人から借りたかだか、で、この本に出会ったっていうのがあって、
そういう意味のちょっとこのエッセイ、好きなんだよなっていうのがあって。
で、あとこの本の本当は大事なところは、ただとにかく始めましょうみたいな、前に進めるために着手しましょうっていうような話をしていて、
なんかキノコ本でも似たような話があったなと思って、宮川さんがルーチンワークをフローのきっかけにっていう話をしていて、
手作業しないといけないのがあって、それを毎朝毎朝こうやっていて、それはすごく退屈な作業なんだけど、それが助走になって1日の仕事ができるようになったよっていうような話をしていて、
なんかすごいみんな同じようなことを言ってるなっていうのをちょっと思いました。Nイコール2でみんなって言いました。
観測範囲の全数ですからね。
そうですね。
いい話でお馴染みの壮大さんが仕事のやる気が出ないとかをどうやってコントロールするかみたいな話で、とにかく細かく、
自分のやる気の無さを下回るぐらいに分解せよみたいな、ブログとかスライドでよく言ってて、それにこのただ始めることっていうのは近いなっていう気がしますね。
あとは前は自分さっき朝全然仕事をせずに昼から本気出すみたいなやり方やったんですけど、やっぱり今フルリモートってコミュニケーションオンラインで取るの大事だよねみたいになると、
割と朝からいきなりチケットについてバッと議論するみたいなとか方針決めるみたいなことが結構多いから、
もうただ始める、ここでペアプロの話も出てきてて、ペアプロで始めるきっかけを作るみたいな話があったんだけど、なんか結構もうモブワークみたいになってるからそれに近い状態だから、
多分今は朝からいきなりわっと仕事ができるようになったなっていうのは思ったりしましたね。
それは良さそうですね。なんか人と喋りながらだと始まっちゃいますもんね。
そうなんですよ。自分が準備できてるかできてないかに関わらず、相談なんですけどとか、コンスプリントのこのチケットちょっとこれここ問題がありそうでとかって言われたらもうスイッチ入れてやらざるを得ないね。
あとなんか自分の箇所分なタスクだと今日はどこからやろうかなみたいな、やっぱり意思決定っていうすごいコスト高いのが一個挟まっちゃうので、それに比べると人が仕事持ってきてくれるのは仕事が進むかどうかは別として、作業が始まるっていう意味では良いですよね。
めちゃくちゃ良いですね。
確かにな。プロジェクトリーダーとかテックリーダーだったらDDSクラブやって困ってそうな人に、じゃあ10分だけでも一緒にコード見てみようかって言って、自分が寝起きでやる気が出ないのをごまかしながら仕事始めたりもできる気がする。
ある意味ではフルリモートで働くと誰とも会話せずに一日終わるみたいな、そういうイメージの場合もあるんだけど、逆に自分にとってはフルリモートだからこそ、とりあえず毎朝デイリースクラブもやるから、ここでちゃんとコミュニケーション取っておかないとなとか、やっぱスイッチ入れるタイミングみたいになっていて。
素晴らしい。素敵な感じですね。
ちゃんとそこが機能していてすごいいいなと思いながら、なんか出社するとダラダラやっちゃうし、出社する時間がみんなバラバラだったりしたっていうのはあったので、昼会にしてたんですよね、その時は12時に。
なので12時までは本気出さないみたいな、そういうことがあったりしましたね、前は。
ありがちですね。
でも確かにちょっと家が遠い人がいると、早く来いってつらいよなとか、別にフレックスだしとかって思ってたけど、フルリモートだと家じゃん、みんな出社する条件一緒じゃんみたいになったから、時間が合わせやすくなったっていうのはありますね。
いや、なかなかいい衣装ですね、ここ。
なので自分の中では一番この本で印象に残ってる話ですね。
読む前のエピソードが強いからな。
じゃあ次に行きますか。
クラッシュレポート収集の現代的アプローチ
次行きますか。ここら辺なんだろうな、次。なんか僕次割と飛んじゃうかもな。
そうですね。
いやもうなんか懐かし話みたいなのあったら行かれてもできるけどなみたいな感じになってきたな。
なんか19番とかがUberからクラッシュレポートを自動的に取得する方法っていうやつで、なんかもう現代だとこれ当たり前だよねみたいな気持ちになってて。
特に多分iOSアンドロイドアプリとかはクラッシュしたら基本的にはそのクラッシュした情報がどっかには送られてるでしょうと。
昔Twitterが出したファブリックっていうのがあったなとか、それがFirebaseに行ってクラッシュリティクスになってとか。
確かにクラッシュするとスラックインに通知が来て、なんかあれやばいなみたいな空気になったのを覚えてるなとか思って。
App Storeに出した瞬間にレートがバーンと上がると、やばいみたいな気持ちになるんですよね。すぐにデプロイができないからアプリとかは。
そうですね。
Webサービスだとロールバックするだけなんですけどね。
そうなんですよね。バックエンドは気楽ですよね。
この辺とか今だと結局Webだとサーバーサイドだから、どうせコンテナーの中にあるログを吸い上げてってなってるし、フロントエンドだとセントリーとかがあるから。
そういうのでいろんなとこにデータを集約して、そのデータを分析しながらもう見るのが普通だよねっていう時代になって、だいぶ変わったなっていうのをちょっと思いましたね。
そうだなあ、確かにあんまり、これが25年前に書かれてる話って考えると確かに大事というか、意識的にやるべきことだったのかもなあっていう感じもしますね。
あんまり読んでる時そうも思わなかったんですけど、普通のこと言ってねって思って読んでたんですけど。
確かにな。
まあそもそもインターネットにつながってない可能性ありますからね、全然そのパソコンが。
そうですね。
そうするとちょっとクラッシュレポート収集するの大変ですね。
この本だと次ネットにつながった時に吸い上げるように作っておくとか、次起動した時にログを吸い上げるようにするみたいなアイディアが載ってたりしましたけど、
今とはちょっと状況が全然違うよねって感じは。
昔使ってたポストペットとか収集してたのかなって思っちゃうけど。
ソフトウェアの全面的な作り直し（ビッグリライト）の危険性
また別の章いきますか。
いきますか。
やっぱこの24章は触れとかないといけないですかね。
24、あなたが絶対すべきでないことパート1ですか。
そうです。
この本の中ですべきでないことパート1で言ってたのが、ソフトウェアをまるまる作り直すなっていう話をしてましたね。
そうですね。
ネットスケープの話ですね、ここで言ってるのは。
ネス系、懐かしい。
そこで最悪の戦略的誤りだったよと。
彼らはプログラムをスクラッチから書き直すことを決めたのだって言って、ネットスケープを書き直したと。
その間に作り直してる間にマーケットシェア奪われてしまったよっていう話がありましたね。
ここら辺はどういうところが刺さったとかありますか。
最近話題になってたのでっていうのはありますけど、
ビックリライトっていうのはやっぱり難しいのかなと思いながら、
あんまり大きく作り直しをしてうまくいくっていうのが、
どこからその問題がやってきていて、何を解決したいのかが、
たぶんよく分かってない状態でシステムを作り直すっていうことになっている場合がきっと多いんだろうなっていうような気がしていて、
オニシャルなユーザーの課題はユーザーが本当はやりたいことができていない課題がある。
でもソースコードに手を入れるのがとても難しい。
じゃあ全部作り直そう。
でも全部作り直してもユーザーがやりたいことが達成されるわけではない。
そうなるときっとうまくいかないんだろうなと思っていて。
今後多分それどんどん起きると思うんですよね。
作るコストがどんどん下がっていくんで。
そうなった時に果たして我々は絶対すべきでないことを信じて、
書き直しっていうのは良くないんだっていう話がどれくらい通用するのか。
もしくはこういう時は全部丸々作り直しといいという判断ができるようになるのかっていうのは読みながら考えていたという感じですね。
どうなんですかね。
いや難しいんですよね。
うまくいけば前に動いてたものと同じものが手に入るだけだ的な話もありましたもんね。
ワインバーグでしたっけ、マイケルジャクソンか。
良い表現だなと思ったけど誰が言ったか覚えてないけど、でも本当に良い表現だと思ったんで信じてくださいっていう気持ちではありますが。
マイケルジャクソンだった気がする。
マイケルジャクソンか。
現在の価値とオプショナリティみたいな話じゃないですか。
うまくいって同じものが手に入るだけっていうのは対ユーザー的なアウトコムだったらそうだし、
オプショナリティ、オプションが増えるんだよっていう意味での価値の最大化、期待値の最大化っていうとそれ以上のもの手に入れてるかもしれないし、
まあ進め方、うまくいけば最高ですっていうのはそれはそうなので、
じゃあその現実的なトレードオフというか落としどころどうするんだっけっていうのを考えましょうよっていうのが大事なんだと思うんですけど、
この本でも言ってるし、この前ケントベックも言ってた話だと思うし。
でもそうっすよね、僕この章を読んでて、確かにって思ったのは、古いコードはテストされている、多くのバグが見つかり修正されているっていうふうに書いてあって、
諸説あるかもしれないんですけど、少なくとも新しく作り直した方がバグは出そうだな、最初のうちは。
っていうのは結構直感に合う気もするので、そう考えると継ぎはぎかもしれないけど、ノックアウトされずにちゃんと自分の足で立ってるっていう意味でいうと、
古いコードってちゃんとテストされているし、多くのバグが取り除かれているっていうのは、そういう見方もできるなっていうのは、ちょっと確かにって思いましたね。
まさにそうだなって今話を聞きながら思ってて、過去自分がやってたやつでも、いかにこれを直さずに使用付けにできないかなとか、切り離せないかなとか、
簡単なページであればもうHTMLに吐き出して、これS3にボンと置いてそこにアクセスさせるとかできないかなとか、そういうことを考えてましたね、確かに。
どうにか変更したいところから隔離して、安定稼働を続けるみたいな状態に持っていけないかなみたいな。
全然関係ないですけど、僕が今までいた会社で、新しく作り直すみたいなことをよくやってるなっていう気がしたな。新卒の頃もやったし、次の会社もやったしみたいな。
で、その次に行った会社は僕はやってないけど、ペチパー会議でお話されると思いますけど、すげえ本気の改造、再開発やってたりするし、その次に行った会社は僕はやってないんですけど、いい発表を初登壇の人がしたりしてたし。
いや運がいいんだな。使われてるソフト、プロダクトを長生きさせてる会社にばっかりいるんだな、じゃあ素晴らしいですね。
確かにそうですね。
いや違うか、単純にベンチャーにばっかりいるってだけか。
ベンチャーで生き残った会社に転職すると、そういう天然ものに出会えるみたいな。まあでも、そういうもんですよねっていう気もする。
それをやった動機っていうのはいろんなものがあるなっていう気はしてて、例えばそれをすごいちっちゃい会社でほぼ一人で開発してましたっていう人が抜けて、これから考えた時にちょっと現代っぽい要素も入りつつ、アーキテクチャからやり直すかって話になったりだとか、
あとモバイルアプリのWebViewからしっかりネイティブ化しようかって話が出てきたタイミングで、そのバックエンドのアプリケーションをAPIとして切り出そうかって話だったりとか、
時代の方が勝手に進み上がって俺たちが陳腐化してんじゃねえかみたいなのはちょいちょいやっぱりあったりはしたので、なんかそういう選択せざるを得ない、やり方はね、いろんな締め殺しパターンとかいろんなあると思うんですけど、
やり方はあるよねっていう軸は全然同じなんですけど、やっぱり作り直さなきゃいけない時、来るよねみたいな気はするな。
いやもう自分が目にしたのは完全にオブジェクティブCで書かれたiOSアプリだったんで、それはまさに今金城さんが言ってた時代の変化によってってやつの最たる例というか、
iOSとAndroidはずっとバージョンアップしないとストアに残してもらえないっていうものがあったりとかするんで、ってなるとAndroidアプリも結局すごい古いのがあったんだけど、作り直しをしてコトリンで書き直してっていうのは、
自分が直接やったじゃないけど、それに合わせてAPIも直してとか、新しいiOSアプリの時はAPIも作りましょうって言って、必要なAPIのリストをアップして100本ノックかみたいな、1日1本やると100日後に終わるねみたいなことを見ながら、
もちろん1日1本じゃ終わらないし、難しいやつと簡単なやつとあって、とても大変だったけど、すごい成長につながったなっていう気持ちは、いろんなことやらないといけなかったんで、その時は思いましたけど
そうそうね、フレームワークがメジャーバージョンアップして古いのがBOLでとかもあるしな そうそうそう、逆にPHPは割と長く無理やり動いてしまうから
まあそうっすね、いい仲悪いとか よくも悪くも、とりあえず明日から突然動きませんとか、収益がゼロになっちゃいますとか、ストアから排除されますとか、インターネットで一切アクセスが来なくなるとか
そういうことはな、インターネットの標準についていくために、例えば全部古いhttpsにするとか、ミックスコンテンツにならないようにいろんなところhttpsに書き換えるとか、そういう地道な活動とかそういうのは確かにありましたけどね
そうっすね、だからプロムがクッキー廃止とかマジでやったら大変な人が多かったんだろうなーとかね そうそうそうそう
まあちょっと本の話に戻ると、あなたが絶対すべきでないことがパート1になってるけど、あれこれパート2以降ありましたっけ
これあれかもしかして、ウェブサイトにはパート1で載っけてて、パート2はここに収録されてないっていうかそういうオチ?
それか皮肉を込めて100個あるうちの中でも一番ありがちな罠みたいな、そういうユーモアな可能性もあるけど、でも他のやつはねパート1って言ったらパート2以降あったんだけどな
そうそうそう、ちゃんと続きものはナンパリングされてて
あれ気づかなかった、騙された、ここの方も続編ありますからね、そっちにあるかもしれない
そうそう、モアの方に載ってるかもしれない
じゃあすべきでないことはとりあえず現時点では1個だけだったということで
そうですね
したらまた別のとこ行きますか
うん
漏れのある抽象化の法則とモデリングの難しさ
25か26行きたいな
うんうん
って言っといて、26でもいいですか?
26でいいですよ
25ゲイさんがマークしてるやつあるけど大丈夫そうですか?
うん、大丈夫で
26章がですね、漏れのある抽象化の法則っていう
小題、エッセイのタイトルで、やっぱり法則とか原則、原理、公理大好きじゃないですか我々は
そうですね、散々今のものに触れてきましたからね
多分70個ぐらい法則を紹介してると思うんで
これ漏れのある抽象化って言ってるのは
抽象化宇宙飛行士の話でもなんかしてたもんな、抽象化嫌いなのかなこの人
自明でない抽象化すべて程度の差こそあれ漏れがあるっていう風にボールドでわざわざ書かれてて
抽象化は失敗する、ある時は小さくある時は大きく漏れがあるのだ、物事は悪くなるものだ
この漏れは抽象化が行われているあらゆる場所で起こるっていう風に書かれてて
この表現自体も好きなんですけど、さっき言ってたビックリとか全面書き直し良くないよねっていう話してた時に思ったんですけど
最初に開発していたバージョンからリリースしてユーザーに使ってもらって機能とか追加していくと
作ってる側、提供する側としてもいろんな発見があるはずじゃないですか
その発見っていうのがモデルとかそのレベルで実はこうだったねとかあると思うんですよね
さっき言ったエコシステムとかプラットフォーム的な都合とかと
機能要件的な話とかも除いたとしても、実はこっちの方が正しかった
こういうモデリングであるべきだみたいなものが出てきた時に
理想で言うと本来はリライトというかリモデリングをすべきなんだろうなっていう気は
個人的にはしてて、仕事でやりたくないなと思いつつ
意外と過ぎて怖いけど、でも本当はそういうのもリライトを持ってくる要因になるよねっていう気はしていて
ていうようなことを思った時のこの自明でない抽象化はすべて提供の差こそは無礼がある
抽象化は失敗するって言ってるわけですよ
僕の考えた最強のモデルが何回打ち破られていったかっていう感じで考えちゃいますよね
考えますね、なんかこれで大丈夫やろうと思って出したら
ここは2件以上入力したいんですけどって言われて、ああ終わったみたいな
なんかこれで決まりやろうっていうクラス作ったのに
なんかよくよく考えたら何だ、ヌラブルなフィールドが増えていきますとか
省略可能なフラグが引数に追加されていきますとか
いやもう
鏡で見てきましたね
やめてください
しかもそういう行動、最近自分で行動不害調査とかして直したりとかしてる時に
既存がそうなってるとAIとかがそれに引っ張られてそういう実装しがちだったりとかして
そうなんですよね
いやもうこれ以上やめてくれみたいな気持ちになりながら
ここは歯を食いしばってやっぱりこのクラスとこのクラスは2つの概念が混ざってるから
分割せればって言ってこうえいって分けるみたいなことをやったりとか
いや難しいなって思いながら
多分これ別に前の人の要件の場合は別にこれで断りてたんだけど
蓋を開けてみたらこういう概念とこういう概念があって
実はその1つだと思ってたものは2つだったみたいなオチなんだろうなと思って
これは誰が悪いってわけでもない気持ちになりながら
頑張って対応するしかないって思っちゃうんですよね
ソフトウェアを柔らかくしとくにはいい感じの抽象化が必要じゃないですか
要するに詳細とか具体によりすぎるとゴリゴリに角張ったもの固いものになってくので
ふわーっと柔らかくしとくためには抽象化が必要なんですけど
だからこそ抽象化とか抽象レイヤーでミスってたら
全てがねっていうと非常に辛いですよね
そこらへんをやる力が欲しいというか
素晴らしいモデリングができる力が手に入ればそれに越したことはないし
それを手に入れられるように少しでも知識とか経験を積んでいくべきだっていうのは
反論するわけもないしそれはぜひやらないけど
このモデリングはまだ自信がないですっていう状態をちゃんとモデリングしたいなみたいな
やり直しが効くように抽象レイヤーを扱えないだろうかみたいな
ことを思いながら生きてますねここ1年2年は
そうですね
それができれば苦労しないんですけどただ苦労しないで済むようにしたいんやって話だから
そうそう苦労しないために全力で頑張りますっていう職業ですからね
そうですね
プログラマーってのは
まあでも
早すぎた抽象化をしないっていうのは1個ありますけど
そうですよねそうですよね
明らかに抽象化が足りてないねっていう匂いをちゃんとつけておくことによって
必要な時にちゃんとやるかみたいなあれになるんでシグニファイヤーになるんで
今の話を聞きながら自分は昔読んだパーフェクトソフトウェアをちょっと思い出してて
最初から100点取りに行くっていうのは無理だからテストして情報が増えるようにテストしましょうねっていうことがやっぱ大事だから
やっぱモデリングしたものを何かしらで情報が増えるようにフィードバックをもらえるようにテストする
それは実装してリリースしてユーザーに使ってもらうかもしれないし
そのモデリングを誰かに話を聞いてもらうかもしれないし
ドメインエキスパートのとこに行ってこれはつまりこういうことですかみたいな
もしかしたら猫は喋ってくれないかもしれないけど
そういうことが必要なんだろうなと思いながら
でもそれを適切にフィードバックしてくれる人を探すっていうのがまたむずいんだよなって思ったりしてました
そうですね猫に関しては飼い主にフィードバックさせるしかないので
そうですね
であれでしょさっき言ってた2クラッシュレポートを取るっていうのをやっていくわけですけど
仕事の話をしないでくださいよ
すいません
そうですね
でも出てきた概念が
最近思ったのは
ここはこっちの画面で表示してるこれを出すからって言われたときに
本当に直そのままのものを出すのか
新しい概念を切ってその概念の裏側には
一個のパターンとしてその別の画面で表示してたデータをそのまま出すのかみたいな
そこは結構違いはあるなと思っていて
拡張性を考えたときには
ちょっと例がわかりにくくて
新しい作ろうとしてるところでどういうものを出したいんだっけっていうものを
もうちょっとじっくり考える必要はあるんだろうな
じっくり考えてこれは本当にただ単に同じものを出せばいいのか
それは今後あの情報もこの情報もこの画面で一気に見たいんだみたいなことがあるのかとか
そういう言われたことをやっぱそのままやっちゃダメだよねみたいなことは思ったりしますね
こういう情報を足したくなったときにどうしますとかっていうのは
ザブリをかける上で使える処方だし
そういうのを考えるとさっき言ったシナリオというかペルソナみたいなのが聞いてきたりしますよね
そうですね
こういう機能をこういう目的のためにこういう機能を作ってこういうUIにするけど
じゃあそれを例えば人事労務系の人以外にも使ってもらうとしたら本当にこれで足りてそうとか
そういう人が使うってことは何かしらその人がニーズを抱えてこの画面に来てる
その背景にあるのは何だろうねとか考えたりするわけですもんね
そうですね
さっき言った早すぎた抽象化とかヤグニとかとは対立するんですけど
なんか少なからずちょっと考えとくみたいな
そうなんか考えておくと最悪なんてかここだったらまだ戻れるなみたいなポイントが分かると思うんで
なんか早すぎる抽象化はやらなくてもいいけど考える必要はあると思うんですよね
それを実際に実装するかどうかはまたあると思うので
ある程度考えておいてこれぐらいだったら書き直しができるとか
ここからだったらまだなんとかなる巻き返せるみたいな部分を
なんか考えておく必要あるのかなーって気がしますね
あとあれか略もあるか
ここは将来どうなるかわからんすぎるからめちゃくちゃ融通効かない書き方にしとこうみたいな
そうするとなんかバリエーションが増えたらしっかり書かざるを得ないみたいなやり方もするな
まあイフ文を一個早すのと何が違うんですかっていうと
いや俺はイフ文を一個早す話を今したんですけどっていう顔になるんですけど
そういうのもあるな
何かが変わった時にここでこのレイアウトとかここに寄せておきましょうとか
っていう決まり事を決めておくみたいなのは多分大事なんだろうなって気がしましたね
表明入れておくとか型をつけておくとかはできますからね
じゃないと本当にソースコードのあちこちで似たような概念ないものは似てるのか似てないのかわからないものが
あれとかによって回ってきてこの時はこうなってこの時はこうなってって言われてもなんかよくわかりませんみたいな
ソースコード読んでもやっぱり厳しいってなっちゃうんで
やっぱ対日的な話な気もするなっていう気がするし
拡張には開いててほしいからオープンクローズドになっててほしいしみたいな
やっぱソリッドにいくなみたいな気持ちを今思いましたね
何に対して開いて何に対して開かなくていいのかが見分けがつけばそれはもう失敗しないんですよね
そうそうそう
開くとしたらどう開くのって話もある
そう
っていう風にやるとねなんかここら辺のあなたずっとぐるぐると同じこと言えるんで
そうで具体でもなくしゃべると結局お前たちのその抱えてる問題は何なんだみたいな感じになっちゃうんで
要はバランスとしか言えない
そうそうそう
ただ転んだ時に転ぶのはいいけど大怪我するような転び方しないようにしたいみたいな
そうそうそう
そうするとやっぱりなんか責務みたいな話とそのインターフェースみたいな話がやっぱ大事だなって思って
そこをカッチリしときたいなっていう気持ちになるんだよな
そうですね
まあいいや暗くなってきたから違う話いきますか
はい
