Backlogポリス秘伝のPMO小技集

最終更新日

この記事は デジタルキューブ & ヘプタゴン Advent Calendar 2022 の 12月8日分の記事として執筆しています。日本での2022年12月8日はもうすぐ終わりますが、安心してください。メキシコでは2022年12月8日はまだ始まったばかりです。

前置きが長いので、小技集だけ見たい方は目次のリンクを活用いただくことをおすすめいたします。

我が家のアドベントカレンダー
我が家のアドベントカレンダー。ちなみに右にあるのはかつてネズミだった何かが付いた玉です

前置きその1

先日人材開発の仕事の一環で、自分を含む全社員に従業員向けのSPI「SPI for Employees」を受検してもらいました。

SPIを利用すると、人事向け・上司向け・本人向けの報告書が届きます。

私に関していえば、職務への適応のしやすさ的に「ただのスピード狂で、関係構築が下手な、それ以外に取り立てて何かあるわけでもない」感じの結果でした。

こんな感じ

前置きその2

さて、私は今年の10月よりデジタルキューブの人材開発室という楽しいミッションを拝命したわけですが、関係構築が苦手なのに人材開発室なのかよというのはおいておいて、受託開発のPMO (プロジェクトマネジメントオフィス) 的な役割は今もやっています。

PMOとしての私は何をしていたかというと、SPIの結果を鑑みて言えば、確かに「いかに仕事を速くするか」はかなり意識していたなと個人的に思っています。またSPIの結果にも出ていたのですが、メンタルが絶望的に弱いので「嫌われないこと」も意識していました。また、Backlogポリスなので、Backlogの平和も守っています。

デジタルキューブのPMOは割とフロントに立って采配する役回りです。持論を言えば、嫌われると割とやりづらい。「嫌われない勇気」という名著もありますが、個人的には嫌われる勇気は必要なくて、とにかく嫌われないようにしようと思ってやっていました。まあ、それでも誰かにはどうしても嫌われるんでしょうけどね。それはもう仕方ないし、もう知らないです。

嫌われたくない

本題

ということで、この投稿では、私が3年弱のPMO経験で気を付けていたこと…主にコミュニケーションに関わること…で、「速く仕事を回す」「極力嫌われないようにする」ためにやっていたことを備忘録的にまとめておきます。

*あくまで私の持論です

テキスティング系① 枕詞を使う

意思決定を促したいとき

いったんXXのようにするのでいかがでしょう?」

「A案とB案があるかと思いますが、私としてはXXXの点でA案がおすすめかと思いますが、YYY様としてはいかがでしょう?」

ポイント

  • 人は決めるのが怖い生き物です。「いったんこうしませんか?」と問うてみましょう。
  • 人は自分で決めたい生き物です。おすすめを提示して決めてもらいましょう。

なんとかとりあえず確認してほしいとき

念のためご確認よろしくお願いいたします。」

「いったんご確認よろしくお願いいたします。」

「お忙しいところ恐縮ですが / お手数ですが ご確認よろしくお願いいたします。」

ポイント

  • 言質を取りたい時、何度も何度も確認を依頼しているが、それでもどうしても確認して欲しい時、途中経過ではあるものの確認してほしい時、この人若干イラついてるかもな / 今忙しいだろうな という時など、シチュエーションによって枕詞を変えると良いでしょう。

どうしても期限を切りたいとき

「進行に支障が出ており、このままですと貴社のご希望の納期に間に合わない可能性がございます。XX月XX日XX時までにお返事いただけない場合は、恐れ入りますがA案で進めてまいります。」

ポイント

  • 相手のためにも、ケツは切りましょう。
  • こちら都合だけじゃなく相手のメリットデメリットを考えているということも伝えたいところ

こちらも大変なんですよ、というのをやんわり伝えたいとき

上長にかけ合いまして、なんとか承認を得ましたので〜」

「通常は対応していないのですが、今回特別に〜」

ポイント

  • 日本人はヒエラルキーに弱いです。
  • 人は特別扱いされると嬉しいものです。ただし、特別感を出しすぎると嫌味になります。

ギスギスさせたくないとき〜すでにギスギスしかけているとき

「(コメントの最初に)ご確認ありがとうございます。」

「(コメントの最初に)ご連絡ありがとうございます。」

ポイント

  • ありがとうと言われて嫌な人はいません。

やんわり断りたいとき

誠に恐縮ですが、〜のため、お受けしかねますことをご了承ください」

上長に掛け合ったのですが、難しそうでした。申し訳ありません。」

ポイント

  • 論理的に説明しましょう。あなたの説明はあなたの預かり知らぬところで知らないステークホルダーに伝えられていきます。
  • 日本人はヒエラルキーに弱いです。

機械的な何かのせいにしたいとき

「〜が悪さをしているようです」

ポイント

  • 「悪さしている」ってかわいくないですか?

断定すると危ないかもなというとき

「〜のようです」

「〜かもしれません」

「〜と思います」

ポイント

  • 言葉尻をつかんでくる相手はもちろん、断定できないケースでは断定しない方が良いケースがあります。そう、政治家のように。

