➰

SIerとWeb系での15年のキャリアを振り返る

に公開
マネジメント
キャリア
働き方
idea

はじめに

リーマンショックの年に IT エンジニアになって 15 年が経ちました。
節目の年でもあるのでこれまでのキャリアを振り返ってみたいと思います。

自分は新卒で入った SIer で 7 年間の受託開発を経験し、その後 Web 系の企業で自社開発を 8 年間経験しました。働き始める前に思い描いていたキャリアプラン通りにはいかず、色々と寄り道もしましたが、振り返りながら軌道修正を続けることで、なんとか今も IT エンジニアを続けることができています。

生成 AI の登場により先行きはさらに不透明になり、会社にもキャリアを頼れない今日この頃ではありますが、何かの参考になれば幸いです。

目次

  • IT エンジニアになるまで
  • SIer 時代の始まり
  • PMO ってなんですか？
  • Web 系への転職
  • プロダクト開発への転身
  • プレイングマネジャーになる
  • 15 年のキャリアから分かったこと

IT エンジニアになるまで

~ 懐かしのFrontPage Express ~

インターネットが従量課金だった時代

  • 小学生時代から HTML を手書きでホームページ作成
    • パソコンも自作が安かった時代
    • ダイアルアップ接続、テレホーダイ世代
  • リーマンショック時に文系の大学から新卒で SIer へ

小学生の頃から HTML を手書きでホームページを作っていました。ダイアルアップ接続でテレホーダイの時間を待ち、夜 11 時になると一斉にインターネットにつなぐ。そんな時代でした。

大学は文系に進みましたが、IT エンジニアになりたいという思いは変わりませんでした。リーマンショックの真っ只中での就職活動でしたが、そんな中で拾って頂いた中堅の SIer に入社することになりました。

当時の IT 業界は 3K とか 7K とか言われ、不人気業種の代表格でした。関西在住だったこともあり、Web 系企業という選択肢はそもそも頭にありませんでした。スマートフォンもまだ普及していない時代の話です。

SIer 時代の始まり

~ Excelを開いている時間が一番長い日々の始まり ~

客先常駐からのスタート

  • 配属初日からいきなりの同期と別れる
  • Struts と Java と Oracle と
  • オフィス街のランチを楽しむエンゲル係数の高い毎日

新卒研修が終わったらいきなり客先常駐からのスタートでした。幸いチーム単位で常駐していたので心細さはありませんでしたが、一緒に研修を受けていた同期と働くと思っていたので戸惑いもありました。

最初はプログラマとして仕事を始めて、Struts と Java と Oracle で簡単な開発を行っていました。この後も色々開発することはありましたが、他の言語を知らないので、最初に見たものを親だと思って何でもかんでも Java で作っていました。

オフィス街でランチがあまりに美味しく、10kg 以上太ってしまったのもこの頃でした。

営業とベテランエンジニアとの協業

  • ヒアリング → 提案 → 見積 → 受注 → 開発 → 納品をぐるぐる回す日々
    • ゼロから売上を立てるまでの一連の流れを学ぶ
    • 給与やオフィスにかかる費用と利益をどの程度確保するかを計算して、顧客の予算に合わせた見積もりを出していた
  • ベテランエンジニアに鍛えられる日々
    • プロジェクトマネジメントスキルの必要性を痛感する

元請けとして案件を請け負っていたので、開発だけでなく色々な仕事がありました。 お客さんのところに行って話を聞き、お金の計算をして見積もりを作り、開発して納品することで売上を立てていました。学生の感覚だとこんなに請求して良いのか？となっていましたが、自分の給与を稼ぐために必要な額はいくらなのかを早めに知っておけたのは良い経験でした。なお、営業はいませんでした。

わりと早い段階でプロジェクトマネージャーを担当することになりました。複数の協力会社のエンジニアと一緒にシステム開発を行う立場でしたが、チームには自分の親と同世代のベテランエンジニアもおり、相当な迷惑をかけたと思います...。

