僕のSESエンジニアキャリアを一変させた話〜ディレクターへの転身〜

コードベリー牧野です。

【2020/05/31追記】
こちらの記事はもともと自分が原体験を見つめ直して今後のキャリアを考えるために、アウトプットしたものです。
ただ、今見直してみて、SESでキャリアに悩む方の参考になるのではと強く思ったのでタイトルを変えて、改めて周知することにしました。
悩めるエンジニアに届くと嬉しいです。

こちらの続きです。
ベースの情報を記載しているので、興味を持って頂いた方は本記事を読む前に読んでもらえるととても嬉しいです。

さて、原体験を探す思考の第二弾です。思考アウトプットなので独りよがりの内容になっていますがご興味ある方は読んで頂けるとうれしいです。

仕事の仕方についても少し触れているので、参考になるんじゃないかと思っています。お付き合いください。

エピソード

簡単な経緯

僕は29歳の時にフリーランスになりました。当時所属していた会社が分社してしまい、働きたい人と働けなくなってしまった。
もともと独立したいと漠然と思っていた僕は、当時上司だった弊社代表の福田に相談し、30歳直前でしたし、思い切ってフリーランスになることにしました。

ディレクター職

フリーとなり、新しい現場へ参画することになります。
引き続きSESではありましたがこれまでのエンジニア職ではなく、ディレクター職でした。しかも、発注サイドとして。
この仕事は僕の人生で大きなターニングポイントになりました。社会人人生の第二のスタートと言っても過言ではない。

僕はもともと開発することが目的になる開発現場に一定の疑問を持っていました。欲しい人がいるから案件があるわけで、それが達成できないと開発にはなんの意味もないわけです。システムは使われてなんぼ。
そんな思いを持っている時に、発注サイドのディレクター職の話を頂いたので、思い切って飛び込みました。

なお、ディレクターというのはコンサルなみに曖昧な職種で、僕の知る範囲でもやることは職場ごとに違うようです。
役割として共通しているのは物事を推進することだと思っています。

もともと調子乗ってた

当時、恥ずかしい話ですが僕は鼻が伸びてました。エンジニアとしては小さなものであればゼロからアプリケーションを作り一人で公開までできるようになっていたし、リーダーとしてプロジェクトの火消しに何度か貢献した、みたいな自負もありました。なのでディレクターとしてもやっていけるだろうなと思っていました。
本当に恥ずかしい話です。

当時の僕からすると超難易度が高い仕事

結論から言うと、現場に入り何にもできませんでした。

超大手事業会社の現場でした。役割は発注サイドとして開発サイドと事業サイドの間に立ち、システム開発にすべての責任を持つこと。
（責任は当然双方にあるのですが、そのような心構えでやれ、という当時のチームの方針でした）
お客さんのIT統括部門のメンバーという今考えると非常に恵まれた仕事でした。
そのため、僕はまったくパートナー扱いされなかった。厳しく指摘されたし社員と同等の裁量も頂けました。ものすごく感謝しています。

システム開発のことを理解・把握しながら、事業サイドがやりたいことも理解し開発サイドに落とします。
なので、事業サイドには開発サイドとして、開発サイドには事業サイドとして自分の言葉で話す必要がありました。双方の意志や業務をほぼ完全に理解している必要があります。

システムは重厚長大で案件規模は数百人月を毎年サイクルで、開発メンバーは100人規模、それでいてディレクターチームは10人いませんでした。

開発だけでなく保守対応も推進していました。開発サイドには事業サイドの意思を伝えるし、事業サイドには障害理由や影響範囲などを的確に伝えます。

ディレクターが機能しないとすぐにボトルネックになってしまい、致命的な要件漏れなど発生するので、みんなとんでもない速さでコミュニケーションしてました。
（僕が馴染めた時には、多いときで20〜30タスクほどを同時に推進できていました。人は成長する。。。）

それから情報整理、会議設計やファシリテーション、ステークホルダーマネジメント的な動き、ドキュメントづくり、受け入れテスト作成、外部連携先との調整などもやっていました。
まじで総合格闘技です。

正直、圧倒されました。やり方すら分からなかった。糸口すら。

やばい、これオレできない。
ここにいる人達、本当の意味で仕事ができる人だ。

