この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。
こんにちは。こばだんな（小林）と申します。
現在は、兵庫県の淡路島でWEBライターやメディア運営などを中心に個人事業主として活動をしております。
以前は、都内のIT企業でシステムエンジニアとしてお仕事をしていました。
- 会社員時代に経験した業務経験や仕事観
- IT企業での具体的な仕事内容、立ち位置、関わったプロジェクト
改めて、当ブログを運営している「こばだんな @iju_kobayashike」です。
本記事では、会社員時代の業務内容について解説しています。
現在、IT系のWEBメディアでの記事執筆、図解の作成等をしております。
こばだんなのライターポートフォリオ
こばだんなのサムネイル・バナー・図解ポートフォリオ
お仕事をご依頼する際の業務経験の確認や知識レベルの確認等にご活用いただければ幸いです。
ヘルプデスク業務の経験はこちら
インフラ設計業務の経験はこちら
セールスエンジニアの業務経験はこちら
コンサルティングファームとの業務経験こちら
※クリックすると見出しに移ります。
もともとはIT系に進むような、プログラミングをする学部や理系の出身ではありませんでした。
わたしは、高校時代は商業高校の”総合ビジネス科”というところに在籍していて、普通科にない「簿記」「ビジネス基礎」などを学んでいました。
その後進学でなんやかんや、縁もゆかりもない青森県の国立大学に進み、経営学を専攻していました。
大学時代はプログラミングも経験していませんでしたし、IT系の会社にご縁があったというわけでもありませんでした。
就活の際に、自分がどんな分野に興味があるかな…と自己分析した結果、多くの人と協力していきながら１つのシステムを作り上げていくシステムエンジニアという職種に興味を持ち、自分の力が発揮できそうだなぁという理由でIT系の道に進みました。
プログラミング経験なしでエンジニアになったわたしですが、正直大変でした。
新卒入社後は3か月間みっちり「プログラミング」や基礎的な「ネットワーク」「ハードウェア」などのIT関連知識を朝から晩まで浴びました。
プログラミング的思考に慣れていなかったわたしですが、めちゃくちゃ挫けました（苦笑）。
大学で情報処理を経験した人やプログラミングを経験した人ならわかると思いますが、当時は「変数」という言葉の意味や”String型”や”int型”といったデータ型の話からちんぷんかんぷんで、それはそれは苦労しました。
講師の方が言っていることの3分の1も理解できないまま、気づいたら1日が終わっている。
そんなこともざらにありましたし、半泣きになりながら勉強していましね。
（当時は同期に大変お世話になりました。）
それでも、必死にプログラミングの基礎知識に食らいつきながら無事研修を終え、各部署へ配属されました。
その後、IT系の腕試し的資格である「基本情報処理技術者」の取得を経て、最終的には「応用情報処理技術者」の資格を取得しました。
社会人1年目の具体的な仕事は、システム仕様にそってプログラムが正しく動作するかを確認する仕事です。
内部仕様が見えないパッケージシステムのブラックボックステストだったため、一部の事実（プログラムの動き）からプログラム仕様を「推測する力」が養われたと思います。
また、推測に基づいて仮説・検証（こうすると→こうなるよな？）をしていくテスト工程をこなしていくことで「論理的思考力」も必要に迫られて学べたと感じます。
■プロジェクト期間：2014/09〜2015/03
■プロジェクト規模
・開発期間：8ヶ月
・利用者：2万人
・開発コスト：1億4,000万
・プロジェクトメンバー数：20名
・管理協力会社数：2社
■プロジェクト内容
オンライン教育系システムの開発
■担当業務：プログラム試験
新入社員研修を終えて、配属されたプロジェクトでは優秀な上司と先輩に恵まれ、”仕事の基本”を学ぶにはとても良い環境で働かせてもらいました。
1年目の時は、比較するものがないので”社会人ってこんな感じなのかぁ”と素直に受け止めていました。
しかし、自分が数年社会人を経験して色んな方と仕事をしてみると、あの時は本当に優秀な人たちにご指導してもらえてたんだなぁと実感しました。
当時の上司からは、配属翌日から「お客さまとの打ち合わせ」に同行させてもらい、システム化要望を聞く機会をもらったり、フォロ―をしてもらいながら裁量のある仕事をさせてもらったと思っています。（期待を込めて）
そんな上司からの期待に応えたいと新人ながらに思っていた当時のわたしは、自己啓発本を読んだりして、意識が高そうな感じでしたｗ
（岩井さんのベストセラー「社会人1年目の教科書」とか何度も読み返していました。）
当時メンターとして1年間フォローしてくれた先輩も、この上司の下で数年働いていたせいか、仕事論的なものが上司と似通っていました。
仕事に対してストイックだったので、わたしもビシビシご指導していただいた印象があります。
当たり前ではありますが、「納期」などの時間間隔や仕事に対する「品質」といった仕事観の基礎はこの1年間で形成されている自覚が確かにありました。
- 分からないことを聞く時は、自分で調べて分かった範囲と自分の考えとセットで伺いにいく
- 仕事を依頼されたら早めに着手⇒全体把握⇒20%できたら確認してもらって、進む方向性を早めに修正して進める
- 仕事にコスト意識を持つ（”時間に対して”給料が発生している自覚）
社会人1年目ではこんな仕事観を持って取り組んでいました。
■期間：2016/01〜2017/05
■プロジェクト規模
・開発期間：1社あたり1~2ヶ月 合計3社
・利用者：1,000~2,000人
・開発コスト：100万~200万
・プロジェクトメンバー数：2名
・管理協力会社数：1社
■プロジェクト内容
オンライン教育系システムの導入支援
■担当業務：営業支援・要件定義・導入支援・教育
・営業支援：営業と同行し顧客へデモ実施や技術的な仕様の回答。
・要件定義：顧客の業務分析を行いシステム導入後の運用の設計。
・設計導入：システムの設定値・マスタデータ等の設計を行い、設定を実装しリリース。
・教育 ：システム利用開始の顧客へのユーザー教育を担当。
社会人2年目になると、1年目のシステム開発プロジェクトは解体され、私は引き続き同システムの運用をしながら別の小型案件に関わることになりました。
小型案件だったので、上司の他は実働が私だけの1人プロジェクトでした。
営業とともに何社もデモを実施したり、顧客の要件を聞いて回ったりと、2年目の終盤から3年目にかけてはセールスエンジニアのような働き方でした。
また、実際に契約までたどり着いた会社(実績としては3/10社くらい)のシステムについて要件定義～設計・導入・教育まで一貫して1人で回していきました。
「新規案件」✖「1人プロジェクト」だったので、納品する成果物(設計書やマニュアルなど）をどのようにするか分からなかったり、契約書ってどうしたらいいのか分からなかったりで、これまた分からないことが多かったです。
1年目に経験した案件とは”規模感”が全然違うので、サービス利用の契約書も自分で確認しないといけませんでしたね…（エンジニアってこんなこともやるの？って思いました。笑）
何回か法務部に相談を取り付け、やれ「反社会的勢力の排除条項がない」とか「この会社は下請法適用だぞ」など指摘を受けながら、聞きなれない「甲」「乙」といった契約書独特の表現に悪戦苦闘しつつがむしゃらに仕事をしていましたね。
開発が始まっても1人プロジェクトだったので、「開発スケジュール」や「成果物（設計書）」も”どういうフォーマットでつくるか”から自分で考える必要がありました。
※システム開発は、だいたい”老朽化によるシステム更新”という流れが多いです。
1社と長く付き合っていくことが多いので、既存のフォーマットの資料があったりするのですが、新規開発システムだったものでそういうものがなく、けっこう困りました。
他の部署の同期に聞いて回り、別システムの参考資料を取り寄せたりしつつ、設計書などを作りました。
小型の案件の[営業⇒受注⇒開発⇒納品⇒運用]というビジネスの流れを何社か回すことができたので、仕事によって対価を得るという経験を実感できました。
- 営業で顧客の要望をきいてアプローチする
- 開発にかかる工数を見積もりではじき出し、契約書を確認して受注する。
- 開発では顧客要望をシステム化に落とし込み、できない部分は折衝する。
- 導入では、ユーザーへシステムの教育を行い運用に乗せていく。
1人プロジェクト中でこれらの経験をしたことで、”自分でどう進めて行けば良いのか考えて行動する”ようになったと思います。
社会人4年目は、主にシステム運用のヘルプデスク業務を経験しました。
■期間：2015/10〜現在(2020/8月時点)
■プロジェクト規模
・利用者：2万人
・プロジェクトメンバー数：2名
・管理協力会社数：2社
■プロジェクト内容
オンライン教育系システムの運用・サポート
■担当業務：システムの操作方法の問い合わせ対応・サーバー運用
新人の時に開発した、オンライン教育系システムの運用を継続して担当していました。
同じシステムの運用を3年も続けていると、システムの仕様や問い合わせの傾向も熟知してきます。
システムの利用者から使い方のお問い合わせや不具合などのお問い合わせに対して迅速に解決していくヘルプデスクのような業務が中心でした。
このシステムも利用開始から4年目になり、お客様の社内で使っている方の習熟度は上がっているものの、利用者層が広がって来ていたので、お問い合わせが減ることはなかったようです。
自分も楽したいので、問い合わせの傾向を収集・分析して、利用者がどこで問い合わせが多いのか、どこで操作につまづくのかを洗い出していましたね。
問い合わせが減って自分の仕事が楽になるよう”情報共有サイト(MicrosoftのSharePoint)”を作成して利用者の方と「よくあるお問い合わせ(FAQ)」を発信したりしました。
1年目からヘルプデスクとしてシステム利用者の問い合わせ対応するを経験してきて、仕事の時に気を付けるようになったことがあります。
それは「お客さまが本当に求めていることは何か？」という視点です。
よくあるケースとして「このデータが登録できない」という問い合わせがあったりするのですが、この時必ず確認しているのが「お客さまが求める対応のスピード感」です。
お客さんが求めていることが…
データが登録できない原因が分からないことで、この先何度も困りたくないのでなんとかしてほしい
今日中にデータを登録したい。（原因が何かはおいておいて）
AさんとBさんで、こちらの回答が変わってきますよね。
Aのデータが登録できない理由を求めている方に、こちら側で手を動かして「対応しておきました」という回答では”いや、そうじゃなくて…”とご納得いただけないと思っています。
また、Bの今すぐ困っていることを解消してほしい方に、グダグダとデータが登録できない理由を説明しても”そんなことはどうでもいいからすぐになんとかしてほしい”とご不満を与えてしまうと思っています。
一口に「データが登録できない」という困りごとでもお客さまが求めているものが異なったりするということを体感しました。
この経験は、システムのヘルプデスク担当者の業務に関わらず、他の仕事やプライベートでも同じ話しかなと感じているので、普段から依頼ごとに対する対応のスピード感を意識して仕事に当たっています。
入社5年目では、これまでの教育系システムではなく、全く別の業務管理システムのパッケージシステムの導入及びカスタマイズ開発を担当することになりました。
■期間：2018/01〜2019/02
■プロジェクト規模
・利用者：150名
・プロジェクトメンバー数：9名
・管理協力会社数：1社
■プロジェクト内容
業務管理システムの要件定義・カスタマイズ開発・インフラ構築
■担当業務：要件定義・インフラ構築
顧客の要件に応じてパッケージシステムをカスタマイズしてシステムを構築していく案件でした。
私のプロジェクトでのポジションは、顧客の業務要件や利用状況に応じてシステムがちゃんと動くようなインフラ基盤（土台）を構築する役目でした。
新入社員の時から、比較的顧客に近い業務よりの仕事が多かったですが、一転、インフラと呼ばれる縁の下のシステム作りを担当することになりました。
システムの土台といっても「サーバ」「ミドルウェア」「ネットワーク」「セキュリティ」の分野など多岐にわたり、本当に分からないことだらけでした。
プロジェクトの中では、お客様の要望を聞きながら
- どのレベルでセキュリティを担保しないといけないのか
- セキュリティを担保するためにどうサーバを構築しないといけないのか
- 費用を抑えるためにクラウドサービス（AWS・Azureなど）を活用できないか
このようなことを検討しながらシステム開発費用の見積もりなどを作成していました。
正確な見積もりをはじくためにも、利用する製品の「種類」「単価」、採用するサービスの「制約」など様々な要素を把握した上で、システムをコーディネートしていく必要があったので、毎日勉強の日々でした。
単身クラウドサービス事業者の担当者と打合せを設定して、サービスについて詳しく聞いたり、社内の有識者にコンタクトを取って資料を請求したり、仕事で必要なインフラ関連知識を集めながらの仕事でした。
当時はインフラ関連知識について「知らないこと」が多く、思ったように業務が進まなかったり知っていれば回避できた課題や手戻りがあって、うんざりしていました。
AWSほんと、勉強しよ。
— ライターこばだんな｜移住の人。 (@iju_kobayashike) January 22, 2019
今の案件をAWSで構築できるように倒せば実務経験もつめるし、ぶったゃけ会社費用で研修も行かせてくれそうだし。
なにより自分のキャリアが、広がる感覚がある。
【AWS求人の単価相場はどれくらい】 https://t.co/uqb2xDQHR4
よくある話ではありますが、終わってみればそういった「知らないこと」に直面した時、それは悪いことではなくむしろ「伸びしろ」であって「チャンス」でもあると考えるようになりました。
分からないことが目の前に積み重なるとついつい弱気になったりストレスになったりしますが、依然と比べてそういった場面でもポジティブな心持でいられるようになったと感じています。
入社6年目の4月から大規模な基幹システムの開発のプロジェクトに異動となり、チームの体制や一緒に働く方などがガラッと変わりました。
■期間：2019/04〜2021/10（予定）
■プロジェクト規模
・利用者：6万名
・プロジェクトメンバー数：150名
・管理協力会社数：4社
■プロジェクト内容
業務管理システムの要件定義・カスタマイズ開発
■担当業務：要件定義、設計、試験、開発
特に、開発を主導で行う会社として、プロジェクトに総合系コンサルティングファームが入ったことで、これまでの小規模案件では関わることがなかったコンサルタントの方々と仕事をすることになったのが私にとっては学びになりました。
コンサルタントの役目としては、現在の業務を把握した上で顧客の要望を実現する手段を検討しながら、システムで使う機能の開発や運用方法をまとめていきます。
当然、その中でいくつもの課題や業務の交通整理など、複雑かつはっきりとした”答えのない”高度な問題に向き合うことになります。
そういった解決すべき事柄に対して、どのようにアプローチして解決していくのか、同じプロジェクトチームとして一緒に進めていくことが大変勉強になりました。
顧客に近いコンサルタントから学ぶことは大変多くありましたが、一言でいうと「仕事の進め方」に尽きるかと思います。
◯仕事の進め方って具体的には・・・
・課題の切り分け観点、クロージング方法
⇒課題発見力、論理的思考力
・会議資料の構成・伝え方
⇒情報を整理する力、折衝方法
・打合せのファシリテーション(進行やクロージング)
⇒プレゼンテーション力、タイムマネジメント
広く一般的に言われている「ビジネススキル」を、実務を通して今一度勉強させてもらったと、個人的には思っています。
新入社員研修でも似たようなビジネススキルの分野ごとに、研修を受けたりはしておりますが、やはり実務経験で学ぶのと机上で学ぶのでは雲泥の差があります。
業界の立ち位置としては「顧客の要望をヒアリングしてシステム化」するので、SIerと似通っている部分もあります。
でも、自社に比べると総合系コンサルティングファームは、経験している案件数や人材の優秀さが頭1つ飛び抜けている感がありました。
自社の中の人だけと関わっているだけでは、今回のような成長が得られなかったと改めて感じ、自社以外の外の世界に目を向けていく良いきっかけでもありました。
- 業務システムの開発経験
要件定義・業務設計・テスト・移行切り替え - 業務システムの運用経験
ヘルプデスク業務 - サーバ運用
セキュリティパッチ適用、WindowsServer、WSUS運用、トラブルシューティング - システム教育
教育資料の作成、システム教育（オンライン・オフライン）、教育コンテンツの作成 - セールスエンジニア
営業資料の作成、営業と帯同したシステム提案営業、見積もり業務 - ツールの導入・運用
Office365、RPA（WinActor） - クラウド設計（Azure,AWS）
長文にお付き合いいただきましてありがとうございました。
お仕事のご依頼については、下記のお問い合わせフォーム または TwitterのDMよりご連絡ください。
よろしくお願いいたします！
チャットワークも利用しています！
長文が送りやすい
レスポンスは早め