スクラム導入の失敗

  • 流行に乗ってスクラムを導入
    • アジャイルサムライの輝き
    • 柔軟な開発を夢見た日々と現実に打ちひしがれる
  • プロダクトバックログの優先順位付けに反発
    • 「全部必須」という考えから脱却できず
  • スクラムマスターへの長文反論メール事件
    • ルールは作れるが、文化を作ることは難しい

仕事にも慣れてきてウォーターフォールでの開発に課題感を感じ始めた頃、業界全体でも開発プロセスの見直しが進んできました。アジャイルサムライを読んで衝撃を受けた私は、チームでスクラム開発の導入に取り組むことになります。

プロダクトバックログやカンバン・振り返りなど色々なプラクティスを取り入れましたが、現実は厳しかったです。最初に決めた開発スコープに対して調整をする文化がなかったため、優先順位で並んでいるものの全部必須となり、要件定義だけが終わらず柔軟に調整されるウォーターフォールと悪魔合体したスクラムとなってしまいました。

この頃スクラムマスターにプロダクトバックログが全部必須で終わるまでリリースできないなら、スクラムではない！と長文のメールを送る事件を起こしました。言っていることは間違っていないのですが、アジャイルな文化の導入における障壁を知らず、スクラムマスターの苦労も知らずに文句だけ言う私は青かったのだと思います。（反省はしていない）

海外オフショア開発の苦労と発見

  • 海外への出張と現地エンジニア教育
    • 国際的な開発の楽しさを知り、のちの OSS 開発につながる
  • 「納期」概念の文化的ギャップ
    • 終わるまでやるのが本当に正しいのか

海外でのオフショア開発も経験しました。出張して開発環境の整備や教育などを行いました。

現地のエンジニアは優秀であり、日本のアニメが好きな方が集まっていました。海外の方とコミュニケーションを取ることは楽しく、今も自分が OSS を開発する上でのモチベーションの一つになっています。

一方で納期に対する考え方は違っており、依頼した仕事が終わっていないこともしばしばあり、仕事を引き取ることもありました。これまで納期は絶対であり、終わるまでやる文化で開発を続けてきた自分には文化的なギャップを感じる瞬間でした。

サーバー買ってきてセットアップして OS を入れて...

  • Redmine を立てたかっただけなのに...
    • クラウド以前の時代のインフラ構築は数ヶ月かかる事がざら
  • RHEL? CentOS? Ruby? MySQL? Apache?
    • Linux に種類があることを知る
    • Ruby on Rails に触れる
  • OS やミドルウェアを構築する方法を学ぶ

SIer は Excel 文化でした。Excel 方眼紙に設計書を書き、Excel で作ったガントチャートにスケジュールを引きます。ファイルサーバーにおいて共有するのがやり方であり、Box のような便利な共有の仕組みはありません。

そんな時 Redmine に出会います。チケット駆動開発の書籍を読み、これだ！となった私は社内向けの導入に突き進みますが、そもそも社内にはホスティングするためのサーバーがありません。

色々な人に聞いて回り、物理サーバーを買ってもらえることになったのですが、サーバールームに置いて LAN ケーブルを繋ぐところから始まったので、稼働開始までには数ヶ月かかりました。

この時に子供の頃の自作 PC の経験が役に立ち、OS を入れるところまではスムーズでしたが、その後に Linux を入れてミドルウェアを入れて...となるところはチンプンカンプンで、何もかも独学で調べながらやりました。Redmine.JP の手順書 には大変お世話になりました。最初はなかなかうまく構築できず、作っては初期化を繰り返しましたが、その中で OS やミドルウェアを構成する方法や動く上での仕組みを学びました。

PMO ってなんですか？

「来期からXXXプロジェクトでPMOをやってもらいます」
「PMOってなんですか？」

