ガジェット通信

見たことのないものを見に行こう

新人エンジニア必見!エンジニアとして成長するための6つメソッドとは?

DATE:
  • ガジェット通信を≫

こんにちは、しょごです。

ふと振り返ってみると、バックエンドエンジニア業を始めてもうすぐ10年が経とうとしています。
思えば高校時代にバンド活動にハマり、大学でネットゲームに現を抜かしていて。こいつぁやばいと思い、1.5年多く行ってしまった大学を卒業後、急いでハローワークに走った日々を思い出すと、なんでちゃんとやっておかなかったんだろう、とうなだれてしまいます。

そんな中、どんな風に開発してるの?と聞かれたことがありましたので、今回は新人エンジニアに向けてエンジニアとしての成長するためのメソッドをまとめてみました。

エンジニアとして成長するための6つメソッド

1. 開発は設計を実装以上にしっかり行う

めっちゃ基本中の基本です。
最初に、完成させたい最終目標に向けて、開発に必要な機能・仕様をまとめます。時にはそれらの設計図として、基本仕様書、詳細設計書、画面設計書、DB設計書などをまとめたり、作成環境によってはサーバ設計書、ドメイン設計書etcとあれこれ用意するときもあるかもしれませんね。
要はこれから作るものをどのように組み上げるかをまとめるお仕事ですね。

ココが一番大事な部分! ココをしっかりやらないと色々ボロが出ることになります。
というか、設計が開発の半分以上を占めていると言っても過言ではないのではないでしょうか。ぶっちゃけた話、実際にコード書くことは人に任せてもいいレベルです。
昔の「プログラマー」と呼ばれた人は流れ図作って設計して、コードを紙に書いてたんですよ。それを「キーパンチャー」って人に渡して叩いてもらうっていう。

2. 動きを細かくイメージする

設計する上で必要なのは仕様をまとめあげ、それを実現するためのアルゴリズムを考えることですね。行動と動作によって現象が発生し、そこから得られる結果までをひとつの流れとして捉える力が必要になります。

たとえば自動販売機でジュースを買う、という流れを考えてみましょう。

お金を入れる。
入れられたお金がいくらか判別し、カウントする。
うまく読み込めなかった場合は返却して再度投入を促す。
入れられたお金がジュースの金額に達したかチェックする。
購入可能金額に達していた商品に、購入可能フラグを付与する。
購入可能フラグが付与された商品を選択した場合、商品を排出し、同時に在庫チェックを行う。
排出後、投入金額の差で余りが生じた場合、おつりとして排出する。

とか、そんなんでしょうか。

動きにすると数秒で結果までたどり着くものですが、実際に流れを見てみると意外と工程があるものです。
ただこちらはあくまでも、正常動作の一部でしかありません。他にも、想定できる不備の洗い出しとそのチェック機能や、想定できない操作が行われた場合のエラー処理などを考慮することで、より強固なシステムを構築する必要があります。

また、ちょっとしたロジックを作るうえでも、スタートとゴールまでをイメージしてから実装するのとしないのとでは、構築するまでにかかる時間が違います。実装時に悩む時間が発生して手が止まる、っていうことを少なくできますからね。

3. お客様の隠れた要望・悩みを考慮する

そもそも新しくモノを作る・作り直す場合、現時点で不満がある、改善したいことがあることが大前提です。
それをヒアリングして考察し、機能や仕様によってお客様の抱える問題を解決することも大事だと思います。そのため、ウチがシステム開発するときに「こんな機能が欲しい」という要望をいただいた際、

今までどうだったのか
不満や悩みはないのか
どうしたいのか
よりお客様がラクな方法はないか
どういったことをお客様が望んでいないか

などを考えて、ディレクターとミーティングを重ねたり、時には直接お客様とお話しています。
せっかく作るからには、使っていただいた際に「これはよくなった」「これは助かる」といったご意見をいただきたいですからね。

4. よく使うロジックは共通化する

1つのシステムに対して、実際にどれくらいの文字数記述をしているか・・・なんて数えたこともないし数えたくもないですけど、それこそ何万文字、何万行と記述しております。

ただ、それらを1から毎回全部書く、なんてことはしません。
必要なロジック、よく使うロジックなどは共通化し、ときにはプラグインとして使いまわします。
よくネットでは備忘録として、こういう記述をすればええねんでって掲載されてるものがありますが、あれも共通化ですね。ウチもよく使う関数、こういうときはこの関数、みたいなロジックセットをまとめて使っています。

