ソフトウェア職人気質の導入
こんにちは、readline.fmです。
readline.fmは、つんどくが趣味の2人が、何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、ハッシュreadline.fmです。
ホスト役は、げんえいさんと金城です。
それでは、げんえいさん、よろしくお願いします。
よろしくお願いします。
で、今回は、あ、そう、BGMを元に戻して。
そうですね。
やってきますが、そうですね。予告した通り、今回読む本が、
ソフトウェア職人気質っていう、ピアソンエディテーションから出てる本ですね。
ピアソン、ピアソン、もうないですからね。
で、現代がソフトウェアクラフトマンシップっていって、あれですかね、最近クラフトマンシップっていうと、ロボ王子さんのクリーンクラフトマンシップとかがあるんで、
それを想起して話すなら、これはクリーンじゃない方のクラフトマンシップということになるんですかね。
確かに。クリーンじゃない方って、つい言っちゃいますね、これは。
で、そうですね。じゃあ、またいつも通り、時代的なところからいきますか。
今回の本も例のごとく、原著が出たのが2001年で、翻訳が出たのは2002年なので、前回読んだデスマッチと一緒ぐらいって感じなとこですね。
そうですね。だから、ゲームボーイアドバンスとかゲームチューブが出た時代ですね。
任天堂で例えるとね、分かりやすいっていうのが、我々の出た知見としては、任天堂の時系列となぞらえると、あ、大体あの辺ねって分かるってことですね。
そうですそうです。だからDSよりはちょっと前の本ですね。
ずっと任天堂の話しちゃう、これ。
やばい。
本の方に行くと、やっぱりもう一個なんとなくこの中で抑えておかないといけない。
時代的な背景としては、やっぱり2001年がアジャイルソフトウェア開発宣言ですよね。
発表されたのは2001年だったりとかしているので、
なんとなく時代の流れとしては、今までプロセスとか大事で、動くソフトウェアっていうよりもドキュメンテーションだったりとか、
そういうものを完璧なドキュメントを作って、ちゃんとしたプロセスを回していけばソフトウェアってできるんだって思われてた時代から、
だんだんとみんな、あれ本当にそうなの?みたいなものが移り変わっていって、
XPみたいなものが出てきたりとかするみたいな、そういう時代背景の中で書かれた本みたいなことを思ってもらえるとちょうどいいかなってちょっと思ってますね。
そうですね。まさにこの本の中でも科学的管理処方とか、あとは計画が高くつくみたいな話とかが出てきてますね。
そうですね。なので今回のこの本のソフトウェア職人技術っていうのは、
そういうある種ソフトウェア工学みたいなものとか、過去に挙げてた本で言うと人欠のシーマとか、
ああいうものの流れを組んでる感じの本って言えるかなっていう気がしてますね。
あとはそうですね、本の個別的な話が入ってく前に、
一旦クラフトマンシップとかソフトウェア職人技術って言ってるのが、
そもそもどういう言葉なんだっけっていうのを簡単に共有しておくと、
少しそういう話をしていく本なんだねっていうのがわかりやすくなりますかね。
時代背景とアジャイル
まず一旦この本の中では、ソフトウェア職人技術、クラフトマンシップみたいなのがすごく大事ですよみたいな主張をしていて、
クラフトマンシップってなんぞやって言うと、ヨーロッパの鍛冶屋の都定制度みたいな、
ああいうものをすごく大事にして、大規模な工場みたいなとか管理みたいなところではなく、
もうちょっと職人っぽい感じの世界観の方がソフトウェアの世界とはちょっと近いんだよみたいな、そんなイメージですかね。
親方のもとで修了して座学的に学ぶっていうよりか、見て盗むんだみたいなそんな雰囲気がありますね。
そん中で職人技術、ここでなんでそれが出てくるかっていうと、結局大使としてはそうではないやり方、
プロジェクトがあってそこに何人入れたら、これは何年で終わってみたいな、
そういうようなものに対するアンチ定制としてクラフトマンシップみたいなことを言っていると。
あとあれかな、中心的なコンセプトとしてもう一つあるのが、技芸と工学みたいな話がよく出てきてますかね。
そうですね。
この二つはどうですか、なんかそうですね、科学と芸術みたいな感じの対比も少し出てきてましたね。
そうですね、あと自分はちょっとピンとこないっていうか、どう説明すると伝わるかなみたいなとこすごく悩んで、
ちょっといくつか最近のスライドだったりとか見てて、SRE NEXT 2024でさんって方が登壇されていて、
その人が工学都市のSRE裁縫っていうところで、工学の意味みたいなところを出してたんですけど、
そこはエンジニアリングの訳語として工学だけど、
エンジニアリングって言った時には実務的と技術的な側面、実際に経験したプラクティスみたいな、
そういう見合いともうちょっとアカデミックな工学、学術的な側面みたいなのがあって、
おそらくここで言う、この本で言うソフトウェア工学の中には学術的な側面みたいな、
研究してこういう規模でこういうことをやると、こうやるとうまくいくんだ、いくはずだみたいな、
そういうような考えが工学なのかなってちょっと思ったりとかしてましたね。
なんか定量化して制御しましょうみたいな、そういうニュアンスですよね。
そうですね、人を人として扱う、個人ってよりは特命のまさに一人一人とか、そういう時の一人みたいな扱い方をするみたいな感じです。
そうですね、パーツというか交換可能な要因みたいな、逆に言うとそこにいる人が誰なんだっけっていうところでばらつきがなくなることで、
ちゃんとマネジメントしやすいとか予測が立ちやすいとか、そういうところに強みを持つというか、やっていこうぜっていうところだと思うので、
そこの対立軸として職人機質とかっていうのを打ち出してますね。
っていうか、対立軸というか結構ボロクソに言いますね。
そうですね、相当批判してますね。
相当批判してますね。
完全にソフトウェア工学がナンセンスだっていうのを100%言い切ってるわけじゃなくて、部分的に適応できるところっていうのをよく考えるべきだ、それは決して万能ではないだろうみたいなところを結構通列なスタンスで述べていて、
前描き、本人の前描きかな?本人の前描きか役者前描きかちょっと忘れちゃったんですけど、いろいろ賛否両論あるでしょう、それは知ってるよみたいなことが書いてありますね。
プロセスと職人精神の対立
それを前提にしてでも言わせてくれみたいな本で、時代背景的なさっき言ったような2000年前後に書かれているそんな本ですね。
この本を読んで通列に批判しているからっていうのもあるんですけど、思ったのが、いかにこれまで計画変調というか、ドキュメントが大事とかプロセスが大事みたいな、相当自分が思ってたよりも大事にみんな思ってたんだなみたいなところがあって、
それがいかにくだらないものなのかっていうことに対して、おそらく友田丸子だったりとか、ソフトウェア職人技術の人だったりとか、アジアル開発宣言だったりとかっていうものがあそこまで出てきたっていうのが、自分が思ってるよりも現場ではそれが大事とされてたのかなって思うぐらいには、この本がすごく批判的だなって思いました。
そういう歴史があったことは知ってるけど、そんなに深刻だったんだみたいな。
そうですね。あれがなかったら、別にあれがなかったら今こうなってないとまでは言わないけども、ソフトウェア工学として、人は一人と個人として見るんじゃなくて、何人みたいなリソースとして見るみたいな考え方をずっと続けてたのかなって思うと、結構怖いなみたいなことを思ったりしましたね。
なんかでも、いろんな消極的な側面と積極的な側面があるのかなと思ってて、消極的な側面としては何だろうな。
事前に綿密に計画を立てて、その通りにやりましょうとか、一人一人の実力差ってある程度丸められるとか無視できるみたいな、そこら辺に対するちょっと楽観的な感覚はあったのかなっていう消極的な面と、説得的にそうしたいっていうふうに働きかけてた歴学もあるのかなと思ってて、
すごい単純な話で、余日間にできないじゃないですか。計画勝手になりません。それってビジネスじゃねえよなみたいな。
で、隣を見たら工学でも、それこそ自然を相手にしてる能力とかでも高度化してやってるわけで、
いや俺たちのIT産業ソフトウェア産業だけなんかよくわからないんでノリでやりますとか、いやそれはさすがにちょっと合わせる顔がないですみたいな。
そういう理由で意図的に、よりこれから発展して大規模化していく、複雑化していく、高度化していくっていうのを見据えて、それこそソフトウェア危機が訪れるぞとか言われてたりするので。
だから計画変調というか、アップフロントにやっていくぞっていうのは、意図してそうやるべきだっていうことでやってたっていう目はあるんじゃないかなっていう気はやっぱり個人的にはしますね。
だから単純に無能だからそうしてたとか、未熟だったからそうしてただけじゃ済まない話だよなっていうような感じがあります。
自分はやっぱり歴史が短いってなると他に頼るしかなくて、過去の例を見るときに、じゃあ周りはどうやってるのかっていったときには今さっき言った通りだし、
あとはソフトウェア開発の状況の変化っていうものはすごく早いというか、いろいろ変わってきてるわけで、
多分2000年より前とかだと1人1台コンピューターがないとかいう場合もあっただろうし、
ワークステーションが1台しかなくてコンパイルしてそれを待ってる間は他の人は何もできないみたいな、だから机上でデバッグしますみたいな、
そういう状況があった場合もあれだろうし、逆に今の段々時代が進むにつれて1人1台コンピューターがあって手元でプログラムが動くようになりますとか、
トライアンドエラーの繰り返しがやりやすくなりますとか、何なら今だったらオンプレで調達じゃなくてクラウドで調達してっていうことができるようになって、
納品まで3ヶ月待たなくていいですみたいな、15分でブログが作れますってなっていって、
時代はもう全然変わっちゃってるっていう、こんだけ変わってることを1つのソフトウェアの開発っていうことで括ると、
それはやっぱり変なことが起きるような気もしていて、ここまで予期したりとか、こういう変化があって同じやり方をやり続けるっていうことは絶対できないよなとか思ったりして、
ひとくぐりに喋るのすげえ難しいなって。我々もだいぶいろんなこと知ってるからそう言えるんだよねっていうのはすごくありますね。
そうですね、後GDしか喋ってないので。
当時にもうちょっと手元でCICDを整備してとか、そんな余裕もないしそんなものもないみたいなことが全然あるわけで、ボトルネックが全然違うところにあるぞみたいなこととかもあったわけで。
そうですよね。下手したらプリント用紙よりもパソコンの数の方がオフィスの中で多いですからね。
紙でコーディングしてくださいって言われると、じゃあ紙買いに行くところからか。
そうですね、とりあえずコピー機の引き出しを開けてみたいなさ。
ソフトウェア工学の疑問
そうですね、本の中でも人間より機械の方が高かった時代がしまったみたいな表現とかあったりして、すごいわかりやすい表現だなって思いながらそのくだり読んでたんですけど、今は人間の方が高いですからね、日本的には。
そういうような時代背景も組みながらちょっと読むと楽しいというか、一概にこの本の中で言ってること全て楽しいと受け取ると、そもそもちょっと時代変わっちゃってるからそうじゃないかもねみたいなものもあるので、ちょっと注意しながら読まないとなっていう感じはありました。
じゃあちょっと本の中身に入っていこうかなと思うんですけど、一旦アウトラインだけ最初に読んでおくと、全部で第5部までの構成になっていて、第1部がソフトウェア工学に対する疑問ですね。第1部からそういうことをやっていって、第2部でソフトウェア職人機質って少し短めの部があって、
第3部でソフトウェア職人機質がもたらすもの、第4部でソフトウェア工学の位置づけを再評価する、ラストが土壇場になって行うことですね。第5部だけ少し色が違うなっていう感じはありましたね。
職人機質VSソフトウェア工学みたいな話をしていくんじゃなくて、やっぱりプロジェクトとかソフトウェア職人、プログラマーをこれからどうやって成功させていくかみたいなところで目先のことじゃなくて、本質的なところの話をするっていうようなのが第5部の土壇場になって行うことをメッセージとして差し込んできたのかなみたいな感じもしますね。
いいですよね。この流れすごい読みやすいなと思ってて、最初に問題提起をして、その後にこういう概念、コンセプトを導入するとどうだろうかって言って、その成果について喋って、その後もう一回、じゃあそういう状況になった時にソフトウェア工学って今どういう位置づけとして考えるといいんだっけ?
自分のが必ずしも優位であるってよりは、その2つを組み合わせて考えたら健全な考え方になるんじゃね?みたいな提案みたいになっていて、すごく誠実というか、ただ単に批判、もちろん批判はするんだけども、ただ単にあれはダメだクソだみたいなことを言い続けてるだけのことではないようなと思ってて、目次を読んだ瞬間にこの本結構いい本だなって思いましたね。
最初に定義した問題に、私が今導入したアイディアって、じゃあどういうふうに、結果としてどういうふうに問題に対してインパクトを与えていそうかっていうのを検討しましょうみたいな流れになっている感じがありますね。
じゃあちょっと第一部から入っていきますか。第一部とか、必要に応じて前書きとか。前書きはでもまあいいか。
さっき話した感じでいいんじゃないですかね。
じゃあ第一部、どの辺りから拾っていきますか?
これすごい、読んでて俺いいなと思って、バッと全部読んじゃって、最後にまとめて感想書いちゃったんだけど、
ここはソフトウェア工学っていうものすごく、もう一回繰り返しになるかもしれないけど、やっぱり計画だったりとかプロセスがすごく重要っていう話をしてるんだけども、
本当にそうなんだっけっていう感じのことを言ってて、すごく思ったのはやっぱりプロジェクトって様々あるけど、これ全部確実に吉田にやってくれるような万能なハウはあるのかいっていうこととかは本当にそうよねって思いながら読んだりとかをしていましたね。
あとはそうですね、その万能なのかい、何て言うんだろうな、万能じゃなくて当てはまらない場面とか、それを適用するのが大げさすぎる場面って非常に多いでしょみたいな話をしていて、
例えば1000人規模のプロジェクトでもないのに、アナリストとデザイナーとプログラマー、デザイナーっていうのは設計者ですね、を分けてウォーターフォール的にというか、
フェーズゲームなんか、このフェーズが終わったら次にデザイナーさんに渡して、デザイナーさんが仕事終わったらプログラマーに渡してみたいな感じの、画一的なその流れって本当に1桁2桁規模が違うところでも同じやり方でやりたいのみたいな、やりたいわけがないみたいなことを書いてたりしますね。
極端な話、1週間とか2週間で終わるプロジェクト、じゃあアナリストを呼んできて分析をして、それで3週間かかりますとかだったら、いや、もう設計を動かして作った方が早いんだけどみたいなこととか、全然あり得るので、必ずしもそのプロセスを絶対視するというか、ことはなんかおかしいよねっていうのは本当その通りだなと思いながら、
でも1000人とかそういう規模ですって言われると、現代の今自分が見ている周りと全然違う感覚なんだよなっていうこともちょっと思ったりしましたね。
そうですね、分からないですね、そこら辺は。ただ、重厚長大なプロセスを中規模以下のプロジェクトにそのプロセスを適用することによって、逆に効率とか品質っていうのが落ちてしまうでしょうみたいな話っていうのも触れられていて、あれですね、十分に良いソフトウェアって別の本読んだ時にも出てきた表現でしたよね。
うん、なんだっけ?
デバルコかな?グッドイーナー…いや、分かんない。組織パターンかデバルコかリスマーチかどれか。
どっかにグッドイーナーの話はあったよねっていうのは。
ありましたよね、ありましたよね。あの表現いいなって思って言及した記憶があるんですけど、この本の中でも十分に良いソフトウェアっていう表現が出てきて、かなり批判的に捉えられてますね。
それが何なのかっていうと、完璧なソフトウェアじゃなくて十分に良いっていうのはある意味ほどほどに良いっていう話なので、例えばそれって致命的じゃないバグだから見つかってはいるけど、一旦ユーザーに届けてしまおう、ディリバリーして出荷して使ってもらおうみたいな、
そういう妥当というか、バグがあるのに気づいているのにあなたはそれを出荷するんですね、そういうことをしなくてはいけないんですねっていうのを許してしまう、許容してしまう、そんな余地がソフトウェア工学的な見方の中には含まれているみたいな話が書いてあって、もうちょい補足する必要あるな。
これソフトウェア工学っていうのと十分に良い裏を返せば完璧でないソフトウェアっていうのを許すっていうのがどういうふうにつながるかっていうと、コードを書く時間とか単体テストをしっかりやってる時間っていうよりもシステムテストとか結合テストとかそっち側の、要するに出来上がったものに対して完全かどうかっていうのを事後的に検査するっていう時間の比率がすごい、ウェイトがすごい大きくなってるみたいな話があって、
それってすごいいびつじゃねーのみたいな話がこの中に出てきていて、それがイコールソフトウェア工学ではないと思うんですけど、ソフトウェア工学的な世界観の中ではそういうことがはびこっている的な話が載ってましたね。
職人的アプローチの重要性
だから十分に良いソフトウェアというアプローチの落とし穴みたいな説が出てきたりしてました。
十分に良いソフトウェアというアプローチは欠陥は不可否であるという神話を永続化させる危険な考え方ですとか、基地のバグを含んだままソフトウェアを出荷するのは良い考えとは言えませんみたいな話が14ページに書いてあります。
でも、そうするとユーザーが欲しいのは満足できるソフトウェアが欲しいわけですよね。
それこそデマルコが言ってた何千個バグがあってもフォトショップは素晴らしいみたいな話とか。
バグはないということは言わないけども、例えば基地のバグを全部潰してリリースします。ただし半年遅れますって言われても、それはそれでもっと早く欲しいんだけどってことも実際にあるからなみたいな。
でもそこら辺のあらかじめ仕方ないじゃんとか不可能だよねって最初から言っちゃうのは職人的な気質じゃないよねっていう話ですね。
だから手を抜いていいみたいに繋がりかねないとか、そもそもバグが発生しないように頭を使うとか、つまり複雑な要件だった場合に、その中で本当に必要なのってどれなのみたいな。
例えば組み合わせのパターンが爆発してしまうってなった時に、このパターンとこのパターンはほぼないんだよねとか、そういうようなことをどんどん潰していくみたいな。
そういうようなアプローチとかも、言うたらサボれるわけですよね多分。サボってバグがあるのはしょうがないし、でも動いてるから一緒みたいな。
たまに500って出てるけど一緒みたいな。そうなるとちょっと辛いって感じになっちゃいますよね。
不思議ですよね。ソフトウェアのバグをゼロでやることを証明するのは難しい、できないっていうのはわかるもの。
でも普段身の回りでソフトウェアじゃなくて、物を買う時にその物がちょっと欠陥はあるんですけど許してくださいって言ってあんま買うことってないよなーって思ったりしながら。
あれですね、レストランとか行ってメニュー表通りの食品が来たことがないなって思うと、あれはバグなのではないか。
顧客の要求を満たしてない場合はたまにありますね。確かに数はあるが。
顧客が本当に欲しかったところは。
このでっかいハンバーガーであり、お手じゃんこのハンバーガーではないみたいな。だんだんそれを受け入れて写真とは違うものが出てくるぞって学習してしまうみたいな。
そうですね、そろそろお世知の季節でもありますし。
確かに、写真と君なんか違くない?みたいなね。
そうですね、このバグがあっても仕方ないじゃん的な態度を少し攻撃しているような感じがあって、それが何でかっていう部分、この著者が考えている職人気質っていうところにすごい繋がるなと思うんですけど、
あらかじめこう決められてたやり方を踏襲したからこれでいいんですっていうようなところをすごい批判してるんですよね。
そのあらかじめ定義されたプロセスとか確率的なやり方っていうものじゃなくて、本当に一職人として自分の目とか自分の頭で必要な問題、本当に解くべき問題とか潰すべき課題っていうのを考えながら、
ちゃんとクリアしていこうよっていうような話があって、ソフトウェア工学っていうものの対立軸として表現がちょっと第三章に書いてあったのが、
状況学習とかより社会的な文脈というか社会的な場面の中でいろいろと学習して適応していくことがそこの重要性ってすごいあるよねっていうような話がページにメモってなかったんですけど書いてあって、
そこを読んで、なるほどこの人がそんなに失用にじゃないですけど、かなり思想強めな感じで批判してるっていうのはそこらへんに対してなんだなっていうのをちょっと感じたりしましたね。
そう考えるとスクラムとかって、スクラム4倍本って通称言われてる本とかでもウーダループの話が出てきたりとか、スクラムの大事なものとして経験主義の話があったりとか適応があったりとかするって考えると、きれいにそこが対立軸として捉えられてるなっていう気もしてくるなってちょっと思ったりしました。
やっぱりプロセスより対話王ですからね、プロセスより対話王。
でも一方でそれって結構その場にいる人に預けるというか任せるっていうことでもあるんで、力量がない場合にはもっと酷くなっちゃう場合もあるわけですよねきっと。
そうなんですよ、だから職人なんですよ、求められるの。
そうなんですよね。
職人というか、マニュアルとか手順に従ってこなす人じゃなくて責任を持って言える人になりなさいよっていうような話をね。
引き受けるってことですね。
いろんなものにつながりそうな感じがありますね。
ソフトウェア開発の複雑性
でもそうですね、だからやっぱり過去トムデマルコの本を読んできたりするとデータフローダイアグラムとかの話があったりとか、アナリストがいて完璧なプロセスと成果物をこれを揃えてこの通りに作りましょうみたいなことをやってたけど、やっぱあれじゃうまくいかねえなっていう方針転換があるっていうのもやっぱり感じられるし。
この本でもトムデマルコが引用されてたりもするし、そのあたりに対する限界というか、うまく機能しなかったなっていうことをすごく実感したんだろうなっていうのをやっぱり読んでて思いましたね。
ある意味職人のクリエイティビティとか上等に対して卒業的なアドリブリアルみたいな感じっていうのが不可欠だよねっていう話になっていくはずなんですよね。
完璧で万能なプロセスっていうのを発見していくっていうのはある種諦めましょうみたいな、それを諦めざるを得ないぐらいソフトウェア開発、そういうプロジェクトって複雑だよねっていう話をしてて。
なんでソフトウェア作るのこんな難しいのかみたいな話が出てて。だって要求を出してくるのが人間なんだもんみたいな。
完璧な要求っていうのを引き出すのが不可能なので、それに従って対応するものを作るっていうのは同じぐらい複雑になるみたいな。
第2章の11ページ、12ページに書いてあった話が分かりやすいというか、好きだなぁ、おしゃれだなぁと思ったんでちょっと紹介したいんですけど。
1個の文章がありますと、メアリーは1匹の小さな羊を飼っていたっていう文章にするとこれだけなんですけど、これどこを強調して読むか捉えるかによってなかなかニュアンス変わってくるよね的な話が紹介されてて。
例えばメアリーっていうのを強調して、1匹の小さな羊を飼っていたって言った場合には、この羊の所有者がメアリーであることっていう側面をすごい強調してるし、
小さな羊を飼っていたっていうところを強調するのであれば、この羊の特性というか特徴として小さかったことっていうのを強調してるし、飼っていたっていうのを強調するとまたニュアンス違ってくるよねっていう話が書いてあって。
要するに我々が普段やってる要求分析。
チャットとか口頭で話して、要するにこれを作ればいいんですねってまとめ直す作業ってここなんですよね。
防線が引いてあって筆者の気持ちを考えなさいだけでも難しいのにセンスが引いてないみたいな。
好きなところから好きな方に気持ちを図りなさいみたいな。
そのぐらい曖昧なところを相手にしてるので、ソフトウェアプロジェクト難しいよなっていう。
そうですね。
でも別にソフトウェア以外もみんなやってんじゃねえのって思うと、ソフトウェアだけは特殊なのかなって思っちゃったりするけど。
確かにね。
朝ごはん買いにスーパーに行って食パンを買うってなったときも、食パンですら選択肢がたくさんあって。
なんとかパルトックスって言った気がするけど、行ったらその隣に美味しそうなクロワッサンがあって。
そうだ俺クロワッサン食べたいなって思ってクロワッサン買っていく場合もあるわけじゃないですか。
ぐらい要求ってものもそもそも気分で変わっちゃう可能性もあるし。
もちろんソフトウェアITしてるのはもうちょっと業務プロセスがあったりとかするんで、もうちょっとコンテキストが限定されたりとか、気が変わったからとかいうことではあんまりコロコロ変わることはないと思うんですけど。
法律が変わったりとか、その社内のプロセスが変わったら、それに合わせてまたソフトウェアも変わる必要があって、みたいなことは多分起きるっちゃ起きると思うんで。
難しいよねっていうのは、他も難しいんだろうけども、ソフトウェアの柔軟さとか、何ならオーバーして作ってもらってるっていう部分もあると思うんで、叶えてほしいみたいな部分もあったりするんだろうなとかちょっと思ったりしますね。
要求分析の難しさ
難しいはずと信じたいっていうのは我々が調子乗ってるだけなのかもしれないですね。みんなやってるんだからつびこび言わないでやれみたいな。
難しいのは、他の分野でも同じようにやってるかもしれないけど、言ったなざが無かったりとか、ソフトウェアのようにオーダーメイドでやってるっていうよりは出てきたものから選んでるだけっていう場合もあったりするかもしれないんで。
本当に客の要求を引き出していって、結果全然違うものが生まれるみたいなことは多分いっぱいあるんだろうなとか。なかなか個人が向上相手に発注するっていうことはないだろうし。
でも確かに自分で言いながら、しかしみんなどうやって要求を引き出してるんだろうみたいなことはちょっと今、突然出てきたけど、どうやってるんですかね。不思議ですね。
どうやってるんですかね。要求を引き出すか、表現するか、合意を取るかみたいなのも、それは別の工学として、要求工学っていうのが当たりしますからね。
あと要求が本当に完璧な要求っていうのがよくわからないですけど、仮にそういうものがあったとしたら、じゃあそれは銀の弾丸になるのかみたいな話も出てきそうですね。
誰が見ても同じものを作ってくれるであろうようという定義というか記述ができれば。それはAIが奪っていく仕事だな。
でもなんとなくそこで完璧にちゃんと書けばとか、これは誤った解釈がされるから、誤った解釈がされないように記述できればみたいな。
こういう発想を持っていくと、ドキュメントから自動的にプログラムを起こしたりとか、そういう願望に変わっていったりとか。
現代風に言えば、それを見てAIが自動的にソフトウェアを作ってくれるみたいな。いう風に発想していくっていうのは、気持ちはわかるなって気持ちがだんだん。
昔は何言ってるんだって思ってたんですけど、本当にそれを信じていったら、そっちの方に行くかもなって思ったりしました。
GitHubが出しましたからね。いい感じにやっていいって言ったら、いい感じのソフトウェアを作ってくれるって言って。
間違ってるところとか、手直ししたいところは自分で、さらにそこから手を加えてみたいな。
だんだん壁打ちをしながら、自分が本当に欲しいものとか、その要求みたいなものを言いやすい時代はもしかしたら来るかもしれないですね。
そうですよね。本当にラピットデベロップメントとかプロトタイピングとかって言ってるやつの次の次元というか、そういうものになっていくんだろうなーって感じもしますよね。
そうなってくると、ソフトウェア工学ってどういう風に位置づけられるのかなとかは、ちょっとこの本を現代に読んで、現代風にアップデートするんだったらどうなるんだろうとかは、
自分の中で答えはあまりパッと出てないんですけど、ちょっと思ったりとかもしましたね。
要求工学はロストテクノロジーになるかもしれないですね。
すごくうまくいくと、そういう風に向かうかもしれないし、
プロンプトハックで生き残るのか、LLMを作り方の方に行くのか、そこから何を聞けばいいのかを見つけ出してくるみたいなことなのか、どういう風にいくかちょっとわかんないですけど。
面白そうな、ゲームチェンジが起きそうな感じはありますね。
そうですね、そうですね。
エクストリームプログラミングの視点
第1部でいうと他に触れておきたいところは、あれか、メタファーっていう話が出てきますかね。
例え表現みたいな、ソフトウェア工学よりも適用可能性のあるメタファーを探るっていう、このメタファーっていうのをすごいキーワードにしてますよね、この著者は。
なんでなんだろうな、だから職人気質っていうのが1個の正解ゴールではなくて、何か言おうとしてることを例えの力を借りて職人気質っていう風に表してるんだろうなっていう気はするんですけど、
だからその意味で言うとソフトウェア工学っていうのも1個のメタファーとして見てるし、いろんな〇〇っていうメタファーの中で、より強く生き残りにつながりそうなものを探っているような感じがあり、
第4章が本当に章のタイトルがソフトウェア工学よりも優れたメタファーを探るっていうふうに書いてあって、
この章はXPとかの話が出てきて、XPとはどんなものかっていうのをこの本なりの観点というかアプローチとして見てるのかっていう話が出てるんですけど、
なんかすごい象徴的だなと思っているのが26ページ4章の第1節の冒頭の部分で、エクストリームプログラミングは様々な意味でソフトウェア開発が科学であるか工学であるか芸術であるかという議論を再認させました的なキュラリがあって、
ソフトウェア開発が芸術であるかとか○○であるかって当然本来はそんなわけがないので、メタファーとしてそういうふうに表現されてる。
で、俺たちがいつもやってるこれって何の性質に近いんだっけっていう議論をXPが再認させたよねなんて話をしてますね。
ここまである種多分IT業界を巻き込んでこういうような議論をできるようなものって今後出てくるのかなっていうぐらいにはやっぱりここがすごく分岐点なんだなっていうぐらいには研究されますねあちこちで。
XPですね、ケントベック誘惑ソーシャルチェンジということなんで、社会プログラミングとかいかにして行動格化じゃなくて、よりにチームとか組織とかものの考え方とかそういうのを含めて広い範囲の変革、ソーシャルを変えたんだみたいな話をね、ケント君が言ってるわけだ。
そこが俺は最初読んだ時に全然そういうことを知らずに、なんかいい設計手法みたいなの書いてあるんやろうみたいなぐらいの気持ちでパッと読んで、8とか原則とか言われてもなんかあんまりピンとこねえなみたいなことを思いながら読んじゃったんですよね。
だからみんな褒めてるけど何がすごいのか全然わかんねえなみたいなことを当時は思ってましたね。
あれですかね、シロ本ですかね、エクストリームプログラミング、入門。3週ぐらいしないとわかんないですよね多分。
そうですね、てか周りになんか解説してくれる人とかそういうコミュニティの触れる機会があると多分きっかけみたいな、あ、なるほどここからこう読んでいくんだとか、こういう考え方として一旦読むんだみたいなのがあるんですけど。
技術書類みたいなコーナーにあって、プログラミングの本読んでると同じような感覚でパッと手に振って、なんかペアプログラミングみたいなの知ってるけどさ、そんなに違うかなと思ってたら、今となってはもうなんかそういうことですねみたいな気持ちになりながら読む本です。
そうですね、社会のあり方変えるっていうと本当にその前とその後で全然世界が変わるっていうか革命的なものなんだ、エクストリームがそれを引き起こしていくんだっていう感じですもんね。
読む前の生活考えられないなみたいな。そういう話がありつつ、ソフトウェア開発、プログラマー、エンジニアリングって、あ、そっか、エンジニアって言うと少し紛らわしいのか、この本の文脈だと。
そうですね、エンジニアリングって言うと工学っていう話になっちゃうんで。
ソフトウェアを作る生業の人っていうのが何に近いんだろうっていうと、伝統的な職人の持つ技術と近いんじゃないかっていう話が、この第4章ソフトウェア工学よりも優れたメタファーを探る。
職人技術の重要性
要するにソフトウェア開発に携わる人はどういうふうにあるべきなのかっていうのを例えて言うんだったら、ソフトウェア工学的な管理手法、科学的管理手法的な考え方よりも伝統的な職人との類似点がよく見られるぞっていうのが4の2で吟味されていくわけですね。
伝統的な鍛冶屋って言われてもわかんないんだよなっていうのと、日本のイメージとしてはもちろんあるけども、実際鍛冶屋の人どうやってるかわかんないなとか。日本の文脈に例えると、後継ぎいなくて大変らしいなとか。
一回盛り上がってるんだなぐらい気持ちにはなるんですけど、きっと弟子がいて職人がいて、それを教えてもらいながら、教えてもらうって言い方をするとあれだった気がするけど、そういう弟子と師匠みたいな関係があって技術を受け継いでいくみたいな。そっち側っていう感じなんだろうなってことだけはイメージでいけますよね。
たぶんその師匠によって流派があったりとか、場所によってやり方が似てる部分もあるし、全然違うやり方を取っているとか、その場にある道具とか材料とかによってうまいことやっていくみたいな。そういう意味でも確率的な方法にするってわけではないっていうこともあるのかなっていう気もしますね。
そうですね。第一部がそんなところですかね。
そうですね。第一部は本当に、たぶん職人技術っていうことに一旦は落ち着いてるけど、もっといいメタファーがあればそっちを採用するみたいなことでもあり、職人なんだっていうことではなく、それに似ている何かなんだっていうことが結構大事そうな気がします。
そうですね。もうちょいニュアンスを勝手に付け足すなら、なんていうか、少なくともソフトウェア工学ではないだろうって言いたそうにしてるなっていう感じがしますね。それよりかは幾分かもしれないのは職人じゃないかみたいな。
そうそう。これが一方で、職人って言ってたんで、職人とはこうあるべきで、だからこうしないといけないんですみたいなことになると、批判してたプロセスと批判してたように全く同じことやってるやんけみたいになっちゃうから、そこまで厳格に鍛冶屋の職人がこうやってたんで、私もこうしますみたいな。
いうことをしてほしいってわけではないんだよなっていうところは、私はちゃんとしておかないと。
そうですよね。いや、鍛冶屋の職人はそんなことしないでしょ。めっ!って言われても。いや、はーみたいな。
まあ別に俺ら鍛冶屋じゃねーしなんてことにしかなくて。