はじめての PMO

  • 数百人規模のプロジェクトの PMO チームに配属される
    • 間接的な業務のみでパンパンの日々
    • 生まれたばかりの子供とハードワークと
  • 定量的な指標を用いてみんなで客観視することの重要性を学ぶ
    • EVM（Earned Value Management）の活用
    • テストカバレッジやテストケース数の把握
    • Power Query に詳しくなってはてブを 600 以上もらう
  • 「鳥の目と虫の目」の必要性
    • 特に PMO の立場において現場が本当に何も見えないことを痛感した
    • 定量的な指標と現場の声の双方で判断することの重要性を学ぶ

大規模なプロジェクトの人員強化により、異動して PMO チームに配属されることになりました。間接的な業務のみに専念するのは初めての経験でしたが、規模の大きさに比例してプロジェクトマネジメントの難易度も上がり、状況把握だけでも相当な工数が必要となることを学びました。また、この頃プライベートでは子供も産まれていたので、ハードワークな日々とバランスが取れず苦労もしました。

色んなチームに赴いてデータ収集や分析などさまざまな支援をしていました。変わらず Excel が主流でしたが、もともとあった VBA のマクロでは何時間経っても集計などの処理が終わらないレベルで資料が増加していたため、この頃登場した Power Query を導入して解決しました。あとでノウハウを展開したところ、はてブが 600 以上もらえたのも良い思い出です。

また、PMO の立場だと様々な数値が見えるだけで、現場が具体的に何をしているのかは意識しないと見えないことにも気づきました。報告を待つだけでは状況はわからないので、定量的な指標だけでなく、現場のリーダーを特定して実際に話を聞くなどし、双方で判断することの重要性を学んだのもこの頃でした。

PMO の視点のイメージ図

プロジェクトマネジメントはスキルと気づく

  • PM の役割と仕組み化された定量的な管理の必要性
    • 自分たちが今どんな状態にあるのか？を把握し決断することが PM の役割と気づく
    • 共通の認識を作るために、いかにわかりやすくシンプルにするか
  • Delivery を元に Quality と Cost を組み立てる
    • 多くの場合において、QCD においては Delivery が最も重要
    • 人月の神話の通り、人を増やす（Cost）ことで Delivery が早くなることはない
    • 要件を品質（Quality）を落とさずに調整することの重要性

PMO をやっていく中で気づいたのは、プロジェクトマネジメントもスキルだということでした。 NASA の失敗から導入された EVM などは古くからあるツールですが、今も十分に有用です。

他にも色々なツールを整備して正しく情報が集まるようにして、今後の見通しを立て QCD の調整を可能な限り早い段階で行うことが PM の役割であり、PMBOK などもあるようにスキルとして体系化されています。

また、QCD はどれも同じく重要ではなく、Delivery が多くの場合に最重要であることも気づきました。道中に複数のマイルストーンを置いて指標を定め、締め切りで指標をクリアできたかを確認し、軌道修正していくことで、プロジェクトの成功率が高まることを知りました。当たり前のことかもしれませんが、体感として理解できたことは大きかったと思います。

Web 系への転職

なんだこのキラキラとしたオフィスは！

転職のきっかけ

  • SIer のキャリア前半でコーディング経験が止まっていたのがずっと心に引っかかっていた
    • この先の SIer のキャリアパスで学べる機会がなさそうだった

キャリアの後半では PMO を担当していたことからもわかるように、コーディングの経験はキャリアの前半のみでした。立場的にプログラミングなど具体的な開発のスキルは身につきにくく、今後も身につけられる機会はなさそうで、その点はコンプレックスになっていました。

そんな時たまたま見かけた募集に応募して、あれよあれよと転職することになりました。

転職活動での意外な発見

  • PMO 経験が予想以上に評価される
    • 大規模プロジェクト経験の希少性
  • マネジメントスキルの市場価値
    • 「無駄な経験はない」という気づき

転職活動を始めて驚いたのは、PMO としての経験が予想以上に評価されたことでした。特に、大規模プロジェクトの管理経験は、Web 系企業でも需要がありました。

