【コミュニケーション】脳内のアイデアは素晴らしく見えるけれど、組織内で他人に作業依頼する以上は言語化しないと手戻りが増えて困ったことになる
はじめに
対象読者
- 仕様が不透明でやり直しが多い気がする現場の開発者向け。
脳内のアイデアは素晴らしく見える
思い付きを形にするのは一苦労
それが小説でもイラストでも動画でも、格言のようなセンテンスであっても。アイデアは美しく素晴らしく見えます。しかしアイデアを形にするのは大変です。
語彙力や画力のなさに辟易とし、試行錯誤を重ねるもアイデアのときに思い描いていたものに遠く及ばず。まず完成させるのが難しいまであります。プログラムだと分かりにくいかもしれませんが、この辺の要領は物理的なモノ作りと同じです。
もし開発者と協働する関係者で、社会人になってから何も完成させたことがないという方は、一つモノを作ってみてはいかがでしょうか。もちろん自分が業務で取り扱っているものの方が、より開発者に寄り添えるかもしれませんが、いきなりWebアプリは難しいでしょうし。
ツクールやメーカーでも十分です。いつも開発者に依頼するように、イメージや理想像を膨らませてメモにしておきましょう。それを実際に作業した後の自分に見せてみて、どのくらい現実的なものであったかを痛感するのです。大なり小なり「なんかちょっと違う」と思う筈。
組織ではアイデアを出す人・実現する人が別
さて同一人物ならば話はシンプルでした。問題は組織においてアイデアを出す人と実現する人が別のパターンが多いということです。社長や経営者がビジョンを共有し、役職持ちが具体的なプロジェクトを推進し、開発者が手足となって具体的な製品に落とし込む。
自分の中にあった美しく素晴らしいアイデアがどうなるか。上手く行けば想像の遥かに上をいくクオリティで上がってくるでしょうが、多くの場合は良くて2,3割引きといったところでしょうか。「なんか思ってたんと違う」状態で上がってくる訳です。
出てきたものが違うのは認識しており指摘を試みるのですが、具体的な提案・代案まで言及することができないようです。これが同一人物ならば諦めも付きますが、別人故につい気軽に「何とかならない？」と言ってしまいます。特に仕様周りでこれをやられると辛いものがあります。
何とかなってないから現状の形で出来上がってきているので、原因を分析した上で条件や仕様を調整しないと何も変わらないでしょう。もちろん開発者は説明しますが、中には自分の理想を100%完璧に実現できるまで粘ってしまう方もおられるのです。
朝令暮改な頭の中の正解
またこの正解にも問題があります。正解がコロコロ変わるのです。終いには最初に言っていたことと矛盾する場合があります。
脳内にあるものは可変です。時間経過と共に美化されていきますし、上がってきた現物を見てブラッシュアップされてしまいます。この変化を認識できていなければ、モノが出てくる度にそれを受けて正解が変わります。「もっと◯◯な感じ」と言われたことはありませんか？
この改善自体はむしろモノ作りの醍醐味です。しかし別人に依頼した仕事のゴールポストが、追いつく度にあちこちに移動するのは問題があります。だから会議の議事録を残し、仕様検討の結果は理由も合わせて記録しておく必要があるのです。それこそ誰が何を言ったかまで。
そうしてゴールを明確に定義し、ゴール自体の移動は関わるメンバー全員が認識を合わせた上で行うべきです。同一人物のときに無意識に済ませている仕様の調整も、チームで動くときには意識的に情報共有しながら行わないといけません。脳内に不安定なまま放置してはいけないのです。
アイデアを組織で実現するにあたり
意思決定して仕様書に落とし込む
開発者側である程度のプロトタイプやデザイン案を作るのはいいとして、レビューから先は具体的に選択・決定しながら、仕様の落としどころを模索する必要があります。
『正解のような脳内の可変なアイデア』を指摘として相手に伝えることは避けないといけません。このために必要なのは文章化です。残念なことに、このバッドコミュニケーションを行う方ほど言語化に苦手意識を持っている傾向はあります。
このため少々手間にはなりますが、別の誰かが言語化を買って出るのも良い方法です。電話や井戸端会議で済まされたら、メールやチャットにして記録を残す。フィードバックに矛盾が生じた場合は、残してきた記録を引用して本人に意図を確認する。それだけです。
具体的な代案も示さず「なんか違うんだよな」を繰り返し、納品物のゴールが全く分からない状態が続くのは不毛です。何を出しても駄目、次の瞬間には別のことを言っている。正直、仕事になりません。
他人事ではなく自分事として事に当たる
自分が困る段階にならないと自分事にならない現象が稀によくあります。これは誰でもどの分野でもやらかすことです。対岸の火事が燃え移るまで気付けないのです。同一人物の場合は困るのが自分なので、ほぼ同じタイミングでした。しかしメンバーに作業を依頼する場合は別です。
知らないと手戻りが発生する情報・作業をより効率よく進められる術は、困るタイミングではなく作業を依頼するタイミングで同時に伝えないと意味がありません。作業が何もかも終わった後、納品物を見てから伝えるのでは遅いのです。
仕様策定から丸投げするにしても。外せないポイントは事前に言語化しておかなければ、文句を言われても仕方がない気がします。暗黙の了解だとか、その会社では当たり前の常識だとか。これらを言わなくても分かることはありません。開発者はエスパーではないので。
相手にとって有益な情報を余裕を持って伝えるのも、依頼する側の責務です。
理由なきやり直しはコンプラ違反
取適法（旧下請法）やフリーランス新法では「不当なやり直し」は明確に禁止されています。同じ社員だとしてもやっていい理由にはなりませんし、理由を説明できなければパワハラと捉えられる可能性もあります。何より生産性だだ下がりです。
外注なら修正の上限回数など事前に取り決めてから作業を開始しますし、これが請負契約ならお互い金絡みの話なので気を付けますが。この辺の線引きが社員同士や業務委託になると途端に曖昧になるのは、良くない慣習だなと思います。
少し話は逸れますが、この問題の遠因の一つは問題が拡大するまで気付けない点です。作業依頼を出すのはマネージャーやリーダー、彼らが直属の上司で社内評価に一枚噛む体制であることが多い。もし問題があったとしても、気が付かないか意図的に隠されてしまう格好です。
だから「ただ報告を待つばかりではなく、人事や経営層が直接現場のメンバーに話を聞きに行くのが望ましい」と口を酸っぱくして言っておりますが、なかなか伝わらないのが現状ですね。
おわりに
プルリクエストのレビューも「誰かの脳内の曖昧な正解当てクイズ」になったら駄目ですが、よくそうなってしまっているケースは観測されます。
もし正解が決まっているタイプのタスクなら、最初から教えておかないとただのクイズです。企業専用のフォーマットがある書類だとか、コーディングルールがWikiに書かれているだとか。そういった事前に知っていれば回避できる情報は、タスク開始前に共有しておきましょう。
この記事に出てくる『正解のような脳内の可変なアイデア』を代案なき批判と罰するのは簡単ですが。何で駄目かというと、これは自分の中の理想とのギャップを埋める行為を、他人にノーコストで求めているからです。工夫も試行錯誤も全部丸投げして、良いところだけ取ればそりゃ楽です。
誰かに何かを依頼する以上は、せめて内容をきちんと言語化し、自分の言ったことには責任を持てる人になりたいものですね。
関連記事
Discussion