「ようこそ魔境 SIerへ！」

はじめに

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

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

それも非効率なので、実際に私が２年半¹で失敗したこと、やってきてよかったこと（ノウハウ）を体系化したので共有します。

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

対象読者

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やスクラム手法)を学習し、ウォーターフォール開発を少しでも改善していくことが大切かと思います。

カイゼン・ジャーニーたった1人からはじめて、「越境」するチームをつくるまで
日本のSIer向けのアジャイル開発・スクラム手法の取り組み方。なかなか改善できない環境のあなたに。

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) | それはきっと必要にならない。

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

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

Name is important | 名前重要

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

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

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

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

とりあえず！
名付けはとても大事な作業の一つであると認識してください。
そして名付けにはルールがあります。まずは、現場のコーディング規約をしっかりと読んでください。言語によってはネーミングのリファレンスが用意されている場合もあります。

Principle of least astonishment | 驚き最小の原則

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

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

ヒント
以下の記事が分かりやすいです。
あっと驚かせるJavaプログラミング(をやめよう）

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

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

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

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

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

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

ヒント
個人的には最近だとPython(激押し)、Go、Kotlin、Scalaが好きですね。³
KotlinはJVMで動き、Javaの問題点を解消したような設計思想です。
（弊社はJava研修なので）手を出してみると良いでしょう。

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

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

とりあえず！
文字列操作で1分以上同じことする暇があったら正規表現使うようにしてください。
とにかく練習して体で覚えていくほうが楽かと思います。正規表現は深いですが⁴、あまり身構えずに挑戦してください。

2-5. UMLを覚える

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

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

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

2-6. Markdownを覚える

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

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

ヒント
以下の記事のように、エディタを導入しテンプレートを作成すれば、うんざりするような会議を爆速に出来るかもしれません。
会議を爆速にする、Visual Studio Code 超便利スニペット集

2-7. 本を読む

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

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

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

3. プライベート面

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

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

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

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

ヒント

全て筋トレで解決するのです。 - 筋トレが最強のソリューションであるマッチョ社長が教える究極の悩み解決法
お金が無くても筋トレは出来ます。 - プリズナートレーニング圧倒的な強さを手に入れる究極の自重筋トレ

おわりに

いろいろ書きましたが、経験しないと分からないことも多いと思います。
新人さんが行き詰まったとき、立ち止まって見てもらえるような記事になっていれば幸いです。

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

プロトタイプ → 調査 → 基本設計 → 詳細設計 → 製造/単体テスト → 結合テストなうといった感じです。一番苦労したのが「調査」です。成果物も決まったものがなく指示も曖昧なので、よくレビューで~~怒られ~~指摘を受けました。作業の進め方やマインドまで指摘されたおかげで、業務面のノウハウはほぼこのフェーズで固まりました。
新人さんは、これを参考として、使えるところだけ今後の業務に持っていってください。 ↩
私は失敗することも成果だと思います。エジソンも言っています。 ↩
現場にはHaskell激押しの変態エリートもいました。すごいH本おすすめだよ！と突然言ってきたときはどんなセクハラかと思ったら、「すごいHaskellたのしく学ぼう！」という本でした。英語の原文は公式からオンライン上に公開されています。 ↩
「メールアドレスのValidateぐらいすぐかけるよなァ？」とかいう変態エキスパートが現場に1人いたりいなかったりしますが無視してください。 ↩