元 Web アプリ保守コンサルから文系新人コンサルさんへのアドバイス

目的

　文系から IT の世界に飛び込んだ方へ, 前職の記憶が残っているうちに経験を基にしたアドバイスを書き残しておこうかと思い立ちました。
　ここに書くことは, ちゃんとコンピュータサイエンスを修めていたり, 実務経験がある方にとっては当たり前のことばかりですが, 自分のような文系新卒には当初わからないことばかりだったので, 同じような経歴の方に届けばよいなと思います。

　偉そうなタイトルですが, 内容は大したことは書いていません。
しかし, 現代日本の IT コンサルタントの中には, 当時の自分がそうだったように, 未経験でアサインされてすぐに顧客先で対応をしなければいけないこともあります。
このため, 意外とこれら当然のようなことを学ぶまでに, けがをしてしまう人は多く存在するものだと思っています。
そうした方がなるべくけがをしなくて済むよう, あるいは軽傷で済むよう, この記事が届いてくれればうれしいです。

　なお, 次の節で前職の状況を書いていますが, ニュートラルな姿勢であって前職の批判などの意図はありません。

前職の話

　これがどんな方に役立つ記事なのかをはっきりさせるために, まずわたしの経歴を簡単に書きます。

　プロフィールにも書いている通り, わたしはコンピュータサイエンスを修めたことはなく, 修士新卒で IT の世界に入って, 研修後保守コンサルに配属されました。
当時はサーバの概念すらよく分からず, 世の Web サービスがどう成り立っているのかも全く分かっていませんでした。
そんな状態でしたが, 思うところあって IT の世界で開発職をやりたいと思い, 修士卒で就職しました。

　研修を終えた段階で基本情報技術者試験午前合格程度の知識は詰め込み*1, Web アプリを扱う部署*2に配属されました。

　配属面談では開発職志望を強く伝えましたが, 当時の人員の関係と, 自分の能力も足りなかったのでしょう, 結果的に保守コンサルタントに配属されました。
正直対人スキルは低いと自認してるので, 意外な結果でした。当時の状況を考えると, コンサルがどんどん減っていた状況だったので, パッと見外に行けそうだしいいだろう, くらいの判断だったのではと思います。
　なお, 前職の保守コンサルタントはいわゆる「IT コンサルタント」というより, 「自社製品特化の保守作業を行う人」のような印象です。
総合的に様々な製品・ツール導入を判断したり, IT 製品導入のための施策や戦略を考えるのではなく, 日々つつがなく自社製品が稼働することを保つことが一番の業務内容でした*3。

　そんな状態で製品研修もほぼない中, お客さん先に先輩と行き, びくびくと何回も確認しながらコマンドプロンプトを叩いたような気がします。
　そこから大体 3, 4 か月の間に先輩コンサルがどんどん辞めていき, あまり引き継ぎや教育はない中, どんどん仕事が増えていきました。
幸い周りには優しい方が多く, 重い内容の時は先輩がついてきてくれたり, 困っているようなコメントを作業記録用チケットに書くとインフラ担当の方も助けてくれたりと, いろいろとサポートしてもらっていました。
　しかし, 周りの方の工数ももちろんぎりぎりなので, あまり理解できていないままの状態で, 迫る納期に向けて試行錯誤でバッチ処理用 SQL を要望に合わせて編集したり, 製品バージョンアップ手順を作ってローカル環境で試したりと一人でせざるを得ず, 結合的な動作確認や先輩のチェックをしてもらうまでの段階で無駄に躓くことが多かったように思います*4。

　わたしは能力の問題もあってか, こうした前職の配属直後の躓きが中々にありました。
　しかし, 曲がりなりにも数年仕事を続け, かついろいろと業務外での学習も重ねた結果, 当時の自分のような配属直後の方には, いくつか送るべきアドバイスを考えられるようになりました。

アドバイス

　ここから, 上のような境遇と重なる方向けに, 早目に知っておいてほしいアドバイスをいくつか書いておきます。
自分が当時早目に知るべきだったことを思いついたまま書いてるので, 粒度は様々なものとなっています。

1. 基本情報技術者試験レベルの知識は最低でも抑えておこう

　わたしが言うまでもなくあちこちで言われてはいますが, 基本情報技術者試験レベルの知識は必ず役に立ちます。
できれば応用情報技術者試験レベルまで抑えておくとより良いです。
特に, もしあなたが技術職を続けたいと思っている場合や, 同じ業界での転職を視野に入れている場合などは, 強力な武器になります。
これら試験では必須の知識が体系的に, かつコンパクトにまとまっているので, 何を勉強したらいいかわからない, という方はまずこれに取り掛かることをお勧めします。