自分では評価に繋がりにくいと思っていた経験が、実は大きな武器になることを知りました。キャリアにおいて、無駄な経験はないということを実感した瞬間でした。

転職前後のスキルセット変化

キャッチアップの日々

  • 周囲との技術力ギャップを痛感する
    • 今振り返るとそんな難しい話はなかったが、当時は理解不能
    • ハッタリでなんとか凌ぐ日々
  • 朝活の日々が始まる
    • オライリーの JavaScript 本（サイ本）を写経
    • 子供が目を覚ます前の朝の 5 時からスタート

転職してまず感じたのは周囲との技術力の差でした。Cookie の仕組みも朧げにしかわかっていなかったので、いわんや実装をやという感じで手が動きませんでした。とはいえメンバーを外されるわけにもいかないので、ハッタリをかましながらキャッチアップして追いつくことにしました。

何がわからないかもわからない状態ですが、入門の書籍を読んでも追いつけるイメージができなかったので、オライリーの本を最初から写経することにしました。現場では使わない言語仕様まで含めて学ぶことと、コードを見続けたことでなんとなく読めるようになりました。英語が少しずつ読めるような感覚に近かったのを覚えています。

子供が目を覚ます前までが勉強時間だったのですが、些細な物音で起きてしまうこともあり、すぐに勉強が中断していたのも今では良い思い出です。

スクラムマスターとしての役割を果たす

  • コードを書けない中でも自分の役割を探す
  • SIer 時代の経験もあって手を上げる
    • 失敗を知っていたのが力になったかも
  • 3 つのチームの立ち上げを行う
    • 自己決定できるチームを作る

コードはあまり書けませんでしたが、仕事をしないといけないのでスクラムマスターの募集に手を上げました。周囲に PM 経験者やチームをリードする経験があるひとが少なかったこともあり、自分には失敗経験もあったので知見を活かすことができたと思います。

過去の経験から、チームを自律させるために必要なのは自己決定することだとわかっていたので、スクラムマスターとしてのチームの立ち上げでも自己決定できるチームを作ることを心がけました。この頃は 3 つのチームを軌道に乗せるまでを担当していました。

コードを書けない引け目はありましたが、自分の役割を見つけることで居場所は幸い見つけられていたように思います。

数万 rps の負荷試験

  • 数万 rps の負荷試験を実施
    • 数十台のクライアントで JMeter を動かす
  • クライアント・サーバーの両方でエラーの嵐
    • ファイルディスクリプタと TCP 上限
    • カーネルパラメータのチューニングを経験
  • パフォーマンスが十分に発揮されない
    • リソースを使いきれていなかった
    • CPU とは何かを少し理解する

チームで開発していたのはプラットフォームに近い API だったので、数万 rps の高い負荷がかかる特性がありました。同僚に教えてもらいながら、JMeter を利用してクライアントを分散した負荷試験を実施しました。

初回はサーバーエラーの嵐でしたが、エラーメッセージを読み込むことでファイルディスクリプタやソケットに関するエラーだとわかったので、見よう見まねでカーネルパラメータなどを調整していきました。エラーが解消されるごとに、Linux の仕組みにも少しだけ詳しくなっていきました。

EC2 のような環境で稼働させていましたが、同時にプロセスが CPU を四分の一しか利用しない現象にも遭遇しました。Node.js を利用しており、シングルスレッドでしか稼働していなかったことが原因だったので、cluster 化によって解消できました。原因はシンプルでしたが、アプリケーションがどういった環境で動くかを想定して実装することで、十分なリソース活用につながることを理解できました。

プロダクト開発への転身

GMV, CTR, CVR, CPA, ROAS...???

立ち上がったばかりのプロダクトに異動

  • 直接顧客にサービスを提供するチームに異動
    • 企画やデザイナーなど異なる職種との協業
    • それぞれの立場での価値の出し方を知る
  • スピード重視の開発スタイル
    • 1−3 ヶ月の短納期で主要機能を次々にリリース
    • ユーザーに価値を届けることの重要性

