00:06
じゃあ、最終部いきますか。第5部。どたんばになって行うこと。第5部は2つでしたっけ、章が。3つ。3つかな。17、18、19ですね。
経験プロジェクトを成功させる秘訣とテストと保守のための設計と永続的な学習ですね。第17章の経験プロジェクトを成功させる秘訣はなんか、これな、プロジェクトのメンバーを職人が決めましょうみたいな。
なかなか、採用とかそっち側の話に踏み込みつつ、できる人にはちゃんと報酬を出そうみたいな話ですね。
そうですね。
なので、どっちかっていうと僕は18、19の話がしないんですよ。
しましょうしましょう。
これテストと保守のための設計っていうところが第18章始まるんですけど、職人のあり方みたいな話、職人技術っていうのはどういうふうに発揮されるかって話をしたときに、作って終わりっていうのは本当にナンセンスなので、
どういうふうに持続的に価値を高め続けるかとか、保守性とか変更容易性っていう話もあるし、単純な品質みたいな話もあるんですけど、これな、いいですよね。18章結構好きなんだよな。
アプリケーションが完成するものではなく、ただ使われなくなるだけであるとか。
あと、いわゆる保守チームっていうところに、テクニシャンというかハイスキルな人を当てないのは信じられないみたいな。
そう、そこいいなって思いますね。
そこいいですよね。
ソフトウェア開発の現場では保守みたいなところに結構新人とか当てたりするけど、ただ車の修理をスキルがない人やってるとか絶対車預けたくないよね、的な話とか思ってて。
新しく作る方が制約条件は少ないわけじゃないですか。自由に作れるわけで。保守っていうのはその制約条件ない中で好き勝手に作ったものを壊れないように改善していく。
もしくは壊れてる部分があったら直していくって考えた時に、どっちが難しいかって言われると、もちろん難しさを単純に比べることはできないかもしれないけど、
知らないものを知らない動作をしているものを自分で調べてそれを直していくって結構大変ですよね。
03:03
しかもバグを直すみたいな話だけだったら、中途にF文を1個生やしましたで対応するかもしれないんですけど、全体の品質を落とさない、保守性っていうのを下げないでやり続けるってことをしていかないとソフトウェアは死ぬわけじゃないですか。
って考えた時にちょっとここら辺のくだりを見ながら個人的にイメージしてたのが、単純なソフトウェアの欠陥、バグがありますっていうのはわかりやすく失敗なんですけど、
それってソフトウェア壊しましたねっていうふうに言えると思うんですけど、仮にそうじゃなくても保守用意性、保守性をどんどん下げちゃったりとか、次に来る要注に対して答えづらいようなソフトウェアにしてしまった、雑なF文を生やして変更してしまったっていうのを中期的なビジネス価値みたいなところを失うっていう意味では、
なんかそれも直してるんじゃなくて壊してるって言えるんじゃないかみたいな感じがして、保守チーム超大事じゃん、そこにロースキルな人を当てておけばいいやろっていうのは確かにちょっと厳しいものがあるなぁとか思ったりして、
ソフトウェアが壊れるっていう概念が少し自分の中で、そこまで踏み込んだ話書いてあるわけじゃないですけど、この本の中にちょっと勝手にそういうメッセージを送ったりしてました。
たぶんそれが起きてるのってビジネス構造上の問題なんですよね、きっと。
そうなんですよね。
じゃあ保守が実際ものを最初に作ったタイミングと保守の時の値段がどっちが高いって言われたときに、うーんみたいな顔をしながら保守運用フェーズなんてそんなにお金はかけられませんみたいな。
そこに対してお金が投資されてないところにハイスキルなエンジンをバーンとアサインするとずっと赤字を垂れ流してますねみたいなことが起きたら、あれーってことになっちゃうから。
結果、単価の安い新人を入れた方がいいよねみたいな。ここで勉強してくれてスキルも身について、後に戦力となってプロジェクトにアサインできるようになっていくといいよねみたいな。
という都合は実は裏にあるわけで、なかなかそれを両立させようとか、もっと言うともしかしたらハイスキルな人を入れてもっとこのソフトウェアを使いやすくしていくんだみたいなモチベーションが顧客にあるとかいうことがないと結構難しかったりしますね。
そうなんですよね。守りの仕事評価しづらい問題があり。
動いてて当たり前でしょって。まあまあ使う側としては動いてるのは当たり前なんだけどさみたいな。
06:04
そうなんですよね。あと言ってね、理想というか思想だけで言うと、問い合わせ対応とかバグの調査とかっていうのは別にそれ専用のチームだったらいられないやろみたいな。
プロダクトを作ったチームっていうのがあるんだったらそこで面倒見ろよっていうのは思うんですけど、ただそれで要するに防火壁がない状態でダイレクトにプロダクトチームに仕事が差し込まれてくるといろいろ破綻すんだよなみたいなっていうのも難しいっていう。
そうですね。常に儲かってればいいんですけどね。お金が絡んでる以上、結局この本が出た後にどうなっていったか、特に日本においてどうなっていったかって言ったらソフトウェアエンジニアを自社で雇用しようみたいな流れはあるわけじゃないですか、実際。
外に害虫してるじゃなくて、ソフトウェアっていうのは競争力の形成になるから自社で囲ってそこと一緒に良いプロダクトを常に改善していくんだみたいな。この1行直すのに影響範囲を調査して見積もりをして、文字が直るのは1ヶ月後ですとかじゃなくて、自社にいればすぐ直せるんだからっていうことだったと思うんですけど、儲からなくなったら人を削るには正社員を削るのは難しいとか。
このプロダクトが終わったら次どうしますかね、みたいな話とか、いうことがたぶんいっぱい出てきたので、本当にやりたいことと現実の制約条件みたいなものはいっぱいあり、理想的にやりたいことと実際うまくできるかどうかっていうのはなかなか難しいですね。
難しいんだよなー。いやー強い保守チームなー、どう作るんだろうなー。
実際強い保守チーム作ったとて、あっちで新規プロジェクトやりたいからって言って人を抜かれていく未来しか見えないんだよな。
チートポーとかの話で言うとね、いろいろプラットフォームじゃないよなー。なんかしら独立したミッションを背負わせていろいろやってもらうみたいな。
保守チームはね、少なくともリファクタリングし放題だよっていうぐらいの裁量は絶対あるべきなので、リファクタリング好きな子はね、プログラミング好きな子も多いので。
あとはこの18章の中で18.2が保守チームは粗悪なアプリケーションの受け取りを拒否すべきであるっていう強いタイトルがついてて、これすごいいいなと思ってて。
保守担当って無理やりやらされる場合が多いんで、そこにやっぱりさっき言ったようにリファクタリングができるとか、目の前の問題を片付けるためにまず付け根をきれいにしようかみたいなところとかをやれるぐらいにはソースコードがある程度メンテできるようになってないといけないし。
09:17
もうちょっと率先して障害対応とか不具合対応を最初にやるチームとしてもいいんだけど、保守チームを。
そこのチームから他の運用してる中で機能開発をしてるチームとかにもうちょっと意見を言う力がないと、あの人たちが見てくれるからって全部そこに流れていくんだよなーみたいなことを思ってて。
やっぱりそのためには強い発言力だったり権力みたいなものはないと大変だなーっていうのは思いますね。
そうですよね。いや1回デプロイしたんで返品は不可能なんでそっちのチームの責任ですよねみたいな。
やるべきことってあれなんですよね。アプリケーションの持続的な進化の可能性を担保するとか磨いていくみたいなチームのはず。
でそれって別にコードだとかCICDとかっていうプラットフォームの話だけじゃないはずなんで、なんかプロジェクトの進め方とかそっち側の話まで踏み込んでいいはずなんですよね。
そうですねそうですね。
っていうチームづくりしてた。
理想と現実はあれど、もうちょっとどうにかしたいですよね。
あと18の8、保守可能なソフトウェアは簡単に診断できるっていうふうに書いてあって、これは最近で言うとオブザーバビリティって言われるような領域の話にそんなにがっつり語られてるわけじゃないですけど、短めの施設ですけど、そんなことが書いてあるなっていう。
そうですね。だからまあ、もうちょっと現代は進んだよねっていうことがやっぱり部分的にはやっぱりありますよね。
そうですね。
有紀さんの最初の方に研究した有紀さんのスライド、SRE NEXTで話されていた中で、ギゲと工学みたいなところの対比の時にSREはもうちょっと工学的なアプローチができるようになっているんだっていう話と、
じゃあそこの部分が昔どうだったかっていうと、問題が起きるたびにエンジニアがリアクティブに、その都度いい感じに直していくみたいな。まさに職人技みたいな。
12:06
ここが壊れたからこう直すみたいなのをずっとやり続けてたんだけど、問題が起きるっていうことを予期するとか起きてるってことを発見できるように、例えばSLを決めましょうとかその間オブザーバビリティの話だったりとか、
いろんな話題が今となってはもう出ているんだから、もうちょっと工学的なアプローチができるんじゃないかっていう話を有紀さんの可能性みたいなところをしゃべっていて、
だからその辺とはすごく進歩しているし、むしろソフトウェア開発の作っていく中の工学はなかなか難しいかもしれないけど、運用部分みたいなところとかにおいてはその工学的な知見はすごく発展しているとか生きているっていうところはあるんだよねっていうふうに思ったりとかしましたね。
先人たちの努力により現代では工学としての知恵を確立しつつあるみたいなことが述べられてますね。
めちゃくちゃいいスライドですね。
いいですね。
なんで見に行かなかったんだろうと思いながら、すげー後悔しましたね。動画も上がってるんで動画も見たんですけど、こんな楽しい発表なんで見なかったんだろうみたいな。
それであれですか、SRA会議チケット買ったって言ってたんですか。
それはまた別の文脈というか、家から近いのとチケット安かったんで、とりあえず買っとくかと思って。
それを買った後に動画を見て、これはSRA会議ちょっと楽しみだなって。
スライド発表されるトークめちゃくちゃ面白そうなのが目白押しでしたからね。
SRA男子をみんな持つ必要があると思うんで、もしかしたらSRA男子と呼んでたものはクラフトマンシップだったのではみたいなことを今一瞬思ったりしましたけど。
そうすると、大体のものがクラフトマンシップで片付けられるぐらいの強いワードではありますね。
そうですね。
でもそうですよね。工学的に管理していかないと、本当にベテランのエスパーで障害対応しましたっていうのがずっと続いていくわけですからね。
そうですね。ベテランと狼少年を知ってるかどうかで応用される。
たまにね、狼見分け職人みたいなのがいますからね。
これはいつものやつですみたいな。いつものやつって。
そう。いつものやつだったら通知が来ないようにしてくれみたいな。
これな、18章はなかなかいいんだよな。
結構話はいろいろありますからね。ソフトウェア職人キースは独占されていないオープンソースツールを好むみたいな話があったりとかして。
15:01
ハピヒロインですよね。
やっぱりベンダーがあれば大丈夫みたいな、もしかしたら信法みたいなものも当時はあったのかもしれない。
多分今よりもオープンソースの当たり前度みたいなのは違っただろうし。
世の中的に、今となってはもう受け入れられてるし。
結局じゃあそれは誰が最終的に責任を取るんだみたいなことを言った時に、いやー別に責任を取るとかはないですねみたいなことになるわけですよね。
オープンソースのコードを使うってことは。
いざという時に自分でどうにかできないっていうところに悔しくないのか、それで本当に職人なのかっていう感じがありますよね。
この辺はもしかしたら、スティーブン・ルビーとかのハッカーズとかっていう本は言及があったりとかしましたけど、
なんかストールマンとかその辺は言及ないのかなってちょっと思ったりとかもしましたね。
あとマッツの名前が言及されたりとかもありますね、18章とかだと。
そうですね。多言語化の例で。
ルビーっていうのは英語圏発祥じゃないから、多言語が対応されてて。
びっくりした、すげーって思ったっていう感じの話が、まあまあなって感じ。
でも今となってはね、やっぱりずっと続いてて、ルビーっていうのは世界的に影響を与えているプロダクトの一つですからね。
てかあれか、多言語化対応が大事だとか優れてるとかじゃなくて、真の職人だったらそのユーザーに対して、
例えば英語を学習しないとダメですみたいなコストを押し付けるっていうのは態度としてふさわしくないっていうくだりでしたね。
でもそう考えるとやっぱり、松本さんが前の話をしていた時に、やっぱり英語が喋れるっていうのはすごくメリット。
いいことで、アプローチ、やっぱり英語圏にアプローチできるみたいな話をちょっと内容でしてたか忘れちゃいましたけど、
過去にしてた記憶があって。だからやっぱり日本に閉じたプロダクトにするつもりはなかったっぽいなと思って。
って考えると、やっぱり強いクラフトマンシップがあるっていうことをすごく実感できる例だよなって思ったりしますね。
なるほどな。
そう考えると、ルビー会議がこういう英語でやりましょうとかって言ってるのって、まさにこの本を体現してるみたいな感じもするし。
そうですね。まあでも18章そんなとこですかね。
19章は最後、永続的な学習の話がありますね。
これ19章特に顕著で、この本ちょいちょい会議を大事にしようみたいな、会議への参加を奨励するっていうような表現が出てるんですけど、
18:10
すげえ後になって気づいたんですけど、これカンファレンスを多分会議っていうふうに略を当ててて。
別にミーティングにいっぱい出ましょうって話ではないってことですね。
ユーザーグループや会議への参加、会議って思ってたんですけど、カンファレンスですね、多分。
そうですね、カンファレンスだと思いますね。
カンファレンスとかっていう話を出してるのは、本当に19章永続的な学習っていうトピックの中で、
いろいろ仕事で必要に迫られてやってることだけじゃなくて、視野を開けたり、視座を上げたりっていう観点でも必要だし、
それこそ労家的なところの体験っていうのも大事にしましょう的なところかな。
さっきジャーニーマンの話をしたときに、一つの会社でみたいなことの難しさの解決とまでは行かないけども、
やっぱり他はどうやってるんだみたいなところを探しに行くっていう意味では、やっぱりカンファレンスみたいなところはないと難しいですよね。
外にいろいろインプットとか出会いを求めに行くっていう話と、
あと普段の日常の中にというか、自分が学習できる環境っていうのを作り上げるために組織内に何かね、
クラスとかワークショップとかそういうの、弁当会みたいなものを作りましょうっていうのが書いてあったりだとか、
あとは内政的な実践者になるっていうようなトピックもあるか。
これはね、日報をかけっていう話なんでしょうね。
そうですね。
でもこれ、内政的な実践者になるっていうのはさっき言ってたベストプラクティスの罠みたいな話に近くて。
優れた開発者はすでに真とは言えなくなった記録を認識し、その事実を生かしてアプリケーションを構築することをますます要求されるようになっています。
って書かれてて。
なんかね、昔のやり方とか、自分が知ってるやり方だけじゃないぞっていうのをやっていこうっていう話ですかね。
そうですね。
時代がどんどん移り変われば、アンチパターンと呼ばれてたものも、こういう場合においては別にOKみたいなものもいっぱいあったりするし、
ベストプラクティスだと言われてたものが、いやそれよりは現代、歳はこっちの方がいいよみたいな。
ゴフのデザインパターンをベストプラクティス集と呼ぶかどうかはちょっとありますけど、
21:03
イテレーターパターンみたいなものは別に言語についてるじゃん、みたいなこととかも。
自分で実装しなくていいよねっていうこととか、やっぱり現にあるので。
シングルと言やめろとかね。
そうそうそうそう。
いっぱいあるので、そういうところは実際に手を動かして得た教訓だったりとか。
過去から学んだけども、現代においてはもっといいやり方があるんじゃないか、みたいなところは知っておかないと、
いや本に書いてあるんでこうしましょうだけだと、ちょっと難しくなっていきますよね。
そうですね。
こんな古い本ばっか読んでる我々が何を言ってるんだっていうのはあるかもしれないですけど、新しい本は取り上げないだけで読んではいるんで。
そうそうそう。そうなんですよね。新しい本は読んでるし、カンワネスでは新しい話がいっぱいされるので、むしろ古い話をしてるところが多くないから、あえて古い本を読むみたいな。
そうですね、はい。
ただそれだけ言ってると逆張りの人みたいな感じがして、なんかよくない気がする。
確かに。みんなJ-POPばっか聞いてるから洋楽聞いてる中にみたいな。
確かにね。そういう感じですかね。
でもそうですね、19章でエピローグもありますけど、エピローグの締めめっちゃ好きなんですよね。
これ、ソフトウェア開発は楽しくなければなりません。そうでなければそのプロセスは間違っているのです。って書いてあって。
なんかこの人多分好きなんでしょうね、ソフトウェア職業として。
楽しくなければプロセスが間違っている。すごいなーみたいな。
じゃあこう、散々批判したプロセスを楽しくやってる人たちがいたら、これどうなるんだろうかみたいな。
やらされてやるみたいな仕事の仕方とか考え方って、やめてこうぜっていうのは多分根底にずっとあると思うんですよね、一冊通して。
そうですね、そうですね。
で、それ何のためにやるのって考えたら、まあ出世するとか、賃金稼いでいくとか、プロジェクト成功させるとかあると思うけど、
職人っていう本当に個人にある意味閉ざした話をずっとしてもいるので、
一番ね、究極の個人に閉ざした話って、好きか嫌いかとか楽しいかつまらないかとか、そこに帰結させるエピローグめっちゃかっけえなーって思いました。
こう迷いなく視線つけましたね。
けどまあね、ここが楽しくなるまでソフトウェア開発を歯を食いしばって最初ちょっと頑張らないといけないっていう部分はあるからな。
大変だよなーっていうのも。
そうなんですよね。
そうだから、なんか前どっかでそういう風に言中したかもしれないですけど、誰にでも勧められるかとか。
24:05
うん。
これ絶対インプットしていた方がいいよって言って手渡せる本ではなさそうだなっていう感じもするんですよね。
そうですね。
これ読んできつくなる人は絶対いるよなーと思って。
こんなに求められるの?みたいな気持ちになっちゃう場合も全然ありますからね。
そうですね。土日に勉強するかしないかでずっと揉めてる世界もあるわけで。
そうそうそうそう。
勉強はしてねーっていう。
この本読んでて、いきいきとこの本面白いっすねーみたいなしてる二人ですからね。
まあまあまあそんなものがありますけど。
はい。
さて一冊読んでみていかがでしたか?ソフトウェア職人キス20数年前の本でしたか?
いやー最高じゃないですか。なんでもっと早く出会わなかったんだろうと思いながら。
毎回言うじゃないですかそれ。
いやーなんか読んでない本があって。
でもほんと、情熱プログラマーとまでは言わないけども、
でもなんかそこにちょっと近いものというか、
やっぱ自分に焚きつけてくれるようなものがあったりとか、
やっぱもうちょっとこう、職人として頑張っていこうと思いますみたいなことを思う本で。
やっぱこれを読むとちょっと勉強しないとなって、もっと頑張らないとなって気持ちになるぐらいに。
しかもそれがこうやっぱ時を経て読んでも変わらないっていうのはすごくいいなって思いましたね。
なんかねこの前のエアプシーの個人技の時代じゃないですけど。
うんうん。
いや組織の話とかソフトスキルみたいな話ってすげー重要性増してるしプレゼンスも増してると思うんですけど。
うん。
なんか結局自分で生き残っていかないといけないよなーっていう気持ちをちょっと新たにさせるというか思い出させるというか。
そうそうそう。
すんごいここまで明確認識が高い話ってまあなかなか普段ないですからね。
やっぱ一人で全部できないとなーっていう気持ちも、まあ別にそこまで書いてはないけども。
でも一人でできることがやっぱりソフトウェアのそのバックエンドだけとかフロントエンドだけとか。
バックエンドもフロントエンドもできてマニフラーも上がってなんならアプリケーション売り込みに行くんだぐらいまで。
できないとまあ対話もできないし。
それぐらいの気概を持ってやらないとなーみたいな気持ちにはなりますね。
でなった時に多分今この本が出た当初と全然違うものは一人でできることの幅はどんどんどんどん増えているので。
27:00
だからもっとコンフォートゾーン向けて新しいことにチャレンジしたりとか自分のできる範囲をどんどんどんどん広げていって。
まあ少ない人数で高い成果を出す。
まあコミュニケーションのオーバーヘッドが多分一番ボトルネックになっちゃってそのために一人一人ができる範囲が広がっていって。
少ないチームで成果が出していけるようになっていくといいなーっていうのは。
考え方は変わらないけどすごく後押ししてくれる本だなーっていうのを思いましたね。
いろいろできた方がね、よりさっきの締めの言葉にあった通りの楽しむっていうところが改めて際立ってくると思うので。
いろいろできないうちにでもあれもこれもやるんだよって言われると辛くなっちゃうから恥ずかしいんだけど。
そこの辺まで含め楽しめるようになっていくと、いろいろできてめちゃくちゃ楽しいじゃん。
こんなに影響レバレッジが効く仕事というか、もうなかなかないわけでやっぱり。
そうですよね。絶対楽しいもんね。一人の生産性が10倍とか100倍とか1000倍とか開くって言われてる職業なんで、今の1000倍自分が仕事できるようになったら絶対楽しいよみたいな。
そう。しかも成果が出てユーザーがどんどんついてきたりとか売上が上がっていくとか。イエーイ。
イエーイですね。いやーなりてぇなー。
なりたいよ。なりたいよ本当に。じゃあどうやったらなれるんですか?そういう人に。
いや、やっぱり会議にたくさん出るんですよ。
ミーティングに呼ばれるぐらい頑張るみたいな。
本当にそっちの会議行っておく。
でも目の前の仕事をね、バカにしたりとか、ザナリにするのはやっぱりありえないんだろうなっていうのが、なんか責任に始まり責任に終わるぐらいの感じは本読んでてしたんで。
いやー、いろいろやっていくっていうとまたニュアンスズレるんですけど、やるべきことをしっかりやっていかないとなーっていうのは思いますよね。
そうですね。
まあそんなところですかね。ソフトウェア、クラフトマンシップ。
ちょっと新品ではもう手に入らなく、入手がもしかしたら難しいかもしれないですが、気になる人はぜひ聞いてほしい。
中古だといくらぐらいなんですか?今。
数百円で買えると思います。自分は多分数百円とかで買ったんで。
Amazonで520円とかであります。
すごい。
送料入れても1000円以内に買えそうです。
送料の方が高いパターン。
ありますね。
本の入手がちょっと難しいなーってなった場合、書名でググってみるといろんな人の書評とか感想とかスライドだったりが出てきたりもするので、
30:05
一旦そっち読んでみて、改めてどんな本なのかなっていうのを味わってみてもいいんじゃないかなっていう気がしますね。
いい本だったな。
次は何を読みますか?
次は何を読むかってなりたいよね。熟練技術者って思って。
次はアプレンティシップパターンですね。
アプレンティシップパターンは?
固定制度に学ぶ熟練技術者の技と心得ですね。
日本語の少なくともついているサブタイトルは。
今回クラフトマンシップの話をひたすらしてきたけど、
どういうふうに身につけるのかとか、どうやったら習得できるのか、どうやったら熟練の技術者に近づけるのかっていうところをきっと学べる本なんだろうなって、
まだ読んでないんであれなんですけど、思っております。
そうですね、力の磨き方とか、自分が置かれている環境とか状況からいかにして学び終えるかっていうような話が書いてある本で。
そうですね、翻訳側の柴田由悉さんですね。いろいろな名調を生み出すでおなじみの鉄板翻訳者、筆筆家の一人ですね。
本も書いてて、翻訳もしてて、この人ほんとすごいですよね。
すごいですよね。
しかもまだまだ現役でエンジニア、結構お年寄りされてるけど、まだまだ現役でエンジニアやってたりもして。
その柴田さんが翻訳したアプレンティシブパターンですよ。こんなの期待大じゃないですか。僕は一回読んだんですけど、久しぶりに読み直そうかなっていうところですね。
自分はまだ読んでないので、また2週間後までに読んできて、すげえ今楽しみにしてます、この本。
はい。よし、じゃあそんなところで終わりにしていきますか。
はい。
はい、ではまた定型文を読んで締めたいと思います。今週も放送を聞きいただきありがとうございます。ではまた次回。さよなら。
さよなら。
