正しい方法で問題解決はしない


あなたに機能追加のタスクがアサインされ、そのドキュメントを一読してみたところ複数のドキュメントで機能が対応する範囲に微妙な差異があることがわかった、とします。


さて、あなたはこのあとどういった対応を始めるのですか。

・タスクの納期が決まっているので、機能追加の要件に従って追加する機能を加筆してプログラムを作り、納期を守る
・仕様の不整合となっているドキュメントを指摘し、解決してからタスクに取り掛かる
・一旦、要件に従って追加機能の対応を行うが、課題共有やレビューなどでドキュメントの不整合を指摘する


3つ目の対応が最良であることは誰でも堂位していただけるのではないか、と思うのです。それと比べて1つ目の対応を取られると、後になってなんで教えてくれないの…となること必須ですが、この対応を取られちゃうのが割とあって。ただ、3つ目の対応でも課題やレビュー記録などに残さないと忘れ去られちゃうのでそうなってしまうと1つ目と同じになってしまうんですが。


で、問題は2番目です。オーケー、教えてくれてありがとう。で、どうしたいんだい。え、直さないと進められないだって。言っていることは正しいんだけどさ、それじゃ進まないじゃない。え、ボクの仕事は機能追加だけだって。そうか、じゃあ、不整合のドキュメントのしゅうせいをおねがいしたいんだ…、それは嫌だって。どうして。不整合なドキュメントを作った人が直せばいいだって。そうなんだよね、でも、ほら、いまその人いないし、あ、関わった人もいるけど、それ巻き取ってもらえないかな…。あぁ、そんな正論言われても…。


2つ目の厄介なところは「どうしたら問題を解決できるかwillがない」というところ、です。


いくら正しくても、そりゃそうだ、元々のドキュメントに不整合がなければこんなことにならなかったし、もしそういうことがそのアサインされた人じゃなくて前からいた人が自ら見つけたらその人たちで片付けたに違いないもの。


でも、それじゃせっかく見つけてくれた不整合の問題は解決しないよねぇ。別に機能追加の不整合の修正は解決する方法が決まったときに考えればいい話なんだよねぇ。


そこをスパッと切り落とされちゃうというか、溝を作られてしまうと問題解決のスキルとしては評価できないんだよねぇ。途中でバトンタッチとなってもいいからそれならそれでそこまではバトンを握ってほしいんだよねぇ。