00:07
じゃあ、次行きますか。
これでもセカンドシステム昇降群はあれですよね、ちょっと触れておきたい話ですよね。
これはどんな、そうですか。
セカンドシステム昇降群って名前はついていて、最初に開発システムが成功した時に、
次にじゃあこういう機能を追加しようとか、あれをやろう、これをやろうとか、
実はこれ溜めてたんだけどみたいな、秘伝の機能みたいなのがパッと出てきて、
そういうものを追加していったことによって複雑になっていって失敗していくみたいな、そういうような話ですね。
なんかセカンドシステム、若干違うんですけど似たような話として、
なんか深夜番組がゴールデンタイムに行って面白くなくなるみたいな。
うん、なんか似てるよね、違う気がするなって、今一瞬思った。
えっと、いや違うんだろうな。
違うんでしょうけど、余計なことしたくなるっていう、なんか人間心理というか、
気持ち、たぶん同じってことにしといてもらいたいです。
でもゴールデンに行くってことは、ターゲットの間口を広げて、
今までの人にも喜んでほしいし、こっちの人にも喜んでもらうから、
あれも追加しないといけない、これも追加しないといけないとか、これやってみようよとかってやった結果、
なんか深夜時代の方が良かったよねって言って、あれ?ってなっちゃうことは確かにありそうだなって思いましたね。
素朴にネタだけやってれば良いようにゴールデンに行って、
よく分からない、売り出したいのかなっていう若手の俳優さん女優さん呼んでトークコーナーみたいな。
セカンドシステム昇降軍ってそういう感じですねっていうのが若干強引な気がしたんですけど。
そう、なんか自分はセカンドシステム昇降軍ってちょっと勘違いしてて、
よくあるレガシー、負債が溜まっているから、もう一回作り直せばその負債は全部解決して、
新しいのを作れば全て解決するんです、みたいな気持ちになっちゃうのをセカンドシステム昇降軍だと思ったんだけど、
全然違ったっていうことをこれを読んでて気づきました。
セカンドシステムっていうのが少し誤解を招きやすいっていうか、
いろんな取られ方しちゃいがちだよねっていう気はするんですけど。
あとはすごくネガティブな、良くない話という意味で作り直せばみたいな話をしましたけど、
一方で2回作るとどこでハマるか分かってるから上手に作れるっていう場合もあるし、
必ずしも作り直すのが悪いっていうわけではないんですけど、
負債が溜まってね、これは全部作り直せば解決するんですって言って、
あんまりよく知らないソースコードを全部捨てて作った結果同じものが出来上がるとかね、
同じ所で負債が溜まるみたいなこともあるんで、なかなか難しいねっていうところと。
そうですね、1個目は捨てろみたいな話がこの本で出てきましたっけ?
03:00
出てきます、後ろの1個1個で触れちゃうけど、
1つは捨て石にするつもりでっていうのが11章にあって、
これは最初の1個目は捨てるつもりで作って、
結局要はプロトタイプ作ってうまくいくかどうか検証してみたいな、
やりましょうねって言ってて、プロトタイプ大体捨てられずに、
このまま行こうよって言って使われる問題がこの本の中でも認定されていて、
見てる中でそれでいいじゃん的な?
そうそうそう、そこは雑にいろいろデータベースの体がJSONになっていてとかね、
あるかもしれないんで、そういう時はしっかり捨てましょうって思ったりするんですけど。
ロカルでSDライト置いてるだけなんで、デプロイしたら全部データ飛ぶんで。
あれあれですね。
でもそうですね、ゲイさんが言ってた2回目の方が筋がいいものができるみたいな話で脱線なんですけど、
最近自分の仕事とか考えてみると、
1回目なんか機能作る時は結構本当にインターフェースとかアブストラクトとか置かないでベタベタに書いて、
何だったらテーブルも作らないでちょっとEラムだったりクラス定数で管理してみたいな感じでやって、
2回目作る時にやっぱりここら辺って闘争するよねってなった時にすってインターフェース切ったりとか、
リファクター入れてみたいなやってるんで、
1回目やっぱりうまくいかないよねっていう気もしますねって思いながら日々過ごしてるんですけど、
この本見たらセカンドシステムは気をつけないと破綻するよっていうふうに書いてあって、
プロジェクトがどうやったら失敗するかっていう本なので余計なことをしないようにしなさいとか、
いやあなたのエゴじゃなくてユーザーが欲しいものを作るようにしなさいとかそういう話ですね、
やぐにやぐにってやりましょうみたいな。
でもこれ難しいなって思うのが結局システムは成功しましたって言っても、
例えば上場している会社であれば株主からもっと収益を上げることを考えましょうって言った時に、
多分ターゲットを広げていくみたいなことをやったりとか、
スタートアップであればもっとユーザーを獲得するんやっていって、
機能は今だとカバーできるのが例えば市場の5%しかないからあと95%が残っていて、
それをどんどん取りに行くんだっていうことをやった時に、
どんどん良さそうだったからって言って機能追加してしまうっていうのは全然今でもありそうだし、
でも求められている部分もある。
それユーザーに求められているわけではなく、
違うステークホルダーから求められている部分もあったりとかして、
これ現代でも全然起きてそうだなと思うし、
すごい難しいところ、
いろんな人を納得させるという意味で難しいことだなと思ったりもしましたね。
俺なんか似たようなさっきのゴールデンタイムのバラエティの話よりは筋良さそうな、
現代風に言うとこういうことかなっていうのがあるんですけど、
06:00
誰だっけな、リュウジーさんあたりが言ってると思うんですけど、
バックログに、プロダクトバックログにアイテム1つ追加するんだったら、
その代わりに今あるやつを1個捨ててからにしなさいよみたいな感じがあって、
それはね、もしかしたら作られる前の、実装される前の話だから、
ちょっと違うっていうところもあるかもしれないんですけど、
機能が増えるとなんだろうな、
作られた機能がうまくいけば有益な試算だし、
少しでも何かの品質特性を妨げるんだったら、
それって不細って呼ばれるものになるので、
紙一重どころじゃなくて全く同じものじゃないですか、
そういう意味で言うとすごい似てるなというか、
あれもこれもやりたくなるとか、
今は落ち着いたからこれもできるはずだっていう風に飛びつくと、
死ぬぞっていう感じで近いなという気はしますね。
最近開発が前倒してるから、
ちょっとどうしようかねみたいなことを話すことがあって、
いいことじゃないですか、前倒してて、
いろいろ準備が整わないからリリースはまだできないね、
バックログ空になりつつあるね、どうしようって言って、
じゃああれ作るかこれ作るかみたいな話をするんですけど、
怖くて追加したくないなって思っちゃうんですよね。
でも仕事しないとマネージャーに働いてないから、
推量下げるねって言って評価下げられちゃうから、
あれしたらいいんじゃないですか、
既存のクラスの名前を変えてコミットしてプッシュしてデプロイして。
それをもう一回戻してね。
ほら毎日こんなに草が生えてます。
それ昔レールズのコミッターの人が、
ナンバーワンになる秘訣はリバーとしてコミットするってことだよってジョークを言ってたけど。
無限ワープみたいな。
でも本当にユーザーのフィードバックもらわないと、
機能を追加することに対する自信みたいなものが、
あんまり持てないなっていうことは最近すごく思っていて、
それがまさにセカンドシステムの証拠群かもしれないなっていうのを
証拠群に陥ると大局にいる、
反対側にいるんだなってことをちょっと思ったりもしましたね。
これ現在42ページ見てもらいたいんですけど、
自制心、セカンドシステム証拠群を克服するって書いてます。
確かに。
自制できてるうちはいいんじゃないですか。
これ僕だったら他のチーム入って一緒にプログラミングするかなとか。
お前が人術交換できないって言ってたじゃないかってあるんですけど、
同じ会社だからやっぱり少なからず他のシステムとつながる部分とかもあるよねって意味だと、
いろいろ見ていきたいし。
同性で入っているプロジェクトとかチーム関係なく
商売対応するんだからさ。
そうそう。
なのでそういう時は全体の改善をやるとかね。
ちょっと手が回らなくてできてないことを、
じゃあこっちで引き取るよみたいな。
09:00
じゃあうちのバックログに入れとくねみたいなことをやっていけばいいんだよなって思いながら、
リファクタリングとか改善活動をやったりとかしてますね。
いいですね。
自制できてますね。
セカンドシステム証拠群そんな感じですかね。
じゃあ次は7章バベルの塔いきますか。
今6章だけどうします?
この本の表紙がバベルの塔になってるんですよね。
確かに。
実は。
だからこの本って人物の神話だけど、
でもバベルの塔のところが実は大事?みたいなことを思いながら。
でも私が持っている版はまたピアソン版なんで、
バベルの塔じゃなく違う絵だったりもして、
いろいろ厄介なんですけど。
僕もピアソンですけどこれバベルの塔じゃないですか?
違うマルゼンだ。
マルゼンのやつがバベルの塔なんですよ。
自分が持ってるのは1個前のピアソンから出たやつで、
中古で買ったやつはこっちが届いたっていう感じですね。
バベルの塔の話に行くと、
なぜ失敗したんですかっていうことですよね。
バベルの塔っていうのはどれくらい伝わるものなんですかね。
みんな知ってるものなの?
このポッドタスト聞いてる人なんか知ってるんじゃないですか?
ウィキペディア呼びますか?
そうですね。
神話ですよね。
天に届くような塔を作ってるんですよね。
バベルの塔っていうのは。
集約聖書か。
塔を高く高く石を積み上げ、
塔を高く高くしてたんですけど、
これが神の怒りに触れ、
そういうことはさせないようにというところで、
その人々が話す言葉をバラバラの言葉にしてしまいましたよって言って、
コミュニケーションが通れなくなって完成しなかった。
上手くいかなくなってしまったっていうのがバベルの塔の話。
そうですね。
もともと同じ言語でコミュニケーション取れてて、
だからすごい生産性とかクリエイティビティもなかった。
そんなことは別に聖書に書いてないと思うんですけど。
そうすると神様が自分の住む世界で
なんか人間来そうじゃね?やばーって
コラーって言葉をバラバラにしてその結果。
っていうよく使われる話ですよね。
そうですね。
ここの章ではバベルの塔みたいなことが起きると
プロジェクトは失敗するよって言って
プロジェクトが成功するためには
例えば十分な人、時間、リソースが必要なんだけども
結局コミュニケーションっていうものが上手くいかなければ
そういう他の要件が満たされていたとしても
上手くいかないんだっていう話をしていて
やっぱりコミュニケーション大事だよねっていう話に
落ち着くんだなとかって思いながら読みましたね。
そうというかアップル墓地、僕なんか好きですね。
ユーモアがあって。
出だしでバベルプロジェクトの管理監査っていう書き出しで
12:04
いきなり始まってて
なんかポストモーティブみたいなこといきなり
し始めてるんですけども
5箇条まず挙げてて
明白な使命あるいは目的がちゃんとあったかみたいなのとか
要因はあるか材料はあるか時間はあるか技術はあるか
っていう5個の項目立ててて
それは全部イエスさん十分に満たしてるよね
でも失敗したよね
それはコミュニケーションが取れなくなったからであるっていう
ワンクッション挟んで
じゃあお前らのプロジェクトの話でもしてやんよみたいな感じ
そう考えたら
例えばリモートワークで働くって
結構やっぱプロジェクトやってくれで
もちろんちゃんとコミュニケーションものづくと取ろうとしていればいいんだけども
それがオンラインになったことによって
今日の作業はこれでこれを担当します
以上で次の翌朝までコミュニケーションが一切ないって
結構難しいですよね
それこそねさっき言ってた
あとは人員投下さえすればスケーラーとしていけますぐらいの
単純化された作業だったらある程度いいかもしれないですけど
なかなかそうもいかないでしょっていうのを扱わないと
やっぱり事業はそんなに伸びないと思うので
そうですね
いやその前段の5個の要件も
だいたい満たしてないぞって思っちゃうんですけどね
そうですね
他の条件が整っててもなおコミュニケーションっていうのがいきなり
全てをぶっ壊すぐらいの強烈なファクターだよっていう話だから
全然間違ってはないんですけど
なんかこの5個揃ってるだけですげえ羨ましいなっていう感じもありつつ
そうですね
あとは足りないものがあった時に自分たちでどう創意工夫するかとか
足りないんだったら調達しましょうになるかもしれないし
諦めましょうになるかもしれないし
妥協点をここにしましょうとかって
コミュニケーションとか取れたらまだできるんだけどもなっていう気もしましたね
あー確かにそれもできないっすもんね
スケジュール遅れてるなんて聞いてないのに君このまだ10秒しかかけてないのーみたいな
話になるとまあ破綻するので
でこれ
ここで言ってるコミュニケーションってそもそもどういうものを指してるのかって話も
売れられてたりはして
あとそうですね
さっき言ってたあの作業の分割とか機能の専門家みたいな
ひとりひとりでしっかりやっておいて終わったらここに集合なっていうスタイルで
よければコミュニケーションそもそも不要になるよねって話が書いてあったりだとか
あとはなんかなんだろうな
強い引っ張る人リーダー核の人が2人いた場合にその役割分担が曖昧になっちゃっていて
とかっていうのはコミュニケーション失敗するパターンだよねとか
っていう話が載ってますね
これのアンチパターンに対応するために下下手術チームやりましょう
15:02
とかって書いてあるのか
そうですね
この本も実は結構あっちこっちから
こっからこっちへ言及みたいなことがあったりするから
章ごとに線を引くと結構立体的に読めて面白いかもしれないなっていうのは
思いつきですけど思いましたね
そうですね
コンティニュアルテーマがバラバラの章立てしてるように見えて
だいぶ同じことをいろんな切り口から言ってる本ではあるので
そうですね
あっちの話こっちにもしてたよねみたいな感じが結構ありますからね
そうですね
依存管理っていう意味で言うとぐちゃぐちゃですね
依存の方向性を揃えたいとか思いますけどね
じゃあ次いきますか
どこにジャンプしますかね
じゃあガンガン進みましょう
12章とかがこれもまたコミュニケーションの話をしていて
綺麗味のいい道具
なんかタイトルからするとあれじゃないですか
やっぱ職人はいいツールをちゃんと準備して
それを使って仕事を進めていくんだみたいな感じがしてたんですけど
タイトルを見た時には
でも読み始めると道具っていうのは大事は大事なんだけども
自分だけが持っている道具みたいなものっていうのは
プログラム開発プロジェクトから見ると分かれていて
本質的問題はコミュニケーションであり
個人的なツールはコミュニケーションを助けるよりも
妨げになるようなものなのだっていう風な書かれ方をしていて
個人的なツールとコミュニケーションを助けるというよりも
妨げになるんだっていうようなことが書かれていて
そこが結構意外だなって思って読んでましたね
具体的にどういう想像をしました?
自分の中では例えば手元で
今だったらビームとかVSコードとかプラグインとかを
自分で選定していいものを使っていく
なるべく自分の手に馴染むようなものを使っていく
みたいな職人みたいなことをやっていて
それが生産性を上げている
高くしているような状態があって
それは別にコミュニケーションの妨げになるかな
みたいな感じはあって
一体これはどういうことなんだ?
みたいなことをちょっと思ったりしましたね
なるほど
そうですね
個人的なツールを使うことの功罪あるよねっていうのは分かる
それがコミュニケーションの妨げっていうのは何でなんだい?
っていう感じですかね
言わんとしてるというか
すごい自分なりに想像力を働かせると
つながることもあるかなっていう感じはするんですけど
ここで言うコミュニケーションって言ってるのが
18:02
本当に何を指してるか次第だなっていうのはありつつなんですけど
例えば僕がUbuntu使ってて
ゲイさんがWindows使ってますって言ったら
ちょっと助けてくださいって言っても
いやちょっとマイクロソフト社に聞いてくださいみたいな
話になってきちゃったりとか
そういうコミュニケーションを取ろうとした時の妨げになってるとか
っていうのはあるかなとかなんだろうな
実行環境が整ってないとか
プロジェクトの進め方に対して
同じやり方をしていないみたいな感じですかね
最近TLタイムラインで話題になってるのはあれですね
他はプロジェクトに用意しとくけど
なんだかんだ職人は自分で作った環境を使うみたいな
それがここでは良くないこととされている
そこで何かトラブルあった時に助けられんとか
うっかり間違ったことをしてしまった場合に
うまくいかないことが起きる
もしかしたらさっきあれで言えば
使ってるゴーデスが違うことによって
突然開業コードが全部置き換わっているとか
もうちょい現代的な文脈というか
我々がピンときやすい頃まで引きずり落とすと
あの人しかそれの使い方わからないから
っていう属人性というかロックがかかっちゃうから
っていうのはある気はするんですよね
コミュニケーションで解決し得るもの
もしくは解決しなきゃいけないもの
なのにコミュニケーションですら解決できなくなるみたいなこと
でもそれを第一に本質的問題はコミュニケーションであり
っていう言い方するのかな
もしかしたらしゃべってる言語が
さっきのバベルの動画から来ると
しゃべってる言語が違う感じになっちゃうってことなのかな
この道具が違うと
そうだよな
あとはこれに対してやっぱり現代的な解決方法というか
やっぱりどっかの共通の環境を用意するとか
CICDは手元じゃなくて
必ず専用の環境があってそこで動くとか
誰かに依存するとか
ツールっていうのが全員等しい状況になるように
どんどん組み替えているというようなこともあるので
そう思うとあんまりこの話って
切れ味の良い道具って
現代だとピンとこないみたいな
そういうことでもあるのかもしれないですね
散々一人一人の秘密道具みたいな話を
バッカーげてるものだとして扱ってるのは
なんでだろうな
的な話を今散々してきたんですけど
結局この人は切れ味の良い道具の話をしてると思うので
21:03
シミュレーターどうするとかデバッグどうやるとか
そういう話をしてるので
切れ味の良い道具必要だよねって話であるんですよね
自分専用のやつっていう道具を磨くことによって
自分の生産性とか職人としての価値っていうのを
高めているっていうふうに錯覚してるんだったら
それはすごいバカげてる
些細なところに気を取られてるよ
本質はコミュニケーションで解決するような
チームとかの話だよ
的な言い方だったらすごいわかるかもなっていう気はするけど
なんか汎用的なツールだけで十分じゃないから
ちゃんと自分たちのやりたいこと
扱ってる問題に特化したツールもしっかり備えておきましょう
的な主張ではあるので
この章は切れ味の良い道具が
銀の弾丸とまではいかないけど
プロジェクトの難しさを
解消を少し軽くしてくれるのかな
といったとこですかね
そうですね
そんな感じですかね
そんな感じですかね
ふわふわ
ふわふわして
下馬力を大いに語る以外のふわふわを感じる
じゃあ進みますか
