プロジェクトマネージャーとしての苦悩：エンジニアの思想との葛藤

2015/12/04 01:25

このQ&Aのポイント

個別な言葉がぶつかり合うエンジニアとの葛藤に困惑しているプロジェクトマネージャーの方へ、解決へのアプローチ方法をご紹介します。
技術的な難しさやユーザーの視点に関する意見の相違が蓄積され、現場の進展が停滞しているプロジェクトマネージャーの方へ、解決策をご提案します。
プロジェクトマネージャーとして、現場のエンジニアとのコミュニケーションが困難な状況に直面している方へ、円滑な意思疎通を図るためのアドバイスをご紹介します。

プロジェクトマネージャーとしてどうすれば

コーダーからシステムエンジニアを得て、ここ1～2年はプロジェクトマネージャーとしての立ち位置で仕事をしています。最近とある会社に転職をしましたが、現場のエンジニアの独善的な思想に悩まされています。私が入社する前から2～3年ほど運用されているサービスなのですが、開発の遅さやバグ等によるトラブル、また機能追加に対して嫌悪感を示して実装しなかったり別の機能に置き換わっているという事が多々あったそうです。現にビジネスとしてスケールしておらず、そういった経営陣の課題もあり、技術を分かる私が今の現場を立て直すという役割で入社に至りました。入社してみると前述のとおりの現場で、自社のサービスを好き勝手作っているような状況でした。テストもまともに行われていなかったり、ドキュメントも最低限のものさえ整備されておらず、最悪機能追加は外注をとも考えましたが、外にも出せない状況でした。後から入社したという立場もあり、エンジニア陣と寄り添いながら課題解決に向けて動こうとしていますが、「なぜドキュメントを作らないといけないのか？」「そもそもその機能は本サービスの思想と違う」「サービスが売れていないのは営業のせいだ」「その機能は今のDBの構造上難しい」といった事を言われるだけで、手を動かそうとしてくれません。私も数年前まではエンジニアでしたのでそもそも技術的に難しい事は分かりますし、追加しようとしている機能はユーザーにとって無駄になるようなものでもありません。今まで受託の現場で育ってきたため、顧客から言われた事は実現しなければいけないという思想が現場にありましたし、それが仕事だということで現場をコントロールできてきた部分がありますが、自社サービスを開発、運営している現場ではそういったコントロールもできません。ユーザーのためだという話を持ちだしても「ユーザーのためとは思えない」「そもそもそういったユーザーはわれわれのターゲットではない」と言い出されてしまいます。今の会社で、プロジェクトマネージャーとしてかなり迷走していまして、どうしたら言うことを聞いてくれるだろうか、どう説得したらいいだろうか（かなりの口下手というのもあり）・・・といったことを毎日考えている状態で、全く先に進展しない状況となっています。このような現場が特殊なのかどうかは分かりませんが、こういった状況のとき皆様であればどういった行動、対処をなされるでしょうか？少々長くなりましたが、ご教授頂ければと思います。

mttk1238
お礼率81% (316/390)

SE・インフラ・Webエンジニア
回答数3
ありがとう数4

みんなの回答 （3）
専門家の回答

質問者が選んだベストアンサー

ベストアンサー

coai
ベストアンサー率50% (152/301)

2015/12/04 06:01 回答No.2

