はじめに
さらなるスキルアップを目指し、インフラ運用保守から上流工程へジョブチェンジして、気が付けば約１年半が経過していました。もう今年も終わるということで、自分を見つめ直し来年のさらなる成長に向けて、この１年半を振り返ってみようと思います。
また、過去の私と同じように、運用保守から抜け出して上流工程に挑戦したいと考えている方に向けても、書きたいと思います。（実際、運用保守の考え方のまま上流工程に飛び込んだら、かなり大変だったので……。）
運用保守担当だった頃
新卒入社2年目からの3年間、金融系プロジェクトでインフラ運用保守業務を担当していました。当時を振り返ると、参画した頃はインフラの経験が全くなく、毎日が苦労の連続でした。それでも、ひたむきに努力を重ねた結果、短期間で業務を独り立ちし、気づけば周りをサポートできるようになっていたあの頃の自分を褒めてあげたい！とはいえ、冷静に振り返ると、あのとき周りからのサポートや尊敬できる人たちに囲まれていた環境があったからこそ、成長できたんだなと、改めて実感しています。
そんな中、運用保守だけにとどまらず、上流工程にも携わりたいという思いが芽生え、さらに努力を重ねました。その結果、基本的に一度配属されると異動が難しいとされている部署から、上流工程に携わることができる部署への異動を実現しました。
あの当時の私の頑張り：
【 私がインフラ運用保守で意識して行っていること(コラム) 】
部署異動後のギャップ！
部署異動してからは、「設計・構築」「プロジェクト管理」「お客様調整」など、それまで経験のなかった業務に携わるようになりました。正直、運用保守を担当していた頃とのギャップがあまりに大きく、ものすごく苦労しています。しかし、これは私がやりたいと望んだ道ですから、逃げるわけにはいきません。
ここでは、運用保守と上流工程との間で、特に私が感じたギャップについて２つほど書いてみたいと思います。（もしかすると、これらは部署の特色によるものかもしれませんが。）
１．業務における正解はない
運用保守では、基本的に手順が引き継がれており、自分で一からすべてを考えて行う場面はほとんどありません。障害が発生した際も、確認方法や対応方法が詳細に標準化されており、よほどの例外がない限り、トライ＆エラーで進めることは厳禁とされています。なぜなら、本稼働中のシステムにおいてトライ＆エラーで対応することは、2次障害を引き起こし、お客様へさらなる影響を与えるリスクがあるからです。
ですが、構築以上の上流工程では、システムを守るのではなく「作る」ことが仕事になるため、基本的にはトライ＆エラーで進めていきます。もちろん、考えなしで進めるわけではありませんが、運用保守のように「これが正解」といえる方法は存在しません。そのため、質問をしても「私も知らないけど？」といった返答が返ってくることも・・・。（この点については次の項番で触れます。）
そのため、検証を重ねて最良の方法を模索していく必要があります。ただし、プロジェクトには工数（期限）が決められているため、無限に検証を続けることはできません。限られた時間の中でメリハリをつけ、最適な方法を見つける努力が求められます。
２．質問のあり方が違う
運用保守をしていた頃の私は、相手に対して「答えを持っているはずだ」という前提で質問をすることが多かったです。というのも学生時代は、基本的に答えが用意されていて、それを教えてもらえるのが当たり前の環境でした。そのため、自然と「誰かが答えを持っている」という考え方が染み付いてしまったのだと思います。さらに、運用保守の現場ではそれが当たり前の文化でした。（この点については、「項番1」で触れた標準化された業務が根底にあるためだと思います。）
上流工程にジョブチェンジしたばかりの頃、運用保守時代の価値観のまま質問をしていたため、思うような回答を得られませんでした。それどころか、質問返しや「私も知らないけど？」といった返答が返ってくることが多く、次第に質問すること自体がしんどくなる環境でした。（異動当時は入社5年目ということもあり、初めてのことでも教えてもらえるわけではなく、「むしろ、なぜできないの？」という雰囲気が漂う中でのスタート）
そういった状況の中でがむしゃらに業務に取り組むうちに、ある重要なことに気付きました。それは、「業務での質問は、単に答えを聞くだけの行為ではない」ということです。そのため、質問は以下のいずれかの形で行う必要があると考えています。（質問というより、相談に近いかもしれませんが。）
１．自分が考えた方法で進めても問題がないか、またその方法以外により適した案がない
かを確認する質問。
２．自分で考え、調べた上で行き詰まった場合に、現状を整理して相手に伝え、その上で
アドバイスを求める質問。
現在業務で意識していること
ここでは、私が業務を進めるうえで現在意識していることについて書いてみたいと思います。この意識していることは、この約１年半の経験を通じて得た学びが基になっています。
※ 成長途中の身であるため、間違っていることも書いているかもしれません。その時は、そっとコメントにご指摘ください・・・。
１．成果物の完成度は、気持ち８０％で十分
私たちが最も重要視しなければならないことは、納期に間に合わせることです。（少なくとも私はそう考えています。）使用できる工数（時間）や納期までの期限はあらかじめ決まっているため、たとえ100%の完成度を誇る成果物を作成したとしても、納期に間に合わなければ、売り上げやお客様からの印象はマイナスになってしまいます。
たとえ期間内に自分が納得する100%の成果物を時間をかけて作成したとしても、内部レビューを通過する際には必ず何かしらの修正が求められます。また、その後にお客様へ成果物を説明する際にも、追加の修正依頼が発生することは少なくありません。そのため、最初から100%の完成度を目指すことは、効率的ではありません。
そこで私は、成果物が約半分程度完成した段階（45～60%）で中間レビューを実施し、早い段階で依頼元との認識のズレを修正するようにしています。その後、完成度が約8割に達した段階で最終レビュー（納品）を行います。この時点でも修正が発生することを想定していますが、最終レビューを通過すれば終了としています。
このように、最初から完成度100%を目指すのではなく、早期のフィードバックと納期遵守を重視する進め方を徹底することで、効率的に業務を進めることができると考えています。
２．割り振られた案件（タスク）の初動
割り振られた案件（タスク）を何となく進めてしまうと、手戻りが発生する可能性が非常に高くなります。そのため、タスクに取り掛かる前に、次のような点をしっかり把握することを心がけています。
１．タスクのゴールは何か？何が求められているのか？
２．期限と工数はどのくらいか？
３．タスクが完了までに必要なタスクはどれくらいあるのか？
４．期限や工数が不足している場合、最低限抑えるべきポイントは何か？
これらを事前に明確にすることで、依頼元との認識のずれを防ぎ、手戻りが発生するリスクを最小限に抑えることができると私は考えています。
３．常に複数パターンを考える（+メリデメ）
物事を進めるうえで、必ず何かを選択しなければならない場面があります。例えば、設計やお客様への提案などです。このような場面で、複数のパターンを用意せずに1つの案だけで進めた場合、上手くいかなかったときに、再度ゼロから方針を決め直す必要が出てしまい、大きな時間ロスを招く可能性があります。
そのため、常に複数のパターンを考えておくことが重要です。さらに、それぞれのパターンについてメリット・デメリットを事前に洗い出しておくことで、選択が失敗した場合でもスムーズに再選択が行えるため、時間短縮にもつながります。このような準備を怠らないことで、効率的かつ柔軟な対応が可能になります。
４．確認・連絡・報告を意識する
基本的なことですが、何歳になっても「確認・連絡・報告」は非常に重要です。これを怠ると認識のズレやミスが発生し、手戻りのリスクが高まります。また、「確認・連絡・報告」をする際には、相手への伝え方も重要です。しっかり伝えられなければ、相手が正しく理解・認識できず、自己満で終わってしまう可能性があります。ただ伝えればよいのではなく、相手がきちんと理解し、認識できるレベルで伝えることが必要です。
だからこそ、私は以下のポイントを意識して「確認・連絡・報告」を行うように心がけています。
【確認の場合】
「確認」とは、私が何かを実施する際に、自分が考えた方法で進めて問題がないか、またはより良い案がないかを確認することを指します。その際、以下のことを意識しています。
１．自分が考えた案を簡潔に伝える。
２．なぜその案を選んだのか、メリットを含めて具体的に説明する。
３．その案のデメリットについても伝える。
４．選択しなかった案について、簡潔にメリデメを伝える。
（複数案を考えていることが前提）
５．最後に、この案以外により良い案がないかを確認する。
【連絡の場合】
「連絡」とは、報告以外の情報を関係者に共有することです。たとえば、会議日程の連携や決定事項に関する情報共有などが該当します。その際、以下のことを意識しています。
１．不要な情報を加えず、事実のみを即座に共有・周知する。
２．共有した情報が関係者に認知されているかを確認する。
【報告の場合】
「報告」とは、業務の依頼者に対し、自分が担当している業務の進捗状況や結果を伝えることです。その際、以下のことを意識しています。
１．主観や推測ではなく、事実のみを伝える。
２．結論から簡潔に伝える。
３．結論の後に、理由や詳細を補足する形で伝える。
４．最後に、今後の方針を伝える。
これらを徹底することで、スムーズに情報連携が行え、認識のズレやミスを防ぐことができると考えています。
５．受け身ではなく、能動的な行動を
どんな業務でも、当事者意識をもって取り組むことが大切です。「言われてからやる」「言われなかったからやらなかった」「言ったけど反応がなかった」といった受け身の姿勢では、業務に問題が発生するリスクが高まります。正直なところ、こうした責任感のないメンバーとは一緒に働きたくないですし、仕事をお願いするのも不安になってしまいます。
一方で、当事者意識を持って仕事に取り組むことで、業務に対するやりがいや達成感が生まれ、自分自身の成長にもつながります。自分ごととして業務に向き合う姿勢は、結果的に仕事の質を向上させ、チームやお客様に貢献できる働き方につながると私は考えています。
【当事者意識】
・どのような課題（背景）があるのかを理解する。
・どうしたら解決できるのか（どう解決したいのか）を考える。
・そのためにはどうすべきかを具体的に行動に落とし込む。
など
６．工数（時間）を意識する
プロジェクトには必ず工数が存在し、タスクごとに使用できる工数が決められています。その中でタスクを進める必要があるため、工数を意識することは非常に重要です。
タスクを何となくで進めてしまうと遅延が発生するリスクが高まります。そのため、計画的に考え、工数を考慮したうえで進める必要があります。具体的には、以下の点を意識します。
１．タスクを細分化し、必要な作業を明確に把握する。
２．工数（時間）内で確実に達成すべきポイントを優先する。
３．経験者からアドバイスを受け、短期間で効率よく対応する方法を模索する。
４．工数が明らかに不足している場合は、早めに上長へ相談し、対応方針を検討する。
これらを意識することで、与えられた工数の中で効率よくタスクを進め、スケジュール通りに完了させることが可能になります。しかし、それでも想定外のトラブルが発生し、タスクが遅延する場合もあります。その際は、速やかに状況を報告し、上長や関係者と連携することが重要です。
７．期待値にズレはないか
依頼主（お客様を含む）が依頼してくる際には、必ず達成してほしいと考えている期待値があります。この期待値の認識がズレてしまうと、手戻りが発生し、無駄なコストが生じるだけでなく、場合によっては信頼を失うリスクもあります。だからこそ、相手の期待値を正確に把握することが非常に重要です。
例えば、以下のようなポイントを意識することで、期待値のズレを防ぐことができます。
１．相手が求めている成果物やゴールは何かを具体的に確認する。
２．期待されている品質や納期について、明確にすり合わせを行う。
３．曖昧な部分がある場合は、その都度質問し、不明点を解消する。
４．進捗や成果を途中で共有し、相手の反応を確認する。
これらを徹底することで、認識のズレによる手戻りを最小限に抑え、信頼関係を維持しつつスムーズに業務を進めることができると私は考えています。
８．説明するときに意識すべきこと
説明が適切にできないと、相手に話を聞いてもらえない、あるいは聞いてもらえたとしても誤解されてしまい、認識のズレが生じることがあります。その結果、思わぬトラブルや手戻りが発生する可能性もあります。そのため、説明をする際には、以下のようなポイントを考慮することが重要です。
【説明時に意識すべきポイント】
１．誰に説明するのか
相手の立場や知識レベルを考慮し、適切な言葉や内容を選ぶことが重要です。
２．説明に使える時間はどのくらいか
制限時間を意識し、話す内容を取捨選択する必要があります。
３．重要な部分は何か、流してもよい部分はどこか
優先度を明確にし、重点を置くべき内容を丁寧に説明する必要があります。
４．前段（まえおき）を忘れていないか
説明を始める前に、なぜこの説明をするのか、背景を簡潔に伝える必要があります。
５．話すスピードに適切か
聞き取りやすいスピードを意識し、早口や間延びを避けることが必要です。
６．「え～と」「えー」などのつなぎ言葉（間投詞）を多用していないか
多用しすぎると聞き手に悪い印象を与えるため、適度に間を取る必要があります。
７．堂々と話せているか
自信を持って話すことで、聞き手に安心感を与えることができます。
たとえ内心自信が持てなくても、堂々と話すことで相手に不信感を与えないようにする
ことが大切です。
８．説明が文字だけになっていないか（表や図の活用）
視覚的な補助を活用し、相手がより理解しやすいようにする必要があります。
これらを意識することで、相手に正確でわかりやすい説明ができ、認識のズレや誤解を防ぐことができます。特に、相手の視点に立って説明を組み立てることが重要だと私は考えています。
９．自分の理解度を確認する
相手から説明を受けた後や、逆に相手に説明や質問をする前に、自分の理解度を確認することは非常に重要です。頭では「分かったつもり」でも、実際には理解が浅いことはよくあります。この状態のままでは、同じ説明や質問を繰り返してしまい、結果として非効率になることもあります。そのため、事前・事後に内容を紙などに書き出して言語化することが大切です。文字として書き出すことで、頭の中を整理し、理解を深めることができます。また、書き出す過程で曖昧な部分が明確になり、より正確な理解へとつなげることができます。
１０．技術者としての行動
私たちは技術者として、「動けば問題ない」という一般的な視点ではなく、責任感を持って業務に取り組むことが重要だと考えています。そのため、検証や調査を重ね、お客様の要望に合った最適な方法を選択する努力を惜しんではなりません。具体的には、私は以下のような場面で次のような対応を心がけています。
１．機能や設定への対応
新しい製品や機器を設計する際、機能や設定が多いと設計に時間がかかることがありま
す。その結果、一部の機能や設定を十分に理解せず、デフォルトのままにしてしまうこ
とも少なくありません。しかし、技術者として重要なのは「なぜその機能や設定が存在
するのか」を理解することです。私は、その意図を理解し、必要に応じて設定を最適化
することを心がけています。
２．サポートからの回答への対応
サポートに問い合わせを行い、いただいた回答をそのまま鵜呑みにするのは危険です。
なぜならすべてのサポート担当者がプロフェッショナルであるとは限らないためです。
中には誤った回答をするケースもあります。だから私は技術者として、回答をさらに
深掘りしたり、自ら調査や別の選択肢を検討するなどをして、最善の解決策を見つけ
るように心がけています。
１１．チームメンバーの管理
規模にもよりますが、基本的にプロジェクトは複数人で進めていくかと思います。しかしメンバーの中には、時折、工数や期限を意識せずにタスクを進めてしまう方も存在します。ですので適切に管理しなければ、進捗の遅れや工数の超過といったリスクが発生する可能性があります。こうしたリスクを未然に防ぐために、私がリーダーとしてプロジェクトを進行する際は、以下のことを実施しています。
１．タスク・期限・工数の認識合わせ
メンバーにタスクを割り振る際には、以下のポイントを明確にし、互いの認識を合わせ
てから取り掛かってもらうようにしています。
• タスクの詳細（何をやる必要があり、何をもって完了とするか）
• タスクにかけられる工数と期限
２．進捗状況の意識づけと課題の共有
進捗状況を管理するため、WBSと課題管理表を組み合わせた簡易表を作成し、メンバー
に毎日状況を記載してもらっています。これには、次のことを期待しています。
• メンバー自身が期限と工数を意識できるようにする。
• 現在抱えている課題や遅れを共有してもらう。
３．メンバーへの声がけ
メンバーが同じフロアで働いているため、手が止まっていたり悩んでいる様子を見かけ
た際には、時折声をかけて状況を確認するようにしています。これにより、行き詰まっ
ているメンバーの気分転換を促し、モチベーションの回復につなげています。
４．メンバーからの相談や質問
メンバーからの相談や質問には、快く対応するよう心がけています。これにより、相談
や質問がしやすい環境を作り、一人で悩む時間を減らせると考えています。ただし、手
が離せない状況の場合は、後ほどこちらから声をかけるようにしています。
このように、認識合わせ、進捗管理、積極的なコミュニケーションを意識することで、進捗遅延や工数超過を軽減できると考えています。
１２．根拠ない自信を持つ
「根拠のない自信」と聞くと、一見無謀に思えるかもしれません。しかし、私はこの根拠のない自信こそが、人を成長させる重要なマインドだと考えています。例えば、初めて新たなことに挑戦するとき、経験や知識がない状態でも、まずは行動することで少しずつ理解を深め、課題を乗り越えてきました。この「まず動く」姿勢は、根拠のない自信に支えられていると感じています。もちろん、単なる楽観だけではなく、行動を通じて結果を出す努力が伴わなければ意味がありません。根拠のない自信とは、「自分ならやれる」というポジティブなマインドセットであり、それが挑戦への原動力となります。失敗や悩みに直面した際も、「いまはまだできないだけ」と捉え、次の挑戦への糧としています。このように、根拠のない自信を持ちつつ、失敗から学び続ける姿勢が、成長への道筋を切り開いていくのだと思います。
１３．常日頃から技術研鑽
技術研鑽を怠れば、個人の能力は停滞するどころか、むしろ衰退してしまう可能性があります。この業界では新しい技術が次々と生まれるため、技術研鑽は必要不可欠です。（そもそも、技術に楽しさを見出せなければ、この仕事を続けていくのは難しい。）私は、自宅に開発環境を整備し、OSやミドルウェア、製品（例：Zabbixなど）などの検証を行いながら、日々楽しんで技術研鑽に取り組んでいます。検証を通じて新しい発見をすることは、技術への興味をさらに深めるきっかけにもなります。また、外部セミナーに参加することで、最新の技術やトレンドに触れる機会を意識的に作っています。これらの取り組みは、エンジニアとしての価値を高めるだけでなく、業務においてお客様により良い提案を行うための土台になると考えています。
とはいえ、何よりも大切なのは、楽しんで技術に触れ、技術で遊ぶことだと思います。
１４．研鑽後のアウトプット
技術はインプットするだけでは不十分です。学んだことをアウトプットしなければ、せっかくの知識も記憶から薄れていってしまいます。アウトプットの方法はさまざまありますが、私はブログを書くことをお勧めします。ブログは他の誰かに見られる可能性があるため、安易なことを書くわけにはいきません。そのため、記事を書く前にしっかりと調べ、検証した上で内容をまとめる必要があります。この過程が、学んだことをより深く理解し、記憶に定着させる助けになります。さらに、自分で書いた技術記事を後から見返すことで、学びを再確認することもできます。ブログは自己成長だけでなく、他の人への貢献にもつながるため、技術研鑽の一環として非常に効果的だと考えています。
これからの私
この１年半、さまざまな経験を積んできました。たとえば、ホテルへの無線環境の導入や、金融会社の基幹システムのクラウド移行といったプロジェクトなどに取り組みました。どれも初めての挑戦ばかりで大変でしたが、その分、とても濃い経験を得ることができたと思います。今後も他者と比較することなく、固定観念にとらわれず、失敗を恐れずに挑戦し、そこから成功を掴み取ることで、自分を確実に成長させていきたいと考えています。来年は、クラウド技術をさらに深く学び、自分の価値を磨くことに注力します。
「チャンスを逃すな、待つのではなく、自分から掴みに行け」という言葉を胸に、これからも積極的に新しいことに挑戦し続けます。