たとえばWordPress周りで画像のあしらいを毎回書くのが面倒だったときは、

// あらかじめテーマへのパスURLとノーイメージ画像のパスを定数宣言しとく
define(‘ITEM_URL’, get_stylesheet_directory_uri() .’/’);
define(‘NOIMAGE’, ITEM_URL . ‘images/noimage.png’);

/**
* アイキャッチを取得、なければノーイメージを返す
*/
function _get_eyecatch_data($post_id, $thumbnail, $noimage = NOIMAGE) {
if (has_post_thumbnail($post_id)) {
$image_data = wp_get_attachment_image_src( get_post_thumbnail_id($post_id), $thumbnail, true );
return $image_data[0];
} elseif(empty($noimage)) {
return false;
} else {
return $noimage;
}
}

とかを用意していますね。

この関数の第1引数にpostid、第2引数にサムネイル設定の名前を渡せば、必要な大きさのアイキャッチ画像が取得できます。ノーイメージ画像がいらなくて、画像がないときは非表示にさせたいのであれば第3引数にfalseを与えればいいのです。
ただ、基本画像のsrcに設定するURLしか来ないので、アップしたアイキャッチのwidthとかも欲しい場合は例外です。。

時にはコピペでもいいんです。エンジニアって、いかにラクして構築できるかもポイントだと思うんですよね。

上の記事のように、多ボタンマウスやキーボードを利用して物理的にラクするというのも一つの手ですね。
最近モニターを横から縦にして扱ってみたいと思ってるんですよねー。(チラッチラッ
べ、別にサボってるとかそういうんじゃないんだからね! か、勘違いしないでよね!プンスカ

5. 誰でも途中から開発・引継ぎができるよう可読性も視野に

開発した人しか対応できないものにしてしまうと危険です、休めません。
それこそ24時間いつでも休み関係なく対応しますよ!って意気込みがあるならいいですけど、ウチはそんなんイヤや、いけずや。

いざというときのために、容易に引き継ぎなどができる準備はあったほうがいいです。
gitやCVSでソース管理を行う、システム仕様やサーバ情報など重要情報をドキュメント化する、などはもちろんのこと、ソースの書き方も気をつけておくべきだと思います。

コレも人によってさまざまでしょうけど、ソースコードのガイドラインを社内共有して誰もが同じようにコード記入していると、いざ他の人が引き継いだときも対応が早いですし、何より誰でもフォローできるって、素敵やん?
条件分岐でも三項演算子を使った書き方は好きじゃないですね、読みにくいし。endif;とかendforeach;とか使う書き方も同様。。

こちらは企業の特質で色々変わってきますが、その点も議題にして話し合うべきだと思いますね。

6. 不具合が起こったら9割以上自分のせいと思う

がっちり設計してても実装中にうまくいかないときがあります。それでデバックするんですけど、めちゃくちゃ時間がかかってる人を何人も見てきました。
そういうときにフォローで入ると、ものの数分であっさり解決できちゃったりするんです。

別にコレは経験値の高い低いや、知識の多さとかそういうんじゃなくて、意識改善する必要があると思うんですよ。解決に時間がかかる人は大抵「なぜダメなのか?!うまくいくはずなのになんで?!」と焦っていると思います。
このままだと思考がとまってしまってしまいます。

言っておきますが、不具合の9割以上は自分の実装ミスが原因です。1割かそれ未満で、使ってる言語やバージョンやブラウザの仕様、APIの不具合とかです。

冷静にいま何が起こっているのか、どこまではセーフでどこでアウトなのか。自分がどこで何をやらかしたのか。意識的に流れを追っていきましょう
そこでダメなところが明確になれば、以前記事にした対応策の調査方法のように時間短縮に繋がると思います。

バグの存在しないシステムなんて絶対ないですから。。。悲しいことに。。。あ、もちろん限りなく0に近くするよう努力して作ってますからね! か、勘違いしないでよね!!プンスコ

まとめ

いかがでしたでしょうか。
最新技術やツールを追いかけるのも大事ですけど、それ以前に最低限エンジニアとして満たしていかないといけない考え方や思想って必要だと思います。
もちろん一朝一夕でできるものでもなく、数をこなすことで身につく経験則などもありますけど、いきなりばーって始まってばーって終わるより慎重に物事を見て動いても良いんじゃないかと思います。
新しくエンジニアを始めた皆さんにとって、少しでも成長の参考になればと思います。

それでは。

カテゴリー : 生活・趣味 タグ :
LIGの記事一覧をみる ▶
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。

TOP