【SIer新人向け】研修では教えてくれないノウハウ集

「ようこそ 魔境 SIerへ！」

はじめに

この記事は、SIer（Systems Integrator）に入ったシステム開発未経験者の新人さんたちへ送る、研修では教えてくれないノウハウ集です。

実際、弊社の長い研修では実務に使えそうなことをあまり教えてくれませんし、ノウハウは現場の人の頭にしかない状態なので、新人さんは暗中模索で仕事を覚えていくことになります。

それも非効率なので、実際に私が２年半¹で失敗したこと、やってきてよかったこと（ノウハウ）を体系化したので共有します。
新人さんは、これを参考として、使えるところだけ今後の業務に持っていってください。

（本当はガッツリ社内向けに書いたものなので、一部汎用的でない表現がありますがご了承ください。）

目次

1. 業務面
2. 技術面
3. プライベート面

の三本柱でお送りします。

対象読者

SIerの1,2年目相当であり、学生時代に契約のあるシステム開発を行ったことがない人。

用語

当記事では職業を示す言葉をSE（システムエンジニア）・PG（プログラマ）ではなくDeveloper（開発者）に統一しています。
定義を「システム開発で設計・製造に携わり、プロダクトコードに直接関係する人物」とします。
日本においてSEやPGの定義が幅広く、システムに精通しない人もこの肩書きになる場合があるため、記事内で認識齟齬が起きないようにするためです。

1. 業務面

1-1. 手段を目的としない

ありがちなのが、言われた作業に対してその作業をこなす事が自分の仕事/価値だと思ってしまうことです。
そうして出来上がった成果物は、レビューにて「思っていたものと違う」と言われてしまうわけです。

実際は目的を達成するための手段（と上位者が思っているもの）が振られているだけです。
なので、依頼内容（手段）と目的が直結しないということが多々あります。
正しく目的を捉えた上で、作業をしましょう。そうすれば、手段の誤りにも気がつけるし、途中で間違った方向に進むこともなくなるはずです。

とりあえず！
成果物の最終的なイメージが持てるまで依頼者と認識を徹底的にすり合わせましょう。

1-2. タスクは細分化からはじめる

WBSの小項目が割り振られたとして、とりあえず手をつけ始めるのがもっとも危険な行為です。
たいてい作業半ばで（本人にとって）想定外の事態が発生し遅延します。
まず最初に、自分の中でより細かなタスクに分解して、自分で管理しましょう。
タスク細分化で作業の全容を知ることが大切で、未然にリスクを認知することができますし、進捗管理もしやすくなるでしょう。

とりあえず！
細分化したタスクの粒度はあわせるべきですが、最初は完璧でなくても問題ありません。
最初のうちは、洗い出したタスクを依頼者にレビューしてもらいましょう。

1-3. タスクを定量的に計る努力をする

自分も上司も、みんなが気にしているのはいつまでにできるかです。

そのためには適切な見積もりと進捗管理が必要です。新人さんにとっては未知の領域であり、難易度が高いかと思います。
しかし見積もりの勘所がなくても、1-2のタスク細分化が出来ていれば、なんとか数字捻出することができます。これが大事です。
でたらめな数値と思うかもしれませんが、細分化の精度次第では誤差はあれど意外と酷くはなりません。

とりあえず！
新人さんのうちから完璧な見積もりや進捗報告を求められることはない思います。
重要なのは、とにかく数字を計算して誤差を減らしていき、有事の際にいかに早くアラートを出せるかです。

注意
進捗の数字というのは要注意です。PJで決められた評価方法で計算すると（●●まで達成したら50%〜など）、80%から進みが極端に遅くなるなんてことも起き得ます。
個人で管理するなら、オススメは残り時間で計算することです。(予定工数-残り所要時間)/予定工数が進捗のパーセンテージです。（作業者の質にもよりますが）もっとも現実的な数字が採取できると思います。

1-4. Yes/Noは論理的に答える

作業を依頼されたら即答せず、一旦タスク細分化をしましょう。
そして所要時間・難易度などを計算したうえではっきりと可否を答えるようにしてください。
（Noとなった場合もそこで思考止めず、どうすればYesになるのか、可能な限り考えて提案すると最高です。）