主に開発者向けに何か伝えるとき

「XXXの調整お願いします」(修正って言わない)

「〜ができない」ではなく「〜したい

ポイント

  • 明らかな修正ではない限り「修正」と言う言葉は使わないようにしています。「元々あった要件に叶っていない」なら修正ですが、それ以外は全部「変更」か「調整」です。
  • お客さまなどから「XXXできない」という要望が上がってくることがありますが、ネガティブな言い方で伝えるメリットは全くありません。全員の脳みそが停止するだけです。「XXXできないのでYYYしたい」に言い換えた方がよほど生産的です。

テキスティング系② よく使う言葉は辞書登録する

BacklogやTypetalkなどのコミュニケーションツールでやりとりしていて、2回以上使う言い回しは定形のものとして辞書登録した方が良いと思っています。

時間の節約にもなりますし、誤字脱字防止にもつながります。(個人的には、誤字脱字や言葉の誤用が多い会社は信用できません。)

辞書登録例(どんどんアップデートしていっています)

入力変換
ありありがとうございます!確認しました。
ありありがとうございます。Wiki に転記しましたのでクローズいたします。
ありありがとうございます。担当回しました。
こか子課題が全て完了いたしましたので、親課題をクローズいたします。
こか子課題に合わせ期限延長いたします。
こか子課題にてスケジュールを引きますので少々お待ちください。
こか子課題にてスケジュールを引きましたのでご確認よろしくお願いいたします。
こか子課題でスケジュール作成をお願いします。
ごかご確認よろしくお願いいたします。
ごかご確認ありがとうございます
ごかご確認いただけますでしょうか。
ごかご確認ください。
ごふご不明な点がありましたらお伝えください。
ごれご連絡ありがとうございます。
じょ情に棹させば流される。意地を通せば窮屈だ。兎角に人の世は住みにくい。
てん添付にて見積書・発注書をお送りいたします。
てん添付にて請求書をお送りいたします。
ほん本番環境に反映いたしましたのでご確認よろしくお願いいたします。
ほん本番環境への反映をお願いします。
ほん本番環境に反映いたしましたのでご確認いただけますでしょうか。
みつ見積書&発注書チェックお願いします。
もん問題なさそうでしたら本番環境に反映いたします。
もん問題なさそうでしたら課題完了をお願いいたします。
よう要件がFIXしましたので開発をお願いします。
よろよろしくお願いいたします。

パス回し系① 人をタグづけしておく(担当領域を知っておく)

パスを回すときに必要なのが「これを誰に回せば良いか?」という判断です。これは慣れるしかありませんが、私は人のタグ付け×人のタスク状況 で振り分け先を決めています。

CSS/プラグイン/サーバ/インフラ系用語/フィード/RSS/API など、何かしらの用語が入っていれば、あらかじめ自分の中でタグ付けしていた担当にそのまま投げます。

以下の記事によると、社会人の読む速度の平均は「約600文字/分」らしいです。つまり、10文字程度のキーワードなら0.1秒で読めます。メッセージを書いて担当者設定するのが1分として、長くても1.5分くらいあれば担当者にボール回しができます。パス回しも前述の辞書登録で時間短縮できる。

パス回し系② 後工程を考慮して回す

後工程の人が次に何をするか?を理解したり、想像できるとパス回しもスムーズになるかなと思います。例えば不具合であれば、解決までに以下のようなプロセスが発生するはずです。

  1. 問い合わせ内容を読んで理解する
  2. 再現できるか調査する
    – 特定の状況下なのか、どの環境でも再現するのか?
    – 現象をすぐに再現できる画面はあるか?
  3. 再現したら、その原因が何かを調査する
  4. 調査結果が出たら対応策を練る
  5. 対応策を実行する

解決するには、後工程へ渡す情報は多い方がいいし、まとまっている方が良いはずです。

従って

「1をするために、顧客からの問い合わせがパッと理解しづらそうならまとめておく」とか

「2のために、自分のPCやSPで再現するかどうかを試して、その結果も後工程の人に伝える」「再現できるURLを確認して渡す」といった先回りまでできれば、後工程は速く進む可能性があると思います。

っていうか、問い合わせした人が後工程まで考えてくれるのが一番なんですけどね。

まとめというのじゃないけれど

まあ、そういう感じで、自分や相手が速く仕事が済むように・円滑に進めるにはどうするかということを考えて実行しているわけですが、言わせていただくならばまず

5分をなめるな

です。

5分ってどのくらいかというと、8時間勤務の場合は8時間の1%。

1時間でいうと、12分割すると5分です。逆に言うと5分が12回連なれば1時間になります。

「5分くらいで終わりそうだったからちょっとやっといた」とか

「5分くらいなら良いかと思ってやらなかった」とか

色々あると思うんですけど、5分を軽視する人ですごいなっていう人、あんまり見たことないです。

自分の5分もそうですし、他人の5分もなめないように。

ただのスピード狂で、関係構築が下手な、それ以外に取り立てて何かあるわけでもない人間の備忘録でした。

12/9は @gorooe の記事「そもそも AWS って何?」です。