キタミ式イラストIT塾 基本情報技術者 平成31/01年 (情報処理技術者試験)

キタミ式イラストIT塾 応用情報技術者 平成31/01年 (情報処理技術者試験)

2. リッチなテキストエディタを使おう

　前職でプログラムなどをこれまで触ってこなかった人は, 割とエディタにこだわらず, Windows メモ帳 (notepad) やサクラエディタなどを使い続けていました。
サクラエディタも軽量でよいエディタですし, 拡張もできて必要な機能は備えていると思います。
実際, わたしの前職の経験豊富なコンサルタントの先輩や, インフラチームの方の中には, メモ帳やサクラエディタを使っている人もいました*5。

　ただし, 彼らのように経験や知識があればそれでも効率的な作業ができますが, 我々のような不慣れな人間がシンタックスハイライトもないメモ帳などを使って xml や SQL, conf を触っていると必ず事故ります。
そして無駄な時間をかけてしまうし, 作業に大きなストレスを感じてしまいます。

　もしあなたがあまりプログラミング経験がなく, かつメモ帳やサクラエディタ, 秀丸エディタなどの軽量エディタをメインで使っている場合, Visual Studio Code や Sublime Text などのリッチなエディタをぜひ使ってみてください。
これらを使うことで編集中のファイルの見通しがかなり良くなり, かつプラグインなどで拡張していけば日々の作業のストレスは大きく減ります。

　なお, サクラエディタなどを否定しているわけではなく, わたしも用途に合わせて VS Code とサクラエディタを使い分けています。
がっつりとファイルに手を入れるときは上記のようなリッチなエディタを, そうでないときにささっとファイルを閲覧・編集したいときはサクラなどといった使い分けは十分ありだと思います。

3. 改行コードに気を付けよう

　これは「2. リッチなテキストエディタを使おう」と重なるのですが, 扱う製品が Windows, Linux 両方で動く場合は, 改行コードというものを意識する必要があります。
改行コードとは, 「改行」を表す制御文字です。
普段我々がテキストを入力しているとき, Enter や Return などを押すだけで改行が実現できており, 「改行」を表す何かを目に見える形で挿入することはほぼありません。
こうした一見目に見えない改行をコンピュータがどう認識しているかというと, この改行コードが Enter や Return を押したときに挿入されているので, 改行を表現することができています。

　ところが, この改行コードはややこしいことに, OS によって異なるコードを使っています。
具体的には, Windows では CRLF (Carriage Return / Line Feed), Linux では LF (Line Feed) となっているのです*6。
このため, 例えば Windows 上で設定ファイルなんかを作成して, それを SFTP や SCP でそのまま Linux に送ってファイルを読み込ませようとすると, CRLF を改行コードと認識できず, 思いがけないエラーとなることがあります。

　これを防ぐためにも, 「2. リッチなテキストエディタを使おう」が必要になります。
Windows メモ帳では表示されませんが, リッチなテキストエディタでは, 大抵右下に現在編集中のファイルの改行コードや文字コードが表示されています。
また, そこをクリックすることで簡単に改行コードの変換が可能です。

　このため, 改行コードの違いを知っておく, OS に合わせた改行コードでファイルを作成することで, 不測のエラーを防ぎ, また発生しても原因切り分けの引き出しの一つにすることができます*7。

4. テック系の Podcast を聞いてみよう

　これは趣味の範疇にも入るのですが, 今の世の中にはテクノロジーについて第一線の方が語る Podcast が存在します。
個人的なお勧めとしては, Rebuild.fm, Turing Complete FM なんかが好きです。
わたしは通勤時などによく聞いていますし, 満員電車に揺られざるを得ず, 本も開けない状況でも, Podcast は聞けます。

　しばらく会社に勤めていると, その業務に関わる範囲でしかアンテナが立たず, かなり閉じた世界に生きることになりがちです。
しかし, これら Podcast を聞くことでアンテナを広げておくことができ, それも第一線の方が最近のトレンド, イベント, 事件などについて語る様子を聞けるため, 勉強にもなるし面白いです。

　わたしの例では, 当時 GDPR が盛り上がったときや, Spectre, Meltdown なんかが話題になった頃, これらでキャッチアップできていたためお客様との定例会などで, ちょっとした話題が出たときに話についていくことができ, 信頼を得ることができました (扱っていた製品と当時の状況から, わたしの職務内容とは関連がない話題だったのですが, それでもキャッチアップできていたことで認めてもらえました。何が幸いするかわかりません)。

