ITインフラ事業本部 ITS第3部
テクニカルスペシャリスト 秦 拓郎
はじめに
こんにちは！テクニカルスペシャリストの秦です。今回はITインフラエンジニアのジュニア層の方々に向けて、派手さはなくてもシンプルに強い「リアルITインフラエンジニア」になるために取り組むべき「学習の習慣」と、ジュニア層がつまずきがちな「ITインフラにおけるシステム開発の実務」についてお話しします。
背景
ご存じの通りIT業界は人材不足といわれており、我々SIerのITインフラ業界も例外ではありません。特に近年のクラウドプラットフォーム勃興でIT人材の需要が高い状況が続いており、未経験者にも門戸を開いて人材の獲得を進めています。ここで問題になってくるのが教育キャパシティの不足です。人を増やすことができても、その人たちを教育できるITインフラエンジニアが不足しているのです。
特に不足しているのはミドル層です。その原因は、2009年ごろに起きたリーマン・ショックによる世界金融危機の影響や、国内でも超巨大プロジェクトであるみずほ銀行の次期システム移行が終盤に差し掛かり、それに従事していたIT人材が解放されて人が余ると予測されました。その結果、採用を縮小・抑制した時期があったのです。
その結果、SIer的IT業界はシニア層とジュニア層に人材が偏るという構造的な問題を抱えることになりました。
さらに人材育成は従来からOJTに重きを置いており、それをミドル層が担っていたことから、先述の構造的な問題によってOJTの担当がジュニア層とシニア層に分散することになりました。
ジュニア層がジュニア層のOJTを担当するというのは、OJTを担当する方の育成にもなるというシナジーもありますが、技術力や経験の不足が補いきれない面もあります。
シニア層は多くの場合チームの主力となって業務を進めていく役割も担っているため、業務とOJTとの両立で疲弊したり、トレードオフによってどちらかがおろそかになったりということもあります。
この状況は、すべての層に「このままやっていけるのだろうか」という、キャリア不安をうっすらと生み出しています。
一方で、ジュニア層が自ら学び、成長していくことでキャリア不安に立ち向かい、ワーク・エンゲージメントを高めていくことも十分可能だと思っています。
そのため今回は、自分自身の成長を会社やチームに丸投げせず、強いITインフラエンジニアになるためのヒントとアクションをこのコラムで発信することにしました。
強いITインフラエンジニアに必要なのは枝葉末節の技術ではなく、揺るぎなき基礎です。技術は目まぐるしく進歩したり変化したりしますが、それに翻弄されずに生き抜いていくためには根底で繋がった基礎が必要なのです。
学習のこと
まえおき「記号接地」について
今回「記号接地」という言葉を多用していますが、これは「物事を身体的な体験や感覚で理解する」という意味です。AI技術でよくいわれる「記号接地問題」と同じく人間も記号接地できていないことがあり、学習や経験によって記号接地していく必要があることを説明するため使用しています。
学習と実務経験
ITインフラエンジニアに限ったことではないですが、学習と実務経験は両方大切です。学習だけでは現実的なことや具体的なことを理解するのは難しいですし、実務だけでは実務でやっていることがそもそも何なのかをメタ的・体系的に理解することも難しいです。学習したことを実務で記号接地するというようなサイクルを続けていくことが着実な成長に繋がります。資格のこと
まず結論として、学習を続ける上で資格の取得はスキルアップのマイルストーンとなりモチベーションにしやすいので、常に何かの資格の取得を目標にしておくとよいと思います。単にITインフラエンジニアの職に就くだけであれば必要な資格はありませんが、自分自身がやりたい仕事をある程度選びながらキャリアを築いていきたいのであれば、それに基づいた資格を持っているほうがよいのは明らかかと思います。
まず取得するとしたら基本情報技術者試験ですが、過去問やサンプルなどを見て歯が立たなさそうであればITパスポート試験や情報セキュリティマネジメント試験からステップアップしていくのもよいでしょう。前者は広く浅い内容でレベルは少し易しめ、後者は基本情報技術者試験と同じぐらいのレベルですが、範囲はセキュリティに絞られるため学習を進めやすい、という具合です。
基本情報技術者試験はITエンジニアの共通の語彙といえるものなので、合格しているか、または合格を目指して学習した経験があるかどうかで業務におけるコミュニケーションのコストが変わってきます。
私がプロジェクトリーダーとしてチームに新しいメンバーを受け入れる際も、実務経験と資格の取得状況で説明の用語やレベルを変えています。
また、基本情報技術者試験は特定のベンダーや製品に依存しないベンダーニュートラルな試験のため、実務に記号接地しづらいという側面もあります。そのため基本情報技術者試験の次はLinux、クラウド、ネットワーク、データベース、AI、ITILなどの入門資格の取得を目指してハンズオンを織り交ぜながら記号接地していくのがよいと思います。そこから先は思い描くキャリアや興味に合わせて上位資格を選んでいきましょう。
ちなみに、基本情報技術者試験などの国家試験以外の受験料はそれなりに高額のため、受験料補助や合格祝金など会社の支援がある状況で受験するのをおすすめします。
プログラミングのこと
ITインフラエンジニアはプログラミングをしないようなイメージがあるかもしれません。たしかにアプリケーションエンジニア（プログラマー）ほどのレベルではないですが、WindowsだとWindowsバッチやPowerShell、Linuxだとシェルスクリプトなどを使ってプログラミングできるスキルが必要です。Linuxではミドルウェアの制御をシェルスクリプトで行うことは珍しくないですし、システム開発においてはITインフラ担当でシステム運用設計・開発を受け持つこともあるため、システム運用を自動化するための運用スクリプト、システム運用管理者やシステムオペレーターが利用する運用ツールを作成することがあります。
最近ではIaC（Infrastructure as Code）も一般的になってきています。IaCの制御ファイルの作成にもプログラミングに近いスキルが必要です。
また、実際にコードが書けるかどうかも重要ですが、そのもととなるアルゴリズムやロジックを考えたり、理解したりできるかということはさらに重要です。コンピューターもロジック（論理回路）を中心に動作しているため、プログラミングの学習はコンピューターの動作原理を記号接地することに繋がります。
先述の基本情報技術者試験（特に科目B）にもアルゴリズムの問題は出題されますので、学習を通して考え方を身につけていただければと思います。
実務のこと
ここからはシステム開発の実務について少し実践的なことをお話ししていこうと思います。経験上、ジュニア層がよくつまずいている設計書とスケジュールのことや、AIのことについて述べていきます。
設計書のこと
突然ですが、世の中にITインフラにおける設計書作成の標準的なプロセスってあるのでしょうか。設計書に記載する内容について説明されているものはあっても、それをどのようなプロセスで作っていくのかについては、非常に暗黙知的であると思います。
ここでは基本設計や詳細設計における、設計書を作成する基本的なプロセスを示すことに挑戦します。ただし、この通りにやれば必ず設計書が完成するという絶対的な手順を述べたものではありません。様々な条件が顧客や親請けSier、プロジェクトによって毎回異なるため、やや抽象的になっていることをご了承ください。
設計書の作成は、設計そのものの重要な要素です。設計書を作成するために知識や技術を学び、目的を理解し、情報を集めて、考えて、作ってみて、人に見せて、直すことを何度も繰り返して完成に近づけていく。その過程で設計そのものも行われていくということを理解していただければと思います。
なお、そもそも要件定義などの上流工程、基本設計や詳細設計が何であるかのような標準的なことは記載しないため、そこは必要に応じて学習してみてください。
設計書の作成プロセス
- 予習する
各設計工程が始まる前に取り扱う技術領域について予習しましょう。可能であれば研修を受講したり、書籍を購入したりしましょう（もちろん会社のお金で）。
- 各設計工程で作成する設計書の目的を理解する
設計工程ごとに何を作成するかは顧客の社内規定などで決まっていることもありますし、プロジェクトごとに決める場合もあります。
基本設計や詳細設計で作成すべきものは何か、という標準的な前提に加え、プロジェクトで何を目的に何を作成することになっているかを理解しましょう。
これが理解できていないとこの後のプロセスはすべてうまくいきません。
- 書式（フォーマット/テンプレート）を入手する
設計書に記載する内容を定めたものや、その書式を入手しましょう。
顧客の社内規定などで決まっていればその書式を使用します。決まっていなくても過去の類似案件などで作成した書式があればもらいましょう。何もなければ一から作ることになりますが、ひとまずは管理しやすいように設計書の管理番号や作成日を記載したり、章・項・節や図表に番号が振られたりしていればよいと思います。
- 前提となる資料（インプット）を読みまくる
設計書を作成するために前提となる資料を集め熟読します。ただ文字を読むだけでなく、登場するユーザーや部署、アプリケーション、ミドルウェア、サーバー、ネットワーク、運用などについて、それぞれの関係までイメージしながら理解していく必要があります。
顧客の社内規定、上流工程の資料、ヒアリングシート、プロジェクト内で共有されている議事録、プロダクトベンダーやオープンソースソフトウェアのコミュニティが公式に発信している情報などが該当します。
- 参考となる資料（リファレンス）を読みまくる
設計書を作成するために参考となる資料を入手し熟読します。あくまで参考資料であり、設計書に直接転用することはできない点でインプットとは異なります。
リファレンスに該当するものは、類似プロジェクトの資料、ブログやSNSで発信されている情報、そしてAIが出力した回答などです。
あくまで内容のレベル感や書き方を参考にすることが目的であることに留意してください。
ジュニア層のメンバーに設計書を作成してもらうと、リファレンスの内容を設計書にコピペしてしまうというミスが高確率で発生します。結果的に内容が間違っていなければまだよいのですが、こういうときは大抵記号接地しておらず、内容について質問しても答えられないということが起こります。
- 設計書ごとの構成を作成する
いわば設計書ごとの目次です。記載する範囲とレベルを決めることになります。
基本設計の構成については、顧客の社内規定で決まっていれば、そこから取捨選択したり、プロジェクトの特性によって項目を追加したりします。決まっていなければ要件定義の成果物、IPAが公開している非機能要求グレード、類似プロジェクトの基本設計書類などが参考になります。
詳細設計の構成については、採用するプロダクトや環境によって内容が変わります。これも類似プロジェクトがあれば詳細設計書類を参考にすればよいですが、同じプロダクトでもバージョンなどが違うと内容が変わってきますので注意は必要です。
一から作成する場合は、設計対象（ハードウェアや仮想マシン、OS、各ソフトウェア、ネットワークなど）の実際の設定画面、設定ファイル、設定コマンドなどの単位で作成するとよいと思います。
- 情報を集約したメモを作成する
設計書ごとの構成に沿って、インプットやリファレンスの参照先、Webサイト、選択肢がある場合の比較と決定までのロジックなどを集約していきます。関連のありそうなあらゆることをとにかく載せていきます。
そしてそれらから導き出される、設計書に記載すべき内容も書き込んでいきます。この過程こそが設計の本質です。
ツールとしては、表などで情報を整理しやすく、画像なども貼り付けやすいノートアプリやExcelなどを使うのがよいでしょう。
- 下書き（ドラフト）する
メモの内容をもとに、書式にあわせて下書きしていきます。
1回目はとにかく速さ重視で最後まで走り抜けます。不明点などがでてきても、ちょっと考えたり調べたりしてわからなければ一旦コメントなどで代替して最後まで立ち止まらないようにします。
図表も最低限のイメージが伝わるレベルで描いておくか、何を描くか記したコメントを貼っておくだけでもよいでしょう。
気づきを得たり、不明点や過不足や誤解などを洗い出したりするためには、とにかく一度全部作ってみるのがよいです。
- 関係者内で共有して指摘をもらう
下書きができたら、関係者内で共有して不明点の情報や指摘をもらいましょう。
もらった情報や指摘を反映したら、またインプットやリファレンスを読んだり、構成を調整したり、メモの完成度を上げるということを繰り返します。このサイクルを多く回すことで完成度が上がっていきます。
最初はチーム内での共有から始め、完成度に応じて共有する範囲を広げていくのがよいでしょう。
- 魂をこめて仕上げる
下書きの完成度が十分に上がったら、文体を整えたりレイアウトやフォントなどの見た目を整えたりしながら完成図書として仕上げましょう。
魂をこめるというのは、設計書の隅々まで思慮と意図が行き渡っている状態にすることです。
魂がこめられていない設計書は、設計書の体裁をなした何かに過ぎず、それは設計をしたといえるものではありません。
スケジュールのこと
人間の行動の傾向として『パーキンソンの法則（第1法則：仕事の量は、完成のために与えられた時間を全て満たすまで膨張する）』と呼ばれる経験則があります。例えばあるタスクに3週間の期間が設定されている場合、本来2週間で終わる作業であっても3週間かけてしまうということが起こるのです。
プロジェクトはWBSやガントチャートなどでタスクとスケジュールが設定され、それに沿ってシステム開発を進めていくことになりますが、タスクに設定された期間を鵜呑みにすると『パーキンソンの法則』が発動しやすくなります。
その問題点は、不測の事態などが発生した際、対応する期間が残っていないとすぐに残業や遅延に繋がってしまうことです。スケジュール通り進めたにも関わらず、です。
これを回避するための対策は、自分自身やチーム内で独自に期間を設定して能動的にバッファ（余裕期間）を作っておくことです。
タスクの内容やもともと設定されている期間にもよりますが、感覚的には20%～50%ぐらいの期間で完了させるよう期限を設定するのがよいと思います。もとの期間が長いほどこの割合は小さくするのがいいでしょう。
独自の期間でタスクが完了しなかったとしても、それまでの実績から現実的に必要な残りの期間を見積もり、期限を延ばして対応します。結果としては本当に必要だった期間で作業が完了するはずです。
なお、独自に設定した期間について「どうせ本当の期限はもっと先だから」と甘くなってしまうと意味がないため、多少緊張感が生まれるよう、所属するチーム内でしっかり管理してもらうのがよいでしょう。
こうすることでスケジュールにバッファが生まれ、不測の事態にも対応しやすくなります。
また、次のタスクの予習や準備をしたり、プロジェクトとして問題がなければ次のタスクを前倒しで開始したりすることでバッファを維持し、不測の事態に強い、柔軟性のある作業体制を保つことができます。
AIのこと
AIについては、プロジェクト内で許されている範囲で好きなように使えばいいと思いますが、「とりあえずAI使ったら何かいいことあるだろう」という時期は過ぎました。現在のAIの限界を知り、AIを何の目的でどのように使うかを見定めた上でないと、かえって生産性を下げることになります。AIの出力する結果は、統計と確率によって数学的に選択された回答に過ぎないことを認識しましょう。数学的な計算結果からもっともらしい回答をしているだけで、正しいことを回答しようという意識も持っていないですし、質問者の思慮や意図を汲んでいるわけでもないのです。学習のところでも少し触れた通り、AIは現実世界に記号接地していないためです。
それらを踏まえて、まずAIに代替すべき仕事は、自分自身にとって質的な負荷が高い仕事よりも、量的な負荷が高い仕事です。
質的に負荷が高い仕事とは、少しだけ自分自身の実力を超えたところにある仕事で、深い理解、熟慮、状況に合わせた判断などが必要な仕事のことです。一方、量的に負荷が高い仕事とは、単純作業やルーティンワークなどのことをいいます。
言い換えると「やればできるけど時間がかかる仕事」にAIを利用することで生産性の向上が見込めます。
具体的な実例として、とあるミドルウェアの設定ファイルを表形式に変換して（さらに設定項目ごとの説明を付けたりして）詳細設計書の一部にしたり、運用スクリプトのテストのために大量のテストデータをCSV形式で出力したりする作業をAIで代替しています。
一方で質的な負荷が高い仕事については、そもそもAIに適切な質問を投げることが難しく、もっともらしい回答が得られたとしてもその正否を判断できないものと思います。そのためAIを利用するには生産性以前の問題があります。
ほうれんそうのこと
最後になりましたが、実務において最も重要なことは直属のリーダーへの報告・連絡・相談です。例えあなたに素晴らしい責任感があっても責任はとれないのです。責任をとるのはリーダーです。
何かしらの問題をひとりで解決しようとすることは、あなたの優秀さを何も証明しません。
問題が発覚したら、多少うしろめたいことがあってもすぐにリーダーに報告・連絡・相談してください。早ければ早いほど傷は浅く済み、結果的になんでもなかったということもありえます。
逆になんでもないはずだったことが黙っているうちに大きな問題になり、余計に言い出しづらくなってまた問題が大きくなるという負のスパイラルに陥ることもあります。その結果、体調を崩したり出勤しづらくなったりして、最終的にプロジェクトを離脱してしまうようなことがあるのです。
設計書のところで下書きの1回目は速さ重視だとか、スケジュールのところで期間を20%にするとかいっているのは、問題点を早く発現させて報告・連絡・相談してほしいという意図もあります。
おわりに
さて、いかがでしたでしょうか。長かったですね！我々も強いITインフラエンジニアを育成するにはどうすればいいだろうと日々考えを巡らせていますが、一方で強いITインフラエンジニアになったり、強いチームを作ったりするためにはひとりひとりの継続した取り組みも必要です。よろしくお願いいたします。
そのためにこのコラムが少しでも役に立てば幸いです。
余談ですが、今回このコラムを執筆するにあたり、AIの使用は最小限にとどめました。具体的には誤字・脱字のチェックのみとし、文章の作成には使用していません。
というのも前回のコラム「あなたもITエンジニアになれる」では、初めてのコラムだったということもあり、いろいろなことを気にして文体の修正や論理展開のチェックをAIで行ったのですが、その結果まとまりはよいけどもなんだかフラットで個性のない文章になってしまった気がしているのです。
AIに直してもらった文章を逆に修正するということもしましたが、なんだか気持ちは晴れず、先述の通り今回はAIで文章をどうこうするのはやめました。そのため乱文になっているかもしれませんが、勢いや熱量を感じ取っていただければと思います。
それでは、最後まで読んでいただきありがとうございました。仕事に戻ります！
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。
