俺はとにかく、パソコンの中で何が起こっているかは二の次で、目に見えているものが動かないと不安で、頭に入ってこないタイプである。
（あと、怠惰だ。）
俺が個人的にそういうどうしようもない人間なのだろうと思っていたのだが、後輩と話していると結構「どうしてそういう実装になったのか」「どうしてそうしようと思ったのか」というのを、いちいち説明されなくてもわかるときがある。
「あー、俺と同じタイプだーわかるわかる」と思うことが多い。
っていうか小さいところにいるモンだから、後輩も片手で数えられるくらいで、しかも実際に指導するとなると機会は少なく、誰かと比べるということがなかったのである。
これ、「タイプ」なのか？ もしかして？
せっかくなので、「俺たちみたいな思考回路をする」人間の思考回路を言語化してみようと思ったのであった。
もちろん、個体差がある。
あと、後輩は俺より優秀である。
動けばいいやという思考回路
プログラミングを初めてたかだか数か月のヒヨコが行き詰まっている。
「ファイル選択ダイアログを出せたけれども、その選択したファイルパスがどこにあるかわからない。テキストボックスに設定したいが、取り出せない」という相談だ。
なるほど？
コードを見に行っているとこうなっている。
OpenFileDialog openFileDialog = new OpenFileDialog();
if (openFileDialog.ShowDialog() == DialogResult.OK)
{
Console.WriteLine("選択したファイルのパス: " + openFileDialog.FileName);
}
まあ……コンソールに出してるからだな！
実際にあったことではないが、似たようなことはたくさんあった。
そして、誰しも最初はそんなもんだと思う。
このコードはおそらく「ファイル選択ダイアログ」のサンプル例をそのまま持ってきたものである。とってきたパスは、openFileDialog.FileNameの中に書いてある。
そのあと、たとえばファイルパスのテキストボックスに入れたいとか、そのパスのファイルを開きたいとか、どうしたいかはプログラムによるから、サンプルは、コンソールに出しているわけである。
コンソールに出しているのだ。
じゃあもう、わかってんじゃん。そこにこたえ、書いてるじゃん。
だから、そのファイルパスを……使えばいいのだが（慣れてくると別にリファレンスを見なくても察せるだろうが）、このOpenFileDialogのクラスの理解なんて一切しなくてもコピペすればファイル選択ダイアログは出せるのである。
そのあと詰まるけど、なんか動くまではいけるんである。
これが、とりあえず動けばいいやという思考だ。
どうやって指導するかというと、俺だったら、とりあえずMSDNの公式ドキュメントOpenFileDialog クラスを案内し、読むように言い、そして複雑すぎて、読んだけどわからなかったといわれ、そのコンソールに出しているやつを使えばいいよ、とヒントをやることになるだろう。
でも、そんな質問をするピヨピヨちゃんは、曲がりなりにも、結構、見てみたら、画面を作っているんである。ボタンを押せば何らか動くし、研修で教えた部分はできている。
見た目の理解は深そうに見える。
ただ、理解というか、クラスをどう扱うかというような、習熟度が足りていないのである。
俺たちは、心のどこかで「動けばいいや」と思っている(かもしれない)
しかし、内心は自由だとしても、この考え方は口に出すべきものではないかもしれない。
そんなことしようものなら、弊社だと、「言ったんか。祠に言ったんか。ええ！？」と長老にはったおされ、夜通しPythonコードのコーディング規約を朗読させられることになりそうだ。
個人目標は、「〇〇システムへの理解を深め、より良いものにしていくために頑張ります！」ということになる。
とにかく、あまりに外聞が悪すぎるのだ。
ここで、アジャイルソフトウェア開発宣言を読んでみよう。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。
すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
*この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
https://agilemanifesto.org/iso/ja/manifesto.html より引用
俺はアジャイルソフトウェア開発宣言が好きなので爆笑しながら3回読み直した。
もちろん、「左記のことがらに価値があることを認めながらも、」なんて書いてあるところを故意に読み飛ばしてはいけないし、それはアジャイルの曲解というものだろう。
しかし読めば読むほど愉快である。
包括的なドキュメントよりも動くソフトウェアを、
包括的なドキュメントよりも動くソフトウェアを、
包括的なドキュメントよりも動くソフトウェアを、
動くソフトウェアを……。
動けばいいやというか、動かさなくては始まらない
ちょっとタイトルをいかにもな感じにしてしまったが、俺は、「「動けばいいや」のプログラミング」というのをそんなにネガティブにはとらえていない……。っていうか別にメモリリークを起こすようなプログラムを動けばいいやと言っているわけではない。
それは一見動くが、動かないプログラムだ。
俺は、「とりあえず動かしてみてから納得が来る」タイプなのである。
動くと楽しいのだ。
まず動かしたい。画面が変化するのを見たい。結果を見たい。自分の行動が、いったい世界にどういう変化を与えたのか、できれば視覚ではっきり知りたい。
だからHTMLはちょっと楽しいし、コンソールにはニガテ意識がある。しかし、とはいえプログラミングは好きだ。
俺たちのこれは、正されるべき悪徳でもある気がする。しかし、物事の構造化を見抜いて、うまいことやっていくのが得意ということでもある。さっきのファイル選択ダイアログのやつだって、いったん教わればもう大丈夫だ。
ただ、このタイプとしてやってきて、いくらか是正しないとならないポイントがあると感じている。
したほうがよさそうなこと
公式ドキュメントを読む
動かしたい。本当に早く動かしたい。コードを張り付けて動作するのを見たい。
俺みたいなタイプが公式ドキュメントにあたることを徹底的に叩き込まれたのは良いことだと思う。
だが、それにしても、なかったり、英語でとっつきにくかったり、わかりづらかったりして、公式ではない実装例を見ないとなんとも話が進まないことがある。
しかし、そういった場合でも公式ドキュメントをあたるという原則は忘れてはならない。
そして、個人ブログは結構テキトーである。
どこがどういう影響を与えているか知る
俺たちはとにかく動けばいいから、動いた後にはしゃいで、いらんもんがついてくることになる。冷静に要らないプロパティを削って使いたい奴だけ使うべきである。
動かす
俺たちみたいなタイプは、たぶん、とにかく動作環境を作ってみないと死んでしまう。
新しい業務を振られて、環境が必要なら、手順書がないか聞いたほうがいい。たぶんない。なければ動かしてるやつに聞け。1例もらえ。データはサンプルをもらうべきだ。エラー例もあるといい。
社内なら遠慮なく聞けばいい。
もし、引継ぎの一例目なら、あまり用意がないかもしれない。
「デバッグするときはどうしたらいいですか？」と尋ねる必要がある。
誰かに引き継ぐときはコストというものがかかるもので、このあたり、当たり前に動かしてるものだから結構見落としがちなのだが、思い出したように教えてくれる。っていうか聞かないと出てこなかったりする。
たとえばなんかの機械のシリアル通信だったら、実機がなくても、Teratermとか、Teratermでダミーデータを送るとか、方法がある。
（これは、もしかしたらWebのプログラマーで、広範なシステムが既にある場合、難しいのかもしれない……）
パフォーマンスを改善できないか考える
俺たちは動くとホッとするので「この動作にしてはやたら遅いかもしれない」という感覚が鈍いかもしれない。
計算量とかO（オー）とか、そういうのよりもっと素朴な感覚だ。
あるアプリを開発していたら、「このファイル、Excelだったらもっと早く開けるけどこのソフトで開くと遅いのはどういうことだろうか？」という指摘があった。
それは、バイナリデータを読み込んできて読むようなものだったんだが、見てみたらSkipやTakeの処理が悪かった。たしかindexで次読み込む場所を見つけては、全部のバイナリデータの塊から切り出していたのだが、いちいち塊からやると処理では、内部では毎回再計算してしまっていて、計算がバカみたいに遅くなるというものだった。
実現はできていた。
規模がデカいときは計画し、相談する
動けばいい。
だがそれは、遠回りしがちな思考回路でもある。
最初の出発点がズレてると確かに動くがいったいどうしてこうなってしまったんだということになりかねない。
ベストプラクティスを探るのは難しい。数例見つけてきて詳しい人に相談したりするかじっくり考えたほうがよさそうだ。
メモをとる
これは俺がテキストで思考し、テキストで覚えるタイプの人間だからかもしれない。
（記憶力が良ければいらないだろう）。
俺は自分のことが一番信用ならないので、記憶を放棄し、メモアプリを使用している。テレワークの余波でノートパソコンが支給されたので、だいぶ楽になった。
それまでデスクトップパソコンだったので、人の席に聞きに行ってメモをとるというのがアナログメモじゃないと難しかったのだ。
例を抜き出し、人に聞いて、どこがこのジョブ固有の情報で、どこが会社固有の事情の手順で、どこがどこでも通じるものなのか理解して、抜き出し、構造化して、似たところは似たやつを使うのだ。
おわりに
「動けばいい」と思っていながらも、やはり浅いと泳ぐのも大変である。難しい。楽しいんだけど。
本質の理解をしないとどこかで行き詰まるな、とひしひしと感じている。しかし、ChatGPTの登場により、ちょっと事情が変わってきたなと思っている。
冒頭で書いたファイル選択ダイアログなんか、もう理解しなくてもほぼ出せてしまうからである。エンジンがついたボートのようだ。遠くまで行けるが、遠いところで座礁しそうで恐ろしいもんだ。
そのとき泳いで帰ってこれるか？ 助けを呼べそうか？
なんでそんな難しい処理を使おうと思ったんだ？ もっとシンプルでいいのに！
みたいな。
詰まる場所が遠く、こんがらがってそして果てしなくなっていきそうである。
だから最近のChatGPTに頼り切った若者はダメなんだみたいなことをいう前に、なんていうか、マジでどうしよう。勉強が必要そうだ。
そういえば、デキる人間を見ていると１ストロークが長い。コードを打ってから動かすまでが長く、ミスがないのでするする動く。俺たちは、っていうか俺は、なんかちょこまかしているかもしれない。筋力をつけていったらたぶんああなれる。