とりあえず...
「とりあえずやってみます...」は、超危険ワードです。たいてい依頼者は 100% やってくれると信じます。
「やるか、やらないか、ためすなどない。」 マスターヨーダも言っています。

注意
感情を交えて回答するのはやめましょう。残念なことに、たいてい嘘になります。
システム開発で嘘をつくと、問題が膨らんで返ってくるだけで、みんな不幸になります。
（時と場合において嘘も必要ですが、マネージャクラスの仕事です。）

1-5. とにかく疑う

どんなモノも人間が関わるので、作業依頼も、設計書も大なり小なり必ず誤りが存在します。
そういったときに「指示通りにやりました」といえば当然自分の責任は無くなります。
ただ、本当にプロダクト品質のことを考えるのであれば、指示内容を疑う、仕様を疑う、設計を疑う、など疑問を持つのも一つです。

とりあえず！
疑う力がプロダクト品質に直結するといっても過言ではありません。
何かあったらすぐアラート、早いうちから鍛えていくと良いと思います。

注意
残業が多くなったらタスク全体を疑い始めましょう。
自分か、上司か、顧客か、とにかく誰かが無駄なことをし始める可能性が高いです。
スケジュール逼迫状況では、59点を60点(合格点)にする意味はありますが、60点を61点にする意味はあまりありません。
そして、無駄な作業は何かしているように見えるため誰も止めようとしないので、手の届く範囲であれば教えてあげてください。（こういうのは若手の方が無邪気に突っ込みやすい）

1-6. 契約形態を理解する

請負、委任、準委任(SES)契約などにおいて自身の役目・スコープ・責任を正しく認識しておくことが重要です。
これがあやふやな人は、本来やるべきではない作業を任されたり、責任を問われたりします。

とりあえず！
（現場はSES契約なので）特に指揮命令系統を意識して作業しましょう。
法律関係なので詳しくは検索するか、マネージャに聞いてください。

1-7. 開発モデルを理解する

契約形態と同じくらい大切です。規模の大きい案件であれば、日本のSIerの多くがウォーターフォール（V字）開発です。
ウォーターフォールの各フェーズでのスコープ、達成条件は何か、マネージャに確認しておきましょう。

とりあえず！
各フェーズの終了条件が達成できないとどのような問題が発生するのか、認識して身構えておくことが大事です。
（できれば、問題を先送りにしようとしている人に注意してあげましょう。）

注意
そもそもウォーターフォール自体がエンジニアファーストの考え方ではないので、問題ありまくりです。
世界的にはアジャイル/DevOpsに移行してきていますが、日本(アジア)は特に遅れています。
苦しい思いをして今の開発スタイルに慣れるより、まずはアジャイル開発モデルを学習し、ウォーターフォール開発の問題を認識するほうが大切かと思います。

ex. マネジメントを勉強する（ベテラン氏より）

マネジメント分野に手を出す、つまりPM(プロジェクトマネージャ)やPL(プロジェクトリーダ)を経験するというのは良い選択です。
PM/PLを経験しておくことで、問題が発生した際に全体を俯瞰的に見て誰が何の作業が出来ていないか判断する力がつきます。
不適切な決断を未然に食い止めたり、警戒して距離感を取り防衛することができるようになるかもしれません。

とりあえず！
日本のSIerにおいて手早く出世するにはPMになることです。
（悲しくも、基本的にDeveloperは評価されにくいです。）

注意
プログラムを避けるためにPMを目指すという人は少なくありません。
彼らでもマネジメントは可能ですが、ほとんどの場合において技術に明るいマネージャのほうがプロジェクトは円滑に進みます。
これを読んでいる新人さんが将来マネージャになったとして、技術知識の研鑽を怠らないでいて欲しいと思います。

2. 技術面

2-1. コーディングの原理原則を覚える

コーディングに大切な要素は数えきれないくらいたくさんあります...が、紹介しきれないので
今まで見てきたプログラミング初心者(自分含む)で、全員に共通して言えた要素を紹介します。

