仕事をしていると、誰しも一度は
「あの人、使えないなー」
と、思ったことがあるのではないだろうか。
褒められた考えでは無いが、事実そういう人は一定数要るのではないかと思われる。
かくいう筆者も、長年
「PDP(プランナー、ディレクター、プロデューサー)は使えない」
という、半ば拒絶反応に近い感情を抱いてきた。
（最近は、DPについては、なぜ拒絶されるような行動や仕事の仕方をするのか、
同じセクションを経験する事によって、理解と共感はできるようになったので、
社外の政治でどうにもならない部分についてのコストについては、
やむを得ないかなーと考えるようにはなった。）
ただふと、この「使えない」という抽象的な概念の定義をしておらず、思考停止している事に気づき、
筆者は一体、PDPの何に対して「使えない」という感情を抱き、
また、なぜそれがマイナスの思考であるかのように感じるのかを、今一度自分に問いかける事にした。
〇記事読まない人向けの結論
「PDPは使えない」は適切ではなく、
「問題に対して解決をするべく、出来る範囲ですら適切な取り組みが出来ない人間の考えは、共感ができない」
が、適切という事がわかった。
以下、その回答に辿り着くまでの蛇足。
〇「使えない」とは何なのか
ここでは、PDPとの仕事をしていて、どういったケースで負の感情を感じたことがあるのか、
現在従事している現場を見て感じた事が一番確実だと思うので、列挙していく。
1．仕様書に、認知負荷を起こす記載が多い
概要：
・網羅パターンの内、抜けているパターンが存在する
→ダイアログのOK/CANCELボタンがあり、OKボタンを押した時の挙動はあるが、CANCELボタンを押した時の記載がない
→数値の、下限・上限・範囲が定義されていない
・ある物を定義する言葉が統一されていない
→ダイアログとポップアップと両方記載がある。恐らく、両方同じものを指すのだろうが、
資料としては、統一してくれないと、万が一別の物を指している場合があるので、確認が必要になる。
・代名詞を、代名詞の示す先を確定できないタイミングで使う
→例が難しいが、「これ、あれ、それ」が、一体何を指しているのか、一目ではわからない。
推測は出来るが、仕事を推測で進めるのは怖い。
・代名詞になり得る範囲を侮っている。
→「こそあど」だけではなく、「画像、ダイアログ」といった物も、場合によってはどの？という事になる。
推測は出来るが、仕事を推測で進めるのは怖い。
負の感情：
仕様書を見るだけでは作業が完結しない←一番の理想は、仕様書を見るだけで作業が完結する←時間コストの観点
仕様書に記載されている内容が、仕様書の記載ミスで、根底から覆り実装しなおしになる←余計な作業コストが増える←時間コスト、精神コストの観点
確認作業が頻繁に行われる←コミュニケーションコストがかかる←時間コストの観点
2. 管理する物を増やす
概要：
バックログでタスクチケット管理をしているのに、なぜかバグリストだけ別でスプレッドシートでも管理する。
バックログでチケットに対する番号採番されているにもかかわらず、
スプレッドシートの方でも、独自で番号を割り振る。
負の感情：
単純に情報入力の手間が2倍になるので手間←バックログでバグの状態だけ見れれば完結するので、無駄な手間と感じる←時間コストの観点
バックログとスプレッドシート両方のステータスが統一されない問題も出てきて、どっちが正なのかを確認する手間も発生する←バックログでバグの状態だけ見れれば完結するので、無駄な手間と感じる←時間コストの観点
3. 意思決定する人間が、意思決定をしない
概要：
例えば、動作確認会をして出たバグを、「誰かお手すきの人書いといてください」と、
担当者を任命しない。
複数人が書いたら、バグが2重に報告されるし、誰も書かないかもしれない。
負の感情：
誰も書かない事に気づくのが遅れたら、せっかく発見したバグを見落としたのと同じことになる←余計な作業コストが増える←時間コストの観点
〇負の感情を感じた物を見返していて感じたこと
リストアップをしていて、これらについてのいくつか仮説がたてられた。
1．これらの行動を起こす事によって、「ネガティブに捉えられる可能性がある」という発想が、当事者達に欠けているのではないか
ネガティブに捉えられるというのをもう少し言語化すると
目的や問題解決に対して、解決する為のアプローチとして機能をすると思っているが、
それが、新たな問題を発生させていたり、問題の解決になっていなかったり、目的達成に不十分だという事に気づけていないという事だ。
身近な物で例えるのであれば
・良かれと思ってやった事は、実は余計なお世話だった(新たな問題の発生)
・歯が痛いので、痛み止めで対処した（本当の原因は虫歯なので、問題の解決になっていない）
こんなところだろうか。
当事者達は、仕様書の記載は十分だと思っているが、エンジニアは不十分だと感じ、
バグシートを作る事でシートを見やすくしているつもりが、（おそらくは）バッグログ上だけで同じことができるので、新たに手間を強いるという問題を発生させている。
2．問題で引き起こされる余計なコストに対する捉え方に、筆者と当事者達の間に温度差があるように感じる。
例えば、
「2. 管理する物を増やす」
の場合、少なからずそれを記載する人間は、記載する内容に不備が出ないように、注力してシートの記入を行う。
これは、片手間でやっていいものではない。
しかし、恐らくは、これを思いついた人間は、片手間で簡単に入力記載が出来る物だと思っているような節がある。
この、問題やコストといった物に対する、認識や感覚のズレが発生しているように思える。
〇負の感情について、もう少し掘り下げてみる
冷静に考えてみると、発生する余計なコストに対して、筆者は負の感情を感じるが、
別に、そのコストを対応する時間を補填してくれるのであれば、別に問題はないはずだ。
エンジニアは無駄を嫌うので、やり直し等を嫌がる傾向になるが、
これについては、気持ちはわかるが、仕事である以上、その無駄な対応はしなければならない。
ではなぜこのように負の感情に繋がってしまうかというと、大抵の場合、時間の補填がされないからだろう。
(まぁ、時間の補填が難しいのは、様々な外的要因を考えれば当然の事ではある。)
事前に防げたかもしれない深夜残業や休日出勤を強いられた、と感じる為、
かなり強い負の感情を抱いてしまうのだろう。
ただ、では、これはエンジニアだけが特別割りをくうのだろうかと考えた時に、恐らくはそうではない。
完全にエンジニア側の実装ミスでバグを仕込んだり、検証をミスして要件定義されている実装が難しく、
要件を変更してもらう場合は、PDPがクライアントとの交渉をすると言う手間が発生するので、
頻度や程度の差はあれど、本質的にはどっちもどっちと言ったところだろう。
では、どっちもどっちだと言うのであれば、相互にこの無駄なコストを減らしていければ、WinWinになる気がするのだが、
恐らく、ここの取り組み方に隔たりがありそうだ。
例えば、筆者、もとい、エンジニアであれば、バグが出ないようにテストは言われなくても自発的に最低限は行うし、
仕様変更があった場合も、柔軟に対応できる範囲を広げられるように、技術を学んでいるわけである。
しかし、PDPはどうだろうか。
見る人によって認識が異なる仕様書を是正しようとせず、
エンジニアを管理する人間なのであれば、せめてプロジェクト管理やマネジメントの手法の参考書でも読んで、悪手とされている事は避けて欲しい物だ。
恐らく、筆者が使えないと感じる要因は、問題に対して解決の手段を取ろうとする取り組み方についての感情と言えそうだ。
そして、ここまでの結論に達して気が付いたが、筆者はPDPにイラついているのではなく、
「このように、仕事に対して無駄なコストを削減しようと、できる取り組みをしない人間」
に対して、イラついているのだろうと思った。
なぜなら、エンジニアやデザイナーに対しても、同じ感情を抱くからだ。
たまたま、そういう傾向の人間がPDPに多く、エンジニアに少ないだけの人生だったのだ。
〇いったん結論
「PDPは使えない」は適切ではなく、
「問題に対して解決をするべく、出来る範囲ですら適切な取り組みが出来ない人間の考えは、共感ができない」
が、適切という事がわかった。
〇この結論を、どのように捉えればよくて、筆者の都合の良い状態に解決ができるか
難しい。
なぜなら、
「問題解決に対して、適切な取り組みが出来ない人間」
は、立場・環境・ものの考え方で、筆者も該当する可能性があるからだ。
PDPと筆者で、問題とする物の定義が異なれば、当然アプローチや考え方も変わってしまう。
バグは後から発生して修正する物だ、仕様書が全てではない、という価値観の人間に、
仕様書をきちんと書いてくれ、という意見は受け入れられないだろう。
出来る事があるとするのであれば、まずは筆者が思っている問題を、問題として認知させる事から始める必要がありそうだ。
この辺は、過去に似たような考察をしたと思うので、そちらを参考にしてもらいたい。
もしくは、ルールを制定する側に立つしかないだろう。
そして、
>筆者も該当する可能性があるからだ。
これについては、自分の能力を上げていれば解決する、というアプローチから一歩進み、
相手にはどういう問題が見えているか理解し、筆者の主観だけではなく、
相手にとっての十分を筆者が満たしているか、という視点も、きちんと考える必要があるなと感じた。
場合によっては、一般的に悪手と言われている手法も正解と成り得るだろう。