顧客に近い立場での開発を経験したかったこともあり、直接サービスを提供するプロダクトの開発を行うことになりました。PdM や企画・デザイナーなど異なる職種の方々との協業を初めて行うことになりましたが、市場調査や UI/UX の改善など、コードを書く以外の方法でプロダクトに貢献されており、どうやって作るかだけでなく、何を作るか・なぜ作るかが売上につながることを理解できたように思います。

スピード重視の開発スタイルであり、1-3 ヶ月のスパンで主要な機能を次々と開発していきました。技術的な負債も貯まっていきましたが、完璧に仕上げてから出すよりまずユーザーに価値を届けることの重要性を学びました。

初めてのマイクロサービスアーキテクチャ

  • モノリスではスピードが出ない
    • リポジトリを分割することがマイクロサービス
    • 脆弱性対応などがどんどん大変に
  • サービス間通信・分散トランザクションの難しさ
    • 依存先が増えるとリリースに気を使う
    • RDBMS 的なトランザクションが実現できない
    • キューの便利さに気づく

時代的な背景もあり、モノリスではスピードが出ないという認識が主流であったため、マイクロサービスアーキテクチャを採用していました。 リポジトリを分割することを実現方法としていたため、管理するリポジトリの数がどんどん増えていきました。一つ一つは早くリリースできましたが、結果として脆弱性対応などの複数のリポジトリを横断して行う対応がどんどん大変になっていきました。

サービス間通信や分散トランザクションなど、従来のモノリスな構造であればシンプルに実現できたものも、仕組みが複雑化していきました。一方で負債だけではなく、キューを活用することで得られるアーキテクチャの広がりなど、同期的な処理・バッチ処理だけでは得られない考え方の広がりもありました。

Kubernetes への移行

  • アプリケーションをコンテナ化
    • コンテナを Push/Pull するという考え方
  • IaC の便利さと中身の見えなさと

Kubernetes への移行においては、アプリケーションのコンテナ化による時代の移り変わりを感じました。都度コンテナを Registry に Push/Pull してデプロイする考え方は、手作業でサーバーを構築していた頃から考えると、随分と先まで来たものだと感じました。

宣言的にインフラを書く IaC は便利なものでしたが、実際に作られるコンテナの中身を知らなくて良いわけではない、ということも学びました。Kubernetes のベストプラクティスに則りつつも、前提としてある程度のインフラ知識を求められていることを感じました。この時に結局、過去に負荷試験をやった時の経験が役に立ちました。

気がついたら一番長くいた

  • 5 年以上携わった過去最長のプロダクトに
    • 今までは数年程度で次に移っていた
  • 長期的に同じプロダクトに携わることで知れたことがあった
    • 数年前の設計の答え合わせができた
    • データベースの容量限界が想定通りにきた
    • 何よりもデータベースを変えることが一番難しいと改めて知った
  • プロダクト、チームが大きくなることで開発速度にも影響があることが知れた
    • メンバー全員のスキルが高く、プロダクトに習熟していても開発速度は遅くなった
    • 一度遅くなった開発速度を再び早くすることは難しい

このプロダクトは 5 年以上携わることになりました。自分はこれほどまで長く同じプロダクトに携わった経験がなく、また成長を続けるプロダクトでもあったので様々な学びがありました。

例えばデータベースの容量は直近数年は大丈夫だが、どこかでデータを圧縮する・物理削除する対象を増やすなどの対策が必要と言っていたものが、実際に対策が必要になりました。この経験から学んだのは、最初の設計の重要性でした。特にデータベース設計は、後から変更することが困難なため、将来を見据えた設計が必要です。短期的な開発スピードと長期的な保守性のバランスを取ることの難しさを実感しました。

