どうも、カネスズです。
私は現在プログラマとして働いていますが、やはり周りには仕事のできる
エンジニアの方が沢山います。
私も「出来るプログラマ」になれるよう努力しているのですが、
そう簡単になれるものでもありません…
今回はそんな「出来るプログラマ」になるために必要な５つのことを
紹介していきたいと思います。
目次
出来るプログラマに必要な５つのこと
今回紹介する以下の5つのことは、私がプログラマとして働く中で
大切だと実感したこと・私が尊敬しているエンジニアの方が行っている
ことから抜き出したものです。
- 後の作業者のことを考える
- 作っているシステムを理解し、使う人のことを考える
- まずは重要な点を抑える
- 自分のソースを他人に教えられるくらい理解する。
- 知識は浅く広く、一部超深く！！
それでは１つづつ見ていきましょう。
１．ソースは後の作業者のことを考えて作る
システムというのは、作って終わりではありません。
不具合が出れば修正する必要がありますし、機能の追加を依頼されるかもしれません。
そこで問題なのは、その修正・追加を行うのが作成者とは限らないところです。
システム作成後は、保守・運用担当として引き続きそのシステムに携わる時もありますが
別の開発プロジェクトへ参加することのほうが多いです（私の経験ですが）
別プロジェクトへ移った場合、修正・機能の追加作業は別の開発者が行うことになりますが、
その人はあなたのソースコードを読んで仕様・実装方法・処理の流れを把握します。
この時、ソースコードがとても読みにくいものだったら、どうでしょうか？
修正者はソースを解析するのに時間がかかってしまうでしょう。
あたなに確認の電話が掛かってくるかもしれません。
お互いに悪いことしか無いのです。
そのため、ソースコードは分かりやすく見やすいものを心がけましょう。
２．作っているシステムを理解し、使う人のことを考える
当たり前ですが、システムを作るということは、そのシステムを使う人がいます。
その人は何か仕事で問題を抱えているがために、システムの作成を依頼してくるのです。
プログラマの中には、ただ設計書通りにシステムを作っていくだけで、
自分が何のシステムを作っているのか、誰がどのように使うのかを
理解していない人が結構多いです。
確かに、その状態でもシステムを作ることは出来るでしょう。
しかし、それで良いものが作れるかは微妙なところです。
システムについて理解していれば、
- この仕様はおかしいのではないか？
- この処理もあったほうが良いのではないか？
- そもそもこの機能は不要なんじゃないか？
といった疑問が生まれてくるわけです。
その疑問を設計者やお客さんにぶつけることで、後の不具合や手戻りを減らしたり、
機能の追加ということで追加料金をもらえるかもしれません。
実際のところ、これらの問題を考えるのはシステムエンジニアやプロジェクトマネージャの
仕事ですが、プログラマが提案していけない道理はありません。
どんどん疑問に思って、どんどん提案しちゃいましょう。
３．まずは重要な点を抑える
システムの開発をしていると、仕様が不明確で作業が止まってしまうことがあります。
そんな時、お客さんや上流工程※１の方と打ち合わせを行うのですが、
まずはそのシステムの重要な部分をまず話し合う必要があります。
※１、開発の依頼元。お客さんがA社に開発を依頼し、開発の手伝いをB社に依頼した時、B社にとってA社が上流工程となる。
この話し合う部分に関しては、プログラマが行う仕事ではありません。
しかし、仕様が不明確という部分を見つけるのはプログラマの仕事でもあります。
なぜなら、仕様が不明確なのにプログラムは作れませんよね？
もちろんそんな状態でプログラマに仕事が回ってくる事自体がおかしいのですが、
設計者も人間です。抜けや漏れ、ど忘れなどもあるでしょう。
というわけで、設計書を見ながらプログラミングをするにあたって
不明確な部分は設計者に聞く必要があります。
この時、設計書を見てとりあえず処理の最初から作る…と言うのは止めましょう。
まずは、そのシステムの重要な部分。つまり、ある会社の受発注システムを
作っているのであれば受発注の処理部分をしっかり確認しましょう。
システムを作るにあたって、最初に細かい部分をこだわってしまう方がいます。
例えば、金額を入力する場所の幅やら高さ。背景の色。入力後のフォーカス位置…
確かにこれらのことも大切です。
しかし、作っているのは受発注システムであり、金額入力システムではないのです。
まずは受発注部分の仕様をしっかり抑えなければなりません。
その他の細かい仕様なんて後でどうとでもなります。
最悪お客さんに妥協してもらうということも出来るでしょう。
ですが、基幹となる部分は妥協なんてしてもらえません。
お客さんに現状報告をする場合で、以下の例を見て下さい。
- 金額入力欄は完璧ですが、受発注はできません。
- 受発注はできますが、金額入力欄が不格好です。
極端な例ですが、お客さんが前者を聞いた場合どう思うでしょうか。
ブチギレです。
このように、代替が効かない重要な部分は初めのうちに仕様をしっかり抑え
重要でない部分は後回しにしましょう。
もちろん、後回しにして忘れることのないように。
４．自分のソースを他人に教えられるくらい理解する
プログラミングをしていると、言語の文法がわからなかったり、
自分の知らない技術が必要になったりすることがあります。
そんなときに役立つのがGoogle大先生。
私もいつもお世話になっております。
Google大先生に聞けば大概のことは解決することが出来るでしょう。
目的のソースコードを見つけコピーして動かしてみると、思い通りの結果になった！！
…よくあります。
検索する→ソースコードを見つける→コピペ→実行→思い通り！！
この一連の流れ自体は良いのですが、問題は…
なぜ思い通りの結果になったのかを理解していない場合です。
基本的に説明できないソースコードを書いてはいけません。
「ここの処理、なんでこう書いたの？」
↓
「ネットに書いてあったからです」
アンポンタンです。
仮にその理解していないソース部分で
- 不具合が出たら
- バージョンアップでそのソースが使えなくなったら
- システム改修で、処理の説明を求められたら
はたして対処できるでしょうか？
後で困ったちゃんにならないように、しっかり理解して
誰にでも説明できるソースを作りましょう。
５．知識は浅く広く、一部超深く！！
一番いいのは超広く！！超深く！！なんですが、まぁ無理です。
開発というのは、「Web系だけ」・「クラサバ系だけ」・「C#だけ」・「Javaだけ」の
ように１系統の開発だけをずっと行うということはありません。
様々なシステム形態を、様々な言語を使って開発を行うのです。
そのため、知識を浅く広く持っていれば基本困ることは無いでしょう。
しかし、それではただの技術者で止まってしまいます。
ひどい言い方をすれば、変えの効く人材となってしまうのです。
それでは悲しいですよね。
ですが、ある技術だけはメチャクチャ詳しい！！
という部分が１つでもあったとします。
そうすると
「あの人って、〇〇に詳しかったよね？相談してみよう」
「このプロジョクトでは〇〇を使うから、あの人は入れたいな…」
ということになるのです。
ゲームで例えると
力：４０、守り：４０、速さ：４０
のキャラと
力：１００、守り：5、速さ：5
どちらのほうが魅力があるでしょうか？
私は断然後者です！
平均的には並以下でも、一点でも突出している部分がある人のほうが
断然求められます。
みなさんも、何か1つ誰にも負けないと言うような技術を身に着けられるよう
頑張ってみて下さい。
おわりに
ここまで、出来るプログラマになるために必要な５つのことを紹介してきましたが
いかがでしたでしょうか。
これら５つのことを当たり前の事じゃん、と思えているのであればあなたは
既に優秀なエンジニアであると私は思います。
私も常にこの５つのことを意識して開発を行っているつもりなのですが
まだまだだなと実感する時ばかりです。
この記事がプログラマを目指している方・良い技術者を目指している方の
参考になれば幸いです。
それでは今回はこの辺で。
ではでは。