人というブラックボックスにどう立ち向かうか？
この記事はGoodpatch UI Design Advent Calendar 2018の14日目の記事です。
突然ですが、皆さんはブラックボックスと聞くとどんなものをイメージしますか？
私は何となく嫌なものをイメージしてしまいます。
もともとの語源は機械装置を指していて、
内部の動作原理や構造を理解していなくても、外部から見た機能や使い方のみを知っていれば十分に得られる結果を利用する事のできる装置や機構の概念。引用:ウィキペディア
とあります。
ブラックボックス、とても素敵なものです！現代は、例えば自動車や、家電、スマートフォンなどブラックボックスが溢れており、とても便利な世の中になりました。
ではなぜ嫌なものだと感じてしまうのか？
それは、“本来の意味の内部の動作原理や構造を理解していなくても”が強調され、外からは何も見えない得体の知れないものという意味で使われているからだと思います。
機械装置だけではなく、人間界で言うとブラックボックスは属人化という意味で使われていたりしますよね。
属人化は、その人しか知らない作業や情報がある状態を指し、基本的には属人化ではなく仕組み化（標準化）した方がいいとされます。
ここでは、ブラックボックス = 他人の思考（外から覗き見ることができないもの）という意味で考えてもらえればと思います。
これは私がこのブラックボックスに対して葛藤したことと、その結果からの考察です。何かのお役に立てば幸いです。
優先順位というブラックボックス
皆さんは、普段タスクや開発する機能などの優先順位をどうやって決めていますか？
またそれを他の人に説明することはできますか？
一人であれば言語化できなくても問題ないと思いますが、
それが複数人のプロジェクトになると、優先順位がプロダクトオーナーに依存して、タスクが止まるということも考えられます。
なぜなら優先順位はプロダクトオーナーというブラックボックスの出力結果であり、その順位を決定した思考を他人が覗き見ることはできないからです。
私も実際にプロダクトオーナーが忙しいために優先順位を確認することができず作業が止まってしまったり、優先順位の低いものから着手してしまったということがありました。
そこでこの優先順位というブラックボックスを解明し、仕組み化することに挑戦してみました。
手順1: 観点の洗い出し
まずはじめに優先順位を考える上で、プロダクトオーナーが気にしている観点を洗い出しました。
ユーザーテストで検証する項目に優先順位をつける手法にアサンプションマップというものがありますが、それと似ています。
ただ違うのは2つの観点（ユーザー体験への影響度 / 自分たちが知っているか）だけではなく、もっと多くの観点で考える必要があったということです。
画像の観点は仮のものですが、実際はプロダクトオーナーと観点が重複しているところがないか、抜けているところがないか確認しました。
手順2: 評価
次に機能やタスクに対して、各観点で「◯」「△」「✕」の3段階の評価を行えるようにしました。3段階にした理由は、それ以上になると評価することに時間がかかってしまうためです。
「◯」=4点 、「△」=2点、「✕」=1点で計算して合計点を算出します。（この数値は適当です）
この合計点が高いものから順に並ぶようになれば優先順位が算出されます。
手順3: 観点の優先順位
プロダクトオーナーにヒアリングを続けたところ、各観点にも優先順位があることが分かりました。
そこで、各観点に重み付けの係数をつけることにしました。
係数によって優先順位が大きく変わるので、係数と「◯」「△」「✕」の点数はプロダクトオーナーにしか変更できないようにしました。その他にも何個かルールを設けましたが、今回は割愛します。
一旦このシートをチームで使ってみました。
結果
プロダクトオーナーが優先順位を決定する時間より、約3倍（約20分→約60分）かかりました！
かつ2人で取り組んだので、6倍生産性が悪いことになります。（そりゃそうだろって感じですが）
しかし、仕組み化して下記のメリットを得ることができました。
1. プロダクトオーナーが不在でも精度の高い優先順位が算出できる
2. 仕組みを改善するという思考になる
プロダクトオーナーと優先順位がずれていたときも、観点が抜けているのか、係数が違うのか、採点の基準がずれているのか、どこが原因なのか発見しやすくなりました。またそうなった場合は、どこを修正すればより精度を上げられるのかという生産的な活動につなげることができました。
3. コミュニケーションコストの削減
観点や係数を可視化したことで、ブラックボックスに小さな光が当てられ、プロダクトオーナーの思考が、少しですが読み取りやすくなりました。係数はプロダクトの段階によって変化するところなので「今は何を重視しているフェーズなのか」、「この観点はこういうときに重要だ」など、考え方が読み取りやすくなり、コミュニケーションコストが削減できたと思います。（これは具体的な指標はないです、個人的な感想です）
仕組み化の考察
点で見ると生産性が悪いという結果で終わりますが、今回の仕組み化をしたことで、長期的に見ると特に「コミュニケーションコストの削減」のメリットが大きいのではないかと思いました。
人は人を完全に理解することはできない。人は他人から見たら全員ブラックボックスです。だからこそ、プロダクトオーナーは価値や要求を伝え、デザイナーは画面を起こして、エンジニアはコードを書いて、アウトプットをしながら具体化して「合ってるよね？こういうことだよね？」を確かめています。
この「合ってるよね？こういうことだよね？」が完全になくなったら、コミュニケーションを取らずに全ての作業が並列化できる、かつ中間成果物がほとんどいらなくなり、めちゃくちゃ生産性が上がると思いませんか？
これは極論ですが、今回の仕組み化をしたことで、「合ってるよね？こういうことだよね？」のコミュニケーションを少しずつ減らせていけると思っています。
（少し脱線しますが、コミュニケーションコストを削減するという意味ではプロダクトオーナーのインプットと同じインプットをするという施策も有効でした。）
しかし難しいのは作業を羅列しただけの仕組み化は、作業者を産むだけなので、コミュニケーションコストの削減は難しいということです。
そして作業者は今後AIや別のテクノロジーに淘汰されてしまうでしょう。
この塩梅に関しては引き続き研究していきたいと考えています。
最後に
AIや働き方改革などが取り沙汰される中、どうやってお金を稼ごうか考えていましたが、今後の人間のお仕事は、作業はテクノロジーで効率化しつつ、作業者を産まない仕組み化をすることなのだという結論にいたりました。
以上です。最後まで読んでいただきありがとうございました！