　単純にエンターテイメントとしてもおもしろいので, まずは比較的ライトな Rebuildfm からぜひ聞いてみてください。

rebuild.fm

5. Linux を勉強しておこう

　今や OSS の時代で, この業界どこでも Linux に触れる機会は多くあります。
前職では Windows Server を導入されているお客様の方が多かったですが, 顧客先でなくても社内システムや転職先など, Linux が存在しないことはほぼないと言えるのではないでしょうか。

　もしあなたが転職を視野に入れている場合, または技術職としてのキャリアチェンジを考えている場合は, 必ず Linux の知識は必要になります。
基本的な概念やコマンド操作には慣れておくと, いざというとき役に立ったり, 選択肢が増えるので, ぜひ抑えておくことをお勧めします。

Windows のラップトップに VirtualBox などで簡単に仮想環境が構築できる時代なので, いつでも触れる環境を一つは用意しておくとよいと思います。

新しいLinuxの教科書

6. プログラミング言語を一つ触っておこう

　これはコンサルから QA, PG などにキャリアチェンジを考えてる方は言うまでもないですが, コンサルを続けたい方にもお勧めしておきたいものです。
プログラミング言語は, 読むだけなら文法や構造が似通っているところがあります。
このため, 一つの (メジャーな) 言語を触れるようにしておくと, 未知のエラーが発生したときの原因切り分けに役立ったり, 社内の業務ツール作成などにも役立ちます。
最近は Python が人気で, わたしも当時 Python を勉強しました。

　前職でコンサルがよく使うツールの一つが Python で実装されていたので, そのコードを読んで自分がツールを作るときの参考にしたり, Java の製品プログラムで予想外の挙動をしたときに自分でデバッグして原因切り分けをしたたりできました。
人員が足りていない状況や忙しい時期では, PG やインフラチームに応援を頼むことが難しい状況が残念ながらあります。
そんな状況でも何とかしなければいけないことはあり, そんな時に自分で少しでも調査を進められるようになっていると, キャリアチェンジ時の自分も含め, いろいろなものを助けることができます。

併せて, Git, Github にも慣れておくとよりよいです。
開発系でも QA 職でも, Github が使えるのは当然のリテラシーのようになりつつあると感じます。
幸い今年 2019年初頭に Github のプライベートリポジトリが無償化されたので, どんどん commit, push してみるとよいと思います。

Pythonチュートリアル 第3版

GitHub実践入門──Pull Requestによる開発の変革 WEB+DB PRESS plus

7. 便利なツールはどんどん使おう

　同じ作業でも, ツールを使うことでぐっと効率が上がることが多々あります。
具体的な例では, 私がお世話になったのは 2つのファイルの差分を比較するための diff ツールでした。
WInMerge (http://winmerge.org/?lang=ja) なんかが有名だと思います。

わたしは最終的には VSCode の diff plugin を使っていましたが, 設定ファイルの変更・差し替えなどを行うことの多いコンサルタントには重宝するものです。
非常にお世話になりました。

これをはじめとして, 世の中には便利なツールが多くあります。
社内ポリシーンなどによってダウンロード・インストールが制限されていることもあるかと思いますが, こうした便利なツールを活用することで作業ミスを防ぎ, 作業効率も大きく上げることができます。

　ぜひ自分の作業に使えそうなツールを, 周りの人に聞いたり探すなどしてみてください。

最後に

　以上になります。
思いつくままに書きましたが, 知っている人からすると当たり前のことを書いているだけだとは思います。
　しかし, 少なくとも当時の自分は恥ずかしながら, これらのことすら意識できないままがむしゃらにやっていました。
きっと当時の自分と同じような境遇になりそうな方, 陥ってしまっている方は一定数おり, そんな方にもしも届いたのなら幸いです。

*1:そういう講義があったわけではなく自習です

*2:思いっきりぼかしてます

*3:後半は部署でもっと積極的な施策, 例えば製品のより良い使い方の提案や営業との連携なども動き始めましたが, 当時は部署・個人のキャパ的に無理でした

*4:本当にやばいときはあり, そのときはいろいろな先輩が休日にも関わらずオンラインで助けてくれたこともありました。本当に感謝しています......

*5:世の中には notepad で OS を自作するような人もいますが, 例外です

*6:Mac OS 9 以前では CR を使っていましたが, 今やほぼないと思われるので割愛します

*7:ちょっと前の notepad では UTF-8 のファイルを保存すると必ず BOM付きで保存されてしまい, このため前職でエラーが多発する, ということがありました。今は大丈夫かもしれませんが, こんなこともあり notepad はおすすめしていません