00:06
こんにちは、readline.fmです。readline.fmは、つんどくが趣味の2人が、何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、readline.fmです。ホスト役は、げんえいさんと、きんじょうです。それでは、げんえいさん、よろしくお願いします。
よろしくお願いします。
すいません、やたら簡単ですけど。
毎回ちゃんと喋ってるってことが、これで証明になりましたね。
本当ですよね。エンジニアなんだから、効率化しろよと思うんですけど、それは本編には関係がないので、入っていきますか。
『人月の神話』の概要
今回読んだのは、人月の神話という有名な本ですね。
ソフトウェアエンジニア、みんな知ってるでしょうっていうぐらいな本ですよね。
いわゆる、読まれてない名著としても有名な気がしますね。
何の定義で読ませたか忘れたけど、古典と呼ばれているものって、みんな読んでないけど中身を知っているものっていうのが古典なんだ、みたいな言い方?
シェックスピアとか、みんなちゃんと読んではないけど、オーロミオとか、みんな知ってるわけじゃないですか、そのセリフを一部分でも。
ルービオの罪とか、っていうのが古典なんだっていう意味では、確かにこの本は本当に古典だって言っていいぐらいな古典ですよね。
あれですね、書かれたのが1975年なんですか?
75年ですね、原著が一番最初の版が出たのが75年って書いてありましたね、調べたら。
じゃあ来年50年?
そうですね、もう50年ですね。
すごいな、それはすごいですね。
50年前って何も…反省していいですか?
任天堂の歴史
任天堂の話しますか?
任天堂の話しますか、確かに。一応ね、今回は任天堂のページ開いてるんですけど。
ちょうどレーザークレー射撃システムを開発してちょっと経ったぐらいの年ですか?
まだ全然テレビゲームって感じじゃないですね。
そうですね、ただ花札とかカードゲーム、ボードゲーム系からは少し変わってるというか。
89年ですかね、1889年に花札の製造開始って書いてありますね、任天堂の創業は。
明治22年ですね、すごいな。
ファミリーコンピューターが83年なんで、まだファミコンが出る前って感じですね。
ゲームウォッチ、ゲーム&ウォッチも80年って書いてあるんで。
そんな中でコンピューターって言われても全然イメージが湧かないですね。
それこそそうですね、パンチカードでやってたとかですか?
なんかそういう…
ですかって。
ですかって言われても大体生まれてないんで。
でも中にそういう話とかも確か出てきたような気がするんで。
75年に出ているってことはそれ以前のプロジェクトについて書かれていることなので、
そういう話も入ってたりするぐらいにちょっと現代とだいぶ差が開きすぎていて、
イメージがすごい難しいですよね。
難しいですね。
ソフトウェア開発の課題
そうですね、その流れで全体的な感想とか印象みたいな話に入っていきたいかなと思うんですけど、
やっぱり少し前の時代、本当にソフトウェアとかコンピューターとかっていう意味で言うと、
1時代前とかよりももっと昔の2時代前、3時代前みたいな、
そんな言葉があるかわかんないですけど、
何世代か前のソフトウェア開発の話してるなぁみたいな印象は結構節々に受けていて、
この本すごいなって思ったのが全体的にやっぱりちょっと昔の本どうしても少し古いかなみたいなところありつつなんですけど、
たまになんだろうな、先月書かれた雑誌に載っててもおかしくないよねぐらいの、
全然今も変わってないなぁみたいな話も出てきて、
そこらへんはやっぱりすごいというか、それこそ古典ですよね。
時代を生き残ってきたというか、読み継がれてる、語り継がれてるっていうのは、
そこらへんの本当に説得力を持った本だからこそだなっていうふうに個人的には思ったりしましたね。
自分もすごい同意見で、やっぱ読んでてつまんないなって思う部分もあって、
それは結局当時の状況が全然わからない。
わからないから、どういうふうに働いてるかとかどういうふうにシステムを作ってる。
同じシステムを作ってるって言っても、やってることって全然違うような作業をしている。
もちろん共通してる部分もあるんだけども、
でも違うことをやってる人にやっぱり共感するとか、
そうだよね、みたいなことってなかなかちょっと難しいなって思いながら、
でも一方で読んでて、あれなんかこれ、
昨日も同じような問題現場で見たみたいなことが全然書いてあって、
それは50年生き残る本だなぁみたいな気持ちもありましたね。
なんかそれこそ、Javaとかっていう言葉はもちろん出てこないしみたいな。
そうそうそう。
スモールトークですらチラッと出てきたかなぐらいですかね。
オブジェクト思考に今後に行きたいみたいなことが書いてあったりとか。
そうそうそう。
今で言うラストとかの位置づけで、オブジェクト思考っていうのがちょっと出てきたぞみたいな、
言語とパラダイムで比較するの変なんですけど、
でもそのぐらいの感じがしますよね。
あとはまぁ、これちょっと先に触れておきたいなと思った部分で、
役者と書きの部分にちょっと面白いなと思って、
面白いっていうかすごくいいなって思ったことが書いてあって、
やっぱりこの本っていうのは定番本であり、
日本の人にも早く読んでもらいたいから頑張って翻訳して、
今自分が読んでる版は情報改定版のやつなんですけど、
情報改定版を早く届けたいから95年に文献書の情報改定が出て、
日本でも情報改定版をすぐ出したい、
頑張って翻訳したがちょっと間に合いませんでしたみたいなことが書いてあって、
当時でもやっぱり注目されていたし、
やっぱりキーとなる本なんだなっていうことが評価として受けられて、
すごく愛されている本でもあるんだなっていうことをちょっと思ったりしましたね。
我々が読んでるのが、
これ20周年記念エディションの後に出されたやつかな?
どっちだ?
アニバーサリー・エディション・ウィズ・フォーリュー・チャプターズって書いてあって、
だから1回この人月の神話っていうタイトルで本が出されて、
その後すごいいろんな反響が本自体に対してもそうだし、
この公演とか行った時にも、
あれは今のあなたはどう考えますか?みたいな、
いろいろ反響があったよねっていうのを踏まえて、
いくつかの章を追加して書かれている本というかエディションなんですよね。
そうですね。
だから改めて振り返る人月の神話みたいな話とかもめちゃくちゃあって、
振り返っているのがもうだいぶ前だなみたいな。
振り返っているのをさらに我々は振り返っているんだみたいな感じもありましたよね。
そうですね。
あ、そっか。
第11章が人月の神話から20年も経てっていうタイトルの章があったりして、
それを日本の読者にも早く届けたいっていうふうなことを言ってるってわけですね。
そうそう。
じゃあ本編入っていきますか。
本編入っていきますか。
これで全体でそこそこ分量があるような内容なんですけど、
そうですね。
てか19章がクソ長いんだよな。
そうですね。19章。
全体で290ページ弱なんですけど、
18章と19章だけで80ページぐらいあるので最後の2つがすごい長め。
読んでても全然残り5章かって読んでたんですけど、
全然終わんねえなと思いながら。
長いんですよね。
ただ最後の3章か。
17、18、19が今言ってた振り返りのやつ。
プラスもう1個エピローグっていうのが入ってるよっていう感じなんですが、
問題入るとどこらへんから行きます?
まあでも第1章からは行きたいか。
そうですね。
タールの沼。
タールの沼はどんな話でしたか?
これはもともとタールの沼っていう、
そこに巨大な獣が落ちてそこから出られないと沈んでいくと。
システム開発も同じようにとても大変で沼から抜け出せないみたいな感じの話ですね。
まさにこの人月の神話っていう1冊を始めるのにふさわしいような感じがありつつですけど、
作る喜びっていうのにも触れてるんですよね、この章だと。
そうなんですよね。
なんか自分が最初読み進めた時に作る喜びの章が、
章っていうか先にそれが来て、
あーなんかすげーわかるわかるみたいなことを思いながら。
あのフィードバックする時みたいなね、最初にポジティブなこと。
そうそうそうそう。
その中でも人々に役に立つものを作る楽しさがあるとか、
複雑なパズルのような組み立て部品を完成させれるとか、
常に新しいことを学ぶとか、
物を作り上げる時の常に喜びがあるよみたいな話とかあって、
これすげーわかるし、今自分がたぶんプログラムを書いていて楽しいなって思うところって結構ここに集約されてるなっていうことも思ったりとかして、
つまり50年変わってないんだなこの辺って思いながら勝手に読んでましたね。
そうですね。もう少しだけ読み進めると、しかし全てが喜びとは限らないっていうふうに書いてあるわけですね。
おかしいな。こんなに楽しいことはずらないなと思いながら。
で、作る苦しみっていう本は皆様のご想像の通りですみたいなことが書いてはあるんですけど、
完璧なものを作るのってすごい難しいよねとか、目的を設定しリソースを提供し情報を与えるのは別の人間だということだとか、
そこで他人に依存しなきゃいけないけど他人ってさーみたいな話があったりだとか、
終わった頃にはもう時代遅れになってるみたいな感じとか。
これでもあれですね、最後に挙げる苦悩は重なる不幸の最後の一撃だ。
あれほど長い間苦労してきた製品が完成時またはそれ以前に時代遅れに見えてしまうことであるっていうふうに書いてあって、
これは現代だとなるべく早くデリバリーしていきましょうみたいな。
ある意味完全な完成みたいなものを待たないで使えるところからしっかりユーザーに勝ち届けていきましょうっていう話があるんで。
ここは時代の違いも少し感じたなぁとか思いながら。
そうですね、あとこういう製品が完成時に時代遅れに見えてしまうことがあるってあって、
本当に一番苦しいのは完成せずにプロジェクトがポシャっていくことではとかってちょっと思ったりしましたけど。
この章の終わり見ると、プログラム開発は多くの人々が目的達成のためもがき苦労とする樽の沼であるとともに、
また独自の喜びと苦悩を伴った創作的活動でもある。
多くの人々にとって喜びが苦悩よりはるかに勝っているのであり、
本書はそういう人のために樽を渡る架け橋を提供しようとするものであるっていうふうに書いてあるんで。
なんか導入部分。
導入ですよね、始まり始まりって感じが。
なるほどな、樽の沼から抜け出すっていうよりかは渡る架け橋を提供しようとしてるんですね。
やっぱり落ちたら最後ですね。
落ちたら最後だと思いますね。
この章だけでも結構文芸的な響きというか、もっとチャラい言い方をすると結構エモいんですよね。
多分昔の書かれたプロジェクト管理の生産管理とか計画の話でしょっていう印象で言うとここまでエモい話というか、
エッセイっぽい話がまとまった一冊だと思われてない気はしていて。
確かに確かに。
そこは実際に読んだ人の楽しみというか、そんな気は僕は持ってますね。
確かにそうですね。
いくつかちゃんと論文として書かれたやつとかもありそうな気はするんですけど、
でも全体的に何て言うんだろうな、ガチガチじゃないって言い方あれなんですけど。
要は論文ってよりはエッセイの方が近い感じは結構全体的な章を見た時には多いよなっていうのは確かにそうですね。
そうですね。だからあれか、ネバドコとか好きな人やっぱ好きなんじゃないかなっていう気はしますね。
まあまあまあそんな感じで。
人月の神話の概要
第2章が人月の神話ですね。
これはもうまとまったっていう感じですけど。
有名すぎてこのポッドキャストで触れなくてもよくね?まであります?大丈夫ですか?やりますか?
まあそうだよねって思いながら読んでたっていう感じはありましたね。
人と月は交換できないって話と、やっぱり人月の神話の話をすぐ知ったくなるけど有効だよね?みたいな場面はあるっていう話が一応載ってるんでそこだけ言及したいなって思って。
月と人が交換可能な場合っていうのは作業者間のコミュニケーションがないっていうのが一番大事だよねって話があって、
結局分担して作業ができるってどういうこと?って言うと誰かを待たないといけないとか、誰かの仕事に依存する状態じゃない。
もしくは聞かなくたってできるような単純なこととかっていうことだよなーとかいうことを思って。
そこを忘れて、いや人を投入しても早くなんないんだよってことを言い続けてしまうと、それはちょっと間違った理解だよねってことだけは抑えておきたいというか。
読んでて、そうだよねそうだよねって思いながら読んでましたね。
そうですね、だから分担できるってことはそれだけなんだろう、仕事を単純な単位、単純化してそのちっちゃい単位に分解して、一人一人アサインできるような的な状況が揃えばって感じですよね。
要するにカーナビ見ないで目的地に着けますよね状態みたいな感じにして。
我々もしかしたら仕事をする上で人を増やしても早くならないしって思うけど、早くするためにどういうふうにタスクに落とし込んでいけば、
もうちょっとこの3日間だけちょっと手伝ってみたいな感じで速度を上げるとかいうことができるような、もしかしたら仕事のやり方みたいなことを考える方法はあるかもしれないから。
そういうような手段だったりとか引き出しみたいなアイディアみたいなものを持っておくっていうのは結構大事かもなーっていうのは思いましたね。
しがちに設計決めてあとは書くだけにするとかはそうですよね。
そうですね。
あとそれこそなんか中Aやりましょうみたいなリリース前に確認しましょうっていうフェーズに、
こういう要件というかこういう動作を確認しましょうっていうのバーテリストさえ作ってしまえばある程度分担してできると思うので、
1人10個ずつやりましょうとか、なんかそういうのは普通に人と月を交換してるねっていう気はしますしね。
まあそれぐらいですかね。
意外とこの第2章人月の神話はそんなにボリュームもないですしね。
これだけだったら買ってきてこれだけ頑張って読むっていうのは全然いけますね。
でもこんだけしかないものがあるし、ずっと読まれ続けている、言及され続けているって相当すごいですよね。
確かにそうですね。
なんかこれ言われる前みんな気づいてなかったけど、おっしゃる通りだってなったとかそういう感じなのかな。
これまあでもそうですよね。
最初に言語化した、光を当てたっていう意味ですごいってことなんですかねやっぱり。
まあそっか、だからあとはあれですね。
散々言われ続けているので、今我々が読んでもそんなに感動がないんじゃないみたいな。
聖地巡礼的な、本当だオリジナルの文章ここにあったっていう喜びはすごいあるんですけど、
先輩に同じ話されてもそんなに面白くなさそうみたいな感じがある。
それこそ冒頭に言った一切古びてないっていう感じもやっぱりすごいある。
まあそんな感じですかね。
パラドックスめいてるというか、上等手段として終わり間際に人をバーって増やしがちだったんだけど、
それあかんかったのかみたいなインパクトはあったのかな。
あの月指したら指引っ張っちゃいけない的なインパクトかな。
で、そうだなサクサク行くか。
今度ここら辺まで行きますか。
ワープしてもらって全然。
じゃあワープしてゲカシューズチームですかね。
全然ワープしなくて次の章ですね。
全然、1ページ、0.5ページぐらいジャンプしましたけど。
ゲカシューズチームなんか前同じ響きを聞きましたよね。
ゲカシューズチームのアプローチ
俺全然それ覚えてないですよね。
いやまあすげー便利なのが、組織パターンが粘る子が言ってたよなって言えばだいたい当たるんで。
そうですね。我々が読んでる本はそれしかないではないけど、ほぼそれだから。
ゲカシューズチームは本当に超プロフェッショナル、超専門家を集めて同じプロジェクトに向き合うというか立ち向かうけど、
そこってそれぞれがプロフェッショナルとして全く同じ役割持ってないじゃんみたいな感じの話をソフトウェアプロジェクトでも同じことできるよね的な話ですよね。
メスを持って嫉妬する人と麻酔を使う人ともろもろもろもの全員違うでしょ的なやつですね。ゲカシューズチーム。
当たり前と言っちゃ当たり前ですけど、これがそういう文章が書かれるってことはそういうことでもあるのかっていうよりもあれか。
できるプログラマーとできないプログラマーの間に生産性がすごいあるからプロフェッショナルの人を集めましょうっていうことか。
あとなんか本当にトップに立つ人、リードする人とそれ以外の人、アシスタントみたいな人が同じ仕事させてはいけないみたいな。
アーキテクティングとかデザインとか全体指針を握る人はやっぱりリードする人。
で、まかり間違ってもそんな若手と一緒に闘技して決めましょうよとかやめろー的な雰囲気を感じますよね。
そうですね。プロフェッショナルちょっと当時がわかんないからですけど、システム開発した経験があるプロフェッショナルってじゃあどんだけいるんだよみたいな感じもしてますよね。
ましてはね、この本でIBMのOS360っていう大型コンピューターのOSの話が出てきたりしますけど、OS、そういう大きいものを作るって多分あんまり経験ある人っていないけど、でも人を集めてこないといけないしみたいな。
そんな状態だったりするんだろうなって気もしますよね。
そうですね。逆に言うとベテランなんだろう、スポーツとかの優勝受け負い監督みたいな感じで、数人いてそれがずっと渡り歩いてる的な雰囲気なのかもしれない。
確かに確かに。
本当に優勝できるかっていう感じがするんですけど。
あとここ読んでてなんか面白いっていうか、現代でも通じる話だし、最近オンクさんって方が強いチームと開発生産性っていう話をしてて、そのスライドがいくつでも回ってきたりとかして見てて、
得意を組み合わせるように座組を考えるっていう話をしていて、PDM、PJM、TLとかサービス開発に必要な役割の人をちゃんと集めましょうねとか、専門家とかジェネリストとか。
その中に座組を考える中にムードメーカーとか気が利く人とかいう話もあって、結構専門性という意味でもどういう人を集めるかっていう話もあるし、現代だともっとチームビルディングみたいな話が強調されるから、ムードメーカーとか気が利く人とかいうところの観点まで考えて、
座組を考えないとなかなかチームとして機能したチームを作っていくって難しいんだろうなーっていうのを最近思ったりとかしてて、結局50年前にその話は向こうに書かれとったなっていう気持ちにもなりました。
そうですね、やっぱりコンピューター進化してるけど人間は進化しねえなーっていう感じがすげえありますね。 そうですね。
効率と自律のバランス
そうか、人欲の神話っていう第2章の後にこの第3章、外科手術チームっていう、一見全然違う話が出るんですけど、人をどう増やすかとか座組なんだろうな、要するに1たす1が0.3にならないようにどうやってワークさせますかっていうのが問題意識としてあるので、
この外科手術チームっていう話になってきてるなーっていう気はしますよね。 そうですね。
その中であくまで嫉妬意っていうそのリードを上に立たせてトップダウンでやるのがうまくやらせる秘訣だ的なスタンスで、少なくともこの章は書かれていて、
それ以外に何があるんだっけっていうと、従来型チームではパートナーは対等とされ避けられない判断の相違については十分話し合うか協力脱走するかしなくてはならないっていうのが32ページに書いてあるんですけど、
嫉妬意っていうのを決めて最終こいつが決めますっていう風にやっておけばそれも避けられる、曖昧なデザインっていうのを避けられるし、その相談とか交渉にかかる非常に大きい時間っていうのをなくせるよね的な感じです。
だから効率ですよね。結構最近の話だと効率よりも何だろうな。
効果を。
そうだそうです。すげー余ったれた表現しか今出てこなくて、効率よりもやりがいが大事じゃないですかとか、そんなこと言いたいポッドキャストじゃないんだよなって思って。
そうですね。っていう中に対して効率をいかに上げるかっていう話かな、そういう時代背景かなっていう気は全体的にしてますね。
自律的なチームっていうよりかはある程度管理しやすい、着実に結果を出せるよりかなっていう。
そうですよね。まだアウトカムっていう話をする前にまずちゃんとアウトプットを出すっていうことが難しい。
アウトプットがちゃんとアウトプットができてプロジェクトが成功しましたっていう時代なので。
それこそ人間よりコンピューターの方が高い時代ですもんね。
そうですね。
ちょうどここから入れ替わってくるんだろうなぐらいの感じはしますけど。
やっぱりこの本読むの難しいなって思いますね。そんな時代背景読み取らないと読めないってなると新卒に渡すのはちょっときついかなとか思ったりしますね。
新卒に渡すって読書感想は絶対いいんですか?
確かに。今どう読むかっていうのは気になるなっていう気持ちもある一方で。
人月の神話のそのキャプターだけだったらどうかな。
人月の神話はプロジェクトの経験ないとわかりづらいんじゃないかなっていうか。
そうね。
人増やして遅くなった経験したことありますか?はい、あると思うんですよね。
そうね。
グループディスカッション就活でやりましょうって言った時に邪魔なうち4人くらいいましたよねって話をすれば。させる気はするな。
第4章をチラッとだけ触りたいんですけど。
一向に我々は触ることができない。
第4章は貴族政治民主政治そしてシステムデザインっていう話があって。
貴族政治って本当に貴族なので地位のある人選ばれた人が全体のデザインしますってやり方で。
民主政治はいやいや一人一人のタミング差の意見を大事にしようぜってやつ。
じゃあシステムデザインどっちがいいんだっけとかっていう話とか。
あと第4章の出だしでコンセプトの完全性とかコンセプトの完全性を達成するっていうキーワードが出てきて。
このコンセプトの完成性こそシステムデザインにおいて最も重要な考慮点だと言いたいっていうふうに書かれてますね。
あれこれはアレグザンダーの前期と言ってることに近いのではないか。
人工的な計画都市っぽい話な気がするけど。
中途半端にいろいろ妥当が見えてくるとすごいほころんでいくよねー的な話に、
そういうトラップに陥る前にこういうふうにやりましょうって言って、
端から端までしっかり統一性とか一貫性を持ったものを作りましょうとか。
プロジェクトにおける考察
それって民主政治的なデザインだと無理じゃないってな感じなんじゃないかな。
そうするとプロジェクトをやっていくときにさっきの人欠の神話とか、
人っていうリソース投入してどうやってブーストかけるかっていうのを考えなきゃいけないよね。
コンセプトが完成するまで他の人は全員待ってなさい黙ってなさいって話になってくるんで。
逆に言うと本当に最後まで完成されたコンセプトとかプログラムというか計画っていうのがあれば、
あと渡された任された細かい単位の担当領域だけやりきればいいので、
それは人間突っ込んでいくらでも走れるよねー的な話に感じたりしつつですね。
っていうそのコンセプトの完全性っていう話がこの後ちらほら出てくる気がしたのと、
プロジェクトマネージャーなんだろうな、
アジャイルリーダーはみんなに優しいけどプロジェクトマネージャーはみんなに優しくなくていいなーみたいな感じがちらほらするので個人的には。
なので大要素はちょっと触れておきたかったなっていう次第でございました。
なるほど、最初自分が読んだ時このタイトルに引っ張られてなんかあんまり
貴族政治民主政治なんかピンとこねーなーとかって思って読んでたんですけど、
確かに今そのコンセプトの完全性の方に重きを置いて読むと、
なんだそういうことかっていう気になるような章ですね。
そうですね、章のタイトルこそ完全性とかコンセプトって入ってないですけど、
よく読んでみると大要素の出だしも締めくくりもそのコンセプトの完全性があって話になってるんで、
多分こっちが主題で、主題というか前提がそこで、
それをやらなきゃいけないのにいろんなトラップあるでしょっていう前提に対する主題、
この章でわざわざあえて語りたいこととして、
貴族政治民主政治そしてシステムデザインっていうのがあるのかなっていうぐらい読んでました。
サービスデザインの重要性
なるほど、面白いなと思うのがこの後に大聖堂の橋が出てくるんですけど、
ガラントバザールっていう本がこの後に。
ありますね。
まあでも多分あれはバザールっていうもの自体をコンセプトがちゃんとしっかりしてさえいれば、
ある種そこに良いとしないものは出てきたりとかするけども、
面白く全体的に統一感が取れたって言い方をするとちょっと違うかもしれないけども、
うまく機能するようなものが出来上がっていくっていうことでもあるのかなとか、
トップダウンだけでできなかったこともできるようになっていくみたいな、
いうことでもあるのかなってちょっと思ったりしました。
これでそこら辺を意識した話なのか分からないですけど、
ライン王将のカバーイラストというか挿入されている写真が聖堂の写真なんですよね。
そうですね。
聖堂?東海?
コンセプトっていうあれか、あっちから想起したイラスト、写真か。
あとなんかちょっとこの話を聞きながら演奏した本で、
去年で翻訳が出た本で、
優れたデザインにとってコンセプトが重要な理由、
使いやすく安心なソフトウェアを作るためにっていう本があって、
まさにこれがそれを引き受けて後にそういうことを書いてくれてるのかなと思いながら、
去年で出本なんですけど、
でも本当にそういうような話だったと思っていて、
サービスをデザインするとか機能をデザインするみたいなことを部分的に頑張ってやったとしても、
サービス全体としてのサービスデザインの全体の統一感みたいなものとか、
使い勝手みたいなものっていうのはやっぱりうまくいかないんだみたいな話も確かあったはずで、
だからこそどういうことを目的としてサービスがあるのかとか、
そのコンセプトっていうのは何なのかっていうことをもっとはっきりしないといけないんだよっていうようなことが書いてあって、
分かるなあと思いながら、
でもこれってサービスってもう今10年とか20年とか続いていく中で、
人が代替わりしていったりとかして、
その一貫したコンセプトを保ち続けるって相当難しいよなって思いながら、
結構読んだ記憶がありますね。
そろそろですね、今本当に知らない名前の本が出てくることがあるなってびっくりしたんですけど、
でも今ゲイさんが話してる間に買ったんで、
来週取る。
早い。決断が早い。
この本、最近設計上手くなりたい、ずっと言ってるんですけど、
設計上手くなりたいなあって言った時に、
きっと設計とか品質とかって、
これ作って何をもたらしたいんですかとか、
使った人がどうなってほしいんですかって話でしかないなって思ってて、
コンセプト、言葉寄せて表現すると、
コンセプトない品質って非常に無価値だと思うので、
みたいなことを思ったりして、
コンセプトどうなんでしたっけっていうところを考えていくと、
いいドメインの抽出とか、
こういうことを表現したらこういう変動性がなんちゃらかんちゃらで、
こういう上流がなんちゃらかんちゃらみたいな話が、
なんかできるんじゃないかなー的なことを、
ちょうど今週の頭ぐらいに思ってたんで、
ちょうど今週ぐらい考えてたのはあれか、この本読んでるからか。
明月の週刊読んでて。
汚染されてるのか。
思考が、
IBMの意識に擦り込まれてましたね。
じゃあ、次いきますか。