36
32

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

プロジェクトマネージャーやプロジェクトリーダー視点での考察

Last updated at Posted at 2022-02-02

概要

この記事は、自分自身のPMやPLとしての考え方を忘れないようにする備忘録。
そして、これからPMやPLやる人の参考になれば良いと思って書きます。
また、PMとPGで対立、対顧客との禍根が発生しないような考え方について書いています。

中には、『それ、違うだろ?』と、思う事もあるかもしれません。
この記事は、私の経験上『これでうまくいった』のリストも兼ねております。
決して第3者の考え方を否定したり、『こうなるべきだ。』と、言う事ではありません。

あくまで、1個人のPM・PLの経験による参考程度に思ってください。
少し長文になりますが悪しからず。
※後で見やすいように整え直します。

第1章:視野

第1章のテーマは『視野』です。
この『視野』は、プロジェクトを遂行する上での『主観的視野』と『客観的視野』について書きます。
プロジェクトを遂行する上では、『客観的視野』が大切になります。

皆さん、プロジェクトを遂行する上でどのような視野を持ていますか?

一言では言えないな。ちょっと深い事質問された。

殆どの人は上記のように思うかもしれません。難しいですよね?
では、具体的に『主観的視野』と『客観的視野』について説明しましょう。

例:職場でアメを貰った。

皆さんにわかりやすい例を『職場でアメを貰った』を仮定して説明します。

主観的発想

あ、ありがとう。

上記の一言で何も考えず、考えても『この人親切な人ね』で終わります。
何も建設的な論理的な話にはなりません。
『親切な人』と、勝手に決めつけて素性がわからないまま仕様を思い込みで動いてしまいます。

客観的発想

なぜ、この人はアメをくれたのかな?

上記は、WHY(なぜ)とアメをくれた事実に軸足を置いて考えます。
どんなことを考えるかと言うと。

  • 仮説1:『職場で一人でアメを食べると気まずいから周りにアメを配っているのかな?』
  • 仮説2:『「このアメお勧めだから食べて」と、思ってアメを配っているのかな?』
  • 仮説3:『何かのお礼としてアメを配っているのかな?』
  • 仮説4:『今日はオフィスが乾燥しているし、風邪ひかないように喉を潤すために気を利かせてアメを差し入れしているのかな?』
    などなど、瞬時に仮説を立てて相手の『目的』について敏感に『アンテナ』を張る必要があります。

次に仮説の裏取り・認識合わせの行動(会話)を行います。

裏付け・認識合わせの会話。

それぞれの仮説に対して、会話を実施し相手の意図を探ります。
『目的=アメを配った経緯』に注目します。

仮説1: 『職場で一人でアメを食べると気まずいから周りにアメを配っているのかな?』
会話(自分): 僕ちょうど小腹空いていたんだよね。ありがとう!
会話(相手): そうなんですか?実は私もなんです。

上記の会話の場合は、相手がおなかを透かしてアメを食べたがっていた。の説が濃厚になってきました。認識があってきました。
要件定義での打ち合わせは、このように相手の『意図』を探るようにそして角が立たないように質問をして、『事実目的を明確に共有・認識合わせする』が大切です。

仮説2: 『「このアメお勧めだら食べて」と、思ってアメを配っているのかな?』
会話(自分): ありがとう。これって何かおススメのアメなの?
会話(相手): いえ違います。ただのアメですよ。
この場合は、もっと踏み込んだヒアリングを行う必要があります。現段階は認識齟齬です。
まだ『意図』が見えてきません。

仮説3:『何かのお礼としてアメを配っているのかな?』
会話(自分): 「ありがとう。これ何かのお礼のアメ?」
会話(相手): 「違いますよ。オフィスが乾燥しているので、喉を潤す用に差し入れです」
この場合は、仮説3としては認識齟齬でしたが、『仮説4が目的だった』の認識合わせが出来ました。

上記の仮説と会話の通り、『目的』の答えは1つとは限りません。
仮説に漏れもあるかもしれません。

客観的視野による会話によって得られるもの。

客観的視野を使って会話・考え方をすると、要件定義など含めたエンドユーザーとの打ち合わせ及び、各種設計による仕様の確定(認識合わせ)、レビューなど重要な観点が見えてきます。

