プログラマ・エンジニアになろうとしているあなたへ
実は、プログラマ・エンジニアになるためには、プログラミングのスキルだけでは足りません。
本記事では、プログラミング以外のスキルについて解説します
プログラミングのスキルだけでは足りないとは？
プログラマ・エンジニアの業務は、いわゆるコーディングだけではありません。
ですので、プログラミング言語だけを理解していても、スキル面で足りないことが多々あります。
以下は、プログラマ・エンジニアの業務の一例です。
- 機能仕様の作成・レビュー
- 詳細仕様の作成・レビュー
- コーディング
- コードレビュー
- デバッグ・テスト
- リリース
- 開発環境の構築
- 評価環境の構築
- etc
チームで業務分担があるのが一般的ですが、プログラムを書いて終わりというケースはまず無いです。
コーディングしたら、コードに問題がないかどうかレビューを行うのが一般的です。
作ったものに対して、デバッグ作業(単体テストなど)もコーディングした本人が行うのが一般的です。
また、請負のようなプロダクトの保守開発をまるごと任される場合だと、リリースを含めて行う必要もあります。
今回はあまり触れませんが、生産性の低いリリースの仕方をしてしまうと、リリース回数が増えるにつれて負担が増えてきます。
つまり、プログラムを書く作業以外にも求められるスキルがたくさんあるということです。
プログラマ・エンジニアなるためのスキルとは？
ソフトウェアのタイプや環境によって、求められるところは若干違います。
チーム開発スキル
ソフトウェアはチームで開発することが多いので、その手法を理解しておく必要があります。
職歴がない場合、経験値が0ということになりますので、少なくとも知識として持っているとマイナス評価は受けにくいと思います。
また、正しいチーム開発手法を理解しておくと、所属したプロジェクトが良いのか悪いのかが判断つきやすいです。
とんでもないプロジェクトも多数あり、そういったプロジェクトについた場合は早々と離脱を検討します。
開発手法
一般に多いのは、ウォーターフォール開発かアジャイル開発のどちらかです。
システム系だとほぼウォーターフォール開発、Webやサービスだとトレンドはアジャイル開発です。
アジャイルでもプロジェクトによって、進め方はまちまちです。
マネジメントスキル
マネージャーでなくても、日程を管理する必要があるのである程度求められます。
ソースコード管理スキル
ソースコードはgitのようなバージョン管理ツールで管理されます。
使わないプロジェクトは無いので最低限、使い方は理解しておく必要があります。
多人数で開発すると、ブランチ管理などが求められます。
未評価のソースコードは安易にコミットしてはいけないなど、プロジェクトによってルールがあります。
gitの使い方は分かりますという話ではないので、ソースコードの管理の手法を理解しておきましょう。
レビュースキル
ソフトウェア開発においてレビューは必ずあります。
不具合の摘出などに効果があるので、レビュースキルは伸ばすようにしましょう。
レビューが上手く運ぶかどうかは、本人のレビュースキルもありますが、所属したプロジェクトの影響も大きいです。
経験上、まともなレビューができるプロジェクトは少ないです。
レビューは目的がはっきりしているので、これができないとポンコツのプロジェクトの可能性大です。
話が脱線したり、意味のない指摘を繰り返したりするのは良くあります。
マネージャーが非エンジニアで介入的だと、この傾向はより一層高まります。
こうなると、別のプロジェクトに行くしか無いかなという感じです。
保守開発スキル
チーム開発スキルとは言えないかもしれないです。
保守開発は既にプロジェクトの方針が固まっているので、基本的に従えば良いです。
ソフトウェアの開発は新規開発、保守開発があり、保守開発の方が圧倒的に長いです。
新規開発とは特性が違うので、理解しておく必要があります。
例えば、プロジェクトの方針を無視してコーディングはできません。
ソースコードが気に入らないからといって、以下のようなことを突然することはできないでしょう。
- インデントをタブからスペースに変える(差分に見えるため)
- 関数名を変える、中身を大きく作り変える(リファクタリングする)
保守開発はテスト済みのソースコードがあるので、極端な改造はできないのが一般的です。
最適なコードにするリファクタリングという作業があるのですが、リファクタリングが許されるケースは稀です。
稼働実績があり、テスト済みなので信頼性があるためです。
性能問題など、大きな問題を抱えているケースくらいかなという感じです。
Googleでもソースコードの再利用は多々されていると言われています。
ソフトウェア設計スキル
ソフトウェアの構造を設計するスキルです。
コーディングスキルはプログラミング言語を理解して、コーディングできると言うスキルです。
一方で、ソフトウェア設計スキルはソフトウェアをどのような構造にして、実現するのかと言うスキルです。
優れたソフトウェア設計ができると、設計通りにコーディングして終わりです。
通常、本番のプログラムは行きあたりばったりでコーディングはしないです。
プロセス・スレッド設計
プロセスの構造やスレッドの構造を設計します。
クラス設計
クラス図を書いたりして、クラスの構造を設計します。
コーディングスキル
実際にプロダクトを開発していくに当たり、ただ単に、プログラムを書けるだけではだめなケースがあります。
一例を紹介します。
評価しやすいコードを書く
プロジェクトやテスト環境によって、上のコードよりも下のコードの方が求められます。
if( A == B && A !=C )
if(A == B){
if(A != C)
# hogehoge
}
上だとテストツールが全パスチェックできないことがあります。
不具合時に不具合解析しやすいコードを書く
エラー処理やログを吐き出す処理を漏れなく書くなどです。
これができないと、不具合が発生した時に障害解析できないことになります。
実務経験、不具合解析した経験が無いと、この手の処理は書かないので経験がないのが分かります。
コンピュータ知識
ソフトウェアはコンピュータ上で動作するので、コンピュータに対する理解が必要です。
基本的に、メジャーなソフトウェア開発企業のエンジニアは一通り理解しています。
OS知識
例えば、Linux系であれば募集要項に「Unix/Linuxを理解していること」とか書かれていることが多いです。
操作だけでなく、基本的なカーネルの動作や仕組みを理解している必要があります。
データベース
SQLなど。知識ゼロの人は少ないです。
仕事の内容によっては、データベースの設計経験を求められるケースも多々あります。
これらのスキルをどうやって学べばよいのか？
ソフトウェア開発者向けの書籍が多数出版されています。
一読しておくと開発で求められるスキルを認識できるでしょう。
各系統、最低1冊は読んで理解しておくことを推奨します。
働いていく上で必須のスキルのため、知っているのと知らないのとではかなりの差があります。
以下におすすめの書籍を紹介します。
ソフトウェア開発全般
達人プログラマー
より効率的、より生産的なプログラマになりたいソフトウェア開発者に向けて書かれた書籍です。
開発の進め方や意識すべきポイントが書かれています。
プログラミング言語を学んだあとの、ステップアップとして良い書籍です。
おすすめの人
- プログラミングを職業としたいけど、開発現場がイメージできない人
- プログラマだけど、より優れたプログラマになりたい人
おすすめの理由
開発現場では何が求められるのか理解できるため。
Code Complete 第2版 完全なプログラミングを目指して
プログラミング言語を学んだだけだと、例えば以下のようなことが良く分からないと思います。
- 関数の命名法則
- 変数の初期化ってどうするのが良いのか
- 変数の使用方法
- etc
プログラミング言語を学べる書籍は、基本的なことは書かれているのですが、実践的ではないことが多いです。
「なんでこの機能が必要なのか」とか良くわからないと思います。
Code Completは、ソフトウェア開発の現場で使える実践的なプログラミング解説書です。
体系的に書かれているので、一読すれば現場で戦えるでしょう。
おすすめの人
- 正式なトレーニングを受けたことがない独学プログラマ
- 現場経験のない人や経験の浅い人
おすすめの理由
プログラミング言語を知っているから、現場で使えるに変えられる書籍のため。
テスト手法
テスト手法は、プログラミング言語の勉強だけでは学べません。
テスト系の書籍は最低1冊は一読しましょう。
はじめて学ぶソフトウェアのテスト技法
ソフトウェアのテスト手法が書かれた書籍です。
この書籍もプログラミング言語を学んだあとの、ステップアップとして良い書籍です。
おすすめの人
- プログラミングを職業としたいけど、開発経験がない人
- プログラムをどうやってテストすれば良いのか知りたい人
おすすめの理由
基本的なことが書かれているので、初心者でも分かりやすいため。
まとめ
今回挙げた項目は、全てマスターする必要はありませんが、ある程度理解をしておくのが望ましいです。