今日は自分の成長について考えたことをご報告します。
そろそろ5月も終わりに近づき、新入社員研修も佳境を迎えている時期かと思います。
自分の成長ってピンと来ていますか？
動けばいい、使えればいい、から出発
新入社員時代にはとにかく動かすこと、動くことに注力していた記憶があります。インフラならとにかく動くconfig、バッチファイルでもとにかく目的を達成するためのバッチファイル。
学生時代に、プログラミングの授業を受けていた時の講師の言葉
「とかく、正しく動くプログラムになってないとね。それは大前提だけど、余分なエラーチェックとかエラー訂正とか、ホントに要るの？ってのはちょっとよく考えてみて欲しいよね。冗長が過ぎるステップがいくつか散見される。」
うーん、なるほど。
でもやっておくに越したことはない、という考え方もあるんじゃないかと？
そんな質問を受けて講師はさらに続けた。
「いや、それが意味があるんならね、存在している"合理的な理由"があればそれは結構なんだけども。
いま、課題で提示したプログラムにそう言う要求はあるか？というと、課題としてエラーチェック・訂正を含めたわけじゃないなぁ。」
いたずらっぽくニヤリとした講師は言葉をつづけた。
「むしろ、正しい動作をどれだけ少ないコード量で実現するか、これを課題では問うたつもりなんだけどね。」
一方で、もう一段階、成長するための要素
始まりは「目的の動作を達成すること」ここはブレちゃいけない、つまり正しく動くことは必要最低限の満たすべき条件ということです。
しかし、このブログにあるバッチファイルはやけに長い、単純なコマンドの代替にしてはやけに長い。
これは、そのバッチファイルを使う人が使いやすくするために、前述で言えば「余分な処理を多数いれているから」という理由があります。使う人が迷わないような操作を実現する、という理由ですね。
使う側がシステムを意識しなくてもその機能が享受できるようになる、という利便性を提供するためには、目的の動作を達成すること以外に「より使いやすくなること」をその目的に加えて作りを洗練していく必要がある、これが次の段階だと思っています。
さらに…拡張や標準化
もう一つ、違った視点で、「拡張性を意識した作り（変更をし易く）にする」とか「標準化によって他の作業者にも扱いやすい作りにする」という、「本来の動作とは全く異なる領分に注力する」という点も考慮が必要になってきます。あんま詳しくないですが、ソフトウェアフレームワークとかアプリケーションフレームワークとかいう共通コードなどがそれですね。
よく出会ったのは開発者が「これは○○さんが作ったコードだからよく分からないんすよね、作り直すしか…」という場面。
私は開発できるわけじゃないからアレをこうやって、みたいな助言ができないので、同意するしかないんですけどね。世の中にはそうじゃないコードってのもあるらしいです。
成長曲線の話
最初は「とにかく正しく動作させる」ということに注力して、目の前のITって道具をドンドン動作させる経験を積んでいくとで、とにかく無から有を生み出す快感を得つつ自分も成長を実感できる状況が続きます。
しかし、とにかく動くようにする、というだけでずーっとやっていくと、いつか壁に当たります。なんでそれが正しいか、なんでその設定にするのか、という点が説明できなくなってくるわけです。他にもっといい手法があるのかもしれない、とか。
そうなると、「使う側によりよいのは？」とか「別の作業者によりよいのは？」とか「業界標準ではどうしておくべきか？」とかそういったものが気になってきて、自分のアクションにこういった要素を加えていくように（必要になってくるともいう）なってきます。
このとき、個人的な経験では自分は成長しているかどうかの成長曲線が見えづらい段階に入っていました。要するに今一生懸命学んでいる知識ってホント役立つもんなんか？って疑問に思いながら日々あれこれとやってるような状況。しかしこれも一つの成長曲線の土台になるものです。学んでいるときは実感できないけど、長期的に見てその学びがいずれ成長として実感できる時がきます。（たぶん…、というか体験談では来ました。）
これ、何の役に立つんかね～？とか思っていた経験は、回り回って役に立った、ということもあるんだなぁ、と実感したことが意外とありましたよ、というお話し。
