ソフトウェア職人気質の重要性
きんじょうひでき
じゃあ、ダイさん。 ソフトウェア職人気質がもたらすもの、というとこですね。
げんえい
はい。 ここからはもう、あれですね。
じゃあ結局、さっきから君たちが言っているクラフトマンシップっていうのは、 結局どういうふうにイコールしてくれるのっていう話がずっと話されているんですね。
きんじょうひでき
なんかね、ちょっと品質みたいな話とか、 何のためにプログラミングをやっているのっていうと、それによってビジネスを支えるためでしょう、みたいな話とかが触れられてきますね。
そうですね。 なんか、第3部全体で、源永さん的に、ここはグッと来たぜ、みたいなところはありますか?
げんえい
自分は好きな話だからっていうのもあるんですけど、 一番最初の7章に、ユーザーの声がソフトウェア開発者のもとに届いていないのですっていうのがあって、
これは何かというと、7章のタイトルがそもそも職人気質がシステムのユーザーにもたらす変化っていうのがあって、
ユーザーの声を聞いて、開発者にそれを届けることによって、 どんどん改善されていくという話があって、
これって現代においても通じて、結局ソフトウェア開発をやっていて、 作れって言われて作って出てくるアウトプットと、
実際にユーザーに会って、こういう人がこういう風に使ってて、 こういうことに困っているんだって分かった上で作っているのって全然間違うよなっていうのを思っていて、
かつ、周りにユーザーインタビューに行って、すごくモチベーションが上がって、 こういう人が使っているんだって分かって、
それが分かった結果、いろいろ改善案とか、 こういう機能があったらもっと便利じゃないですかとか提案までしてくれたりとかしていて、
きんじょうひでき
ここ、もうこのタイミングでも言われてるし、今でも通じることだなっていうのを思って、 この7章は結構全体的にすごい好きだなって思って読んでましたね。
職人っていうとすごい、こう、眉間にシワを寄せて、 話しかけづらそうな孤高な人みたいな、一匹狼みたいなイメージ。
ユーザーとの対話
きんじょうひでき
日本語だけかもしれないですけど、地面からそういう印象を受けるかもしれないんですけど、 全然そうじゃなくて、
本当に何が必要でどういう責任を果たすべきかっていうのを意識して、 自在に動いていくみたいな職人像が語られてますよね、この本は。
で、そう、7章の最後の説が、 ソフトウェア職人決定によって共同開発がもたらされるっていう風に、 説のタイトル、見出しがあって、これかっこいいですよね。
いいっすね。結局、共同開発じゃなかったわけですよね、今までは。 そうです。
げんえい
自分のお城に引きこもって、偉い偉いプログラマー様ごっこやってるだけっていう。 結局これも、じゃあやっぱり対話じゃん、みたいな。
で、対話するためにはお互いのリスペクトが必要だったりとか、いうこともあるわけで。 その尊敬とか信頼みたいなものを得るためには、そもそも対話してないとか、
きんじょうひでき
コミュニケーションがないところがいきなり、それは生まれてこないわけで。 そうなんですよね。だからビジネスアナリストとソフトウェアアーキテクトが最初にいて、
要求を引き出してきて、なるほど、こういう感じで作ればいいんですねっていうのを決めて、それがどんどん下流に落ちてくるみたいな。
この本で描かれているソフトウェア工学的な世界観だと、実際にコードを書く人とか画面作る人は全然ユーザーと対話しないわけですからね。
げんえい
で、その中であなたはユーザーのことが好きですかとか言われても、いやユーザーって誰ですかみたいになっちゃうので。 そうそうそう。
契約の場面に出てくるあの人ですかって言って。 あ、それに見たことありますみたいな。 そうそうそう。
で、この中でも、購入者とユーザーは違うということという点を肝に銘じることって書いて、っていう話があって、本当これみたいな。
買う意思決定をしてくれている人と、実際買ったものを現場で使っている人はまた別だからさ、とかいうこととかまで考えとかないと、
まあうっかりその買う人の話だけ聞いて、満たしたものを作ったけど、ただ単にそれを導入された、システムを導入された現場は混乱してますみたいなこととかも全然待ってるわけで、
そういうところまでが結構セットで考えとかないと危ないよなーって思ったりとかしますね。
きんじょうひでき
げんえいさんの会社だと本当に多そうですね。導入の意思決定する人と、実際に使ってくれる人みたいな。
げんえい
B2Bサーフとかはね、まさにそれで、今期の目標にシステム導入って書いちゃったから、どっか一社決めて導入しないとってやってる人と、現場でそれを使わされる人っていうのは全然違うので、
きんじょうひでき
両方をハッピーにさせるっていうのが一番いいことだと思うんですけど。 そうですね。
げんえい
けど、両方をハッピーにさせるってやっぱりなかなか難しいし、導入した後に、これがあってよかったよって言ってもらうためには、やっぱりユーザーのことは知ってないといけないし。
導入の意思決定に必要なものと現場で必要なものは多分違うと思うんで、そこはちゃんと割り切ったりとか、トレードオフになるんだったらトレードオフを考えないといけないしとか。
職人の責任と成長
げんえい
結構考えるね。ユーザーの声を聞きましょうって言って、本当に聞いてそのまま作ってもダメだし、
聞き方もいろんなヒアリングの手法だったりとか、出てきたものをどう分析するかっていう手法もいっぱいあるし、大事だと思ってるけど大変だなーみたいな。
きんじょうひでき
でもね、職人は自身の仕事に責任を持たなければならないって書いてあって、要するにコードを書くとかバグを潰すっていうのが職人の本当の責任ではなくて、
いかにユーザーと一緒に良い世界を作るかっていうところがあんたの責任でしょっていうふうに突きつけてくる感じがすごいありますよね。
げんえい
そうですね。そうなってくると医療系とかめちゃくちゃ背負い込むとめちゃくちゃ大変ですよね。人のある生命にかかわるものとか。
きんじょうひでき
いや、改めて話してみると7章いい章だな。
げんえい
これは多分自分が普段考えてることとかなり近いことが書いてあるんで、感情がかなり乗って喋れるっていうのがありますね。
この中で署名をするっていう話が入っていて、ソフトウェアのクレジットに名前が載るみたいな、名前が載るからにはちゃんと仕事をするっていうことでもあると思うんですけど。
きんじょうひでき
私が作りましたってやるやつですもんね。
げんえい
そうそう。生産者の顔は見えないかもしれないけど名前が見えるくらいまではあるわけで。でも現代のソフトウェアって別にゲームとかクレジットがあるかもしれないけど、なかなかそうじゃないと載らないっすよね。
きんじょうひでき
あとオウンドベリアで開発責任者とかデザイナーとかの顔と名前が出たりとかはありますかね。
採用工法的なニュアンスが強いかもしれないんですけど、とはいえこの機能は私が作ってこういう思いで取り組んでましたとか、ここにすごい工夫したからぜひ使ってみていろいろお声いただきたいですみたいな、ああいうのはすごいやるべきなんでしょうね。
げんえい
そこも含めてストーリーテリングとしてプロダクトを売っていくみたいなところまでやってるような番組ありそうだなっていう気もしますね。
つまりそれぐらい広報されてて目にするからイケてるプロダクトなんだろうなって。自信を持ってイケてるってことはイケてるってことだなっていう風に取ってほしいという意味でもやってる場合もありそうだなって気はしますね。
きんじょうひでき
自信がなかったら出て行きたくないですもんね。
そう?
いや、わかんないです。言われた通りに作っただけなんです。バグがありますか?いい仕様なんでみたいな。
げんえい
あ、そうですね。それの仕様なんて言えないですね。そういう風に表になっては。
まあ書名を入れたらみんなやる気を出すかって言ったらちょっとそこまでは言えなかったんで。
いかせるかって言われるとちょっとああって思いながら。
でもこの章はすごく周りの人にも読んでほしいなって思ったりするぐらいすごい好きでした。
職人気質っていうことの一つに本当にちゃんと責任を持つっていうのがあって、そうするといろんなもの、人だったりシステムだったり、自分の活動だったりっていうところがどんどん質が変わっていくよみたいな。そんな話ですね、第7章は。
金城さんはどっかこの中で章を気に入っているとか、こういいなみたいなありました?
きんじょうひでき
これそうですね、どこだっけな。なんかでも好きというか、話したいし多分この本の特徴の一個だろうなって思っているのが、12章、13章。
げんえい
12章がアプレンティスで13章がジャーニーマンなんですけど、アプレンティスは弟子みたいな感じですよね、新人みたいな。
きんじょうひでき
最初にアプレンティスからスタートして、ジャーニーマンっていうちょっと独り立ちした、弟子を取るまでじゃないけど独り立ちした人みたいなっていうくらいではない立場になって、
げんえい
最終的にね、より熟達して人を育てるとか、行進を育成するとか、業界の発展を支えるみたいなところまでいったのが職人、クラフトマンだっていうような世界観の描き方なんですけど、
これでですね、アプレンティスはわかるんですよ、新人だよねみたいな。本母して、オンJTして、いろいろ仕事を覚えてもらおうなみたいな。ジャーニーマンって何ですか、結局。
そうですね、何なら俺はジャーニーマンっていう地図を見るたびに、なぜか頭の中でシャーマンに変換されて。
きんじょうひでき
最高ランクなのではぐらいの感じに。
げんえい
そうそう、そう思ってて。ジャーニーマンってちょっとよくわかんねえなと思って、一応Googleでパッと検索したときには、長島の職人、旅人って出てきたりとかして、
どの辺までをジャーニーマンって呼ぶのかなと思いながら、いろんな現場を点々として解決していく人がジャーニーマンなのかなみたいなことはちょっと思ったりしましたけど。
だから下積み時代が終わって、いろんなバンドのサポートメンバーとかに入れるようになったけど、自分でソロでやったり、自分のバンドを持って生活していくぞっていうほどにはならないぐらいの感じかな。
きんじょうひでき
そもそもこの職人ケースっていうか、弟子がいて、師匠、職人がいてみたいな世界観が、イメージはわかるんですけど、じゃあ実際の会社組織とか、現代のビジネスっていうコンテキストでどういうふうに実現されるんだろうかっていうのが、
少し独特な世界観の話をしているなっていう感じは全体的にあるんですけど、その中の最たるものがジャーニーマン。ジャーニーマンとはっていう。
ジュニア以上、シニア未満なのでミドルっぽい話ではわかんないですけど、今の会社でいうと当然スタッフよりは下。一発のチームリードとかできるぐらいとか、テックリードないしジュニアテックリードぐらいの感じなんだろうなとはわかるんですけど。
ジャーニーマンって、独り立ちしてサポートをがっつり受けなくてもしっかりとアートカムを上げられる、アートプットを出していけるみたいな人。だからその流しの職人としていろんなギルドに入っていって、仕事を受けてちゃんと成果を上げられる。
逆に言うといろんな世界、いろんなギルドのやり方とか、いろんな職人と出会うことでどんどん成長のサイクルを回していくっていう話だと思うんですけど。会社の中でできないですもんね。
ジャーニーマン、自分の力で責任を持って成果を出せるから、よりオープンワールド的な世界観というか、いろんなとこ渡り歩いていろんなものを見たり聞いたりできて、その人のキャリア考えた時に非常に重要な成長のための糧となる機関だなと思うんですけど。
やり方がわかんないので、今の日本企業の中で。もったいないはずなんですよね。ジャーニーマン的な成長経験が詰めないことは。
げんえい
そうですね、そうですね。だからこそ人は転職していくのかみたいな気持ちは若干ありますね。
きんじょうひでき
そういうこと?
げんえい
でもそんな感じじゃないですかね。この本で、2000年前後の本をいろいろ読んできて、やっぱりプロダクトの成長みたいなところを継続して、このプロダクトをどんどん良くしていくんだっていうよりも、やっぱりプロジェクトベースがあって、ある技術までにこれを開発するんだ。
もちろんその中で仕様変更があったりとか、動きが変わっていくってことはもちろんあるんだけども。
それが終わった後に、この本の別の章とかでも、保守運用を引き継ぐみたいな話が出てきたりとかもするんで、やっぱりプロジェクトベースで人がどんどん入れ替わっていく。
ジャーニーマンの成長
げんえい
別のプロジェクトに参画するみたいな。そういう価値観の中にあるんだろうなみたいなのはちょっと読みながら考えてましたね。
きんじょうひでき
そうなるか。なるほどな。そうですね。
げんえい
たぶんちょっとそこは、もしかして現代のプロダクトを成長させて育っていくみたいな考え方と、別の現場においては納品が終わったら手を離れるっていう場合もあるだろうし。
そういうシチュエーションによっていろんな多様さが出てきた中で、ジャジャーニーマンってどういう立ち位置になるのとか、一社で長く働いてもらおうって考えた時に、それなりの規模がないとプロジェクターはそもそも複数ない。
1個、2個しかないってなった時に、多様な経験を積むっていうことが難しいみたいな。そういうのはあるだろうなっていう気がしますね。
きんじょうひでき
そうですね。そうか。物理的な面でいうと、いろんなプロジェクト、いろんな環境に出たり入ったりしましょう。
そこでしっかりといろいろな仕事をちゃんと完了させていきましょう的な話かなって思う一方で、熟達の段階においてジャジャーニーマンっていうのがどういうフェーズなのかってやっぱり経験とか責任みたいな観点で隠れるかなと思って。
ちょっと新人を教育するっていう責任を引き受けてみたりとか、あとはいろんな師匠というか職人、クラフトマンに出会って、そこからいろいろなやり方、自分の視野を広げるような学びをたくさん積んでいくっていうフェーズなのかなと思うので、
やり方としていろいろなプロジェクトとかいろいろな会社に出たり入ったりっていうのは難しかったとしても、今も自分はジャーニーマンという時代に差し掛かってるんだなって自覚した人は、そういう視野を持って、
そういう意識の持ち方でいろいろ触れてみたりとか、どっか行ってみたりとかっていうのが大事そうだなっていうようなことを今話したり話し聞きながらちょっと考えたりしました。そういうことなのかな。
げんえい
そんな感じなのかなみたいなことを思って、もしかしたらジャーニーマンとしていろんなクラフトマンに、地球上の強いクラフトマンに会いに行くぞみたいになったら、でも確かにあの会社のCTOがいるところで働いてみたいとか、
だからCTOが仮にクラフトマンだとしたら、あの会社で働いてみたいなとか、そういうのとかどういうふうにやってるんだとか、あそこに弟子入りするとどうなるのかなみたいな。
で、弟子入りした結果、ちょっとこっちの若手の面倒を見ながら、このプロジェクトをやりながら、あとこれもやってくださいみたいな、同時に3つ仕事が降ってきて全部やるみたいなことをやりながら、だんだん熟練の職人になっていくのかなみたいな。
もしかしたらその人がある段階でどこかでCTOを任せられるとか、ギルトを作っていろんな人を引き連れてプロジェクトをやっていくのかとか、何ならどこかで作ったチームでそのままチームごと転職していくとか、そういうようないろんなパターンがやっていく中で出てくるのかなみたいな気がしますね。
きんじょうひでき
そうですね。いろいろな段階とかがあるにせよ、いろんな人と出会ったり、いろんな責任を引き受けながら技芸の熟達っていうのを目指していくんだよっていうような話が10章から13章はそんな話ですかね。
げんえい
そうですね。
ソフトウェア工学の再評価
きんじょうひでき
じゃあ第4部行ってみますか。ソフトウェア工学の位置づけを再評価するっていう話ですけど。
げんえい
そうですね。大事なのは対立ではないんだよってことは言ってるってことですよね。
きんじょうひでき
これもうちょい早めに言ってくれてよかったやでみたいな気持ちになりますよね。
げんえい
そうですね。
きんじょうひでき
なんか別にそんなに怒ってなかったんですねみたいな。
げんえい
だんだん冒頭で、ソフトウェア工学はちょっとみたいな感じの話をしてたのに。
ソフトウェアのプロジェクトは規模がいっぱいあって、数ヶ月で1ヶ月2ヶ月で終わるものから何年かけてっていうものもあるんで、一概に適応するなよっていうことから始まったものでもあるんで。
じゃあデカいプロジェクトに対してソフトウェア工学的な知見なしに突っ込んでいくとどうなるかって言ったら逆に大変そうっていうこともあるだろうからな。
きんじょうひでき
そうですね。なんというかカオスなりすぎるんでしょうね。
工学的なコントロールっていう観点でやっていかないとやっぱりいろいろ厳しい。
ただ逆にそこまで大規模じゃねえよっていう話の時に管理管理っていう風にやりすぎると、なかなか本当に必要な創造性みたいなものを失われていってつまんねえものを作るっていう話になるぞみたいな。
そんな感じかなっていう気がしますし、おそらくこの人の中でいうとソフトウェア開発者っていうのは本質的にクリエイティブな仕事。
いろいろなものを見聞きして取り入れて、そこに対して適切に解を見出していくっていうような職務なんだっていう立場に立ってる感じがあるんで。
そう考えたら小規模なところに工学的な管理とか制御とかっていうと、なかなかいびつだよね。なんか違うよねっていう違和感あるよねっていう話な感じがしますね。
げんえい
そうですね。
クリエイティブなソフトウェア開発
きんじょうひでき
だから解こうとしてる問題が違うんだよっていう風に明確に書いてあるんで。
げんえい
この最初の方とかにNASAの事例とかが出てきて、より早く、よりうまく、より安くみたいな話が書いてあるんですけど、そこは別にNASAでソフトウェア工学を頑張ってやったけどうまくいかないみたいなことだったアプローチが必要なんですっていうことで、
これを現代で読み換えると、菅はうまいことやってますっていう話なのかなみたいなことをちょっと思ったりとかしましたね。
きんじょうひでき
NASAの話とかが出てくるのが15章ですよね、確か。
げんえい
15章ですね。114ページの一番上ですね。
きんじょうひでき
このソフトウェア工学メタファーの危険性っていうのが15章なんですけど、なんかここを見ると改めてこの著者がどういう意味合いでそんなに批判したがってるんだ、どこら辺を何だろうな、意見をぶつけたいのかなっていうのが少し垣間見えてきますよね。
それこそソフトウェア工学は科学的管理法を奨励しているっていう話があったりだとか、あと工場的な感じでやってはいるけど、そもそもプロジェクトをまたがって再利用難しい。
どんなプロジェクトにも通用する管理手法っていうのがないんやで、みたいな。
げんえい
そうですね。
きんじょうひでき
別の章であれですね、誰にでもぴったりなフリーサイズの服はないみたいな例があって。
それはウィットに飛んでていいなとか思いましたけど。
あと長期の再利用は危険であるとか、その画一的な標準プロセス、要するにこれだけ覚えておけば生きていけますみたいな考え方っていうのが厳しいとか。
あとベストプラクティスはプロセスの確信を阻害するとか。
げんえい
はい。
きんじょうひでき
結構この15章はそういうことを言いたかったんだねっていう真に迫る感じがして個人的に面白かったですね。
げんえい
そうですね。従来の作業分担はソフトウェア開発では機能しないみたいな、まさに工場の流れ作業の文脈で標準化か開発の標準プロセスみたいな話を中で言ってるんですけど。
確かに結局今現代においてはクロスファンクショナルチームを作りましょうとか。
作業分担といっても工程で区切るんではなくてものを作るっていうことは一緒なんだけども、そこをちゃんと作りきれるような、一人で作るのは難しいから作りきるチームにしてそのチームで作りましょうみたいなことにもなっていて。
やっぱりプロセスを変えることができるぐらいとか、そのチームに権限があっていろいろ自由にできるみたいなところに寄ってっているのは本当にここで批判しているものがどんどんアップデートされてって現代でもこういう考え方はちょっと危ないねみたいな感じになっていってるなっていうのは読みながら思ってましたね。
あと結構ちょっとどこにあったか忘れちゃったけど、DevとOpsが分かれてるんですよね。まだこの本の時代だと。
きんじょうひでき
そうそうそう、どこにありましたっけね。
げんえい
どっかであって、18章とか5部でちょっと先取りしちゃうけど、5部とかでもやっぱその補修チームとアプリケーションを作るチームみたいな考え方になってて、この辺とかもまだDevOpsっていうものは一個になってないっていうところもあり、これを結局分けてるのは時代的にしょうがないみたいなところで分かれてたんだけども、
時代が進むにつれて、ここを分けるとおかしなことになるから、ちゃんと一緒に考えようよっていう風に進んでいくってなると、ここで言ってることがどんどんどんどん、
なんていうんですかね、この本の中でも想像してることよりも現代はもっと統合的にやられてるっていうか、いう風になってて、予見してるとまでは言わないけども、目指している方向にどんどんどんどん近づいてるなっていう気がしますね。
きんじょうひでき
そうなんですよね、そことそこを繋げるんだみたいな要素は、悪い意味で驚いてるんじゃなくて、なるほどって感じするって意味で驚くような要素と要素を繋げてる話はちょいちょいあって、
それこそゲイさんが言ってた従来のスロー分担はソフトウェア開発には機能しないとこを見てみると、いろいろなロール、アナリスト、デザイナー、プログラマー、テスター、ユーザー、インターフェーススペシャリスト、テクニカルライターみたいないろんな作業を分担して、上流からどんどんどんどん明確に勝ちと決められた工程があって、
仕事作業が流れていくよねっていう、上から下へ流れていきます。上へのフィードバックとか、上と下のコラボレーションがないですみたいなやり方で作られたソフトウェアって、それは最終的にもレガシーアプリケーションになるみたいな話が書いてあって、
よくあるテストがないのがレガシーだとか、そういう話とは全く違うところから、何をもってレガシーとするかって話出してきたなっていう感じがするんですけど、どんなアウトカムを埋めてるかとか、将来的にどんどん持続的に進化していけるかっていう意味で言うと、古くなる運命が定められてるみたいな話で。
げんえい
そうですね。
きんじょうひでき
そのプロセスで作られたものが、もうニアリーイコールレガシーアプリケーションだっていう言い方も、確かにめちゃくちゃ面白いなって思ったりしたんですよね。
げんえい
いいですよね。そしてソフトウェアの仕組みを本当に理解している要因が一人もいなくなりっていうのが。
なんでこういうソフトあるんだっけ?あそこで言われたから作ってるし、このドキュメントにこう書いてあるんだよみたいなことをみんなが口々に言ってて、これが止まったらどうなるんですかねって言ったら、多分お客さんが大変になるぐらいの解像度でしか喋れなくて、
実際アクセスログインに行ったら、ほとんどつかれてないんじゃないですかねっていう世界は全然想像できるなって思ったりしますね。
きんじょうひでき
いや、なんとなく似てるから、レコピペされた行動がありそうな雰囲気がプンプンしますもんね、その現場。
げんえい
すごいですよね。結局ドキュメントに書いてあることを信じて作っていくと、そういう道に行ってしまうっていう話が後に書いてあって、
まあそうですよね、なんでこれを作るんですかって。ここにこう書いてあるんだよって。結果、じゃあこれを俺がサボったらどうなるんだろうみたいになると、実は誰も困ってないみたいなことが起きるかもしれないみたいな。
きんじょうひでき
ドキュメントが常に古いみたいな書いてあったのってここら辺でしたっけ?
げんえい
ここら辺だっけ?
きんじょうひでき
16章か。16章も結構好きなんですよね。ソフトウェア工学からの教訓で、規模とか複雑さっていうのが重要だよって話とかが載ってるんですけど。
要するにプロジェクトなしのプロダクトの成功のために必要なことっていうのをしっかり見定める必要があるよね。そのためにはやらなくていいこととかやっちゃいけないことっていうのは避けなきゃいけないっていうような論説が展開されてて。
ただ余裕のない変更は豪華なものとなるとか、いろいろ書かれてる中でドキュメントは常に時代遅れで間違ったものであるっていうふうに書いてあったり、正確な見積もりはとても高くつくとかね。
あ、で丸子さんが言ってたやつみたいな。
げんえい
そうですね。
ドキュメントの重要性とコミュニケーション
きんじょうひでき
これ見積もり、見積もりとても高くつくあれですね。見積もり自体、見積もりっていう行為に関して発生するコストっていうのと、見積もりっていうのを深刻化しすぎたことによって発生する失敗、痛い意味を見るっていう意味で高くつくみたいな、そういう感じもするような。
げんえい
確かに。その後者の考え方はめちゃくちゃいいですね。
こう、握りたいから蜜持ってみたいな、藍蜜を取ってとかっていうのをやった結果、すごい痛い意味を見るっていう、すごい偶話大将だなみたいな感じがしますね。
きんじょうひでき
これそう、ドキュメントは常に時代遅れで間違ったものであるっていうのは、メンテナンス難しいよねって話はあるんですけど。
少なくともドキュメントドリブンでやってる開発の現場っていうよりも、チーム内とかステークホルダーとかユーザーとどんどんコミュニケーション取ってフィードバック出し合ってやってる会社の方が、新しい、ちゃんとアップデートされたものが作れるよねっていう観点での相対的な評価のニュアンスもあるのかな?
げんえい
何か変わった時に全体の整合性が取れてるかって、そもそも整合性が取れてるって保証することがやっぱりできないので、結局変えたけどその後、ちゃんと今目の前で動いてるものと合ってるっていうことって、担保できない以上はそれはもう古いもんだよねっていう話なのかなっていうのは。
当初作ったドキュメントと最終的に現場で整合性合わせで頑張って作った行動は最終的にどんどん差が開いていくっていうことなのかなって思ったりしました。
きんじょうひでき
こういったトークンをソフトウェア職人機質に活かすと。
決めました、そういうルールなんで、ルールのっとってれば完璧なんでっていう話じゃなくて、自分の持ってる時間、使ってる時間っていうのは何のためにあるんだっけっていうのを考えたら、ユーザーの声聞こうよとか、ユーザーじゃなくてもその一緒に関わってる組織の中で必要なことはしっかり話していこうよ、対話していこうよ。
それが職人機質だよねっていうような話っぽい気がする。
げんえい
そうですね。
きんじょうひでき
ただそんなこと言っても千人規模とかそういうクソデカプロジェクトでそんな一人一人が勝手に動いてたら大変だから、まあまあまあ、ケースがいいケースなところはありつつ。
げんえい
結局規模がでかくなっていくってことに対して、別に今の我々も現代の人々も結局多分対応はしきれていなくて、じゃあこれとどうやって戦いますかみたいなところはまだずっと探究されてきて、結局マイクロサービスみたいなのが出てきたのは多分一個、そういうことだと思うんですよね。
どんどん規模がでかくなっていって、失われていきソフトウェアの良さがなくなっていったよね。
じゃあどうするって言ったときにマイクロサービスに分割してみるかみたいな。
分割したり分割したりで結局今度複雑になって、100何十個のマイクロサービスが立ち上がらないとシステムが動きませんわ、もう誰も把握できないよねみたいなところとかって。
結局どうやってその問題を、いかに問題を見極めて困難を分割するっていうところって多分答えは出なくて、どうやったら人間が把握できるサイズに収まるかみたいなのはずっと考え続ける。
ただ単に規模がでかくて、このプロジェクトは失敗するよねっていうのではなくて、どうやったら成功できるかみたいなところを経験的に学習したものを活かしながらやっていく。
それがクラフトマンシップなんだっていうことなんだろうなっていうのを読みながら思ったりしましたね。
きんじょうひでき
改めて言われるといろいろ耳が痛いなっていう面はありつつ、ただ知らなかったこととか完全に意識してなかったことっていうのは意外と少ないなっていう気もしますよね。
げんえい
ある種いろんなものに諦めがついて、ちっちゃく作っていこうねとか、ある程度の規模になると失敗するっていうことが目に見えてるから、どうやって規模をちっちゃく始めるかとか、あるタイミングで分割するかみたいなことにみんな目は行ってるよねみたいな、それを知らずに落とし穴にはまるみたいな、そういうところはもうないよねって気はしますね。
きんじょうひでき
ないか?本当か?
げんえい
いや、分かりながら落ちる部分はあると思うんですよね。どうしても避けられなくてとか、プロダクションの成長スピードがあまりにも速すぎてついていけなかった場合とか、つまりハンドルを握ってると思ってたらうまく握れてなかったとか、そういうことはある意味ではあると思うんですよね。
でもそこは知らなくてそれをやってるんじゃなくて、市場に思ったより受け入れられて規模がでかくなって人を入れないといけなくなっちゃったりとかした結果うまくいかないとか、本当に分かってるんだけどどうしてもしょうがなかったみたいなのは、のと全然知らずに経験もしたことなくて失敗しちゃうっていうのはちょっと違うものだよねっていうのは思ってはいますね。
結果的に失敗するのは一緒かもしれないけど。
きんじょうひでき
でも負け方も大事みたいな話ありますからね。
げんえい
そうそう。その中でいかに被害を最小限にするかとか。リスクだって分かっていながら人を入れたことによって失敗したんだったら、そこから何を入れるかみたいな部分はきっとあるんだろうなと。