また、原因に心当たりがないのに開発速度が低下することも発見の一つでした。チームのメンバーがプロダクトに習熟する中でも発生していたのは、複雑度の増加とステークホルダーの増加に伴う自己決定権の低下が一因だったようには思います。プロダクトだけでなく、プロセスにおいてもリリースの独立性を保つことの重要性を学んだように思います。

プレイングマネージャーになる

プレイングじゃないマネージャーって？

手を動かすことを手放す

  • マネージャー職としてチームを率いることに
    • 調整役としての振る舞いが新たに追加
  • 自分で手を動かすより手を動かしてもらう
    • ボトルネックにならないように
    • 手を動かさずに価値を発揮することへの抵抗

前述の通り長くいたこともあって、マネージャーとしてチームを任せてもらえることになりました。プレイングマネージャーではありますが、調整役としての振る舞いが新たに増えたこともあり、手を動かす時間が取れない日々がやってきました。自分で手を動かすとボトルネックになってしまったこともあり、どっちつかずの状態に悩みました。

ここで思い切って、手を動かさずにチームとして価値を発揮するための振る舞いをするように動き方を変えました。IT エンジニアとして手を動かさないことには正直なところ抵抗がありましたが、PMO 時代の経験を思い出し、手を動かさないでも価値を発揮する方法はあるので、その実現にどうすれば良いかを考えるようになりました。

複数の組織の潤滑油となる

  • 複数のチームのマネージャー・より上位の役職者との協業
    • チームを横断した課題の解決に取り組む
  • チームを横断した課題に対して、より俯瞰的な視野での取り組みを始める
    • PMO の経験が役に立ち、複数チームの場合に発生する課題の解像度が高かった
    • 何を解決すれば良いかに過去の経験が存分に役に立った

他のチームのマネージャーやより上位の役職者と話をして感じたのは、現場との距離感でした。 ただ、この課題は PMO 時代の「鳥の目」で経験済みであり再現性のあるものだったので、SIer 時代の経験を活かして同様の解決ができないかを仕組みなどから提案するようにしました。

立場変われば人も変わると言いますが、立場上見えなくなってしまったから発生していることも多いと思います。上から下まで同じものを見るようにすることが、同じ目線で仕事を行うことにつながると、改めて実感しました。

15 年のキャリアからわかったこと

人生いろいろ、キャリアもいろいろ

キャリアは思い通りにいかないが、それでも計画は必要

  • キャリアは思い通りにいかないが、それでも計画・再計画は必要
  • 意図せぬ異動や配置換えの中でも学べることがあるか、探してみる価値がある
    • 計画が崩れてマイナスに捉えるのも仕方がないが、その中でも探す
    • 何かのきっかけをくれたと捉えるぐらいが良い

結果的に自分は当初想定していたキャリアとは随分と異なる道を歩んできたように思います。ただ、そんな中でも現状を振り返り、再度計画を立て直すことはしていました。

大規模プロジェクトへの意図せぬ異動があった中でも、なかなか得られない機会と捉えて PMO が何をするべきかを自分で考え、実践したことは後になって振り返って得難い経験だったと気づきました。

自分が望まない変化も、何かのきっかけと捉えることでコントロールできないものに対する耐性ができるので、ポジティブに捉えられるようになるかと思います。

思いもよらないところで経験は役に立つ

  • 振り返って経験を棚卸することで、変化に備えられる
    • 自分が何ができるかを知ることで、置かれた場所での役割を見つけられる
    • 自分に何が足りないかを知ることで、今後必要な経験がわかる
  • スキルよりも「実績の言語化」が重要
    • 実績を「何を」「どうやって」「どんな価値を出したか」に整理しておく
  • 資格を取っておくと良い

計画を立てるだけではなく、振り返りも重要です。例えば新しいプロジェクトに参画するときにも、自分に何ができるかを知っていれば、自分の居場所も自ずと見つかると思います。 また、自分に足りない経験を知っていれば、今後経験すべきことがわかり、経験を積むために違うプロジェクトに参加するなどのアクションを取れるようになります。