私はPMの習性として、事柄・仕様を主観的な視野で即座に決めつけません。
また、いきなり相手の言っていることを否定することもありません。
まずは、耳を傾けます。

得られるもの
要件定義・各種設計・レビューの重要な観点、仕様確定の認識合わせが得られる。

注意1
主観的な視野による解釈で、勝手に相手の目的を決めつけず、まずは耳を傾けること。

注意2
人の特性や考え方・経験・得意分野を考慮してチーム編成を組むこと。
お客様と打ち合わせするときも、『目的』を的確に射貫くためいろいろ探りを入れて見つけること。

ここまでが、『第1章:視野』のお話です。

第2章:PMは常に冷静であるべし。

皆さん、『炎上プロジェクト』って経験したり耳にしたことありませんか?
または、炎上まで行かなくても上手く遂行できないプロジェクトってありませんでしたか?

上記は、なぜ起こるのでしょう?
自分なりに整理した結果が以下の通りです。

ダメなPMの例
PMが感情的にあちこちでバトルしたり、人に無関心だったり、言い訳したり、精神論を唱えたり、ろくに会話せず勝手にいろいろ決めると、プロジェクトが炎上する。
または、禍根がたまる。ステークホルダーと、人間関係がうまくいかない、フラストレーションがたまる。

じゃどうしたらいいの?
それは・・・・

心得を決めること。
PMこそ、常に冷静に周りに目と耳を傾け、論理的・客観的に考えて裏を取り、『プロジェクトの目的』と言う名のゴールにチームを導く必要がある。
その土台の上でPMBOKなどの話が載ってくる。

そして注意点

注意
PM・PLは常に客観的視野を広げ、ステークホルダーにアンテナを張り巡らせ、人を見て時に『目的』がずれかけている場合は、是正すること。

第3章:教育

皆さん。
昨今の人手不足に便乗して下記のような人増えていませんか?

  • 勉強したくない。
  • パソコンは元々苦手
  • 仕事に意欲持てない。
  • そもそもITに興味がない。

何故か上記の様な人が時々入ってきてしまいます。
この場合は、そもそも興味意欲が無いので、いくら教育しても育ちません。何年も同じ状態です。
かつ、コロナ禍も相まって本人も「この仕事向かない」と、認識しておきながら会社にしがみつきます。
この手は、本当に手が焼けます。

人は、『興味』『意欲』があれば、いくら未経験だろうがスキルが低いだろうが成長できます。
しかし、『興味』『意欲』が無ければ、何をしても無駄です。ずっと足を引っ張られどうしようもありません。正にIT介護状態。
そして、世話が焼ける事によってPM・PLが本来持たなければいけない、『客観的視野』が狭くなってしまいます。

では、どうしたらいいのか?
それは次の章です。

第4章:面談・面接

『興味』『意欲』を計り、世話が焼ける人を入れないファイヤーウォールが『面接・面談』です。

この業界は、PGを目指す人が多く、いろんな人がいます。

  • プライドが高い。
  • 主観的視野しかなく、客観的に物事を考えられず、無意識に攻撃的になる。
  • 技術力高いところを好む。
  • 逆にほどほどの技術力のところを好む。
  • 新しいことやってみたい。
  • とりあえずやってみたい。
    などなどいろんな人がいます。

しかし、1点共通していることがあります。
それは・・・

応募者は基本的に全員ITに興味・意欲がある。

です。

その『興味・意欲』を計るところが、面接官の腕の見せ所かもしれません。

基本的にありきたりな質問は、当事者が練習して応えられるようしてきます。
経歴書も少し盛ってよく見せようとしてきます。
その経歴書に合わせてストーリーを考えてきます。

注意
ありきたりなやり取りでは、『興味・意欲』がわからない。

採用予定ノルマをこなすために、この注意点を考慮しないまま面談して通してしまうと・・・
第3章で紹介したIT要介護者になってしまいます。
興味意欲が無いので、成長できません。

じゃどうしたらいいの?

合えて少し深い突拍子も無い質問をして、相手の動き・考え方・目の輝き度、回答内容を見る。

です。

あえて、ITに興味がある人なら突っ込まずには居られない質問を用意します。
今の状況、お互いの立場を鑑みた観点を持っているかを測ります。
将来的にめんどくさい人、お客さまとの会話の耐性ができるかも見るため、あえて曖昧な質問をします。
例えば、『なぜ1Byteは8bitだと思いますか?』と、質問します。

