00:03
どうしよっかなぁ。
まあ、進んでって最悪、戻ってもいいんじゃないですかね。どうしてもあれだけど、つって。
いや、大丈夫で、今のところ見落としてる顔がなくて。
まあでも、重宝になっちゃうんですけど、17ですかね、永遠の議論。
永遠の議論はこれは、なんかもう名前の通りだな。全部名前の通りでやってほしいんですけど。
まあ、なんか意思決定とかアクションに繋がらないのに、なんか同じ問題を何回も何回も掘り出してきて話してるとか。
逆にミーティング1個取っても、あれ、今1時間話して何決まったんだっけみたいなので終わっちゃったりとか。
なんかそういうのあるでしょっていう、これはアンチパターンですかね、永遠の議論は。
そうですね。
で、まあそれだけだったら、そんなに普通のことしか言ってなくないっていう気がするんですけど。
なんか僕、ここの中で書かれてたエピソードというか話がちょっと、ああなるほど素敵だなって思ったところがあって。
アメリカの海兵隊の話として書かれてるんですけど。
実はそこは海兵隊って非常に起動力とか決まったことはパッとやるみたいなところが、
すごい強く求められる組織ではあるっていう前提がもちろんあって。
ただまあ意見は全然しっかり持ってしっかり出すべきみたいなことを肯定しつつ、
ただ意思決定とそこから繋がるアクションっていうのをどうやって迅速に回していくかみたいなところで書かれてるんですけど。
決定に従うことと決定に賛成することは別のことだと認めているのだとか、
ひとたび決定が下ったらそれに従わなければならないこととしているとかっていうのが書いてあって、
決定に賛成することと従うこと別っていうのはめっちゃいい態度だなっていうのをめちゃくちゃ思って。
決まったことに対してうだうだ言われているとやっぱり、
当然その人に対処している時間ももったいないし、周りの意識も下がっちゃうっていうのが正直あると思っていて、
ただ自分なりに考えて意見を持って、ある意味そこにこだわりたいぐらい意思を持っているっていう人をないがせろにしたくないなっていう気持ちはもちろんあって、
ってなった時に決定事項に従ったら負けっていう構図を塗り替えて、
賛成することと従うことって別で、チームとしては決まったことは従ってくださいねみたいなことを言えるといいなって思ったりします。
これたまたま最近自分は別の文脈で、
ディスアグリアンドコミットっていう言葉でツイッターとかでも流れてきて、今の初任は一例として長谷川靖さんのブログで、
行き詰まったときこそディスアグリアンドコミットで前進しようみたいな記事が貼ってるんですけど、
Amazonとかは結構そういうカルチャーっていうのが言われてるんですね。
03:05
最近ポッドキャスト聞いてても同じ話、Amazonのディスアグリアンドコミットの話がちょっと出てきたりとかして、
割とこの本が2009年に書かれて、15年後にはそういうことでいきましょうよっていうのが、
Amazonの場合は2016年の冠文主総会なのかな。
この原則を強調しましたよみたいな話があったりとかして、
すごくいいけど、自分が納得がいかないものに対してディスアグリアンドコミットするって結構大変だよなと思いながら。
だいたい変に議論してるときって、本当に失敗するべきなんだよなっていう気持ちもあるんで、
どっちもいいから早く作ってユーザーに見せて検証しようよとか、そういうふうに思ったりするんですよね。
ちょうどこのリンク、たまたま見つけて貼ったリンクとかでも、やっぱりやり直しが効く決断は早くしましょうみたいな話があって、
そうですよねみたいなのは作って、別に見せて、これでもうこれダメじゃん、やり直そうよって言って、
やり直せるものは多分それで良いじゃんっていうのは、本当そうだよなと思いながら。
だいたい文字情報だけ見ながら考えてるときって、みんな思い浮かべてるもの違って、違うから議論が永遠に前に進まなくてみたいなことがすごく多いから、
こういうふうに、こういう状況になってるぞって思った時にみんながどっちかに決めて、
決まったことには従って全力でとりあえず前に突き進みましょうみたいなことが言えるといいよなってすげえ思ったりしますね。
そこで取り返しがつかないことと、結構特別に取り返しがつくような取り消しが可能なことだったらパッとやっちゃおうぜみたいな話が、
あれですね、ティーワダさんの発表につながっていくわけですね。
そうですね。
アジリティを支える品質特性の中で、これもAmazonの話として紹介されてますけど、
2wayドアっていう考え方が紹介されていて、
ロールバックできる方法さえ用意しておけばとりあえずリリースしちゃおうぜみたいな感じに近いかなと思うんですけど、
決定を簡略にする方法を入り口だけじゃなくて入った後にパッと出てこられるような2つ目のドア、
2つ目じゃないか、入ることもできるし出ることもできるドアっていうのを利用しておいて、
それによって1決定のコストというかリスクですかね、
1回やっちゃったら終わりっていう状態っていうのを回避していきましょうみたいな話で、
ワダタクトさんのお話が今ちょっと頭をよぎりました。
エンジニアとかだと多分、このアップデート分かけたらロールバックできないんだからここは慎重にとか、
テーブル作って横でデータ貯めとくのはできるっちゃできるし、ユーザーに見せてないんだったらそうやっていつでもドロップできるよねとか、
06:03
多分いろんな取れる選択肢を考えながら、どうやったら自分たちが困らなくかつスピードを持っていけるかみたいなところを検討するようなっていうのは結構、
この2Aドアみたいな話を聞くとよく連想しますね。
データディスクは本当に取り返しがつかない場合が多いんでね、時と場合によっては。
そうですね、そうですね。
逆に言うとそこ以外はね、ソースコードなんて別にロールバックする必要ないんだからとか。
うん、うん、うん、そうなんですよね。セキュリティ周りと継続データの破壊だけは気をつけて、あとは割とどうにかなる。
うん、なんである種コードレビューでスワッカーのドキュメントを直しますみたいなのは別に、ある種見ずにアップデートしたって直すの違いだからとか、いつも思ったりしてた。
多分見るものによって注意深さが変わってくるんですよね。
こいつマジしたら、あれ?これマジして本番出たらもう終わるじゃんみたいなものはちょっと注意深さを見ないといけないし、
本番影響のものは別に、もういいよマジしちゃってみたいな気持ちになったりとか。
そうですね。本番に出すといっても物質値がすぐ飛ぶようなものはちょっと慎重にやるかとか。
そうそうそう。
なんかちょっとメニューの文言表を変えますかぐらいだったらとか。
で、実は意外とユーザー影響でかくて後で怒られがちみたいなことがたまに。
まあそこはやっぱりポストモーティング文化みたいなのを育みながら。
でもそうですね、ちょっとまあ話す側でというか、今の17層の聞きながら、聞きながらというか自分で話しながら思い出したのが、
海兵隊、これ海兵隊って言ってるのはアメリカ海兵隊ですもんね。
組織作りとかチームビルリングみたいなところで海兵隊参照されてることがめちゃくちゃ多い感じがして、
なんかいろんな本が出て行ったりとか、認定スクランバスター研修受けた時も参考書籍として、
組織作りの文脈でちょっとね紹介されてたりとかして。
なんかよく見ますよね本当にアメリカ海兵隊。
そうですね。
もしかしたら最強のチームってのはアメリカ海兵隊ってことなのか。
それを言うとなんかちょっと現実にしづらくなるんですけど。
まあまあまあね、いろんな意味で強いと思うんで。
アメリカ海軍に学ぶ最強のチームの作り方って本が実際ありますね。
でもそれ海軍ですよね。
そうですね、これは海軍か。
でもどちらかというと、スクラムの父のジェフ・サザーランドがいたのが海兵隊じゃないでしたっけ確か。
そうか。
どちらか今ググっちゃいますけど。
あと別で野中育次郎先生のアメリカ海兵隊非鋭利型組織の自己確信っていう中古新書の本があったりとかもしますね。
09:01
えー、なんすかそのめちゃくちゃ面白そうなやつ。
全然今パッと検索して出てきたっていうだけなんで、中身知らないんですけど。
サザーランド軍隊にはいた、アメリカ軍にはいたと思うんですけど、
あー、米空軍か。空軍ですね。違うところでしたね。
まあでもスクラム海は、アイザール海は結構海兵隊の話、反送してる印象はありますね。
うん。
まあみたいなところで。
うん。
次の質問いきますか。
いきますか。
ちなみに今1時間20分ぐらい。4分の1。
うん。まあ全部読むとは言ってない。
が。
まあでも結構前半に面白い話多かった印象はあるんですよね。
そうですね。
読んでて疲れただけかもしれないですけど、後半は。まあまあまあ。
じゃあ次は20章の一人ひとやつですかね。
これはプロジェクトの作業が一つの任務につき一人の責任者明確に対応しますと。
で、どれが自分の任務でどれが仲間の任務か各自が正確に知っている。
っていうのが、まあそれがいい状況という意味で書かれてるってことですかね。
うん。まあでもこれは確かにすごくある種わかりやすいですよね。
フロントエンドエンジニアとバックエンドエンジニアと分けて、
フロントエンドはこの人に任せて、
バックエンドは俺がやるから、じゃあフロントエンドはお前に任せるなみたいな状態とかになってると、
まあこれは俺がちゃんとやらなきゃいけないんだ。
全う責任を全うしないといけないんだみたいな状況っていうのは非常にわかりやすいですよね。
あとあれですよね。マネージャーとスクラブマスターの兼務をやめなさいとかね。あります?
そうですね。兼務するとそうなんですよね。複雑さがどんどん上がったりとかスイッチングコストが上がったりとか。
あと言うてフロントエンドとバックエンドで分けるのどうなんみたいな気持ちもありつつ、
でもやっぱ得意領域は分かってて分かり合ってたいし、
一方で全員がそれなりにできますだと、
あの人がやってくれるしみたいになると、それはそれでうまく回らない場合もあるので、
なかなか難しさもあるなって思いながら、
これはとある会社のバリューに昔あったバリューに書いてあったんですけど、
背中を預けるみたいなのがあって、それはやっぱりチームとして背中を預けて自分がやるべきことをマットするっていうのは、
結構自分は好きなタイプだなって思ったりとかをしながら、
この一人一人役をチョイスしたのもそういうとこもあって、だったりしますね。
確かにな、今話聞いてて思い出したんですけど、
前にいた会社、5年以上前だと思うんですけど、CTO室になる部署に配属されて、
バックエンドが僕一人でフロントエンドがもう一人のフロント、JavaScript大好きっ子がいたんで、
12:05
2人でやってたんですけど、2人CTO室だからCTOがもしかしたらいたかもしれないけど、
めちゃくちゃ楽でしたね、確かに。
お互いパート領域は分かってて、ある種接合点はもちろんディスカッションしていろいろ物事を決めると思うんですけど、
それ以外に関しては自分で全部進めなきゃいけないんだなって思うと、
一緒に人がたくさんいて進めるっていうのを、またそれをみんなで意思決定するって難しいことでもあったりするしとか。
周りのレベルに合わせないレコードを書くってこんな楽なのか?みたいな気持ちも。
そうですね。
やってた仕事の内容的に、結構複雑なエッセイでのクエリを書かないといけないよね、みたいな場面とかあった時に、
何の遠慮もなくて言うと、後で背後から押されそうなんですけど、
よし、難しい生クエリ書いちゃうぞ、みたいなね。
それ引き継いだ人はすごいこっちを見てるみたいなことはないんですか?
あるかもしれないですけど、一応家内ツールというか管理画面とかだったんでまだ。ユーザーが触れるところじゃなかったんで。
問題がまず解ける。問題解くことが一番まず最初大事ですからね。
そうですね。
一人一役めちゃくちゃいいなと思いつつの、役のサイズどうするみたいなところが結構難しいんだろうなと思って。
さっき言ってたフロントもバックエンドも一人でやっちゃった方がいいじゃん、みたいな。
技術レイヤーとかで分けるんじゃなくて垂直で分割した方が本当は取りやすいんじゃないかとか。
そうですね。
バックエンドって言っても、例えばAPIとかウェブ側、オンラインシステム作る側とバッジ作る人分けますか?とか。
データ処理集計のバッジやる人とアプリ側分けますか?とか。
いろいろ出てきちゃう中で。
あと、スクラムチームとかはクロスファンクショナルでやるべきだっていうふうなこと言ってるのは、同じようなことが一人個人、一個人っていう単位でも言えるんだろうなとフラクタル構造だと思うんです。
役割、役名を分割していった時に何が起こるかっていうのは公明の法則でよく語られるんで。
そのチーム内の個人っていう単位でも起きかねないとかで考えると難しいですよね。
兼任は良くないと思いつつ、メインとサブがあるのは良くないなと思いつつ。
ただ全部やれることはいいことなんだろうなってすごい矛盾した気持ちがあります。
今のその話を聞きながら、このショーの一人ひと役って調理場の写真で例がレストランなんですよね。
15:03
で、ソース係の人はソースを作るし、パティシエは焼き菓子を担当しとか、話が書いてあって。
でも確かに料理って肉専門ですとか魚専門ですみたいな、そんなふうに分かれてるのかなって思ったんですよね。
でもラーメンさん、住所は分けてましたよ。
麺の専門家とスープの専門家と具材の専門家で分けてて、プロダクトのロジェクトマネージャーみたいな人がいて戦ってたんで。
さっきの金城さんの例でいくと、味噌ラーメンを作れる人、塩ラーメンを作れる人みたいに垂直で分かれてた方がいいんだねって思ったときに、
プログラミングの分野だと垂直に分けるとそうなんだけど、他の現場で垂直に分かれてる部分あんのかなって。
少なくとも料理ってシェフがいて、その人がメインで料理をして、盛り付けとかソースだったりとか、
そのメインの部分ではないサブのものを他の人が作ってるみたいなイメージが勝手にあるんですけど、
他の現場ってどうなってんだろうなってふと思いましたね。
そうですね。最強の麺と最強のスープっていう話と、このスープにある最高の麺っていうのは違うよねみたいな話があったりするんで、
そういう意味だと味噌ラーメン専門家、味噌ラーメン道を極めし人みたいな方がいいかもなって思ったりしつつ、
なんかちょっと文脈違うかもなぁと思いつつ、文章をしてるところを言うと、お寿司とか寿司屋さんとかは隊長みたいな人が握るところをやるし、
ちょっと修道中の人がネタを切るとかは多分任せてますもんね。
そうですね。そうだと思いますね。
あとなんかですね、すげーバイネームになっちゃうんですよ。目黒にトンキっていう老舗屋さんがあって、あそこはめちゃくちゃ面白くて、
なんかラインみたいになってるんですよ、調理が。この人が肉切って、この人が衣付けて、この人が揚げてみたいになってて、
で、それ全体切ってる人が一番トップの人みたいな。このオーダー来たからそろそろあれやってみたいな。
で、あそこは調理してる調理場が本当にマニュファクチャーの工場みたいになってて見えるんですけど、
カウンターというかディケイテーブルの中に調理スペースがあって、そこで全員の職人の動きが見えるんですけど、
あそこはすごいいつわつもロワールド的な、いろんな人がせわせなく動いてて見てて楽しいみたいなエンターテイメントだと思ってるんですが、
なのでとんかつは分量してるかもしれないですね。
なるほど、今の話を聞いて、なるほど、だからやっぱ工場的な作り方、
その同じものを同じペースで作るものと、やっぱりこの都度ちょっとこれは違うみたいな、
18:03
行って戻って行って戻ってみたいな反復を繰り返す場合等ではちょっとやっぱ話が違うんだなっていうことをなんとなく認識しましたね。
あとあれですね、たぶんそのとんかつ作りとか寿司職人とかは、
ラダーみたいな感じでこれをできるとか次のステップみたいな感じになってるんで、
コミュニケーション取りながら相手が言ってることがわかるっていうのが前提にあるかもしれないですね。
理解があった上で運動してる。さっきのベンチメンバーじゃないんですけど、
ポジションチェンジはできると思うんで、みたいなのは大事かもしれないですね。
そうですね。プログラマーもあれじゃないですか、ラダーはあったような。
まあまあまあでも、それこそコードを書けない人が上流で設計とかおかしいじゃんみたいな話とかね。
そういう分量は多分良くない。
そうですね。
けどコードを熟知してるからこそ見えてる世界があって、
初期設計とかグランドデザインというかアーキテクトとして全体設計やりますみたいな。
一人一役っていう文脈とはちょっと違うかもしれないけど、
そういうのが責任と分割して、責任分割するっていうことは相手が言ったことに対して、
さっき言った手戻りとか発生させない、受け入れて打ち返すみたいなところもちょっと意味の中に含まれてると思うんで。
そうですね。
っていうのはあるかもしれないですね。
いやー面白いな、より一役。
面白いな。
アドレナリンジャンキー、あれですね、なんか一人でサラーと読んでたときはふんふんそうだねぐらいだったんですけど、
ちゃんと話すとめちゃくちゃ面白いな、この本。
なんかどこつまんでも結構面白そうにちゃんと出てくるからすごいな。
そうですね、そうですね。
じゃあ次、キンジさん。
これ、カーマ中大の緩和、プロジェクト言葉、いいですか。
これはなんか普通の章、83個ある章のナンバーに含まれてないんですけど、
なんかプロジェクトの中で使われる言葉とそれの本当の意味みたいな、
謎の対応表が急に2ページドーンと何の説明もなく挿入されていて、
何ですかね、例えば使われる言葉、中足な人員増長に対して本当の意味いらないみたいな書いてあって、
意味繋がってなくないとか思うんですけど。
この辺はあれですよね。
まあでもこの急速間人員増強って遅れてるから人を増やしましょうみたいな文脈で多分使われるんだけど、
現場にいる人たちの本心は、いや別にいらないんじゃないみたいな。
人を増やしたとて終わらないんだよな。
高度の完成とかって書いて、テストはまだですっていう意味ですね。
テスト書いてあって、いやテストこれから書きます。
これできたって言ったじゃないかみたいな。
そうですね、いやなんかそういうようなデイリーサンドアップミーティングで一応動くところまでは書けましたとか報告したんですけど、
21:06
テスト書いてみたら壊れてたとかね、あったりするんで。
ありますね。
動くところまでは書けたけどまだバグが残ってますみたいなことが本当は正しい意味だったのだろうかとかね。
あとでもこれな、別の章でもしかしたらコメント書いた気がするんで出てきたかもしれないんですけど、
これプロジェクト言葉、使われる言葉としてベストプラクティスっていう証言が出されていて、
でそこ本当の意味っていう対応のところに、ここで働いていない人が考え出したものだから、
我々がやることよりは遥かに素晴らしいってのが本当の意味でしょみたいな書いてあって、
なんかねこうベストプラクティスって確かに組織の中で生まれてきたものじゃなくて、
本に書いてありましたとか、この前なんかカファレンスであの人が発表してたこれ良さそうです、
木原さんが言ってましたみたいなことがベストプラクティスとして採用しましょうみたいな話だと、
なんかねこう自分たちで見つけたものですっていうニュアンスでは確かにあんま使われないかもなとか。
そうですね、なんかそこの多分含んでる意味って、
つまり自分たちが作ってるより、自分たちよりも、自分たちが多分上手くいってない、
上手くいってる、上手くいってないをどう捉えるかもあるんですけど、
自分たちはベストな状態ではないっていうことを認識しながら、外にはより発展的なことをしてる人がいる。
だからこそっていうことでもあるんですよね、きっと。
隣の芝生みたいなね。
ちゃんと自分たちのいる現場については、いかにレガシーかみたいなところの解像度がすげえ高いと思うので、
当然外から仕入れられるものって、当然外向きにパッケージされた綺麗な話が多いと思うので、
そういう意味では必然的にそういうふうになるでしょみたいな感じはしますけど、
なんかでも他の人が言ってるから多分素晴らしいぞっていうちょっと思考テスト的なニュアンスも含まれてると思ってて、
ちゃんと本当はそれこそいいプロセスとかいいフレームワークがあるから使いましょうじゃなくて、
自分たちの足りないところをこういうふうに使えば補ってくれるっていうところまで、
ちゃんと捜索するべきなんですけど、ベストプラクティスだからやりますとかいうと、
なんか強制的に上書きできるみたいな雰囲気でベストプラクティスって言ってないお前どうなんみたいな話で書かれてるのかなって思いました。
そうですね、それだしやっぱり外にあるものって少なくともなんかNイコール1の話じゃないと思うんですよね。
こっちにも適応されてこっちにも適応されてあっちにも適応されてうまくいってるからある種そういうことを抽象化して出てきたものがベストプラクティスだと思うんで、
24:01
やっぱり良さそうに見えますよね。
そうですね。
このベストプラクティスは必ずしも全てのものに当てはまるものではないので、
自分たちのものに当てはめた時にうまく馴染むのか爆発するのかはやってみてのお楽しみみたいな部分はきっとあるよねっていう気がしますね。
そうですね、ここにベストプラクティスがあるのになんでミキランジェルになれないんですかって。
そうそうそうそう。
で、さっきあのあれですよね、魂を貸すっていうところで、いやそれベストプラクティスのために使うって魂を売ってるっていうことですよね。
あーすごいなー、ちゃんと繋がってますね、流石パターンランゲージとかイメージしてただけある。
あともう一個触れたい目に入ったなっていうのが、限定リリースに対して本当の意味としてはそれは無機能リリースだろうみたいなことが書いてあって、
無機能っていうのはどうなのだろうかって覚えつつ、
これはまだベスト版なのでとか一部のユーザーにだけ今ちょっと先行リリースで使ってもらってますみたいなことを言った時に、
やっぱりプロダクト提供している側、事業者としてプロダクト全体の価値っていうのをちゃんと提供できてるっていう状態とはまだ言えないよねみたいな風なことを言ってる気がしていて、
限定リリース、アザエルとか散々やってる意味としては限定リリースとかフィーチャートグルーとかめちゃくちゃ効果的なプラクティスだなとは思ってるんですけど、
やっぱり限定リリースまで行きましたとか部分開放まで行きましたっていうところで甘んじていてはいけない、
それは全然ゴールじゃないなっていうのはここを見てちょっと思ったっていうのがありますね。
なんか自分はこの限定リリースの捉え方はもっと悪い方に捉えてて、
逆になんかモデルはできました、画面はないですとか、ログイン機能だけはあるけど本質的な価値は積み上がってない、
つまり価値のある部分から作りましょうってやらずに、なんか作りやすそうな部分からコンポーネントをとりあえず作ってて、
タイムアップが来たんで一旦ここで開放し出しましょうみたいな。
なるほど。
だからなんか機能間の連携があまりなくて、なんか設定はできるけど、じゃあこの設定されたものはどこで見れるのみたいな、
いやそれまだちょっと作ってなくてみたいな、なんかそういうプロジェクト言葉なのかなっていう風にちょっと、
つまり無機能ですって言うと何もできてないだろうお前って直接言われちゃうから、
いやこれ限定リリースでまだちょっと次、フェーズ2があるんでって言いながら作ってる感じのイメージなのかなって思ってましたね。
なるほどね、そうですね、そっちかもしれないですね文明的には。
27:01
近所さんが言ってたようなパターンは、いやそもそもちゃんと作ってるんだから大丈夫だよっていう。
確かに、僕の方がまだ優等生ですね。
いやそうですね、いやあるな、はい。
まあプロジェクト言葉そんなとこですかね、なんかちょっと皮肉すぎて嫌だなと思ったんですけど、
まあ話し相手がいるとやっぱり面白いところではあるな。
まあでもそうですね、もうすぐ遅れは取り戻せますとかって、
いやそんなことないんだよみたいな話を思いながら、
多分言ってる人とかは目の前の人を説得するためにそう言わざるを得ないみたいなの使って、
なんか目に浮かぶなみたいな。
そうですね、いやトイボックスで見たやつだなと思ったりはして、
まさに本当にあるよねとか見たことあるわみたいな気持ちになりながら、
自分はなんかまあ皮肉はそうなんだけど、結構あるあるなんて思いながら見てます。
はい、じゃあ次行きますか。
次は、これ話してみたいなと思ってた、ソビート式っていうのが21章で、
完成した製品は顧客が要求した機能を備えているが嫌われてすぐに捨てられるっていう章で、
まあインクが悪いってことですかね、要は。
機能はついてるんだけど、うまく、ちょっと使うと壊れちゃったりとか、
なんかうまく使うのが難しかったりとかして、
っていう話でソビート式ってついてて、
なんか全然自分は歴史的な詳しくないから、
ソビートってそんなんだったんですか、知ってたら教えてくださいっていう気持ちで、
ここの章を取り入れました。
これ、そうですね。
これなあ、間違ったこと言うリスク高いなとか思いながら、
何ですかね、捨てる範囲捨てるって言った以上はお前責任取るよみたいになっちゃっても嫌なんですけど、
社会主義的にやってると、いくら働いても別に褒められるわけでもない、
給料変わらないし、
ってなると労働者が、さあこのぐらいやればいいんじゃねって言って最適化してしまって、
クオリティーは下がるみたいな話はあるんじゃ、あるって書いてあったのも見た気はしますね。
なるほど、まあ確かに言われたら確かにそうだって。
そうそう。
そう思いました。
やっぱりね、50m走で手繋いでみんなで一緒にゴールしましょうってやると別に、
この50m走に本気を出す価値はなくなるので。
確かにな。
自分の中でもソビエットって言われた時のイメージが、
最近ソビエットのデザインだったりとか、
あと建築の展示とかを見に行くと、
ソビエットのアンビルトって言って立たなかった建築、
設計はしてたんだけど実際立てなかった建築みたいなものとかを展示してるのとかって、
30:02
結構かっこいいなと思うものがあったりとかして、
イメージとしてすごくポジティブなイメージがあったんで、
なんかそうなの?みたいなとか言うのを思ったりとかして、
ちょっと気になったなっていうところですね。
なんかでもちょうど昨日、RSGTの今年の頭ですね、
2024のKANOモデルのKANO先生が昨日と話してて、
それを見てたんですけど、
いかに当たり前品質とか魅力品質みたいなところが生まれたかみたいな話が触れられていて、
子供のおもちゃの話で、
よく壊れるから嫌だって言われてるようなおもちゃがあった時に、
じゃあ壊れづらくしたら子供喜ぶのかって言われると、
壊れなくなっただけだと別に欲しいものではないよね。
でも今言ってる品質とか通信パークのクオリティの担保の仕方とかって、
いかに故障しないかみたいな話で言ってるから、
これだけにいかにして欲しがってもらえるか買ってもらうかっていうのを考えた時に、
別軸の品質っていうのが必要じゃね?みたいな話。
そういう背景で生まれたんですねっていうのは、
僕は昨日知って、
なんかこのソビエト式の話と非常によく繋がるかなってちょっと思ったりしました。
確かにそうですよね。
子供におもちゃ渡して、
壊れなくなっただけじゃ絶対喜ばないですね。
そうですね。
漫画で言うと別にページ数も多いし、
確かにキャラクターが書いてあって吹き出しも書いてあるから、
漫画としての要件を満たしてる。
が、話は何も面白くないみたいな。
確かに故障はしてない。
五字雑誌もないし、ページが書けてますとかもないし。
ってなっても合わないですもんね。
そうですね。
それだったら何をするだとか書いてある面白い漫画買った方が楽しいのでやっぱり。
この要求した機能は備えてる?切られてすぐ捨てられる?ってちょっと連想して、
近所さんの話とつなげながら思うのは、
以前にトムでマルコの本読んでた時に、
バグをゼロにすることに躍起になってしまうと、
それはあまり良くないみたいな話が確かあったような気がするんですけど。
そうですね。
結局品質っていった時に、
バグがないっていうことが大事っていうよりも、
自分たちがコアとして売ろうと思っているものはないであって、
それがちゃんと機能するっていうことが一番大事だよなっていうのを、
二つを見かけ合わせながら思ったりしましたね。
そうですよね。
バグがない完璧な、ただし使いたい機能がないソフトウェアよりかは、
33:04
めちゃくちゃクラッシュはしてほしくないんですけど。
クラッシュしても自動保存があって復旧できます。
たぶん2wayロアじゃないですか。
まだ嬉しかったりするし。
あとは、ある種この使いにくいっていう部分で言うと、
大会しにくいサービスとかね。
バグなんか動いてるけど大会しにくいみたいなダークパターンみたいなやつって、
別にユーザーにとって何のメリットもないんだよなみたいなことだったりしますよね。
そんな入念にテストされてもないみたいな大会できないことを。
品質の話は他人事として考えるとめちゃくちゃ面白いですよね。
めちゃくちゃ面白いですよね。
自分でやると。
考えることがめちゃくちゃ多くなって難しいなって思っちゃうんだよな。品質ごと自分で。
頭が痛いですよね。
この機能はどれくらいの魅力品質があって、完成したらいくら売れますかとか、
わかんないじゃんってなっちゃうんで。
あとちょっとこのソビエットに関連するとAK-47って。
有名作品ですね。
世界一売れたという。
世界一売れたっていうものなので、
嫌われてすぐに捨てられずに、むしろ世界中で使われたんじゃない?みたいなものがあったりとか。
最初は自分が銃を連想して、銃の話じゃないかと思いながら。
ソビエットって。
でもあれ、構造率どうだったか僕はわからないんですけど、あれが流行った理由って調達コストが低いから。
作りやすいから、揃いやすいからが理由かなっていう気が。
なるほど。
知ってますかね。
そこがこのプロダクトの品質レスみたいな話言われたらまさにって感じなんですけど。
使い捨てですぐ調達ができるっていうのは、ある種我々にとってはウェブのクラウドのインスタンスみたいなものだと思うと、
いつでも破棄できて、いつでもすぐ調達できるって考えると。
そうですね。
イミュータブルインラストラクチャーとか。
ましては銃とかはやっぱり、それ自体がいくら壊れなくても回収できなくなっちゃうコストというかリプがめちゃくちゃ高いと思うので。
壊れないものが敵に渡った時最悪じゃんみたいなね、あると思うんで。
確かにね。
って考えた時に、本当に壊れやすさっていうパラメータに振りたいかっていうと、たぶんね、そこは飛行機とかも楽かなっていう気が。
確かに。
飛行機もあれだな、戦争の機材として見やすがあるから、僕が言ってるのは旅客機ですね。安全性とか耐久性とか。
36:00
ちなみに自分からAKの話を出しておいて、AK-47、世界を変えた銃という本が未だにずっとツンドロになっていて、
今話をして、これはこの本を読めばきっとどうだったかわかるんだろうなって思ったりしました。
確かに確かに。ソフィエト式そんなところですかね。あんまり国名とかを使われると、出しづらくなるな。
最悪切って大丈夫?
いやいや、出せると思うんですけど、やっぱり答えはないっていうところは。
そうそうそう。
じゃあ、もう2時間待ってますね。
