エンジニア不足、エンジニア不足と言われて久しいですが、日本でのプログラミングスクールの先駆けとも言えるTECH::CAMPさんのサービス開始が2014年なので、今や8年が過ぎようとしているわけです。
ともすると、市場に既にベテラン級のエンジニアがわんさかいてもおかしくないんですが、今でも「エンジニア採用できない」という声が絶えることないように見えます。はて？どうしたことだろうか、と思ったので今市場でどんなエンジニアが求められているのかを考えてみました。
高い技術力よりも「いい感じ」力を求めている
エンジニアというと、技術を駆使して問題解決をするスペシャリストというイメージがあり、技術力が高い=優秀という認識を持つのが自然です。実際、技術力が低くてまともにプロダクト開発出来ないようでは論外だし、技術的な難問の攻略が命運を分けるケースはあるにはあります。
しかし、実際には開発プロジェクトの失敗事例は、技術力の問題と言うよりほとんどが人間関係に起因する問題だったりします。
- 決まったはずの仕様を後からひっくり返された
- バグばっかりでプロダクトが全然成長しない
- 仕様かバグかで主張が対立して信頼関係が崩壊する
- 言った通りにしか作ってもらえない
などなど、開発現場に関わったことがある人なら一度は聞いたことがあるんじゃないでしょうか。こういったトラブルは「なんかいい感じにしてくれる」エンジニアが一人いると圧倒的に減少し、なんとなく手詰まり感のあった開発チームがスルスルと回り出します。
そして市場が求めているエンジニアとはつまるところこの「なんかいい感じにしてくれる」エンジニアなのではないかと考えました。
なぜ「いい感じ」が必要なのか
なぜ「いい感じ」が必要なのかを説明しようとすると、開発手法の話に言及する必要がありそうです。
我が国では、システム開発の現場は「ウォーターフォール型開発」という手法により運営されていました。これは、最初に何を作るべきかを定義し、それを工程ごとに徐々に詳細化しながら仕様書として定義し、完成した仕様書を元にシステムを開発するというアプローチになっており、一見非常に合理的な手法です。
引用: 仕事内容｜業務内容｜採用情報｜三菱ＵＦＪトラストシステム株式会社
しかし、システム開発業界の歴史の中で、この手法には大きな欠陥があることが明らかになりました。一つは仕様は後から必ず変わってしまうこと、もう一つはシステムの複雑性が要因で仕様書と実際のシステムとを同一に出来ないことです。
仕様書を基準にして作るべきシステムの範囲と責任が決まる、という大前提に成り立っている方法なので、そもそも仕様書が変動してしまい厳密に正確に記述できないとなると、当然崩壊してしまうわけです。
そこで生まれたのがアジャイル開発です。これは、従来のように先に仕様を全部決めてから作るのではなく、作る単位を小さくして、その都度その都度議論を重ねて最適な形を作っていくというアプローチです。前述した仕様書の問題をいくらか解決してくれます。
引用: アジャイル開発とは？主流の開発手法「スクラム」も…｜Udemy メディア
ところが、よしこれで万事OKだと！というわけにもいかないんです。
従来は顧客から要件をヒアリングして何を作るべきかを定義する「上流工程」と、実際にそれを開発してシステムを構築していく「下流工程」という区分けがあり、この上流と下流を媒介するのが仕様書でした。
仕様書があるおかげで、上流下流間でのコミュニケーションは簡素化されていましたが、仕様書の絶対性が弱くなるほどに、人と人との対話でこれを埋めなくてはならなくなりました。アジャイルソフトウェア開発宣言にも「プロセスやツールよりも個人と対話を」と記述されているのはこういった背景があります。
つまり、ウォーターフォール型開発にせよ、アジャイル開発にせよ、プロジェクトの成功の命綱を握っているのは依然「人」であるということです。本来手法論というものは人間に依存する部分をできる限り減らして、誰がやってもある程度常に同水準のものが出来上がるようなものであるべきですが、残念ながら我々IT業界はまだまだ未完成なのです。このことが腹落ち出来ていなければ、アジャイル開発を導入しようが、どんな便利なツールを使おうがうまくいきません。
ではどうしたら良いのか？そう、「なんかいい感じにしてくれる」人が欲しくなるのです。
このポジションにはPM（プロジェクトマネージャー）を置くのが定石で、とっても優秀なPMがいればそれだけでけっこう上手くいきます。ただ現実はそう甘くはなくて、優秀なPMはそうたくさんいるわけではないのと、mofmofのように2,3名のエンジニアが一つのプロジェクトを担当する小規模チームでは常に専任のPMを置くのはコスト的にも採用面でもやや現実的ではありません。
なので小規模チームでは必然的に誰かがPMのような動きを兼任する形が多くなります。だったらエンジニアがそれをやってしまえばビジネスサイド・開発サイド間のコミュニケーションは一気通貫になるし、少人数で上手く回るのでコスト的にもメリットは非常に大きい。つまり市場からすると喉から北斗百裂拳が出るほど欲しいエンジニアになるわけです。
「いい感じ」とは一体何か
PMBOKとかをちゃんと履修しておけば、もっと理路整然と説明出来そうですが、なんせ雲のジュウザのごとく我流で突き進んで来てしまったので自分の言葉での説明を試みます。
- アジャイル力
- アジャイルイベントの目的を深く理解し、ただしく実行出来ること(形式上やっているだけではダメ)
- プロダクトオーナーが何を求めていて、何に不安を感じているかを理解して仕事が出来ること
- 思考力
- 自分が考えていることを正確に言語化して伝えることが出来る。もやもやした気持ちや複雑なものごとを言語化して整理出来る
- 拮抗する選択肢の中から、いずれかを選択し主張する能力。何が正しいか分からない状態でも仮説を元に一つの結論を示すことが出来る
- 他者の主張を類推し素早く理解できる。会話を重ねながらものごとを深く理解することが出来る
- 課題の本質を見抜いて、適切な対処の方法を提案し建設的な議論が出来る
- プロジェクトマネジメント力
- 直近の開発計画だけ見るのでなく長期の視野でも計画を見据えることが出来ること
- リスクを予見して問題になる前に適切な対策が打てる
- スケジュールに合わせてスコープと期待値を調整し、問題なく着地させることが出来る
- コミュニケーション力
- 他人の感情に惑わされず、冷静に議論を正しい方向に導いていける
- ビジネス力
- 開発しているプロダクトの意義や目的を深く理解し、ビジネス的な目的の達成に寄り添った開発ができる
アジャイル開発を前提とした言葉も用いられていますが、本質的にはウォーターフォールもアジャイルも関係ないスキルが列挙されています。これらのことがきっちり出来ていればどちらの手法であっても関係なく上手くこなせるはずです。
深堀りしていけば、一項目ごとに本一冊書けるような命題なので、興味があれば関連書籍を手にとってみてください。
mofmofでの話
上述した観点ですが、実はこれらのほとんどがmofmofでの評価基準としてそのまま定義されています。mofmofでは技術力が高いのは当然として、それ以外の能力も非常に重視されています。
mofmofのエンジニアは一般的なエンジニアに比べると求められる範囲が非常に広く、人によっては「なんでエンジニアがここまでやらなきゃいけないの？」と思われるかも知れません。mofmofがここまで求める理由は、我々が「システム開発をすることでお金を得ること」を第一の目的としていないからです。
ぼくはmofmofという会社で「テンションが上がるものづくりの仕事を生業にする」という言葉を掲げています。売上も大事なんですが、それ以上に大事なのは「我々がいかに楽しくやりがいを持ってものづくりの仕事を出来ているか」です。
言われたものをただ作るのではなく、エンジニア自身が深く考えて関わることで、プロダクト開発に対して真に主体的で楽しい開発が出来ます。それこそが「テンションが上がるものづくりの仕事」を実現する一要素だと考えています。
オレ/私もそういうエンジニアになりたいなーって思った方は弊社への応募をご検討くださいまし。