この質問は、先日Twitterでやって多くの声を頂きました。
いいベンチマークが取れました。
主な回答は下記のパターンでした。

  • そもそも8bitと決まっているわけではない。
  • 8bit以外で1Byteとしているハードウェアがある。
  • ISOで2008年に決まった。
  • なぜISOで決まったのか歴史的にひも解く必要があり、即答できない。
  • XXXXXなために8bitになったのでは?
  • お前、ただのいきりじゃん。
  • お前、答えろや。
  • 恐らく、XXXXな視点で質問していますよね?私はXXXXXXと考えています。
  • わからないので、逆に教えてください。
  • 自分は、それはわかりませんが。〇〇〇の話だったら詳しいですよ。
  • 各種説はある。そっちの説は間違っていそうだけど、明確な答えは見つけられない。

上記の質問は教壇で放ったのではなく、面接を想定しています。
はい。いろんな意見を頂きました。
しっかり、『この人とプロジェクト回せそうだな。将来、お客さまとも認識合わせて仕事してくれそうだな』と、印象を受ける回答がありました。
逆に、瞬時な客観的発想が出来ず、主観的感情が暴走して的外れな人もいました。
それでもここに共通点があります。それは、『みんなITに興味がある』です。

そして、ITの仕事は必ずしも技術力だけ求められるのではありません。

『仮説を立てる』⇒『裏付けをする』⇒『認識合わせをする』
時に、意見を言う。質問をする。
ここで、コミュニケーションが求められます。

狭い視野による主観的な感情では、相手の意図を理解できず勝手に決めつけを起こす人もいます。
でも、それは、怪しい点にはすぐ気づける長所です。
『わからない』って言う人は、Yesマンにならずにわからないことは、「わからない」と、はっきり言える人です。
『それはわからないけど、〇〇だったら詳しいです』と、言う人は、自分の立場をわかって他でアピールしようとしています。
そして、誰に何を言われたでもないのに調べ出す人もいました。
びっくりなのが、具体的な書籍を紹介して「Nページに書いています。」と、言い出す人もいました。

みなさん、優秀じゃありませんか?
ここでの共通点は、『自分なりに考えて動ける人』です。

PMやPLは、多少の癖が強い客やPGが居てもまとめなければなりません。
相手に長所、特性、得意分野、相手の考え方を尊重してチーム編成をする必要があります。

みんなが輝ける場所を作る。
それが、PMの仕事なのかもしれません。

最後にプロジェクトを円滑に遂行する考え方をもう一つ紹介します。

第5章:『結果論型』『目的論型』2種類の人間

IT業界は、PGやお客様に限らず殆どの人は、無意識のうちに『結果論型』と『目的論型』に分かれると思います。

例えば、NULLについて。
結果論型: 自分は学生時代、NULLはヌルって習った事実がある。今までのプロジェクトもそうしてきた。
目的論型: NULLは英語に近い発音をすると、普通ナルだろ。

上記のケースはどちらも正解です。
なぜなら『NULLはNULL』だからです。
あんまり揉めるようなら、多数決でも取って開発規約に『今回のプロジェクトに限り、ナルで行く』と、でも書いて沈静化しましょう。

上記の様に特にプライドが高い人ほど、『結果論型』と『目的論型』で衝突が起きやすくなります。

結果論型(長所)
過去の成功体験をベースに安定志向を行く。
過去失敗したことは、指摘する。

結果論型(短所)
客観的視野が狭すぎて、主観的視野が異常に広い。
過去の経験に捉われすぎて、あまり会話などせずにすぐ決めつける癖がある。
早とちりしやすい。

目的論型(長所)
経験に捉われず、目的の事ならとことん知識を吸収する。
過去の経験に捉われない発想で、効率化を図ることができる。

目的論型(短所)
チャレンジ精神が大きすぎると、リスクも多く背負いがち。
結果論型の人について、強く言い過ぎてしまう事がある。

我々は、上記の様なITに興味がある個性豊かな人々をまとめて、プロジェクトが円滑に進むように切磋琢磨する必要があります。

そして、人間は誰でもPMでもミスをするものです。
そのために確認すればいいですが、お互いの長所や考え方を尊重していくことが重要だと思います。

以上、長くなりました。

36
32
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
36
32

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?