【29歳男性/元SI出身エンジニア】ビジネス面をアピールすることで開発ディレクターへ抜擢

ひとえに目の前のプログラムを意識しているか、「サービス」を意識しているかのギャップが大きいです。
例えば、プログラムを意識していると、開発の方針を考えるときに「こういう書き方とこういう書き方があります」といった具体的な話をします。ただ、サービスという”商品”を作り上げていく上で意思決定をするにあたってはどうでもいい情報であることが多いです。 「どのように作るか」ではなく「この案で作るとユーザーの体験がこのようになる」といった、ユーザーの体験やサービスとしての品質に意識を向けなければ、開発ディレクターとしての仕事をこなすことはできません。
バグの報告１つにしても、「ここでエラーが起きているんです！」というのは開発者としては気になってしまう情報ですが、サービス影響を気にするのであれば「ここでエラーが起きているので、ユーザーは入力の途中でエラー画面に遷移してしまいます」といったユーザーレベルでの影響を語らなければいけません。 重大なバグだが、そもそもその機能での売上は微々たるものだったりと、開発者としては重大なバグであっても、サービス目線で見ると優先度の低いバグであることも多々あります。
現場で働いている方だとよく分かると思うのですが、このギャップは経験を積んでいる人でも抱えていることは多いので、このギャップを埋められるエンジニアは現場で重宝されますし、より上流の立場へのステップアップが望めます。 逆に細かいところが気になってしまう方であればディレクションではなく、技術に特化する道が向いていると思います。

よくある話ですが「システムをこうして欲しい」という要望をいただいたときに、その背景や先方の業務内容を元にニーズを整理していった結果、いただいた要望よりもよりよい改修ができた時は嬉しいですね。
ユーザー側からシステムをこう変えて欲しいという具体的な要望が来ることは、先方も画面をよく触る人たちなので、よくあります。しかし、言い方は悪いですが、彼らは業務のプロであっても、システム開発のプロではないので、他にどういう手段があるのか、その改修にどれぐらいのコストがかかるのか、その改修によって他のユーザーはかえって不便になることはないかといった観点では、要望を出してくれません。 なので具体的な要望をいただいても、それを鵜呑みにはせずに、相手の背景を考えます。その結果、相手が想像していた以上に改善ができたり、コストが想定の数分の１だったりしたときにこの仕事のやりがいを感じますね。
コストが想定よりも低くなれば、空いた予算でさらに他の改善もできることになりますので、サービスを短期間でできるだけよくしていくことにも繋がります。
いろいろな関係者から開発要望をいただくなかで、要望の優先順位をつけたり、効果がないと判断した案件を却下することは非常に難しいですね。複数の部署からの要望はそれぞれが、やるべき、と考える観点が違うので、それを横並びにして比較することは難しいですし、それを他部署に納得してもらうこともまた難しいです。特に技術的な都合によってどうしてもできなかったり、できるけれど期待効果よりもコストが大きすぎるときは、具体的な理由が理解できないからこそ、納得していただくのが難しいです。技術をわかりやすく説明することのほか、常日頃から先方の業務内容や大変さに理解を示してコミュニケーションをとっているかも、納得感には影響すると思っています。
効果がないと判断した案件については、どういった調査、推定をして効果がないと判断したのかを説明するようにしています。それによって、効果的な反論が来るのであれば、それは実はやるべき開発だったというだけの話ですから、フラットにやるべきかどうかを判断すればよいと考えています。

ビジネス面の知識を持ち合わせていると有利です。営業が一般的にどういった考え方で仕事しているか、よくある部署ごとの摩擦に関する感覚などは重要です。
営業の考え方というのは要するに、営業が売りに行くサービスの場合売りやすいか、わかりやすいか、あるいは競合が入ってきたときに反論しやすいかといったところです。これも踏まえて開発の方針や視点を考えると、よりよいサービスが作れるようになります。
また、いろいろな部署にいろいろな利害関係がありますから、サービスを運用している部署や問合せ窓口とったそれぞれの部署から見たときにこの開発はどう見えるのかを意識する必要もあります。もちろん開発部署の利害関係もここには大きく関わってきます。それぞれの部署から納得してもらえるような開発のプランを考えること、それができる政治的感覚を持っている人は向いています。
一般的な会計知識なども持ち合わせていると、利益率などの議論にも参加できるため、役立つと思います。あとは先程言ったように、”プログラム”ではなく”サービス”を意識して開発を考えられるかといったところですね。
開発経験はあったほうが圧倒的に有利です。開発経験がない方でもこのポジションの方はいるのですが、「この案件にどれぐらいのコストがかかるか」「この開発はリスクが高く、慎重に進める必要があるか」といった肌感覚がつかめないので、開発者たちと会話をするときの感覚の違いに戸惑っている印象です。
逆に開発経験があると、上記のことを開発案件の題名を見ただけで、なんとなくはわかりますので、それを土台にして仕事を勧めていくことができます。それから開発上のメリットデメリットとビジネス上のそれとのトレードオフを考えるときに、開発の知見がないと、開発のメリットデメリットは開発者の言われるがままにしか理解できないため、フラットに判断できないという問題もあります。