多くのエンジニアを見て

最近、ある雑誌で『⁠「⁠ゆとり世代」がこれからの世の中で生き抜いていけるのか？』という特集を目にしました。その特集記事の要旨は、これまでの団塊世代が年功序列で無難に働いてきたのに対して、これからの若者は「成果主義」と向き合う必要があるが、「⁠ゆとり世代」はその危機感が分かっていないのではないか、といったものでした。

筆者は仕事柄、多くのエンジニアに対して面談を行います[1]⁠。面談した結果、「⁠このエンジニアをプロジェクトに採用しよう」と決めても、期待通りのパフォーマンスがでないことが多いのも事実です。一方、面談を受ける側からすると、プロジェクトに対する自分の適応性をPRするのはとても難しいでしょう。エンジニアのスキルや適正を見極めるのはとても難しく神経を使うものです。

しかし、最初に面談を行った時に、「⁠このエンジニアは他と違う。一本筋が入っているな」と感じた時には、多くの場合、期待通りの成果をあげてくれます。つまり、仕事に対する取り組み方、モチベーションが成果に大きく影響していることは言うまでもないでしょう。

今回は、エンジニアの求められる資質について考えてみたいと思います。

小人数プロジェクトの特性

筆者が数年前に経験したプロジェクトは、開発規模はそれほど大きくありませんでしたが、他にもプロジェクトが複数あり、スキルも人数も足りない状況から開始しました。小人数のプロジェクトにおいては、メンバ構成の良し悪しでプロジェクト成功の大半が決まると言っても過言ではありません[2]⁠。

そのため、プロジェクトメンバが決定していないことは、とても大きな課題でした。

エンジニアの採用

筆者は、自社内でメンバを探しましたが、どうしてもスキルの合う方が見つかりませんでした。そこで、これまで取引のある数社の協力会社に連絡をとり、必要なスキルを伝え、対応の可否を問い合わせしました[3]⁠。

しばらくして、問い合わせを行なった一社より、今回のプロジェクトにマッチする人材がいると連絡が届きました。確かに開発スキルや業務経験は問題なさそうです。

システム設計や開発を、はじめて一緒に仕事するメンバに任せるのはとても心配なことです。できれば、簡単な仕事を少し経験してもらった上で適正を見極めたいものです。しかし、すでにプロジェクトは開始直前でもあり、筆者は、紹介を受けた方をプロジェクトに採用することとしました。

受身な設計

プロジェクトが開始して程なくした頃、成果物を見て違和感を感じました。「⁠お客様の運用を考えた設計になっていない」そう思いました。真偽を確かめるため、色々と質問を行いますが、少しずれた回答が返ってきます。

「これで良いと言われた」「⁠それは知らない」「⁠自分の範囲はここまで」完全に受身な姿勢でした。システム設計において、お客様はすべてのことに気付かないものです。システムエンジニアは過去の経験や他社事例を駆使して、お客様から「要件」を引き出し「気付いてあげる」スキルが求められます。お客様と議論をぶつけてこそ、信頼されるエンジニアとして認められるのです。

気を利かせるとシステム仕様が増えると考えがちですが、受身な姿勢で設計したシステムの大半は、実際の利用者がテストする段階で問題が噴出し、「⁠言った、言わない」「⁠仕様追加」で揉めることが多いのです[4]⁠。

この段階で、プロジェクトの建て直しを行ったことは言うまでもありませんが、対処した内容については割愛します。

エンジニアマインドを育てる

先日、小学生の娘の運動会に行きました。筆者の運動会に対するイメージは、「⁠勝ち」「⁠負け」にこだわらず、できる限り競争心をあおらないように、小学校によっては、順位も「優勝」「⁠準優勝」といったり、「⁠1位」「⁠2位」といったりするというものでした。

しかし、先日の運動会では、先生が率先して自分のチームを応援し、勝ったら生徒と喜び、負けたら本気で悔しがる姿を見受けました。生徒に、結果も大事だということを教えているようで、とても頼もしく見えました。

「草食系」が増えたと言われる時代ですが、いつの時代もエンジニアは「職人」であるべきだと思います。

もし、自分が受身な性格だと自覚があるなら、意識的に「自分事」として考えられるトレーニングをお奨めします[5]⁠。