インタビュー技術の探求
インタビュー技術。そう、げんえいさんがね、あんまり好きじゃなさそうって言ってた。
そう、なんかあんまり。 僕は結構好きですけどね。
いや、なんかもう早く、早く次に設計の哲学院みたいな気持ちで読みながら、あと、多分、インタビューみたいなものは、多分専門スキルみたいなものでもあったりするから、
きっともっといい本があるんだろうなーとか思って、なんかあんまりここは力入れずに読んでたっていう感じですかね。
そうですよね。リサーチ系の本とかめちゃくちゃ専門分野としてありますもんね。
そうそうそう。 これちょっと106、107ページだけ触れたいかもなぁ、そしたら。
「丸飲みしないで済ます方法」っていうエッセイなんですけど、これ丸飲みって言ってるのは何かっていうのは、まあいろいろあるんですけど、なんかすげーフリリアントジャークみたいななんか存在のプログラマーが出てくる人なんですよね。
うんうん。 いや、俺のやり方が正しくて、今まで使ってたのが間違ってるから、僕は直したんすよみたいな。
うんうん。 違くて、現状と計算結果が合うシステムを作っていったのなんだけどって、いいような話がされてるじゃないですか。
で、えーっと、これは、まあいいやその106、107って言ってたのがいくつかですね、いいことが書いてあってね。
技術指導者講習会での討論から拾い集めたヒント集であるっていうのが載ってるわけですが、一つ目が言葉遣いに気をつけようで、二つ目が理解の幅を広げよう。
うんうん。 で、三つ目が不完全さに対して寛容であろうで、四つ目が最終的原因者は利用者であることを認めよう。
で、五つ目が理屈のわからない相手のために働くな。 うんうん。 ですね。これはなんか印刷して飾っておきたいですよね。
そうですね、なんかもう普通に現代で同じ話されてないっていう気がするな。 いや、ずっとしてるんですね。
え、だって68年50年以上前ですよ、これ。 いやー、人間進歩してない、進歩してないっていうか、世代交代というか、いうことが起きてるからっていうのはもちろんあるんだろうけど。
あ、違う、68のわけじゃん、86年か。 86年、まあでも40年。 40年。
いや、なんか最終的権威者は利用者であることを認めようとかも読みながら、なんか最終行動やお客様という言葉をこう連想したりとかしながら。
そうですね。 で、結局最終的にこれユーザーが使えないと、いや、あのできましたって言っても、いやできてないやんけみたいな話散々してるなとか思ったりとか。
これ、その4つ目、最終的権威者の下りの締めの文もいいですよね。
もし自分が利用者より頭が良いと思うことが終始あるなら、たぶんプログラマーを辞めて利用者の上司に繰り返すべきなのだって書いてあった。
まあ、でも今だとこうインターネットってやつがあって、俺たちが聞いて、プログラマーの方がいろいろ影響を及ぼすという意味ではいいのかもしれないみたいなことをちょっと今一瞬思いましたけど、たぶんそういうことが言いたいわけじゃないんだよね。
そうですね、そういうことではないと思うけど。
上手にできると思うんだったら、実際もっとやって、それで成果を上げた方がいいよっていう。
そうですよね、だから上手にできるっていうんだったら、じゃあちゃんと権限をもらって、実際それを全うした方が、なんていうか、もくいってやった方がいいよとか。
設計の哲学とモデル
そうですね、第4部はそういう怖い話があったりとか、まあでもそんなところなのかな。さっきね、結構序盤で触れてたコンピュータリソースが増えてきたら、カリカリにチューニングしたコードっていうよりもこっちの方がいいよみたいな話とかを。
ここで出てきてますね、102ページに。仕様とか要件っていうのがあったのに対して、それをコードに落とすっていうのはある意味翻訳作業。その翻訳を、わかりやすいじゃないですか。
そうですね。 そうですね。
で、ただ今だったら面白い、拡張性、変更用意性っていうのをいろいろゴニョゴニョしてやるやり方もあるし、まあメモリちょっとね食っちゃったりとか、スタックが少し深くなったりするかもしれないけど、今でいうとどっちがいいのよみたいな話とかがあったりしますねっていうようなことが書いてあったりして。
そうっすね。 で、だからユーザーというかステークホルダーが出してくる要件で、こういうことを実現してくださいって言われたときに、まあそれを一般化って言ってますけど、まあ抽象化ですよね。ある程度こういう動きなんだろうな、こういう要求が根っこにあるんだろうなっていうのを見せて。
うん。 抽象化するからこそ拡張性を織り込めるとかなると思うので、そういうことも素敵、昭和的な話が書いてあったはず。 うんうんうん。いやーもう全然全然違う時代ですからね。
どうっすね。 だから逆に言うと多分我々もじゃあこの10年ぐらいでいろんな芸術を身につけたが、じゃあもう10年先になったときにはまた前提が変わってくるんで、じゃあその変わった中でどういうふうな設計が良いとされるかとか、今はこういう問題があったからこれはやらないほうが良かったけど、
うん。 今後はこういうことを積極的にやった方がいいみたいなことっていうのは多分いっぱい出てくるだろうから、多分そういうことをちゃんと学び直さないと、あの人の書くことが古いんだよなとか、いやもうこれんなことやってるけどこれは現代においてはもう最適化されてるから問題にならないんだよなとか、そういうようなことがいっぱい言われちゃいそうだなっていうのを思ったりしますね。
確かにな、継承あんま使わないほうがいいよねみたいなことをよく話すからな。 あとそうですよね、86400みたいな数字をバッて使う必要なくて、いや60×60×24って書いても最適化走るんで変わらないですよとか、そのレベルの話を気にするプログラミングしたことないんですよね。
まあそうですね、割とでも極力早いほうがいいよね、無駄なことをしなくていいんだったら無駄を減らした方がいいよねっていうふうに考えると、そういう誤差じゃんみたいなこともあっても、常に考えましょうねという意味ではそういうことを言うみたいなことはあるかもしれない。
なんかでもどっちかというと日コストみたいな話が、日負荷的な話がありますもんね。 86400めちゃくちゃ見慣れてるんで書いてもらった方が1日ねってなりやすいんですけど僕は。 60×60×24だと一瞬迷う気がするんだよな。
どっちもあるな、86400って見た時にピント確かに来るからなもう。 まあ定数化しといてくれればいいんですけどね。 あとなんか昔、すげえ昔に、ポッドタストなんで名前出さないですけど有名な同世代のプログラマーが、
タゴラスの定理ぐらいはみんな知ってると思うから別に、俺だったら関数化しないでいないんで書くけどなーみたいなこと言ってて。だからそこら辺もね、読み手に一発で刺さるかみたいな話があるから、面白いなーって思ったりしてましたね。
いやそういうの、どこにこう当然のラインを敷くのかっていうのは結構難しいなっていうのは常々思いますね。 そうですね。あと、三平方の定理、ピタゴラスの定理っていう名前の関数作られると逆に色絶えそう。公式見ればわかるんですけど、公式てか計算式見ればこれやりたいのねってわからず。
ピタゴラスなー。スペルがわからんからな。 そうだよねー。マス関数のグにありそうな気もするけどね。 あーPHPのマス関数なー。
きっと使うことがあんまないからないんだろうなー。 PHP標準偏差出せないですからね。
確かに。あーまあそうね、統計知識とかってどれぐらい人に求めていいかわかんないだったりするんだよなー。 わかんないですよね。僕はベクトルの計算がマジで、高校で数学1Aとかレベルのやつが、うわ怪しいと思ったんで、
あれですね、働き始めてから実家からチャート式を取り寄せて高校数学やろうって思ってました。で、ライブラリ見つけちゃったからやってないっていう。
いやそうなんだよなーなんか、むずいっすよね。別にそのベクトルの計算するだけだったらまあじゃあ自前そんなライブラリ入れなくても自前でちょっと書きゃいいしなみたいなことってたびたびあるしなー。
あとまあね、なんかURL貼ってここの書いてあるこれですっていう風に言ってくれれば。あれか、前どこだっけ、ペチパカイか、で作者さんが言ってたコメントに計算内容を証明したのを全部コメントに入れたからすごい長いコメントがあるんですよ、これ論文ってあるんですかね、誰か知ってたら教えてくださいって言ってて。
論文で扱うようなレベルのコメントで書くってクソ面白いなーとかっていう話がありましたね。
しかもそれじゃあ論文なかったら論文にできる可能性があるってことだよ、なんてことだし。
はい。
まあだんだんそれできたから次行きますか。
次行きますか。
次が設計の哲学ですね。これがすごい期待して、おーって読み始めたら、うん、あれ?みたいなことを思った図ですね。
でも最初の合成からいいですよね、設計とは何ぞやっていうタイトルはすごい興味深いですよね。
そうですね、そうですね。でまあ、この中で設計ってじゃあ何なのっていう話をしてる中で124ページとかに設計の仕方を学ぶとは、モデルの作り出し方と評価仕方を学ぶことにほかならないっていうような太字になってるところがあって。
あれ?モデルって言うんだ。
そう。
この本なんかあれなんですよね、モデルのことをずっと模型役をやってて、結構毎回脳内変化しながら読んでて、ううってなりながら読んでたんですけど、モデルか。
ここではなぜかモデルって言ってるんですよね。
別物なのかな。多分揺れてるだけですよね。
揺れてるだけとか、あともしかしたらここの中で原型と少しだけ違っているみたいな、では模型と原型とかなんかその辺の言葉遣いのためにあえてここではモデルとかっていうことを選んでるのかなーみたいなことをちょっと、何か理由があってこっちではそのモデルっていうことをあえて使わないといけなかったとかなのかなっていうふうに。
なるほど、すいません話を残し終わっちゃったんですけど、ちょっと多分本の中ではニュアンス変えるためにモデルっていう単語を使ってるかもしれないけど、いわゆるモデルですよね、我々が。普段よく知ってるというとおこがもしんですけど、よく見かける概念であるところ。
モデリングしようって言った時とかに使うモデル。で、こう一言言われると、やっぱそうなのかみたいな。設計するっていうのはやっぱモデルを作ってそれが評価できるっていうことが、やっぱ大事なんだなーっていうのは、ここでもそう言ってるのかみたいな気持ちになりましたね。
自然淘汰の比喩
モデルの評価って難しいですよね。
いや難しいと思いますよね。で、この本のなんかそのもうちょっと前の方とかだと、自然淘汰みたいなものを比喩っていうか、設計のいい設計、いいではないな、まあ設計されたっていうことを自然淘汰みたいなことを考えて、
えっとこう1万年経過してこういう形になってるから、こうなんですみたいな、いうような生物の進化だったりとか。で、生き残ったものっていうのがまあいいものなんだっていうような、いいもの、生き残ったものっていうものを考えるみたいなことを言っていて、
システム評価の重要性
だからある種それが評価、だからダメだったものっていうのは破棄されていくっていうような考え方と並べていたりするんで、まあちゃんと環境に適合できるものがまあ最終的に評価されるっていうことでって考えると、
えっとまあモデルの、モデルを作って評価するっていう時の評価っていうのはちゃんとそのシステムの中で適合できるかどうかっていうようなことになるのかなっていうふうに思いますね。
ちゃんとが難しすぎません。で、それができるんだったら多分適合関数をちゃんと定義して、それに合格、パスしたやつが価値ですみたいな話できると思うんですけど。
多分設計でいった時にこうまあ最初の方の設計だったらまあトップダウン的に分割してうまくその分割ができるっていうところだったりとかすると思うんですけど、でも実際は現場では全体が見えてるわけではないので、分かってる範囲で頑張ってまあそれを生み出していって、まあ時間とともに評価を経てより良くしていくしかまあないよなあっていうふうに思っています。
おだしょー 思ったりもしましたね。あとはなんかこの中でそのモデルのもうちょっと時間軸を短くして考えた時に、じゃあ例えばなんかある画面を作ろうと思った時に、じゃあこれはSPAでAPIで値を取ってきてってした時に多分APIのインターフェースみたいなものを設計すると思うんですけど、
なんかここからこうデータを取っていろんなことをやっていって、ああでもこのAPIの設計だとそもそも実現ができないねみたいなことを素早く検証したりとかいうぐらいのレベル感で言えばまあそうですねこう設計をして評価するってことはまあちょっとプロと作ってみて、こんな感じでその画面のレイアウトは全然崩れてるけど、まあ欲しい情報が出てるよねとか、この情報を出すときにこんだけのデータリソースがあれば出せるよねっていうふうに思ったりもしますね。
っていうようなこととかっていうのはまあ評価に当たるのかなっていう気がしましたね。
124ページ見ると、適切な合成を書く分析にそれと気づくことはもっと難しいって書いてあるんで。
逆に言うとこれが曲がりなりにも早い段階で、ここまずいねとかこれはちょっと失敗してる気配があるぞとかっていうのに気づけると、なんか設計の経験値を積みやすいというか、さっき言った作り出し方と評価の仕方を学ぶことが設計の仕方を学ぶって話だったんで。
早めに採点結果が返ってきてくれれば、じゃあもっとこう作った方がいいのかっていう風に螺旋状に上がっていけると思うので、嬉しいですよね。
そうですね。
仮説検証と設計プロセス
そりゃあそうって感じなんですけど。
けど実際のシステムっていうのは思ったよりも長く生き延びてしまい。
そうですね。
思っても見ない使われ方をして、大変なことになるんだよなっていうのを経験上学んでいるが、それにどうやって向かえばいいのかなっていうのはずっと探究し続けてるって感じですよね。
まあであれか、ここは最後のやつが多分一番言いたかったことというか、一番主張したかったことではないにせよ一番読者を殴りつけておきたかったことかなーっていうのは太字で書いてますね。
アイディアを十分分析しないうちに試してみてはいけないが、そもそもまだ十分良いアイディアがないうちに分析に時間を潰すのもいけない。
変異と選択の間のバランスを取れと。
そうなんだよな。仮説もない中、とりあえず作ってみようとか、とりあえず手を動かそうってやっても多分あんまり得るものはなくて。
当てずっぽうと仮説は違いますからね。
結局失敗したけど失敗しちゃったね、で終わっちゃうと何も情報が増えてないし意味がなくて。
こうじゃないかじゃないか、こういう可能性だったらこういう風にいけるから、じゃあこういう可能性が本当にあるのかどうか調べてみようっていう風にしてやってみて、
じゃあこれでいいんだねとかこれじゃダメなんだねっていう、何かをちゃんと得るものを期待するものは何なのかみたいなことがないと、
確かに立ち止まってても何も情報が増えないのはそうなんだけど、当てずっぽうに何かやったから、ラッキーパンチみたいなのもあるかもしれないけど、
それを効果的にするためにはちゃんと仮説を立てたりとか、何かこうしたいと思ってるみたいな自分たちの意思みたいなものがないと、
結局時間を潰してしまって、タイムアップが近づいてきたんでとりあえず何かっぽいものを作るしかないって言って作って、
最後突然変異がやってきて大変なことになってしまう、怪物に変化してしまうっていうことが起きてしまうんですよね。
ちょっと暗くなってきたんで次に行きますか。
次に行きますか。でも逆に言うとこれがヒントで、そこがさえどうにかすれば何か最悪は免れるんだよなっていう気持ちでもあったりしますね。
そうですね。
事業がうまくいかないとかあるかもしれないですけど、でもそこで得た経験値でまた次何かできるんで、
ただ何もせずお金が減っていって失敗しましたよりは全然得るものはあるはずっていう。
そうね、さっき言ってたようなやっぱり事業っていう外側のシステムの中の一部でしかないですからねソフトウェアは。
って考えると、事業レベルでの仮説検証をしたんですっていうふうに、なんか急に言い逃れみたいなことになりましたけど。
だからそういう目線は確かに大事かもなとか。
そうそう。だからそういう目的を持ってシステムを分析、設計、合成していけばいいんだけど、
ただ作るだけだと多分あれ、何だったんだろうねって終わっちゃったりするんで、まあ勿体ないねっていうことですね。
これであとあれだな、130、131ページあたりシステム設計の3大Bっていうのがあって、
この章すげえ面白そうだなって思いながら読んでたんですけど、もう1回読み直したいんだよな、なんか咀嚼しきれなかった気がしてますが、
ゲイさんは咀嚼済みですか?
食事中ぐらいな感じですかね。
いやでも本当なんかここ、その3大Bって言ってるのが、あり方、ビーイングと振る舞い方、ビヘイビング、なり方、ビカミングっていうこの3つっていうところに着目しましょうみたいな話をしていて、
なんかここに結構システム設計のヒントあるんじゃねっていう気は、なんかやっぱり読んでてすごいしたんですよね。
うるんですよね。超個人的なこと言うと、ベチコン不幸化の発表の内容に絡めたいんだよなって思いながら。
でも確かに、システムを見るときに何に着目してますかみたいなこと考えたときに、
なんかあり方とか振る舞いっていうものは考えるけど、その発展、進化、歴史、学習、なり方、その変化みたいなところとかって、
なんかそれ考えだすとキリないから、一旦そこの条件はこうフリーズしようぜ、他を考えようぜみたいなことをやりがちだなーって思ったりもするし。
なんかでも、いやここは理想な気するんですよねっていうのが、最近の個人的なブームなんですよね。
例えば〇〇マネージャーっていう名前のクラスをつけたら、そこは多分いろんな仕事が流れてくるぞとか、
なり方というか、こいつがこういう生命だとしたら、進化していったらどうなるみたいなのって、
なんか人間予知できるんじゃねっていう気がしててですね、そういう宇宙の声をですね、福岡は私を見るで話したいわけですよね。
いいですねいいですね。
なんかね、すげー、例えが難しい。スポーツでもあるじゃないですか、この選手とこのヘッドコーチを一緒に置いたらどうなるだろうかみたいな、まずいぞこれはみたいな。
だったら間に一例挟みましょう。そうするとオープンクローズローにできるみたいな話とか。
そういう話、なんとなくこう分かってきたぞみたいな気持ちはあり、例えばそのあり方みたいなもの、この中で言うと、
そのあり方みたいなものの見つけ方みたいな着目の仕方が甘いんじゃないかとか、本当はそのあり方ではなくそれは科学的な変化だったりとか不科学的な変化まで含んで考えてしまって、
結果ゴッドクラスが出来上がったりとか、ユーティリティーというゴミ箱が出来上がったりとか言うみたいなこととかなのかなーみたいなことをちょっと思いながら。
でもなんか時とともに変化しない構造とかあり方みたいなのって、例えばなんですけどシステムオブレコードみたいな考え方、その帳表みたいな考え方でアップデートとかしないっしょみたいなものの、
それがどういう構造とかどういう風にあるのかみたいなことがちゃんと定義できるかどうかみたいなことだったりするのかなって考えると、そもそもそういうことに着目せずに現在だけ考えればいいんだとかって言ってアップデートしちゃうと、
気球システムってものが複雑になっていくみたいな、言うようなこととかがなんかこの辺の、なんかこれをこのまま現代に持っていこうってよりは、なんかこういうものにヒントを得ながら、なんか前も話したかもしれないけど、
時間軸みたいなところをスライダーを動かしながらちょっと考えられるようになると、たぶん設計が上手にできるんじゃないかとか、なんかそういうようなヒントになりそうなものがここには眠ってる気がするっていうような気が、本を読みながらしましたね。
あとこれ時とともにって言ってるのが、なんていうか、普通にユニックスタイム何秒ぐらいかみたいなタイムスタンプ的な話っていうよりか、たぶんイベントとかこういう出来事があって、このタイミングで世界が変わったように第2章第3章みたいな話とかもあるし、
本当に永久に変わらないものっていうのを想起して時とともに変化しない構造って言ってるわけではないと思うんで、ってなってくるとじゃあどういうイベントをこれから迎えていくんだろうねっていう話になってきたりしますよね。
そうするとビジネスのロードマップとかプロダクトロードマップとかになってくるから、それがあり方っていうのがなんかこの最初に見た時に、この少なくともあり方ビーングと振る舞い方ビヘイビングっていうのはなんか問題領域と解決領域っぽい話だなっていう気はなんとなくしてたんですよね。
いわゆるドメインモデル的なふうに皆さんがおっしゃるよく呼んでるやつが一番ここに依存しようってよく言われるやつで、で2つ目がなんか技術レイヤーとか実装詳細とかまで含めた設計みたいな話とか。
でここは変えられるようにしておきたい、変えやすいようにしておきたい。なぜならそこって、例えばユーザーが1000人の時と100万人の時で当然やるべきことを果たすべきことは変わるので、それで時と共に送る。科学的な変化、科学なのかっていうのがちょっとわかんないですけど。
そう考えるとこのビヘイビアって言ってるのは本当に振る舞いなので実装だなみたいな感じがして、パラダイムデザインだってなってくるんですけど賛があるんですよね。
システムの変化と進化
ビカミングっていうのを考えようってなってるんで。で実際これワインバーグがこのエッセイの中で言ってるのは131ページか。設計家はとかくなり方を無視するっていう風に言ってて。だからビーングとビヘイビングしか見てないよねっていう感じなんですよね。
今この話を聞きながらどういうものがあるのかなみたいな3番って思ってたときに、法律の改正が来たときに、それは時と共に送る。
システム開発の変化と課題
不可逆な変化、つまり何か可逆の方は自分たちで変えることができる。何ならやっぱりアメターができそうなものってちょっと今考えてて。3番は法改正とかでこれ対応しないといけないですみたいな。年末正成とか去年の分をそのまま使い回せるって言ったら、いやそんなことはないっすみたいなわけじゃないですか。
今年は今年のルールがあるからっていうようなそういうものなのかなみたいな。結局そこを見越して本当は作りたいんだけど、そこを見越して作ればいいんだけど、いや今のことで精一杯だし、今目の前にあることを実現するためにシステムを作るっていうこともそれはそれでやっぱ大事なので、
何かそのなり方みたいなところは無視されて、結果的にその場ではうまくいくみたいながちょっと先にはとてもとても難しくなっていくっていうことなのかなっていうふうにちょっと解釈しましたね。
発展進化歴史っていうような言い換えがその3番のビカーミングのところに書かれてるから、法律改正とか時代の変化みたいな。もう電気がない時代に多分戻れないよねとか、インターネットがない時代考えられないよねとか。
そんなイノベーションレベルの話だけなのかっていうのはわかんないですけど、ここら辺は不可逆一方通行ですもんね。
そうですね。なり方は開発って書いてあるから、ここはわかんないんだよな。開発ってどういうことなんだろうみたいな。
開発ってどこ書いてありましたっけ。
図3の130ページの図3。あり方が補修で振る舞い方が機能で、なり方が開発って書いてあるから。
この図がどういう分解の中でツリーみたいなのがあるんですかね。システムっていうのが事物と家庭っていうのがあって、その家庭の家庭プロセスですよね。
家庭の下のリーフにあり方、振る舞い方、なり方っていうのが書いてあって、それぞれ保守機能開発っていう正しい書きが添えられてると。
だからこの章はもう一回じっくり読んでみたいけど、読んだところであんま分からないんだろうなっていう気はしてて。
ワインバーガーラールなんですけど、なんか空中戦みたいな話ばっかりしてるんですよね。
そうね。
例え話なんだよな。
でもなんかちょっと面白いなと思ったのが、そこの131ページの下のところが、近頃はシステム開発のための自動化システムに多くの関心が寄せられていると。
そのような開発システムがあれば、単に欲しいシステムを記述し、その記述を適当な計算機に放り込み、後は出力装置の前に座って綺麗に組み上がったシステムがポンと出てくるのを待ってれば良いということになるっていう話が書いてあって。
これ、2025年の話してます?みたいな気持ちになりましたね。
毎年というか、みんなずっと同じこと言ってるんだなっていう気がしましたね。
自動化システムと設計の可能性
プレスが出てきて、グラフィックが綺麗って言って、プレス2が出て、すごい実写みたいって言って、プレス3が出てきて、本当に実写みたいみたいなことを毎回言うみたいな勢いで、同じことやってるんだなっていう気持ちになりましたね。
確かに。どっかのワインじゃないんだからって言ってね。
史上最高のグラフィックと言われたプレス鉄を遥かに忍ぶ表現力みたいな。
でも本当にその中でも当たり通しみたいなのはきっとあるってことですよね。近頃の変化を見てると。
あるんでしょうね。
いやまあ、もっと20年30年スパンで見たら大したことなかったって終わる可能性はありますけど。
そうなんですよね。
そういうシステムに関してどういうスパンでどういうふうに観察して、どういうふうに記述してっていうようなことがちゃんとできれば、そのちゃんとが難しいんだって話はさっきからずっとあるんですけど、できればシステムってものがもうちょっと上手に作れるんじゃないか。設計できるんじゃないかっていうようなことではあるんだろうなっていう。
なんかそれはそうっていう気持ちしかしてこなくなったな。言いながら。
いやーファインギーさんがあと10年早く今ぐらいになっていればファインバーグさん呼んでくれたのかな。
確かにケントベックは来ましたからね。
ケントベック来た。
バブおじさんを呼んでたの別の会社でしたっけ。1回リモート講演してくれてて。
どこだったっけな。
どっかやってましたよね。違うとこな気がするな。
そうですね。でもファインバーグが今のソフトウェア開発を見てどういうことを考えるとかどういうふうなものの見方をするかっていうのはやっぱ聞いてみたいですね。
聞いてみたいですね。
なんかいわゆるプロダクトデザイン的な方にもしかしたら要求仕様をもっと探検しようぜってなってるかもしれないし。
普通にコンサルタントとして開発チームをほとんどよくしてるとか組織をよくしてるっていう可能性もあるし。
まあでもちょっと次いきますか。
いきますか。はい。