具体的なスキルよりも実績を「何を」「どうやって」「どんな価値を出したか」と整理して言語化することで、自分の評価と他者の評価を一致させられるようになります。これも新しいプロジェクトに参加するときに、期待値のすり合わせに大いに役立つと思います。

Web 系の IT エンジニアには少なかったのですが、IPA などの公的な資格をとっておくことは重要だと思います。自分は基本・応用情報技術者・情報セキュリティスペシャリスト・システムアーキテクトを新卒から 5 年以内に取得しましたが、ここで浅く広く学んだ知識はインデックスになるとともに、経験できていないことを知るのに大いに役に立ちました。

15 年のキャリアのマインドマップ

「不安」はエンジニアにとって自然なサイン

  • スマホの登場・クラウドの登場の時にも同じことがあった
    • 古くは Web（オープン系）の登場においてもきっと同じだった
    • 新しい技術においても流用可能な、普遍的なスキルは何かを見つける
  • 「キャリアの軸」を意識する
    • 自分はどこで何を武器にして生きていくか

IT 業界は特に流れの速い業界であり、生成 AI によりそれはさらに加速しています。当然不安になることも多いと思いますが、IT エンジニアにとっては自然なサインです。

これまでもクラウド・スマホなどの破壊的な変化はありましたが、IT エンジニアは必要とされてきました。新しい技術の習得は必要ですが、変化の中でも変わらず活用できる普遍的なスキルは不安の解消に一役立ちます。

また、不安を感じているからといって手当たり次第に手を出すのではなく、「キャリアの軸」も意識することが重要です。自分の場合は PM の経験が長く、普遍的なスキルも多いと感じていたことから、このスキルを軸に置きつつも、コーディングなどのスキルも足し算したエンジニアを目指してきました。

いのちだいじに

  • プライベートとキャリアはバランス
    • メンタルや体を壊しては元も子もない
    • 生存者バイアスに注意
  • 自分自身と家族を大切にする
    • しっかりした基盤のもとで変化を乗り越える
    • 人の助けを得る

少し毛色の違う話ですが、自分自身の体調は最も優先すべきことです。仕事が終わっても考え続けてしまったり、メンタル面でのプレッシャーが強い業界でもあるので、プライベートとのバランスは重要です。自分の経験談にも生存者バイアスがかかっていますが、他の人と無理に同じようにはせず、自分がちょうど良いレベルの負荷で仕事を続けることが最重要です。

仕事を続けるには家族の協力も不可欠です。仕事に全力を注げるとき・そうでないときが当然ありますが、変化の激しい業界なのでたまには後からついていって、人に助けてもらうことも必要だと思います。

なんだかんだで、なんとかなる

  • 「なんとかなる」という楽観的な気持ちを持つことも大事
  • 自分の中で「やりきった！」と思えていることが重要
  • 経験を振り返り、自分がやってきたことを把握することが「なんとかなる」につながる

最後になりますが、「なんとかなる」という楽観的な気持ちを持つことも大事だと思います。

プロジェクトマネジメントが十分でメンバーに恵まれていても、うまくいかないこともあります。 適当に進めていても、案外何事もなく終わることもあります。プロジェクトの成否に関わらず、自分の中で「やりきった！」と思えていれば、それは経験となり次に活かすことができます。

不安の方が多い場面もあるかもしれませんが、これまでの経験を振り返り、自分がやってきたことを把握することが「なんとかなる」につながります。様々な場面で「なんとかなる」と思えるようになって来ているのなら、それはしっかり経験を積み上げて来たことの証拠です。

さいごに

15 年のキャリアを振り返りましたが、まだ折り返し地点でもないことに愕然としています。

今後この業界がどうなっていくのか、どのようなキャリアを歩むべきかは自分も考え続けていきたいと思います。

皆さんのお話も聞きたいので、ぜひご遠慮なくメッセージをください。お待ちしています！

Discussion