「いいエンジニアの条件」とは

「いいエンジニアというのはどういうエンジニアだと思いますか?」

これは私が面接でたまに聞いたり、逆に私自身も聞かれたことがある質問です。同じ答えはほぼなくて、皆さん自身の経験から色々な答えを聞かせてくれます。正解はない質問ですが、私の回答は決まっています。

運用設計ができるエンジニアがいいエンジニアです。

これは私自身の経験からの答えであり、正解というわけでもありませんし誰に押し付けるわけでもありません。重要なのは「なぜそのように考えているか」という点です。その理由は、適切な運用設計ができるということは運用を見据えたシステム設計ができるからです。

システムインテグレータやベンダで働くエンジニアの多くは業務が分割されています。プリセールス、プロフェッショナルサービス、サポート、のように。システムインテグレータのエンジニアは提案から設計構築まで行いますが、運用や保守まではやらないケースも多いかと思います。お客様の立場からすると設計構築ではなく運用保守こそが本番なのですが、プリセールスエンジニアはその時点で(契約上の制約などもあり)離れてしまうことが少なくありません。

すると実際そのシステムはどのように使われているのか、何が課題なのか、どの点は良かったのかと言ったことがわかりません。障害があれば呼び出されたりしますが、安定した定常運用時にはなかなかタッチできないのです。また障害時などスポット対応するくらいでは、中長期においてどのような管理設計が適切なのかと言ったこともわかりづらいのです。

幸か不幸か私は若い頃、デスマーチに遭遇しました。炎上後に投入されてから半年近くしてやっとで運用にこぎつけたシステムは運用問題が続出。そこから約一年半、運用も担って各種対応をしていました。この時に学んだことは、「早い段階・前工程での失敗や問題を後工程で解決するのは限界があるし効率が悪い」ということでした。よく「是正措置のコストは予防措置のコストより高い」と言われますが、まさにこのことです。

その案件の後私は

「企画・設計段階が大切」
「お客様との信頼関係・十分なコミュニケーションが大切」

ということを強く心に念じ、プロジェクトマネージメントやコンサルティングを重視するようになりました。システム管理部門のお客様だけでなくエンドユーザがどのように使うことになるのか、変更やアップグレードなどを考慮した時にどのような統合管理や運用管理が便利で、そのためにはどういう点に気をつけるべきなのか。利便性、管理性、セキュリティを一定水準に維持するためにはどうすればよいのか。

多少言いにくいことであっても、そういったことをしっかり考え、お客様のシステムを企画・設計する時にしっかりとその「なぜ」を伝え、場合によっては「過去の経験・実例」を話すことでお客様には普通伝わります。納得してくれ、信頼度も高くなります。

お客様は通常運用の当事者ですしエンドユーザのこともご存知ですから発言には説得力がありますが、お客様とて過去の方式が一番だと思っているわけでもありませんし、より良い提案があるなら是非乗りたい、と思っています。お客様が我々を頼ってくださるのは我々のそう言った知見や提言を求めているからであり、その期待に応えられれば必ずご満足いただけます。

スクラップ&ビルドを繰り返すだけの提案エンジニアにならず、先の先まで見通し、なぜ・何がいいのかをお客様視点で説明できるようになるためにはどうしても経験が必要です。業務以外でその経験を積む方法についてはまた別途述べますが、これが私が「運用設計ができるエンジニアがいいエンジニアである」と考えている理由なのです。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
嬉しいです!またきてください!
1
初めまして。サラリーマンエンジニアです。IT企業に勤めております。 独立開業して年収○倍という話をよく聞きますが、そうではなく我々のようなサラリーマンエンジニアが取りうる手段は何か。どのようなスキルを身に付け年収を上げていくか、といったお話を考えていこうと思います。
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。