事実、僕があまりにできないので卒業していた元メンバーが教育役として戻ってきてくれて、ゼロから教えてくれました。（この人がいなかったら僕はおそらく3ヶ月でクビでした。今でも尊敬する先輩です。）

余談：QA1000本ノック

印象に残っているのはQA1000本ノックですかね。僕が勝手にそう言っているだけで、実際にそんな儀式はないですが。

開発サイドと事業サイドの間にいるので、大量のQAが双方から来るのですが、それをすべて1ストロークで終わるように文章を書くのです。
もちろん、複雑な箇所は事前に会話しますし、期待値調整も行います。

論点が明確である
共有、指示、確認などの目的が明確である
聞きたいことが明確である
背景を理解した仮説がある
クローズドな質問である
読みやすい文章である

このような要素が求められました。
様々な要素から仮説を立てた時に結論が自明だった場合、こちらで回答を確認するのみ、ということも多々ありました。（それを質問すると「何か論点あるの？聞く意味ある？」って怒られる）
当初、1つのQAを書くのに長いと1時間ぐらい掛ってました。分かりづらいと回答すらもらえないし、少しでもズレるとやりとりが発散して収拾に時間が掛かり他のタスクが遅れるため、すごく注意を払いました。
この経験は今の自信になっています。

僕は特別な人間ではない

少し前置きが長くなりましたが、この仕事で僕自身が平凡な人間であることを強烈に自覚しました。
なにしろ、周囲の人は上記の激務をいとも簡単に回していました。タスクの総量が多いのでみなさん忙しかったですが、量が多いねって感じでした。めちゃくちゃ難しいことしてるのに。
みんな記憶力も抜群。3年前の決定事項の背景をメールで聞くと事細かな長文で返信をくれたりしました。
毎日数百通飛び交うメールを全部読んで把握している人も珍しくない。

スペシャルな人達というのはこういう人たちなんだ。

その後、一緒に働いていた人たちの多くは起業したり出世したり各所で要職に付いています。やはりスペシャルだったんだな。

人間やり方を覚えればなんとかなる

こんな僕でもあの環境になんとか食らいつくことができた、そんなことも感じました。
確かに才能には敵わないけど、ある程度やれる方法はあるんです。そしてその方法は他人から教わらないとできない。
今までできなかったんだから自分であがいてできるようになるわけがない、そんな風に感じています。

だから今僕は恩返しも兼ねて、

年齢や立場関係なく優れていると思った方法は教えを請い取り入れる姿勢
立場や損得関係なく、相手にGiveする姿勢

を大事にしています。

システム開発の背景にあるもの

これはシステム開発の現場だけにいるとまったく見えないところでした。システム開発に落ちてくるまでにいろんなことが検討されているんですよね。そんな当たり前のことですが、目の当たりにして初めて実感できました。

また、システム開発とは種類が全く違う能力で要件が考えられています。使う頭が全く違うんです。

大雑把ですが、

開発は方法を考える仕事。
その背景にある企画は新しい価値を考える仕事。
間に立つディレクターは目的を考える仕事。

そんな感じです。

率直に言うと、僕のような凡庸には開発だけやっていると難しい思考だと思います。そして体験しないとこの難しさは分からない。
本当に貴重な体験をさせてもらいました。

仕事は目的がすべて

上記のような激務だと、目的からずれた仕事はすべて無意味です。他のタスクといつもトレードオフの構造だからです。無駄な仕事で大事な仕事に穴をあける可能性があるんですね。だから、いつも仕事の目的を問い続ける必要があることに気づきました。

そもそも仕事は目的に向かってやるコトである、という本質を理解することができました。

無駄か判断つくことも少ないと思います。そういう場合は必ず自分なりの仮説を立てて検証する。目的からズレていればその仕事は捨てるべきです。

仕事の基本

恥ずかしながら、ビジネススキルの基本を理解することができました。

考える
伝える
動かす

他にも数え切れないのですが、大まかにこんな基礎を叩き込まれたと思います。

新規参画してきた人のフォローもしてきましたが、ほぼ全員基礎がないことにも気づきました。
自分はできると思ってても、多くは全然できてないんですよね。まさに当時の僕！！

まとめ

こう見ると、あの激務をしていた自分が今でもちょっと信じられないです。
強烈な原体験と言えそうです。

読んで頂きありがとうございました。