インセンティブのパラドックス
次ですね、6章ですか。ソフトウェア設計におけるインセンティブのパラドックスだそうです。
ここはちゃんと翻訳されてそうだな。
インセンティブパラドックスinソフトウェアデザインって書いてあるんで。
おー、じゃあ何かあってそう。なんでこの一時疑いながら読まないといけないんだ。
ソフトウェアをコンテナ化しっていう風に書いてあるんですよね。
これはパッケージングするぐらいな意味なんですかね。
分割してカプセル化したり閉じ込めたりしてみたいなニュアンスで読んでましたけど。
この辺はいつやるかは議論があるけど、やった方がいいよねってことに対しては、議論の余地はないよねって言ってて、それはそうっていう。
この章では結局パラドックスって言ってるのは、やった方がいいってことは分かってるけど、じゃあなぜ新機能はメンテナンスよりも優先されるのかっていうようなところを話してる章ですね。
これはどうなんだろうな。あんまりそこまで超目新しいなっていう感じはしなかったかな。
そうだよねって思いながら、それ機能を出した方がいい際の影響もあるし、あの人たちが頑張ってるんだなってなるから。
なんか別にパラドックスって言われるんだけど、まあそれはそうやろうっていうような気持ちになる章でしたね。
パラドックスそうですね。立場的なところが違うと矛盾するよね。同じ組織のはずなのに的な意味なのかな。
あ、違う。経営者対開発者じゃないか。ユーザーと開発者かどっちかっていうと対立軸が。さっき言ったプログラミングに種類あるって言ってるうちの、それぞれ両方大事だけどそれが誰にとって価値のあることなのかっていうのが違う。
それって矛盾だよねって話か。新機能の要求と設計改善の必要性のバランスを取りながらグッドニュースファクトリーを維持することが経営者であるあなたの役割ですよって書いてあるんで。
まあ成功犯じゃないけども、第三の道をちゃんと歩むんやでみたいな感じで。いやでもそんなことができるんだったら苦労しないよって次言われそうだよな。
まあそもそもちゃんと売上げになるような機能開発とかプロダクトデザインできてるんだっていうのがまずハードル高い。
そう。そうなんすよね。
そうするとやっぱり打席に立たないといけないですもんね。
そう。でもいっぱい作ってもいっぱい売れなければ、結局なんかこうパラドックスな話になってるけど、結局なんか開発者に対して信頼があれば言ってることが通るし、信頼がなければ通らないっていう話でもあるのではって若干そういう気持ちもあるんだよなって思いました。
なんか結局機能作ってるって言ってるけど、それ別にユーザー使ってないじゃんとか、それによってどれくらい売れてんのっていうことを説明できないと、結局何を作ってるか説明できないのに、あいつら作ってるって言ってるけど、一体何をやってるんだっていうふうに見られると、あんまり信用できないよなーって思ったりはするんですよね。
そうですね。
いや言いながらすごい心が痛いなっていうか。
そうそうそうですよね、うっみたいな。
なんかブーメランが頭の後ろに返ってきてるような気持ちはあるんですけど。
でもこの章のラップアップのところというか結論のところにちょっといいこと書いてあるなーっていう気はしていて、いいこと書いてあるなーって言いながら途中から読んじゃうんですごい偏った編集というか、良くないインターネット仕草になっちゃうんですけど。
同時にエグゼクティブは全ての機能開発を中止し長期に渡って構造のみに集中するという近視眼的な試みを押し留める必要があるっていうふうに書いてあって。
いいですよ。
その下にイタリックで同じようなことが書いてある。経営幹部は全ての機能開発を中止し長期に渡って構造のみに集中するという短期的な試みを押し留める必要があるって書いてあって。何で何で2回言うとるみたいな。
大事なことなんで。
これはそうなんですよね。ソフトウェア開発者の味方ですよ、君たち頑張ってねーみたいな話をするでもないし、お前ら言ってることよくわからんからとりあえず新機能作れみたいなことだけを言ってるわけでもないし、両方やりなさいよと。
ビジネスに変化をもたらす機能を讃えるだけでなく、グッドニュースファクトリーを活性化させるソフトウェアデザインも讃えようって書いてますね。
そうなんですよね。結局そこに繋がらないと構造と振る舞いを見直しましたって言っても、別にその機能誰も使ってないんだよねとかなったら意味ないし。
逆に言うとね、大機能、すごい大きいマイルストーンに関わるような機能の今のうちに土台を整えておこうとか、そういうのは多分効いてきますもんね。
そういうような、これは経営者向けに喋ってるけど、エンジニアもビジネスがわかるっていうのは別に数字がバランスシードを読めるようになるとか、
そういう意味話じゃなくて、これをやるとどういうふうにいいことがあるんだっていうことをちゃんと説明できないと、やっぱ話が通らんよねっていうような気もしましたね。
そんなことはもうずっと言われてるっちゃ言われてるけど、改めてね。
そこら辺って別に、じゃあMBA取りに行かなきゃいけないよねとか、すごい経営者目線を持ってビジネスを学び取っていくしかないぞみたいな、そこまで大それた話になる必要もないかなっていう気がして、
3Xモデルの展開
単純に社内でよく出てくる機能とか、話題になっているやりたいことなんだっけみたいな、そういう力学というか流れだけ抑えるだけでも、ここら辺の行動を多分きれいにしておいた方がいいなって判断に繋がるかもしれないし、
今ここのリファクタリングとかリデザインちょっと頑張ってみると、こういうことを繋がりそうですよねとかっていう話もなってくると思うんで、なんかそれだけでも十分にいい気はするんですよね。
なんかビジネスが分かるようにするってそんなにそこまで超難しい話としなくてもいいはずなんで、だってビジネスって会社の中でみんなやってるでしょみたいなね、じゃあ会社の中の人のことが分かればひとまず結構いけるぞみたいな面もあるはず。
もちろんたくさんいろんなことを知っていて、いいことはいっぱいあるし、別にMBA取るぞって思って取りに行っても全然いいと思うけど。
ユーザーインタビューにちゃんと出るとかもすごい大事ですけど、それだけじゃないよという気もするので。
それだけじゃないよっていう話をもっといろんな人がいっぱいする必要があるっていうことでもあるのかな、ジャストすると。
っていうことをちょっと思いましたね。
そしてじゃあ第7章ですか。
そうですね。
第7章、3Xモデルなぜデザインが突然重要になるのか。
そうですよね。なぜ、こういうデザインって構造とかの話ですけど、なんかこの間までは別にいい感じに開発してたのに突然リファクタリングしないとってこいつら有意になったんだろうみたいな。
本当にする必要あるのかなみたいなことを思ったりするけど、なぜそういうことが突然出てくるのかっていうようなところですね。
これだから3Xモデルっていうのがなんじゃいっていう話からですかね。
そうですね。
エクスプローラー、エクスパンド、エクストラクターですか。
そうです。
これは全部やれよっていう話であってます?
これはフェイズですね。
フェイズになりますよね。
ケント・ベックがフェイスブック、ケント・ベックってフェイスブックにいたんですけど、そういえばそうだったなってこれちょっと読みながら思ったんですけど。
分かる。
2011年にフェイスブックにケント・ベック入って、社内のプロジェクトとかを見てると、大体3種類ぐらいに分かれますよっていうふうにやって、
運用フェイズになったようなプロジェクトと、これからどんどん大きくしていくんだみたいな、前例がない規模感に大きくしていくんだっていうようなプロジェクトと、
革新的な、多分メタクエストとかですかね、メタのワールドを作っていくような革新的なプロジェクトと、3つのフェイズのものがあるんだよっていう。
多分このフェイズによって取る選択肢とか、今までの機能を作ることとデザインを見直すことっていうのをどういうバランスでやっていくんだっていうのは、フェイズによってまた変わってくるよっていうような話をしているとこです。
そうですね、それで何で違うんでしょうねっていう話ですもんね、そのフェイズによって違うっていうのは想像つくけど。お前さっきまで振る舞いと構造をどっち開発するかみたいな話をしてたけど、さてどこ行ったのと。
ある種スタートアップが全部辿っていく道のりっていう感じでもあるなってちょっと思いながら読んでたんですけど、やっぱ最初のスタートアップの最初期ってそもそもこれが使われるのか使われないのかとか、PMFするのかみたいなところで実際作ってものを触ってもらって市場に出してフィードバックを得てみたいな、
っていうようなことをやってるタイミングっていうのは、構造を見直すとか云々かんのではなく、機能がないとお金を稼げないってなるんで、このイノベーション、3Xモデルとエクストラクトになるかなの部分は、そもそもまだコードベースがちっちゃかったりとかするから、
できなくなっていった時には、完璧なものを作るってよりもどんどん出してフィードバックをもらうっていうフェーズだよね。だからここはフィーチャーの方が大事だよねっていうような話をしてますね。
エクストラクトじゃない、エクスプローラーですかね、最初だから。
エクスプローラーでしたね。で拡大、今度どんどん大きくするようなフェーズですね。
01から100になったとかそういうやつですかね。
拡大機は急速な成長と市場シェアの獲得が大事ですよって、どうやらこれはニーズがありそうだ、じゃあジン取りゲームに早く勝つぞみたいな、いうようなことをやってるタイミングって感じですね。
ここでね、さっき言った存続が命題になるみたいな話が、多分ここからやっと出てくるんですもんね。
そうそう。
で、存続するためにはやっぱり変化に適応し続けるっていう話、デリバリーの速さみたいなところになってくるから、なんか全部ツギハギばっかじゃなくて、ちゃんと変更容易性をしっかり保った構造をちゃんとやっていこうみたいな感じ。
だから多分リズムが変わってくるというか、さっき言ったフィーチャーをバンバン作るっていうのばっかやってたところから少し、リファクタリングとか、タイリーを普通にいつでもやれって話か。
リファクタリングとか、もっと言ったらデザインリアー化までいくのかわからないですけど。
でもそれこそCICDがどんどん遅くなっていくよねとかあって、じゃあそこに直すのに投資しましょうねとか、もしかしたらデザインシステムみたいなものをここで入れた方がいいかもねとか、多分そういうようなもうちょっとふくりで聞いたりとか、全体に聞くような最適化みたいなものをちょっと考えないといけないねっていうのが出てきたりとかするのかなっていうのをちょっとイメージしてましたね。
サーバー3台にデプロイしてればよかったのが、このフェーズで10台20台ってなってた時にオートスケールの設定をしておかないと人が一生手でやるのは辛いとかいうような、そういうのとかもあったりしそうだなとか。
最初はEC21台とか、その1個の印刷の中にMySQLとApacheが同時にいますとかね。現代だとあんまないかもしれないけど、一昔前とかだったらそういうのもあっただろうしとか。
あとあれもあるかな、データベースをそろそろリーダーとライター分けようかみたいなのとかね。多分出てくる。
で、最後はエクストラクト。
エクストラクトがあると運用フェーズっていう感じですかね。いいですね。ちょっと部分を引用すると、しかしエクストラクトの段階道がその本性を表し始める。
コードネーズワーク、クイックフィックスとパッチワークの迷宮とかし、高いメンテナンスコストとオプション性の低下につながるっていう風な一文があって、いいですね。
そうですね。エクストラクト、成功の罠っていう風に書いてありますもんね。
でも成功しないとここに来れないんだよなっていうのも事実なんで。
最近ツイッターかなんかで見たやつで、儲かってる会社に行ったらだいたいコードのレベルが低いみたいな、メンテナンスが大変みたいな、いうようなことを書いてて。
いやそれは、生き残ったからそれが残ってるのであってみたいなことを突っ込まれてて、いやそれはそうみたいな気持ちになったやつがありましたね。
そうなんだよな。複雑さがそのまま還元、還元?反元?プロジェクションされてるコードになってると、って感じですもんね。
これが3Xモデルって言ってるのかな?なんか3Xモデルっていう単語出てなくないですか?
本文には多分出てなくて。
なんか、自分で言った言葉ぐらいちゃんと自分で蹴りつけてほしいなって思ったでしょ。
最初読んでわかんなくて、原文を読んで、やっとわかったって感じでしたね。そのXっていうのがEXから始まるやつなんだなみたいな。
成功の罠
モデルと言ってるからには何かをモデル化したということだろうから、成長、事情フェーズ、成長の段階っていうのを抽象化して、こういうフェーズ迎え、こういうフェーズをこういう順番で迎えるよねっていうモデル化しましたって話なのかな?多分。
そう、ということにしておきましょう。多分そうだと思うんで、そういうことが結局言いたかったんだよねっていうのは。
特にね、この本最初から言ってるように、本じゃないか、このブリーフィングはエグゼクティブに向けたものですって言ってる通り、なんかやっぱりこう胸を打つ感じがありますよね。
最初はめちゃくちゃ開発したよね。うん、わかるわかるみたいな。
でもどうだい、サービス事業が成長するにつれてエンジニアがちょっとため息多くなってませんかみたいな。それが成功の罠にはまる前触れかもしれませんみたいな。
せっかくここまで伸ばしてきたんだからここからも勝ち続けるためにちょっとこういうところを見ておいてくださいっていうような話に見えるんだよな。
いつ近道をして、いつ長期的な投資をするのかっていうような表現も出てきていたり。
いやーもうなんかわかるわかるみたいな、首がもげる。
ここに部分追加すれば終わるんですみたいなので、追加したが故にその先が地獄みたいなのとかありますからね。
いろんなものを思い出して、でもそれによって契約が取れて大きいお金が入ってくるからお給料払われてるって言われると、うーんみたいな。
だからだんだんそういうパッチワークみたいなのは、しかもAIがあるからね、パッチワークどんどんやりやすくなっていくと思うんで。
やっぱり構造を見抜いてうまくやれる人っていうのはより必要になっていくんだろうな。
ソフトウェアもでかくなっていくし必要になっていくんだろうなっていうふうにやっぱり感じますね。
そういう人にやっぱりちゃんとルールファイルを書いてもらいたいですね。
そしたら誰でも機能増やせるんで。
もはや人じゃなくて機械が機能増やしてるかもしれないけど、そうなった時には。
ビッグリライトのリスクとメリット
で、まあ次ですか。最終章ですね。
そうですね。
グッドニュースファクトリーを翻訳諦めてグッドニュース構造とかやってらっしゃいますね。
そうですね。なんかすごい大変なことになってる。力尽きた感じがあるんだよな。
幸能章はどうでした?面白かったところは。
そうですね。やり直しの誘惑を避けましょうねっていう話が出てるんですけど。
そうですね。僕もそこハイライトしてる。
やっぱりビックリライトはうまくいかないからやめろって書いてて。そうなんだよなと思いながら。
ビックリライトするようなフェーズまでにどうにか手を打っていい感じにしときましょうねって言われたらその通りって思いながら。
今度こそはうまくやるという約束でシステム全体を再開発することは見かけよりも収益性が低くリスクが高いとか。
やり直しがうまくいくというのは中システムとほぼ同じことをするシステムを手に入れるという意味であるとか。
そうなんだよ。
それ聞いちゃうと既存のシステムを反復的に改良していく方がいいっていう話は納得感ありますね。納得感あるが、そうですね。
走りながら車を処理する方が安全で楽しくて快適なんだっけっていうのはわからんよな。
本当にリライトしないといけないものもあるっちゃあるんですよね。
例えばですけど、自分が過去に見たもので言えばオブジェクティブシーで書かれたiOSアプリでもう誰もわからんってなってて、
これをメンテし続けるのかみたいな気持ちになった時にはもうこれは新しいアプリを作るしかないんやってなって、新しいアプリに移行するとか。
そうなんかユーザーを巻き込むような、こう変わりますっていうのはありですよね。
ありですよね。リライト、ビッグリライトプロジェクトってそういうレベルじゃないと厳しいんじゃないかなっていう気はしちゃうんだよな。
大体ビッグリライトしようと思った時に、ついでにこれもやりたいとかって出てくるじゃないですか。
ビッグですからね。一個ぐらい混ぜてもバレないでしょって。
でそれをみんなが混ぜた結果、なんか旧版と新版で挙動が違いますっていうのがいっぱい出てきたりとか、
抜け漏れがあったりとか隠れしようがあって、ああみたいなことが起きて辛くなるのはあるんですよねって思いながら。
でも難しいですよね。ビッグリライトがうまくいくかどうか本当にわからないことが多いけど、
これはもう全部書き換えないともうあかんみたいなところまで行ってしまったシステムって多分やるしかない気もするし。
そうなんだよな。たぶんこれは会計上の問題とかもあって、システム作って原価消却してって、
消却した後にしたらこの新しいの作るみたいな、たぶんそういう考え方で作ってるソフトウェアとかもあると思うんで。
そうなっていくとどうしてもビッグリライトしないといけないみたいなこともあるんだろうなって、
SIの現場とかを見た時にちょっと思ってありました。その時は思わなかったけど、今になって振り返ると、
ああなるほど、大難世代システムとかって言ってるのはそういうことなのかとかっていうのをちょっと思ったりとかしましたね。
いろいろな力学にがんじがらめられてるのはあるよな。
もしかしたらエグゼクティブの人も、いいリズムでリファクターをしてとかっていうのは大事って思ってるけど、
そもそもその会社の会計上のルールとか、これまでやってきたものがソフトウェアを扱ったことが全然経験がなくて、
ソフトウェアっていうのはある種一点物を買うかのように作ってもらって、それを10年使い続けますみたいな。
そういう世界観にいる人からしたら、そんなことやるのはちょっと無理っすよって言われちゃうっていうのはあったりしそうだなっていうのも、
現実はそういうもんだったりするっていうのは一個あるかもしれないですね。
しんどいですね。なるべくそういう未来を迎えないように過ごしていきたいなっていうのはあるけども。
あるけども、そう。
成果を祝うことの意義
そうですね。あとは管理しやすいインクリメントで設計するとか、デザインの業績を祝うとか、そういうのが書いてますね。
やっぱこの祝うっていうのは、リファクタリングしたいですとかっていう話ってエンジニアから出てきて、
したいですって言ったからやって当たり前だろうみたいなことになっちゃうけど、やっぱうまくいったんだったら祝わないと良くないですね。
なんかXPの人たちって結構祝うの好きじゃないですか。印象が。
そういうのがある。
ありますよね。
アジャイルのゾンビスクラムサバイバルガイド。
XPじゃないじゃないですか。
XPじゃないけど、あれでもやっぱ祝いましょうっていう話が出てきたし、人を褒めるとかプロジェクトがうまくいったことに、やっぱ祝うってことって大事なんだなって思ったりとか、
KBTやるとよくみんなプロブレムに目が行きがちとかなっちゃうけど、良かったことにも一緒に見る必要があるよねっていうのをやっぱ思いますね。
なんかXP代本あるじゃないですか。エクストリームプログラミングニューモンかな。
あれ多分今手に入りやすいのが第7版化になってるんですけど、最初の版だと確か何かリリースしたらピザとビール飲んで祝わなきゃいけないみたいなことがプラクティスとして挙げられてた気がして。
いいですね。
確か消されたんですけど。
確か確か。
一日複数回デプロイするからビール飲むペースが早くて。
ずっと継続的にビールがデリバリーされてくる。
どっかのカバレルみたいな。
タフな人が持ち歩いてきて。
持ち歩いてきてどうですかって。
なんかピザパーティーあれって書いてあったような気がしてるし、消されたような気もしてるんですけどちょっとうろ覚えです。
意外に調べた気もするけど。余談なんですけど、そういうのもあって、ステーション5、文化圏だなーって思って勝手に。
そんな印象があります。
まあまあでもそんな感じですかね。第8章はやっぱりまとめて、バランスというか両方やるんだよ、それって大事なことだよっていうのが。
グッドニュースファクトリーをちゃんと蘇生していきましょうと書いてありましたね。
最後はグッドニュースファクトリーを背長く延残していくことができる。
延残して笑っちゃう。
オペレーションだったのか。
そういうことでしたね。
原文見てみるか一応。
そうですね、オペレーティングがグッドニュースファクトリー4years to comeって書いてあるんで、オペレーティングですね。ビルディング&オペレーティング。
なるほど。
延残してしていくか。
延残していきましょう。
というような感じでしたね。
めっちゃ喋ったね。
40ページでそんな喋れるんかっていうのを引いてます今。
これ1時間で終わるだろうって思ってたけど。
僕40分ぐらいかな。そうすると文化ってどうしようって思ったんですけど。
普通に4本以上撮れてる。
そうですね。我々は何でも喋れるということです。
撮影はしてたからか。
