社内の大きなプロジェクトを実行する際に、外部からエンジニアを集めてプロジェクトを運営する手法は、IT業界ではごく一般的な手法です。
しかしその場合にネックになるのが「社内にエンジニア経験がある人間がいない」ケース。社内のプロジェクトであるからには自社の社員がPMを務める必要があるものの、PMに適した人材はエンジニア経験がないケースは本当に多いものです。そこで今回は、非エンジニアがエンジニアのマネジメントを行う場合に心掛けたいポイント５つをご紹介します。
■目次■
自分が何を求めているかを具体的に明示する
これまでエンジニアとしての経験がなく、現在もエンジニア以外の職種で活躍している人材が、プロジェクトマネージャやチームリーダーとなるケースはよくあります。チームやプロジェクトの長として、エンジニアの作るものの方向性を決め、なおかつ仕上がった機能が要件に合致しているかを見定める必要があるからです。
ここで重要なのは「エンジニア経験がないから」と技術的バックボーンが無いことに難しさを感じず、「自社のビジネスや業務を最もよく理解している者」として「何を欲しているか」を明示的に掲げることにあります。
エンジニアは幾多のプロジェクトを経験し、顧客の要望に柔軟に応える術をもっていますが、その技術も顧客要望の要点やビジネスの要諦がはっきりしなければ、発揮しようがありません。
最初のチームミーティング、キックオフミーティングで自分のビジョンを宣言し、それを終始一貫する姿勢がエンジニアチームをひっぱる力の源泉になるでしょう。
精神論に聞こえるかもしれませんが、細かく複雑な要件定義に惑わされて、シンプルで強力なお題目が薄れてしまうことが後々の障害につながることもあるため、非常に大切なことなのです。
モノづくりを担う人材であるという意識を持つ
エンジニア、特にIT業界のエンジニアの成果物は、ドキュメント以外に手に取って確認できるものがありません。
端末やブラウザの向こう側で結果だけが表示されることが多く、「モノを作っている」という実感がわかないケースもあるでしょう。
非エンジニア出身のマネジメント層の中には「何を作っているのかハッキリしない」とまで言う人がいるほどです。
しかしその認識は大間違いで、ひとたびそのような思いを口に出したが最後、チームやプロジェクトのエンジニアの心は離れてしまいます。
心が離れたからといって仕事を投げ出す人材が皆無とは言え、そこに「プラスアルファ」の価値を生み出すような良好な関係を築くことは難しくなってしまうのです。
例え所属している会社やコミュニティが違えど、一旦チームを組んだのであればエンジニアのモノづくりに理解を示し、時には背中を押してあげるくらいの気持ちがマネジメントを円滑にします。
コンサルタントの高単価案件は、アサインナビがご紹介 しています。
ある程度の「職人気質」に理解を示す
エンジニアはどこか職人気質を持った人間が多いことは事実で、経験豊富でスキルの高い人材ほどその傾向があります。
表面上はコミュニケーション力が豊かで、「我」を消して職務に邁進しているようであっても、納得のいかない支持や要求には頑として応じないとうケースもあるのです。
日常的に緻密さと正確さ、創造性を求められる仕事をしているからこそ、筋の通らない要求には決して納得していないということを理解しておきましょう。
業務の都合上、どうしても筋の通らない案件を消化してもらう必要があっても、「本来正しいのは君だ」という点を強調しておくことが大切です。
大規模なプロジェクトほど、チームメンバーとの付き合いは長く濃密になります。
順調に進んでいるうちは良いのですが、ひとたび障害や仕様変更が発生したとき、チームメンバーがどこまで自分の指示を受け入れてくれるかは、それまでの理解者としての姿勢にかかっていると言っても過言ではありません。
「今回は納得のいかない仕様変更だが、この人のためならなんとかしよう」とエンジニアに思わせたなら、大抵の困難は乗り切ることができるものです。
労働環境の改善を考える姿勢を忘れない
エンジニア、中でもプログラマは労働環境が悪化しがちです。このプログラマの労働環境の改善に目を向けることは、全体の生産性を高めることにもつながり、エンジニアの信頼確保にもつながります。
プログラマは長時間労働になってもしかたない・・・という姿勢では、エンジニアとの溝は埋まりません。非エンジニアだからこそ、チーム内の労働環境を悪化させないようマネジメントに注力する必要があるといえます。
この姿勢をチームが認めてくれれば、緊急対応時などにエンジニアに前向きに対応してもらうことができるようになります。
コンサルタントの高単価案件は、アサインナビがご紹介 しています。
WBS作成を通じてチーム一丸となる
非エンジニアがマネジメントを行う場合、自分一人では工数の見積もりを出すことはできないかと思います。エンジニア全員とタスクを摺合せ工数を把握することで、エンジニアのチームへの帰属意識が高まり、自分のタスクの意味を意識づけすることに役立ちます。
自分自身も、WBSの作成を通じて実作業ベースで、全体像を可視化することが可能となります。
実作業の内容を理解できなかったとしても、どういうタスクが発生し、どれくらいの工数になるのかを知ることは、のちのキャリアにも有効なのではないでしょうか。
コンサルタントの高単価案件は、アサインナビがご紹介 しています。
WBSの必要性については、エンジニアへの適切なマネジメントの仕方でもご紹介していますので参考にしてみて下さいね。
