ソフトウェア開発における「基準」と「意思」の重要性
基準っていうのがどういうものなのかっていうのは、まあ最初の方にチラッと振れてるからいいか。
期待値というか、ここは満たしてほしいなみたいな。
基準、あれかな、第2部の扉見てみると、基準はベースラインとなる機体だ。決して超えてはならないと決めた境界線であるってやつですね。
だから自分の中でのこれは最低限やるべきこと、スレッショルドなのかスタンダードなのかは、あれですけど、自分がプロとして働く以上はここは譲れない、実体に満たそうと決めてるもの、みたいな話ですかね。
そうですね。
それを期待っていう言い方にするのか、綺麗な言葉遣いで。で、その次のページを見ると、クソを出荷するなと書いてあると。
まあギャップがね、やっぱ人に響きますからね、ギャップっていうのは。あれですね、自分がいいなと思ったのは、10章の品質のところで、紙の本で言うと240ページなんですけど、
時間の経過によってソフトウェアを良くするために何が必要だろうか、それは意思だっていうふうに書いてあって、当たり前なんですけど放置してたら良くなるってことはないんで、内部品質みたいなところとか、
それもしかしたら、顧客にとっての機能をより良くするという意味での品質という方をとってもそうですけど、改善しようと思わなければ改善されないんですっていうことがあって、でも本当にこれなんだよなって思ってて、
リファクタリングしたいですって言うけど、じゃあ勝手にやったらいいんじゃないとかっていうのを思ったりするんですよね。それって強い意思があって、このコードは許せないとか、こんな複雑なコードありえないでしょ、俺が良くしてやるよって思ってる意思がある人ほど勝手にどんどんやってきてソフトウェアが改善されていく。
そうじゃないと多分現状が変わらない。何なら悪くなる。悪くなるっていうのは言語のバージョンアップとかによってその書き方が古くなったりとか偉いになってしまうっていうことを考えたときにどんどん悪くなっていく方向はあるので、それに対抗するためには何が必要なんだっけって考えると、意思なんだなっていうことをすごく強く感じましたね。
やる気こそ成功の秘訣ってことですか?
そういうことになっちゃいますか。
成功の鍵か。
トムデマルコ、ピープルウェアより。
「恐れを知らない能力」と変化への挑戦
リファクターしていいですか?確かにここ数年聞いてないな。職場がそういう感じだからってのはあるんですけど、何というか、必要だからやるんですよみたいな。境界線を疑わなくなってるみたいなところはあるかなとか今話し聞きながら思いました。
あとはあれですよね、多分我々は結構プログラミングを書いてきたから、どれくらい力を入れていいのか、力の加減みたいなものが多分わかってきたっていうのはあるはずで、昔リファクタリングしたいですって言ったら、リファクタリングって呼んでるのは実はシステムを丸ごと書き換えたいですっていう話だったりとか。
ここを丸ごと、なんとか言語で書き換えたいですとか、蓋を開けると実際やりたいって言ってることの中身はなんだろうとかって思ったら、これはもう古いやり方なんで、AWSのあれに乗せ替えたいですとか、話が結構大きかったりするんですよね、リファクタリングの中身が。
本当にそこまで頑張る必要があるんだっけとか、仮に例えばそれの作業に1ヶ月かかりますかって言われて、1ヶ月遅らせてまでそれをやる必要があるんですかって言われると、説明ができなくて、リファクタリングをやらせてくれなかったからこうだっていうふうな話になるっていうのは、過去自分もやったことあるし、そういうものの言い方を。
っていうのはあるけど、だんだんだんだんわかってくると、なんかここが鍵になりそうで、ここ直しておかないと機能追加無理だなとか、こっちはまあ最悪このまま塩漬けにしとけばいいなとか、だんだんだんだんそういう判断ができるようになってくると、多分勝手にリリースに間に合うように直していく、必要な構造の見直しは勝手にやっていくよってことができるようになっちゃったんじゃないかなっていうような気はしてますね。
ここら辺を切り離したいなーみたいなところまで、浮かぶのがセットというか、あとはやるだけだなーってところから始めますもんね多分。
いや、そんなことはないな。なんかめちゃくちゃ読んでて、ここなんだっていう時代を踏んだりはするか。
でも結局多分実際自分たちが直そうとか着手しようと思った時って、なんかその対象を十分に理解して、何がひどくて何がひどくないのかみたいなことが見えてないと。
で結局直して不具合が出ました。これやっぱりいらんことしないといけないとかって言われるわけじゃないですか。
そうっすね、書き換えてみたけど思ったより良くならねえなっていうのを同じぐらい、もしかしたらそれ以上に体験してるからっていうのもある気がするな。そのネガティブケーヴァビリティみたいなの多分あるじゃないですか。
ありますあります。
ここは直感的にちょっとムムムって感じだけど、多分今のビジョンと知識で書き換えても、多分そんなに気持ちよくはならんぞとか。
ここは今見ると広いコードだけど、こうなった経緯がなんとなくぷんぷんに寄ってくるみたいな。
めっちゃわかるめっちゃわかる。あの仕様が追加されて、さらにその次にこの仕様が追加されて、順番に書いていくとまあ確かにこんな感じになりそうだなみたいなとかね。見ててだんだんだんだんわかってくるみたいなのがありますからね。
素朴にやるとそうなるよねみたいなのいっぱいありますからね。
そうだよな。
悪くなる一方だし、基本的に仕様を追加すると複雑になることの方が多いので、よくするためには皆さん強い意思を持って勝手に書き換えて失敗して、本当にインクリティカルな失敗はやばいですけど、フィーチャーとグルなどを主流に使って失敗していきましょうという気持ちですね。
そうね、品質っていう章ですからね。でもその次の説が恐れを知らない能力っていう風になってて、まさに下手に変更すると良くないんじゃないか、よし見てみぬフリだみたいなのをやめろって書いてあるんですよね。
それはわかるぜって思った。わかるがしかし。
そう。
だからどうなんですかね、僕が足りてないのかな。
この恐れを知らない能力を読みながら思ったのが、十分に理解してると、こういう可能性があるかもしれないとか、ああいう可能性があるかもしれないって言ってやっぱり手が出せないみたいな問題で、組織の中に長くいるとあって、
でも一方で新しく入ってきた人が、え、なんでこんなになってるの、これ直せるじゃんってピュッと直して出しちゃうみたいなことがあって、それはたまたま事故が起きてないっていうだけの話かもしれないけど、
そういう突破力みたいなものっていうのは、長くいるともしかしたら失っていくのかなっていう気持ちを思いながらこの恐れを知らない能力っていうところをちょっと読んでましたね。
でも恐れを知らないでいることを期待するって書いてあるんですよね。
そうなんですよ。
いやだからそうだよなぁ、ここはあれじゃないですか、チームに持ち帰って話してみると非常に面白いんじゃないですか。
だからあっちから近づいてきてる電車のことですか状態になってるって話ですよね多分。
そうですね。
いやでもまあ確かにな、究極的にはあれじゃないですか、システムって変更を加えるからある種不具合が起きる、既存にある不具合っていう話はちょっと置いといて、
仮に不具合がないシステムがあって、それに対して変更を入れるから不具合が発生してしまう。
でも偉い人はこう言うわけですよね、不具合なんか出してないで絶対に不具合を出すなみたいなことを言ってくるけど、
でもそれ究極的に言うと何も変えないっていうことが一番いいんだよなってなるんですけど、
でもそれをやってるとビジネスで負けていくんで最終的には良くないってなっちゃうんですよね。
そういうリスクを背負った上でチャレンジした方がいいのかなっていうことまで考えると、
そういう不具合が出てしまうかもしれないような恐れっていうのを乗り越える必要があるよっていうことなのかな。
でももっと多種多な話か、普通に。
それはそう思います。
品質への妥協と「バグがあって当たり前」という現実
例外が出てうわーって気持ちになって落ち込むとですね、次でプロデュースするのちょっと怖くなりますからね。
そうっすね、エラーになるとか本当に思わぬところで例外が出るとか減ってきましたけど、
うわーなんか悪意理が重いみたいなとかはね、あったりしますからね。
品質のところで言うとその次にあるエクストリームな品質のところの2行目からのここもグッと来るなーって思ったのがあって、
読み上げると、我々はいつからバグがソフトウェアの特性であると受け入れたのだろう。
我々はいつから一定レベルの欠陥があるソフトウェアを出荷することを受け入れたのだろう。
みたいなことが書いてあって、そんなこと言ってもさーみたいな風にももちろん思うんですけど、
この視点から捉え直したことは確かにあっただろうかっていうのはちょっと思ったりとか、
タリアの中で本当にゼロからほとんど自分ばっか書いてますみたいなプロジェクトの時とかは結構、
自分がコードレビューすればバグは一個も出ないみたいな状態には近づいたことあるんで、
こういうのはわかるんですけど、なんかここら辺はすごいですよね。
短期と傲慢が続いて離されてるなみたいな感じが。
こういう試行実験をしながら、じゃあチームでどういう風にやっぱり今、
これはそんな誰も使ってないし、後回しでいいよねとかいう取り味をしてるものを、
もうちょい違った視点で見て、こういうものが生まれてしまうのをまず咳き止めるためにはどうしたらいいんだろうねとか、
いう話の仕方とかやっていくと結構面白そうだなってちょっと思いましたね。
ある種不具合ってもので、誰も使ってない部分とか、
誰も使ってないんだったら機能消せっていう話でもあるかもしれないけど。
そうそうそう、それみたいなバグですからね。
例えばフォントサイズの指定が1ピクセルずれてましたと、
1ポイントずれてましたって、じゃあこれ誰が困るんだっけみたいなとか、
いうことを考えた時に、そもそもそれをバグとして取り扱うのかどうやったら生まれないようにできるかみたいなことを考える時に、
今までだとちょっと間違えちゃった、じゃあでもこれどっかで直そうねって言って、
バックログの後ろにどんどん追加されていって、たまり続けるみたいなのをどうやってコントロールしたらいいんだろうね、
なんかそれを受け入れると、ある種優先度低いやつはもうやらないってことではないとは言ってるものの実質やらないになってるよね、
みたいな状態とかが起きてるっていうことをどうやって解消しようかなっていった時に、
こういう視点があるといいのかなっていうのはちょっと思いますね。
エクストリームプログラミングと品質の変質
バグがあって当たり前だと思ってませんかなんてなかなか言ってくれる人いないですからね、
ボブおじさんぐらいしか言ってくれないですかねこんな。
言われたらバグがないソフトウェア作るのは無理なんだよっていう話をついついしちゃうからな、
それ相手が分かってないからそういうふうに説明するんだけど、
でもボブおじさんは知ってて言ってるからねこれは。
バグがあるのを受け入れてますよねって言われたらやっぱりこう引っかかるというかムムってなる部分はあるわけじゃないですか。
いくらでも言い訳できるしね。
いくらでも言い訳できるし、確かにこれ今の自分の振る舞い方、あり方ってバグを受け入れているっていう状態だと言われたら指定できねえなみたいな、
そう思っちゃってる部分があるってことなのかっていうところにちょっと傷つきながら読んでました。
まあでも確かにな、上司に言われたらムカつくんだろうなこれ。
なんでバグ出てんの?全部テストし…スレいいじゃんとかって言われて、
全部とはみたいなこうパーフェクトソフトウェアを頭の中でチラつかせながら。
でもそれを縦にそういうこと言うんじゃないっていう話だったよなあの方も。
全部テストを全部証明しろとか、それライクストラの前で同じこと言えんの的なこと言っても何も始まらないわけですからね。
喧嘩は始まるかもしれないけど。
いい方向には進まないですからね。
ここの説のタイトルがエクストリームの変質っていう風に書いてあって、
なんかこの言葉使いは好きなんですよね。
このエクストリームってやっぱりエクストリームプログラミングとか、
やっぱりデプロイは多ければ多い方がいいぜじゃないけど、
1週間に1回リリースしようぜみたいな話とかは、やっぱりすごい極端だったわけじゃないですか。
そうですね。当時の考え方ができればもう極端だったわけですよねあれは。
設計して実装してQAフェーズでテストしましょうとかって言ってたのを、
なんかペアプロで話せながらやればレビューもできるんじゃねえとか。
エクストリームの変質に対するこのエクストリームっていうのは本当にバグがゼロであるみたいな話になっていくんだろうなっていうところも含めて、
すごい短い説ではあるんですけど、面白いなって思いながら読んでました。
いいですね。
バグがないのが品質ですかっていう別の話は出てくると思うんですけど。
品質って難しいですからね。
だとしたらゼロ度のコードが一番品質が高い。
そうなんです。
俺はよく言う、機能作らないのが一番バグ読まなくていいんだよって。
「機能を作らない」こととリスク
ゲインさんってコード書きたい人だと思ってましたってこの間、昔の同僚に言われて。
別にコード書かなくて問題が解けるんだったら別に俺それでいいと思ってしたよなっていう話をして、意外って言われました。
マジでレプロしなかったら障害基本起きないからな。
そうなんですよね。そうなんですよ。
AWSが落ちるとかクラウドが落ちるとかそういう部分あるかもしれないけど、変更したことによる不具合っていうのはもう安定化としているものでは起きないですからね。
だからエラーバジェットとか余りすぎるのも良くないみたいな話も出てきますからね。
そうなんですよね。だから結局チャレンジしないっていうことが一番のリスクだっていうことになっちゃうんですよね。
目先の目標と遠い目標を合わせた時に突然変えてくれって言われてもいや無理っすみたいな。
いやもう手順書はないしみたいな。このアップタイムすごい長いサーバーはもうどうしようもできませんみたいな世界がやってきちゃうんで。
そのためには日頃から常に変更され続けている状態にならないと辛いですよね。
勇気、見積もり、そして「NO」と答える技術
そうですね。まあそうだな。第3部の基準は他なんかありますって言ってもあと第11章の勇気だけか。勇気はやっぱりXPだなー感はありますよね。
そうなんですよね。そこから来てるでしょって思いながら。やっぱ見積もりの話はどこ行っても出てくるなっていう感じはしますね。
見積もりの話とそこに続いて出てくるNOと答えるみたいな話も最近よく聞きますね。
キノコ本でも宮沢さんがNOっていう話をしてたし、最近だとアキさんがNOを伝える技術みたいな本を出してた気がするし。
アラインドは基本的にずっとNOと言ってましたしね。
そうですね。だからまあ全部イエスっていうのがいいことではないんだよっていう話ですね。
イエスなら誰でも言えるみたいなことまで書いてましたよね。
そうなんですよね。NOって言った瞬間にじゃあどうするのっていうこと言われるようになっちゃうから。
それ考えないといけないっていうのは、イエスもが楽っちゃ楽なんだっていうそういう意味では。
ハードワークしないといけないのは両方一緒かもしれないですけどね。イエスもの。
11章意外とあれか。ページ数は少ないのか。
そうですね。
TDDの話終わったらめっちゃテンポ良くなってんだよなこの本。
まあソースコードがあったからっていうのが一個あると思うんですけど。
後ろにいくにすれてなんかすげえもっと読みやすい本になるなみたいな。
だからTDDの方は知ってるから多分読みやすいっていう方で、後ろ2部3部の方はテンポ良く読めるなっていう本になっていきますね。
「倫理」の章：ソフトウェア開発者の影響力と責任
第3部何しますか。
第3部いきますか。
継続的挑戦的学習の話が今の勇気の章にあったけど、まあいいか。出してもいきますか。
まあみんな勉強しましょうねって話はどこでもしてるからいいかなって思っちゃって。
そうですね。
で、3部が倫理で。自分がこの本買った理由もこの倫理っていう話してる本あんまないからなと思って買ったっていうのをすごく覚えてて。
一番楽しみにしてた部ですね。
一番短かったですけどね。
そうなんですよ。
あっという間に終わって。
届いてパッと開いてあれ?なんか思ったのとちょっと違ったなみたいな。もうちょっと話してるかなと思ってたんですけど。
いやでもなんか一番やっぱり読み応えがあるというか、この本のここまでの第一部第二部で積み重ねてきたものの上でこの話がある。
ちゃんと繋がってる話として倫理が語られてるっていうのはなんかすごい印象深いなって思いながら読み終わった後に思ってましたね。
ですよね。
倫理はどんな話でしたかこの部は。
そうですね。倫理はやっぱりソフトエンジニアの影響力っていうものがとても大きくなっているので、悪いことはしないようにしましょうと。有害なこととか誠実でありましょうとかいうような話が出てくるって感じでしたね。
それであれですね、序文というか最初の方から語られてたインシデントというか社会的な問題になったこういう事故が実はソフトウェア開発プログラマーによって引き起こされてる的な話とか。
そうなんですよね。で、やっぱり社会的にエンジニアってものがある種オタク、物好きなものがあったものがどんどん社会の中心になっていくよという話とかもあって。
なんか結構自分はこういう語り口好きだなっていうのが、映画とか小説でも何でもいいんだけど、社会的にエンターテイメントとして重要されているものの中でどういうふうにソフトエンジニアが表現されてきたかっていう話がこの本に載ってて。
1983年のウォーゲームとか、86年のショートサーキット、93年のジェラシックパーク、99年のマトリックスっていて、全部この映画にはソフトエンジニアが描かれているんだけど。
だんだん年を減ることによって、ソフトウェア開発者ってものがまずそもそも作品の中に描かれていくようになるし、悪いやつだったりいいやつだったりとかっていうふうな表現のされ方をして。
そういうようなことを見ていくだけで、この時代感においてソフトウェアってものがどれぐらい大事なものだったのか、ないしは珍しいもの、物好きなものだったのかみたいなことがわかっていくっていうのは。
この本の中ではこういう作品を取り上げたりしてるんですけど、それ以外にも世の中のものを語るときにこういう表現の仕方ってすごいいいなと思ってて、すごいこのやり方好きだなって思ったりしましたね。
歴史的視点とプログラマーの社会的認識の変化
そうですね。すごい熱量で語ってますよね、ここ。文字数的な意味でも。
そうそう。
その前段で歴史的なコンピューターチューリングが出てきてみたいな話から、時代をパッパッパーって振り返っていくのも、僕はこっちも好きでしたね。それぞれの壁に刺さってる感じが。
やっぱね、今の物事を見るのに歴史を振り返るっていうのはいいですからね。そうすると今どういう、なんでこうなってるのかっていう説明がすごいつきやすくなるというか。
そうですね。
1960年の時にIBMは700シリーズを140台販売したとかって書いてあって、140台とか普通の企業が新卒140人にコンピューター与えますみたいになると、一瞬でそこで同じ台数だけ売れるんだよなと思ったりとかして。
確かに世界中のコンピューターの数と、そこそこ大きい企業の常質が扱ってる数が同じみたいな。
全然時代が違いすぎるよな。逆に言うとそれぐらいの人しか触ってなかったっていう時代なんだなって思うと、超レアじゃんみたいな。
職業として見なされてないんじゃないみたいな。実際なんかありましたよね、どっか職業として。プログラマーっていうのが。
最初の方かな。この部でしたっけ。
オランダのエンジニアがプログラマーって名乗りたかったけど、ダメだったみたいな。ダメって言われたっていう話がどっかにあったけど、最初の方だったかもしれない。
それぐらい、あんまりプログラマーっていうのが知られてないっていう感じ。ダイクストラか。
ダイクストラは数学者でしたっけ。
そうですね。結局そうなっちゃったっていうのがありましたね。理論物理学者という肩書になってたっていう。プログラマーにしたかったけど。
理論物理学者めっちゃかっこいいけどな。
かっこいいけど、本人としては納得いかずっていう。
そういう問題ではないっていう。
プログラマーのアイドル性：マイクラ開発者の事例
っていうように、ソフトウェアを開発してる人たちの影響力ってものが全然変わってきたんだよっていう。
この中でもマイクラのソフト、マイクラ作ってる人が子どもたちからサイン求められるとかってあって。
そこを痺れましたね。
プログラマーでサインくださいって。もちろん著者だから本にサインくださいっていう話はあると思うけど、
あのプロダクツ作ってるんですか。サインくださいって。あんまり確かに普通はなんないよなって思いながら。
でも、このとこでは子どもがやってきて、プログラマーってのはすごい人なんだ、アイドルなんだっていうような扱いを、
ヒーローになるんだっていうような扱いをされている。
俺その場にいるんだけどなって言って、ボーボー寺さん書いてましたね。
俺も一応有名人なんだけどなみたいな気持ちになりながら隣に見てたって書いてあって。
ここいいよな。少年なんか、これジェブさん?ジェフさん?
なんて読むんだろうね。
ジェブさんかな。
少年はジェブにサインを求め質問ゼミにした。彼の身にはジェブ以外誰も写っていなかった。もちろん私もそこにいた…
まあ言葉知らないだろうな。
それもあるんですけど、単純にプログラミングできる、ハッカーだ、プログラマーだ、かっこいいじゃなくて、
本当にネームドというか個体として識別されてこそのアイドルじゃないですか。
野球選手かっこいいじゃなくて大谷翔平さんだってなるみたいな話だと思うんで。
そうっすね。
なんかそういう意味でも、プログラミングすごいとかプログラマーになりたい超憧れてるだったら、
たぶんボー寺さんも気づいてたんじゃないかな。12歳で知ってたかわかんないですけど、その可能性もあったけどそうじゃないぐらいの女性な少年ですら、
マイクラの産みの親すげえ超かっこいいイケてるっていうのがアイドル性を帯びてるってそういうことかなと思って。
確かに確かに。
プログラマーでさらに日本で今プログラマーっていうのは人気な職業にもなり、
たぶん有名人みたいな人いてカンファレンスに行くと会えるみたいな感じもあったりするから、どんどんその傾向が強くなってるような気もするんだよな。
ソフトウェア開発者の影響力と倫理観の自覚
憧れると一緒に働けなくなるから憧れるのやめましょうっていうしかないのかな。
それ言った人とは一緒に働けないだろうからなどっちにしろ。
このショーというかこの部は本当にパンチライン的な訴えかけてくる言い回しとかも多いですよね。
ソフトウェアっていうのはこんなに世界的に影響力を確かに獲得してきた。
社会のルールとしてソフトウェアが一つOSみたいに組み込まれてるってなってくると、
ソフトウェア開発者の皆さんは世界のルールを作っているのは自分たちっていうふうな自覚を持っているだろうかみたいな話とかも出てきたりとか。
パッと今ちょっと連想したんですけど、厳密にコンピューターの歴史で考えたらもうだいぶ長いっちゃ長いんですけど、
このみんなが使うようになってっていう時代から考えた時に、
みんながiPhoneとかスマートフォンを持ち始めてから15年ぐらい、2010年ぐらいから15年って考えた時に、
業界の歴が浅いからそういう影響力に対してあんまり自覚がないんだみたいなことを仮に考えたとしたら、
車社会の時って自分たちが作ってるものが人を殺してしまうかもしれないとか、
事故が起きたら乗ってる人が死んでしまうかもしれないみたいな、
そういう倫理観みたいなところってどれぐらいでみんな自覚するようになったのかとかってちょっと気になるなっていうのを思いましたね。
車の前って馬なんですかね。
馬ですね。馬ですね。
馬か。
なんか身体的な増幅があるっていうのは想像しやすいかもなーっていうのはあるかもですね。
わかりやすいですからねやっぱり。
めっちゃ早く動いてるけどまあしないやろうとはならんと思うんですよね。
直感的にわかる。そうだねわかるしね。
あとアナログだからこう仕組みがわかりやすいアナログだからまあちょっと今の今のコンピューターはコンピューターの車はコンピューターいっぱい乗っとるやろうみたいな話あるけど、
まあ仕組みがある程度。
その話は出てますからね。
仕組みがわかるからなー。
なんかでも確かにこうね人命とか社会的な本当に経済規模的な意味でめっちゃでかいインパクトを与えているような新しい産業とか業界っていうのは多分過去にも何度も出てきてますもんね。
そのはずだけどワールドワイドにこう聞くっていうのはでかいのかなやっぱそういう規模感ではなかった今までなかったっていうことなのかな。
っていうのとあとあれじゃないですか資本がある人じゃないと参入しづらかった気がするんですよね。
その重工業になってくるとに対してねあれじゃないですか大学の電源を拝借していって車庫とかでどうにかなってたわけじゃないですか。
そうですねガレージでできたりとか大学の中でやってDIKサイトを作ったら何十億人が使うサービスになりましたみたいなその間にはだいぶ飛躍あるやろっていうことはあるけども。
そうですね座を取ったりしてますからね。
そうそうそうけどそういう成長の仕方はあんまない。
もちろん頑張って例を挙げればあると思うんですけどねその過去にもあると思うけどもこのスピード感で同じ人が5年とか10年の中で影響力が一個の大学だったのから
20億人が使うものになりました。結構なさそうな気がするんだよな。
てなった時にじゃあ10%の人に影響がありますとか1%の人に影響がありますっていう世界が20億人の1%っていったら2000万人なのでめちゃくちゃ影響がありますよねとかいう世界になってきた時に
大学のそのDIKサイトですっていうノリでいろいろやってたら確かにまずいよねっていうのはなりますね。
そうですね。
急増する開発者人口と経験不足の問題
てなった時にやっぱ倫理観っていうものは必要になるし、そう考えるとGoogleとかがDon't beevilって言ってたのは確かにっていう気持ちになったりとかしますね。
いやーなんか改めて異常な世界にいますね。
そうですね。
これあとあれか。ここだ。ここかな。芸術さんが引用してるからここなのかな。なんかエンジニアの人口がどんどん増えていってるから。
5年ごとに世界のプログラマーの人数は倍になっているとか。ってことは世界のプログラマーの半数が5年未満の経験しか持たないことになるとかっていうのは。
これ我々の共通の知り合いの人が結構このフレーズ気に入ってよく使ってる印象もありますけど。
すごいですよね。
すごいですね。なんかそのムーアの法則よりは遅いかもしれないけど。5年で書いてやばいよね。
世界のプログラマーの半数が5年未満の経験しか持たない。あーなるほどーと思って。
そう考えたら業界の歴史が浅いよねって言っても、まあそうだねって思うよねっていう気持ちになりながら。
これでもすごいよね。そうすると5年未満の経験しか持たない。
会社で言うと食堂エンジニア雇ってて半分が5年未満ですみたいなのってあんまりなさそうかもって思ったんですけど、それは会社によるかって今思ってしまって。
そうですね。なんかこう5年経った人たちが。
ベンチャーとかだと全員CTOも含めて5年未満とかあり得るからな。
そうですね。とか転職してって新卒しか残ってないみたいな世界観とかも悲しいパターンもありそうですし。
上が減っていって劣質まで最終半分が5年未満はなかなかしんどいっすね。
しんどいっすね。
それは人口が増えていってるって話とは別のニュアンスもあるけど。
そう。みんな成長して羽ばたいていったんですみたいな。
これ相対的に見て経験不足なのは構造的に待ってても解決しないみたいなことを言ってるわけですよね。
そうそう。
経験不足なので子供みたいなもんなのに社会的責任とか影響力大きくなってるんで高い倫理化を求められる。
言い訳してんじゃねえぞお前らみたいなメッセージを感じる。
うっかりミスと社会システムへの影響
そうですね。たぶん今5年で倍だよねって話してたのが、もっと社会的に見た時にコードを書く人ぐらいの範囲で捉えたらもっと増えていくわけですよね今後。
AIによってバイブコーティングで物を作っていく。
でそれをまあなんか何でもいいですけどどっか行ってプロにしてみんな使ってねーってやった瞬間に、もちろん攻撃に合うとか、そういう人は損するっていうのは攻撃されてる場合もあるかもしれないし、
気づいたらそれがいろんなところに依存していて、社会的な影響を持ってしまい、とても大変なことに繋がっていくってなった時に、
職業プログラマーというか、就職して仕事でプログラミング書いてる人だけではなくて、そういう影響を与えてしまう可能性があるんだよっていうことも含めて、
もっと広い範囲にもしかしたら読まれるべきかもなっていうのは、この倫理の章だけかもしれないけど、ってちょっと思ったりもしましたね。
そうですね、知っておかれるべき話だよなーっていう気はしますよね。
クローラーを作りましたと、1秒間に100回アクセスしたみたいな行動になったら、相手方に迷惑をかけたりするわけで、それでよってサイトが使えなくなって、
社会システムが止まりましたとかになったら、そんな簡単なものは起きないでしょって思ったりはするんですけど、
でも時と場合によっては、アタックだって言われて、裁判になったりもしてたりするんで、うっかりやると、うっかりそういうこと起きてしまうんですよねって思いながら。
そうですね。だから自転車に乗る人が道路コツを知らなくていいのかみたいな話と似てはいる気はして。
あれは叩きやすいっていうと語弊がありますけど、わかりやすく危険だから気をつけましょうって話をしやすい気はするんですけど。
あとはあれですかね、第三部。第三部というかこの章か。
プログラマーの誓いと継続的な学習
章じゃないんだよな、第三部の扉なんだよなここだから。
プログラマーの誓いっていうのが最後出てて。
ここはちょっと長いなと思ったけど、十条あるのか。
そうですね。
ここは大事ですよね。
大事ですね。
コンピュータープログラマーの職業の名誉を守り維持するために、私は自分の能力と判断の限りにおいて以下のことを約束する。
って言って十箇条書いてあるんですけど、自分たちのある意味居心地がいいからかわからないですけど、自分たちが選択してこの職業をやっている以上はこの場所を守るのは自分たち一人一人なんだなみたいなことを思い出させられたりとかしながらちょっと読んでましたね。
そうですね。なんかこれ貼っときたいなどっかに。
どっかにね、貼っときたいですよね。
印刷して誰かリモートワークしてる人の机とかに貼っておいたらいいじゃないですか。
いやでもちょっと今急ぎなんでとか、これちょっと明日リリースしないといけないんでみたいなことを言われた時にこれを見ながら本当に?って。
あなたは私が作るコードは常に最高傑作だと言えてますか?って問いかけたくなる。
いやそんなんいいからリリースさせろって言われるかもしれないけど。
でもまあ慌てると良くないという話も後ろに出てたんで。
やっぱこういうことを常日頃からちゃんと意識しときましょうねっていうのがめちゃくちゃいっぱい書いてあって。
私の技術の学習と工場を怠らないっていうのがあって、いやそうだよねって思いましたね。
古いやり方するのがそれだけで悪とまでは言わないですけど、リスクが高くなったりはするからな。
状況が変わってそうですね。
テストってのは手動テストで今までやってきたんで、手動テストがちょっと信じられないとかって言われたら、ちょっと勉強してくれって思ったり、すごく簡単な話をするとそう思っちゃったりするからな。
次行きますか。
次の章行きますか。