DRY(Don't repeat yourself) | 繰り返すな。

コードをコピペした瞬間に何かがおかしいと感じてください。
無駄にコードが増えるということは、他者がコードを読むにも、変更があった際の修正にも時間がかかると最悪です。
これ以降の全てに言える話ですが、コードは誰かが保守をしていきます。
未来、誰かの時間を奪う、苦しめるようなコードにならないようにしましょう。

とりあえず！
ロジックは基本的にコピペ厳禁！

KISS(Keep it simple. stupid!) | シンプルにしておけ、この愚か者。

ありがちなのが「多く書いていたほうが分かりやすいかも...」とコードを増やすことです。
基本的にコードはシンプルが好ましいです。
日本語とは違うので、書いてあることが少ないほうが余計なことを考えずに済むので、読みやすいのです。

とりあえず！
読みやすさが大事ですが、プログラミング初心者が思う読みやすさと、他者の読みやすさは乖離しているケースが多いです。
なので、まずは「もっとシンプルに書けないかを常に意識する」というやり方が良いと思います。

注意
ある程度コードが書けるようになると、高度な技術を使い強制的にコードを短くする、つまり難読化をしてしまうケースがあります。
そういうレベルに到達したときには、「他者にとっての読みやすさ」を心がけてコーディングをしたほうがよいでしょう。

YAGNI(You ain't gonna need it) | それはきっと必要にならない。

今言われていないことまで想定して作る必要はありません。
必要になるかもしれないと作り込んだコードがもし不要だった場合、
改修や保守をする人は「なぜこんなコードが？意味があるのか？」と解読に時間を取られてしまうことでしょう。

とりあえず！
こう言っておきながら、YAGNIのバランスは非常に難しいです。
製造する機能がどの頻度で変更されるかに影響されるからです。
丸投げですが、困ったときは製造リーダに相談しましょう。

注意
これと併せて意識しておきたいものに、OCP（オープンクローズドの原則）というのがあります。
こちらのOpenの部分は「拡張性が高いコードを作れ」というもので、YAGNIとは逆のように聞こえるかもしれませんが、共存しています。
拡張要件が決まったときに、的外れで複雑なコードを改修するより、YAGNIが適用されたシンプルなコードを改修するほうが簡単、ということです。

名前重要

一番当たり前のようで一番大事な要素が「名前」です。
プログラムにおいて、クラス名・メソッド名・変数名...など名前はたくさん出てきますが、
全て誰が見てもわかる名前を付与しなければいけません。（変数のスコープが短いものはある程度許容されますが）

名付けには2つの意味があります。

1. 名前である程度の処理内容や状態を提供し、改修/保守する人のために読みやすく時間がかからないようにする。
2. 本当に意味が理解できていないと名付けができない、よって自分の理解不足に気がつける。

個人的に、2番目が新人さんにとって重要かと思います。

とりあえず！
名付けはとても大事な作業の一つであると認識してください。
そして名付けにはルールがあります。まずは、現場のコーディング規約をしっかりと読んでください。

驚き最小の原則

プログラミングをしていると、自分では何が正しいかわからなくなる時があります。
迷ったときは、驚き最小の原則を適用してください。
使う人、見る人がもっとも驚かなくて済むような設計/実装にしましょう。

とりあえず！
数日後にレビューする人、数年間に保守する人、数十年後に解析する人にとって読みやすいコードを、
と意識すると必然的にできるかと思います。

ヒント
以下の記事が分かりやすいです。

• あっと驚かせるJavaプログラミング(をやめよう）

2-2. デザインパターンを知る

先人たちの知恵です。どれも特定の状況においての最適解を提供してくれます。
1人で悩んで悩んで出した答えは、きっとデザインパターンに含まれているでしょう。
なので、まずは知ることが大事です。

とりあえず！
デザインパターンは意識しなくてもFWが半自動的にやってくれてたりすることもありますが、
非機能でバグが出たときのためにも、どういう設計で動いているか正しく把握しておきましょう。

ヒント
デザインパターンに関しては以下の書籍がケーススタディ付きで学習しやすいです。（お値段そこそこしますが...）
アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

2-3. 異なるパラダイムを学ぶ

（最低限一つのプログラミング言語を基本構文を覚えてからですが）
静的型付け言語しか触れたことが無いなら動的型付け言語を、オブジェクト指向なら関数型を、といった具合です。
異なるパラダイムを学ぶことで言語の特性を比較して理解できるので、非機能要件で悩んだときに正しい実装の助けになるかと思います。
実際Java8からラムダが実装されたように、勉強しておいて損はないです。

とりあえず！
（弊社はJava研修なので）Python3も視野に入れてみましょう。

ヒント
KotlinというJVMで動く言語がJavaの問題点を解消したような設計思想です。
Javaをやっているのであれば手を出してみると良いでしょう。

2-4. 正規表現を覚える

異なる文字列をパターンで認識する魔法です。
特に調査において、人間が介入しないため「速い」「精度が高い」「再現性がある（レビューが容易）」と絶大なメリットをもたらします。

とりあえず！
文字列操作で1分以上同じことする暇があったら正規表現使うようにしてください。

注意
正規表現は深いです。
最初のうちからメールアドレスのValidateがすぐに書けるレベルまでは不要だとは思いますので、あまり身構えずに挑戦してください。

2-5. UMLを覚える

我々の世界の共通言語です。
システムを図解して説明するときはUMLを利用すると、認識齟齬が抑えられます。

とりあえず！
完璧ではなくてよいので「アクティビティ図」「クラス図」「シーケンス図」をさくっと書けるようになっていれば、色んな話し合いが上手くいくことでしょう。

ヒント
UMLを書きたいときは、PlantUMLが便利です。（私は使っていませんがmermaid.jsも有名）
テキストベースなのでバージョン管理もしやすく愛用しています。Atom,VSCodeアドオンもあります。

2-6. Markdownを覚える

Markdownはテキストの共通言語のようなもので、構造的で可読性の高い文章を短時間で書くことができます。
（この文章もMarkdownで書かれています。）
様々な技術系のサービスから、個人メモ、TODOリストまで、幅広く利用することができます。

とりあえず！
議事メモなどを自分オリジナルの■や[TAB]で整理せず、Markdownで書いてみましょう。
まずはたくさん書いて、構文を覚えてください。

ヒント
テキストエディタでも扱えますが、Markdown対応エディタを利用したほうが便利です。
昔はSublimeTextが有名でしたが、最近はAtom、Visual Studio Codeが人気のようです。

2-7. 本を読む

手早く安価に他者のノウハウを吸収するのに、本は良いツールです。
とくに新人さんのうちは「知らなければ誤りに気がつけないし学べない」という壁があるので、
本を読み、知見を広げるというのはとても大切な行為だと思います。

とりあえず！
新人時代に読んでよかった本を列挙します。
業務で必ず使えるテクニックが載っているので、金銭的・時間的に余裕があれば読んでみてください。
（言語やツールに特化したような専門書は抜きで、汎用的なものだけ記載）

• Clean Coder プロフェッショナルプログラマへの道
  プロのDeveloperとしての業務の行い方、心構えが学べる本。
• プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
  あらゆるシステムの原理原則を載せたカタログ的な本。
• リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
  プログラムで必須のお作法を学べる本。
• アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技
  プログラミングの原則からデザインパターンまでプラクティス付きで学べる教科書。

3. プライベート面

3-1. 心と体の健康を大事に

最近は変わりつつあるものの、業界的にはまだまだブラックのイメージが強いです。
事実、違法なことは無くとも、スケジュール逼迫による長時間残業や休日出勤が多々あります。

ハードワークとオフィスーワークの相性は最悪です。
座っているだけで血流が悪くなり、体調不良にとどまらず、いらいらする、落ち込む、と精神的疲労を加速させます。
うつ病にならないための自己啓発本は沢山ありますが、そんなことより、まずは体の健康を大事にしましょう。

とりあえず！
筋トレです。（もちろん有酸素運動も大事です。）

ヒント
筋トレが最強のソリューションである マッチョ社長が教える究極の悩み解決法

---

以上となります。
別視点で、もっとこうした方が良いなどあれば大歓迎です。参考にさせていただきマッスル。

Illust : ヒューマンピクトグラム2.0 - TopeconHeroes