難しそうですね…私ならキレて投げ出します(笑) でもテストがまともに行われていないというのは致命的ですね。新しくテスト要員を雇う必要がある、そう上の人に主張するしかないかも知れませんね。仕様通りに動くかどうかを確認するだけでなく、改善案も出せるように、「デバッグチーム」「テストチーム」ではなく「品質向上チーム」として。テストに必要だからという理由で、最低限のドキュメントを作成させる事もできるかも知れません。ユーザー目線のドキュメントを、品質向上チーム内で作成できるかも知れません。開発者目線でデバッグ・テストできるように、プログラマが一人は欲しい。ドキュメントの作成ができるように、DTP経験者が一人は欲しい。作っているシステム回りに明るい人物、たとえば経理プログラムなら経理マン、Webサービス等ならWeb技術者等が一人は欲しい。上記「一人は欲しい」と書いたが、得意不得意、向き不向き等があるので、できれば2～3人雇えればベストだが…。過去に「品質向上チーム」に居た事がありますが、技術じゃなくてセンス、あんまり体系化できるものじゃなくて、個人の経験に頼らざるを得ない分野なんですよね… ある程度パターン化はされているけれど、当然ながらあらゆるケースに応用できるものであるハズはなく、このケースに当て嵌められるかどうかという判断は必要だし、システム毎に新しいテストケースを生み出すセンスが問われたり… どういう人物なら向いているかと言うと、性格が悪ければ悪いほどいい。嬉々としてプログラマが嫌がる想定外のデータを読み込ませ、不具合を発生させまくって「ウォッシャ!!」とガッツポーズを取りながら、不具合報告に記入するような… 仕様書を見ながら「う～ん、この仕様だと、ここがやばそうな気がするな…」と想定しながら、意地悪くその辺りをつつき回って「ほらほらヤッパリ、ウキキッ」と喜んでいたりとか… 私は性格が良かったので、心苦しく思いながら、そういうプログラマが嫌がる事をしていましたが…ウキキッ閑話休題そうやって、品質向上チームを作って、品質向上チームのチェックでOKが出ないと出荷させないというルールを作って、品質向上チームを後ろ盾になぜそれをやらないといけないかと開発チームを説得、場合によっては直さないと出荷させないと強硬策でま、もしすべてが上手く行けば…という空想レベル、妄想レベルの話ではあるけれど・他プロジェクトチーム案件のテストも、そのチームで受けるようにして、全社的に品質向上を図るようにして、予算を確保(1案件のために新しく数人を雇うより、複数案件の品質向上が図れるとなると各案件毎の費用分担は減る) ・チーム名を「品質向上」のような名前にすることで、反対意見を出しにくくする(品質向上のためという錦の御旗を立てる) ※当方が過去に在籍したのは、Quality assurance(QA、品質保証)チーム・システム全体を(下手をすれば、作成しているプログラマ本人よりも)広く知ることができ、新人を鍛える場として機能する(テスト・デバッグ作業を続ける事で、システムの内部仕様まで詳しく把握、結果的に使えないプログラマをクビにしてQAチームから開発チームに移籍というケースが多々あった) ・別チームにすることで「こんなもんレビューの域に達してない、最低限のチェックは済ませてもってこい」と付き返せる、「レビューして欲しければドキュメントを持ってこい」と言える…かも？(私はそれに近い事を言ってた) そんなところを説得材料に、なんとか上手く上と交渉してみてくださいな

その他の回答 (2)

koutei-no-inai
ベストアンサー率15% (84/546)

2015/12/04 07:20 回答No.3

エンジニアたちがなぜ言うことを聞かないのか。たんに反抗的というのではなく、いい大人なんですからそれなりの理由があるはずです。会社がそれを許してきたことも背景にあるでしょう。エンジニアはクライアントと直接話をする機会がありますか。プロジェクトマネージャーから指示を受けて作業をするだけではなかったでしょうか。だったらクライアントのニーズなんか理解できるはずありません。独善的な態度を「エンジニアの誇り」と履き違えて、ますます独善に陥ってしまいますよ。私があなたの立場なら、クライアントさんに頼んで企画会議から同席させてもらいます。もちろん担当させるエンジニアも同席させます。あとからゴネなくていいように、エンジニアとしての意見も言わせます。それから、成果物に対してクライアントがこんなに喜んでくれたということを、エンジニアにも伝えます。自分がつくったものを喜んでもらって、嬉しくないはずありませんから。それが真の誇りややりがいになって、クライアントのニーズに沿ったものをつくるようになるのではありませんか。時間はかかると思いますが、それが今のあなたに期待されている役割ではないでしょうか。