コラム記事
成長するために必要なことは
初学者の人から「プログラミングがなかなか上達しない」といった話を聞くことがあります。初めからバリバリにコードが書ける人は逆に少ないと思います。最初の頃は分からなくても、やっていれば、殆どの人は誰でもできるようになるものです。
自分が所属する会社で「地獄を見れば成長できる」と先輩から言われたことがあります。自分もその意見には納得できます。例えば、23時位まで残業するような日々を半年も続けば爆速で成長できるでしょう。成長速度を爆速に上げるには、自分をそこまで追い込む必要があります。納期のあるトラブル対応でもすれば、短期間で成長できるでしょう。
しかし、いつまでもこんな環境で仕事ができるのは独身の間だけです。自分には４歳の子供がいますが、子供ができると、従来の仕事環境がガラリと変わります。家庭を持つと、自分の都合だけで夜遅くまで残業し倒すといったことができなくなります。（人によるかも分かりませんが）
独身の人は、今の間に残業を謳歌しておきましょう。これが独身貴族の特権だったんだと、後からしみじみ感じる時が来ます。（おーっうるうる・・・）
初学者の人が成長するために言っておきたいアドバイスがあります。それは「コードは盗むもの」だということです。初学者が始めから、我流だけでコードを書きだすと、多くの確率でドツボに嵌るものです。コード量が短い場合はそれでも大した問題にはなりませんが、コード量が長くなると、一つ直した修正の影響があっちにもこっちにも出だすことになります。この修復作業が後々、自分を苦しめることになります。
先人が書いたコードには、たくさんの教訓が生かされているものです。先人が犯した失敗を自分も繰り返すことで成長の糧を得るよりも、先人が犯した失敗を自分は繰り返さないようにすることの方が、断然有意義です。
エンジニアの現場で働いていると、このような言葉を聞いたことはありませんでしょうか。「車輪の再発明をするな」「巨人の肩の上に乗れ」どちらも同じようなことを言っています。品質は我流で作り上げようとしなくていいんです。先人のコードを盗めばいいんです。それが圧倒的な近道です。
品質のよいコードを書くには
コードの品質はテストの回数に比例すると言われています。品質を上げるにはテスト回数を増やせばいいでしょうか。しかし、闇雲にテスト回数を増やしても、結果的に多くの工数をかけてしまうことになります。
コードの品質を上げるには、コードに品質を埋め込むことが大事です。換言すると、コードの定型を引用するということです。定型となるコードは一朝一夕で作成できるものではありません。そこに至るまでには長い経験が必要になります。
品質の悪いコードの典型として、スパゲッティコードといわれるものがあります。中身がぐちゃぐちゃになっていて、全く整理がなされていないコードのことです。SIerの開発の現場にいると、ときどき、このようなプロジェクトに出くわすがあります。そんなプロジェクトにアサインされた日には悲惨です。毎日が終電の日々となります。
なぜこのようなことが起こるのでしょうか。はたして、未だに謎ではありますが、このようなプロジェクトは懲りることなく繰り返されるものです。
一番の大きな原因は、仕様を詳細まで固めることなく、コーディングに入ってしまうことが原因だろうと思っています。
開発のメインはコーディングだという発想が拭いきれないのです。段取り八分という言葉があるように、仕様さえピシッと固めてしまえば、コーディングなぞ単なる力作業なのです。
はやる心がコーディングに向かわすのです。焦る心がコーディングに向かわすのです。本来であれば、落ち着いてしっかりと仕様固めに専念するべきなのです。多少のスケジュール遅れが発生したとしても、後から新幹線でカーンと行けば間に合うと信じる心が大事なのです。
コーディングに時間がかかるのは、スケジュールが遅れたからでも、エンジニアのスキル不足でもありません。決定的な要因は、仕様変更に伴う出戻りが発生するからです。これが８割を占めていると言っても過言ではないでしょう。それさえ発生しなければ、コーディングは実は大して時間はかからないものです。
それともう一つ、コーディングの最初に、共通関数をビシッと整備しないことも原因でしょう。共通関数を先に整備しないばかりに、同じような関数がプライベートモジュールの中で、たくさん作られてしまうことになります。如何に無駄なことをしているか。共通関数は他所の同じようなプロジェクトからコピーしてきて流用すればいいのです。全てを一から作り上げる必要はありません。
しかし、見積もりには全てを一から作り上げることを前提にした工数で算出されるものです。だがこれでも、蓋を開けてみれば赤字になるものです。このような先人の轍は踏まないようにすることです。
分かりやすいコードを書くには
個人的には、コードを書くときは階層的に整理して書くことを意識しています。また、他人が見やすいというよりも、先ずは、自分が見やすいように書くことを意識しています。自分が書いたコードは、後で本人がメンテすることが圧倒的に多いからです。
自分で書いたコードでも、半年位経った後に見直すと、何をやっているのか分からなくなるといったことがしばしばあります。しかし、見やすさを重視して書くとこのようなことは減ってきます。
また、後からメンテが入ることを想定して、極力短時間でメンテできることを意識して書いています。例えば、パラメータを１つ変えただけで、カスタマイズ完了にするとかです。一瞬で終わるようなカスタマイズでも、半日分の工数で見積ったりすることもあります。
分かりやすいコードを書くのは、あくまでも自分のためです。
あと、リーダブルコードというエンジニア界隈では有名な本があります。この本を大絶賛しているエンジニアは割と多いようです。この本を参考にするのもいいでしょう。どちらかと言えば中級者向けの本ですので、ある程度、コードが書けるようになってから、我流を卒業しようとする人向けの本だと思います。
できるエンジニアの条件
学生の時と社会人になった後とでは、できるエンジニアの条件は変わってきます。
学生の時に趣味でプログラミングをしてたり、授業の課題のためにプログラミングをしている時は、関数を多く知っている、アルゴリズムを多く知っている、トリッキーなことが実装できる、などといったことが、できるエンジニアの条件だと考えているかと思います。
しかし、社会人になってお金をもらって仕事をし出すと、そんなことは、単なる自己満足でしかないということに気づいてきます。社会人になってからのできるエンジニアの条件とは何でしょうか、一言でいえば「納期を守れる人」だと自分としては考えています。
仕事で書くコードにトリッキーなコードなど必要ありません。ちゃんと動くものを、決められてた期間内に、ちゃんと納める。求められるのはその１点だけです。
社会人になると自分の書いたコードが、他人の環境で動くことを目の当たりにすることになります。最初の頃は、「うわー、自分が書いたコードが普通に使われているよー」と、妙な緊張感を持ったものです。
プログラマーとエンジニアは違うの？
SIerにいてますが、プログラマーという言い方はしますが、エンジニアという言い方は聞くことがありませんでした。Web系の開発現場では、プログラマーではなくエンジニアという言い方をするようです。SIerには、PG、SE、PMといったヒエラルキーがあったりします。Web系の開発現場は、真逆で、エンジニアというと、割とリスペクトされているようです。こういった違いがあるようです。