定性情報の定量化 ～愛の大きさを数値で測る方法
こんちゃ。ゼバ会です。
今週のテーマは、恋愛小説好きの乙女が気ぃ狂わせてイカりそうな話。
愛の大きさを数値化する方法です。
より正確には、世間一般的には定性情報と見なされがちな情報を、正しく定量化していくための考え方についてです。
「愛」は、定性情報とされがちなものとしては典型的な例というわけです。
とはいえ、、、皆さんの中にもいるんじゃないですか？
嫁や旦那に対する愛の大きさを数値で点数化されちゃ困る方。
あと、部下の成績を数値化されると実は困る経営者とか？
だって、そういうのがちゃんと数値で出ると嫁に怒られる人だっているだろうし、経営者は給料アップしてあげないといけなくなるしね。
そういう理由で考課制度をわざと曖昧なまま放置してる企業、絶対あるでしょ。知ってるんだよ。
これを読んでいる皆さんは、そういう企業に正当なプレッシャーをかけるためにも、「定性情報の定量化」というテクニックをキチンと身に着けていってほしいと思います。
１．なぜプログラムは定性情報なのか
そもそも、デジタル情報の塊であるはずのプログラムが、世の中的に定性情報とされているのか。
それを明確にするには、定性情報という言葉の定義をはっきりさせる必要があるように思います。
Weblio辞書によりますと、マーケティング用語である、との注釈つきでこのような説明があります。
「数値化できない定量情報以外の情報で文章、画像、音声などのこと。」
でもこれじゃ説明不十分ですね。
辞書の説明文だからしゃあないけど、ビジネススクールの講師がこの程度の説明で済ませたらブン殴られますよ。
なんで文章とか画像とかだと数値化できないか？
その理由は２つあります。
理由１．数値化するのに必要な要素が複雑に絡み合いすぎている
理由２．評価が人間の感情論で決まるから
たとえば芸術作品の美しさなんかは、「丁寧さ」「繊細さ」「インパクトの強さ」「ストーリー性」の４軸で評価が決まります。
この４つのうち「インパクト」と「ストーリー性」は感情論だし、なおかつ、これらが複雑に絡み合って１つの作品になっていたり、同じ評価軸の要素が作品内の複数個所に登場したりするために、どういう観点で評価したらいいのかが、どうしてもパッと見では分かりづらくなります。
ですから、芸術品は「定性情報」なんです。
でもプログラムは？
プログラムそのものに「繊細さ」なんてものはいらないし、むしろ繊細さはない方がむしろ望ましい。それから「インパクトの強さ」とか「ストーリー性」なんかはないわけで、残る要素は「丁寧さ」のみ。
こりゃなんとかすりゃ数値化できんじゃないの？
もちろん初心者には難しいでしょうけどね。
なぜなら、ただ「丁寧に作られてるかどうか見るだけ」っつても、見るべきポイントは様々な箇所にバラバラに散在していて、評価者はそれを頭の中で再構築しながら評価せんといかんからです。
そうです。
プログラムが世の中的に定性情報とされているのは、「定量情報として扱うのがメンドイ」から、というだけの理由なんです。
加えて現実には、メンバーの仕事を感情論的に評価するリーダー・マネージャーもいたりして、そういう人のやり方がプログラムの評価をさらに複雑にします。
プログラムに対する感情論的な評価は、サービス全体の評価としてやるべきことであって、プログラム単体に対する評価を感情論でやっちゃいかんのです。
なぜって、「サービス」という概念はいわば全体が１つの作品ですが、その作品１つ１つを構成するパーツは単体は作品ではないからです。
２．じゃあ、そういうときどうすればいいのか
簡単な話です。
要は、客観評価が可能な「観点表」を用意しておけばいいのです。
ものすごい回りくどい前振りだった割に、答えは単純そのもの。
ビジネス本なんかには「定量評価を行うには数値に着目すべし」なんて書かれてますが、要は「上手な人ほど多くなる（もしくは少なくなる）数値は何か？」を考えればいいわけです。
もちろん全世界的に使えるスーパーパーフェクトな観点表はないですが、個人的におすすめする初級プログラマーの品質観点表は以下の通り。
・Cyclomatic complexity が、チームの規定を超えたメソッド数
・メソッドに対するホワイトボックス型の網羅テストのバグが出た数
・メソッド総数を、当初の予定よりもオーバーさせてしまった案件の割合
・プログラマー側の事情で当初の設計を変更せざるをえなくなった件数
・当初の設計よりもパフォーマンスが出ていないメソッドの数
・他人が作ったメソッドに依存するような処理を書いた回数
ね？
これらはあくまで例ですが、こういうの ↑ って「上手な人ほど数値は小さく出る」でしょ？
こういうことよ。
これらも含め、とにかくアイデアを大量に集めること。
そしてその中から「自分達でも計測できるもの」を選択することもポイントです。
（つまり考えることを諦めていたら観点表は作れないということ）
これらから、指示ミス・指示漏れの数と作為的にそうした数を差し引けば、初級プログラマー自身の点数が数値で出てくることになります。
今回の例の場合はゼロに近いほど優秀なプログラマーです。
人事考課のビジネス本とか読むと、「IT技術者の客観評価は難しい」とか普通に書いてあるけど、あんなん嘘っぱちですよ。
「おまえが知らんだけだろ、世の中のせいにすんな」と強く言いたい。
初級プログラマー以外にも「レジ打ちのバイト」「ウェイター」のような、いわゆる機械的な作業に従事する類の仕事は、おおむねだいたい「１点単位での点数化」がほぼ可能です。
（接客業の場合は、接客マニュアルから「チェックシート」というものを作って、そのチェックシートに正しく従えた数を数える）
２．評価が感情論で決まる業務を客観評価する方法
同じように、「理由２．評価が人間の感情論で決まる」パターンについても、似たイメージで点数化できます。
上位の責任範囲になればなるほど客観評価が難しくなってはいく傾向はたしかにありますが、感情論を数値化する方法を、人類はとっくの昔に知っているのです。
１７世紀のイギリス人数学者ウィリアム・ペティが基礎を確立し、その後１８世紀にドイツ人牧師ヨハン・ジュースミルヒがとても美しい学問を完成させました。
そう。「統計学」を使えばいいのです。
そもそも統計学は「人間の感情を数値化する」ための学問です。
・このピザ屋の５段階評価値は？
・当社製品をまた利用したいと答えた人の割合は？
・このサイトは役に立つと感じましたか？
・あなたは犬派？ 猫派？ それとも人間？
ほら。もともとは感情論だったはずのものが、数値で点数化されてる例はいっぱいあるでしょ？
このような統計を、「人間の感情が数値化されている」と捉えることで、あらゆる感情論を定量化することができるわけです。
日常業務の場合は評価するのにいちいちアンケートとってらんないので、「ここまで完成したら何点」みたいな点数表を作るのもいいでしょう。
（最初の１回くらいは本当にアンケートで統計を取ってもいいかもしれませんし、やりようはいくらでも）
前回の引きで言った「夫の妻への愛を数値化する方法」についても、まぁ、要はなんのこたぁねぇ、点数表で点数化すればいいってオチだったわけですね。
・お土産を持って帰った回数
・土日にデートに誘った回数
・夕飯の支度を代わりにやってくれた回数
・洗い物がいつの間にか終わっていた回数
などなど。
自分の旦那をどういう観点でチェックしているかはもちろん妻によりますが、人間が他人を評価するときに「脳内で統計学的に処理している」のは確かです。
なので、嫁からの自分に対する評価項目が分かれば、その評価を上げることなんて造作もないわけですよ。ケケケ。
ビジネスの場合、点数表を作るときのポイントは、評価者によって点数がバラけない文章を考えることです。
せっかくよい点数表を作っても、言葉尻の誤解で点数が変わってしまっては意味がないですからね。
悪い例）
・見づらいメソッドを書いた数
↓
改善案）
・複数のビジネスロジックにまたがるメソッドをうっかりで書いた数
これは、「要素が複雑に絡み合っている場合は、きちんと紐解いてから項目を作る」のと同じことです。
もちろん言葉の誤解は書いた人間が文章下手なだけでも生じますが、要素が絡み合ったまま観点表を書くことによって、よりバラつきの生じやすい文章が出来上がりやすくなるのです。
なので絡み合う要素の一部に感情論が含まれる場合は特に、評価項目をあらかじめ十分に小さい単位にまで分解しておく必要があるわけです。
３．次回予告！！
ただ、、、、、
でもよく考えたらさ、いや、よく考えなくても直感で考えて、絡み合ってる要素の分解って難しくね？
そう簡単にできなくね？？？
そのように感じたそこのあなた。
あなたの感覚は正しい。
当たり前ですが、分解するのが難しいからこそ、プログラマーの評価は今までずっと定性情報ってことになっていたのです。
でもそこはゼバ会。
世間的に仕方ないとされているものに対し、世界を革命する力を与えんがために生まれた会なのです！（ばば～ん！）
やりましょう。
というわけで次回は、「複雑な概念をかみ砕いて分かりやすく分解する」でお送りします。
なお今のうちに行っておくと、次回お送りするのはスモールステップ化と呼ばれるビジネススキルに関する内容です。
これは知識があればすぐ実践できる系統ではなく、多少の訓練が必要となります。
ですがこのスモールステップ化は、「これができる人の数でアプリの品質は決まる」というくらい、物凄く重要なスキルになります。
もしチーム内にできる人が少なければ、２～３日くらい開発を完全にストップしてでも全体で訓練する意味があります。
それくらい価値のある情報のキッカケとなるものですので、アプリの品質が慢性的に低くて悩んでいるチームリーダーの方は、心して聞いていただきたいと思います。
でも訓練つったって、実際にはそんな２～３日もかかるものじゃないです。
普通は１時間くらいウンウン唸ったらすぐできるようになります。
もちろん、個人の方が個人的に努力して会得してもメチャクチャ役立ちます。
場合によっては仕事に対するストレス量が大幅に減って、健康寿命そのものを何倍にも伸ばせるかもしれません。
スモールステップ化はそういう系統のスキルです。
ぜひお楽しみに！
この記事が気に入ったらサポートをしてみませんか？