不正へと走る組織（７）
さて、今年も残すところあと僅かとなりました。今年も色々な世間を騒がせた事件がありました。
まず、エンターテーメント界を震撼させた、JKT問題。あの揺るぎない絶対的な地位を固めていたジャニーズ(J)が脆くも崩れ去った。スキャンダルに揺れ動いた歌舞伎界(K)。今まさに隠蔽体質で炎上している宝塚歌劇団(T)
それと中古自動車業界の巨大企業、ビックモータも不正問題で撃沈。次はこれも軽自動車ではNo1のダイハツの不正問題の発覚。
どれも、これも共通しているのは今に始まったことではないこと。(どれも、これも、そんなの昔から・・・)かなり昔からその組織を蝕み根付いていたこと。それが今になって表面化していることである。
今になって表面化する理由は何だろうと考えてみると、やはりこのご時世、SNSやネットで情報が拡散するから隠せなくなって表面化しているのでないだろうか？
一昔前の情報化時代の前、インターネット時代の前であれば、このような不正、スキャンダルがあったとしても関係者に「なかったことにしておいて・・・」と口止め、あるいは圧力をかけておけば、隠す通すことは可能だったかもしれない。
今は情報化時代。必ず、どこからか情報は漏れる。隠し通せない。上記のように利害関係のある間柄の中では力づくで隠し通せるかもしれないが、利害関係のないところに情報が漏れると、興味本心であっと言う間に広がる。(所謂、外野の野次馬根性)
前回、noteにも書いたダイハツの不正問題であるが、ワニは日本の古くからの年功序列、終身雇用による現場の属人化。それによる経営側、管理側から現場への丸投げが原因の一つあると思っている。
それと前回のnoteの中でも日経ビジネスの記事、下の記事にもかかれている「員数」という言葉にうーむ・・・と唸ってしまった。
「員数」とは？世間一般ではあまり使われないが、旧日本軍内で使われてた装備品や物資の数を示す言葉らしい。(今の自衛隊ではどうなんだ？使われているのか？)
要は帳簿上の数合わせのことで、実際は装備品や物資の数があっていなくても、帳簿上の数さえ合っていれば上官は安心するのだ。(所謂、帳尻合わせ)
こんなことは日本の企業組織の中、昔から、どこでも行われている。
ワニはIT業界でもう30年以上働いているが、やはり過去に似たようなことはあった。
製造業であれば上記のダイハツのような自動車業界もそうであるが、モノを評価する上での基準に以下の3つがある。
Q：Quality（品質）
C：Cost（コスト）
D：Delivery（納期）
製造業でQC活動(Quality Control(品質管理))等に関わったことのある人ならわかっていると思うが、モノは上記のQ、C、Dのバランスで成り立っている。これをレーダチャートに書くと
このような三角形になり、この三角形がバランスがとれて外側に広がって大きい方が良いとされる。つまり、吉野家のように早い、美味い、安いのがよいとされている。
ダイハツの場合はD(納期)とC(コスト)を優先してQ(品質)を犠牲にしていたという訳である。
IT業界の生産物はは製造業とは違って「モノ」ではない。生産物はソフトウェアであったり、システムである。だが、IT業界の生産物である、ソフトウェア、システムにもQCDはあるのである。
D(納期)とC(コスト)ついては製造業とおなじである。が・・・
IT業界におけるQ(品質)って、何ぞ？「モノ」じゃないだろ？
と思われるかもしれないが、IT業界におけるQ(品質)とはバグの数で計られるのが一般的である。つまり、
バグだらけのシステムは使い物にならん→品質が悪い。
バグが少ないシステムは優秀→品質が良い。
という訳である。1.の方はまぁまぁ、言い得ていると思うが2.の方は、今この時代は必ずしもそうではないかもしれない。(後述)
ワニも過去にnoteで何度も取り上げているが、IT業界の開発管理手法において古くからウォータフォールという手法が用いられていた。(今はアジャイルが主流になりつつあるが、それでもまだ多い)
ウォーターフォール（Waterfall）は、ソフトウェア開発の現場で利用される開発手法です。英語で「滝」を意味し、上流工程から下流工程へ順次移行していく開発手法である。
一般的に、ソフトウェア開発は
要件定義
→→設計(概要、詳細)
→→→→コーディング
→→→→→→テスト(単体、結合、総合)
の順番で行われる。これが前工程の終了を持って次工程に進むので多段の滝のようなのでウォーターフォール（Waterfall）と呼ばれている。
ここで、Q(品質)の話になるが、試験工程においてバグの発生件数が前工程の品質の評価になる。
ここで問題なのが単体テストである。
ワニは30年以上もITの業界にいるが、令和になった今でもこの単体テストにおける「単体バグ数と内容を報告しろ」と言ってくる、プロジェクト、発注元が今だにある。
前述のようなウォータフォールモデル、V字モデルは30年以上も前の、汎用機時代の概念である。
昔のリソースが乏しい汎用機時代ではコーディングと単体テストは別々におこなわれていたが、今やPCが安価で処理能力が飛躍的に向上した時代、開発者のPC上のIDE(統合開発環境)の中で、これらは同時に行われるのが常識である。
つまり、コンパイルエラー(文法誤り)はIDE(統合開発環境)の中でその場でわかり修正ができる。単体テストもコーディングしながら
実行するのが常識になってきている。
そうなると・・・コンパイルエラー(文法誤り)や、単体テストで期待通りじゃなくても、その工程がまだコーディング中なのか？試験工程なのか？基準が曖昧になる。
なので、今やIT業界において単体バグ、単体バグ数という概念が希薄になり、意味をなさなくなってきた。
なのに・・・
単体テストにおける「単体バグ数と内容を報告しろ」と言ってくる、プロジェクト、発注元が今だにある。
前述の説明をしても、
「いや、昔から報告してもらっているから・・・」とか
「上から報告しろっていわれているから、そういう決まりだし・・・」
とか、情けない答えしか返ってこない。おそらく、大企業の上層部、品質管理部ような実権を握っている人たちは30年くらい前はバリバリの現役だったのかもしれないが、現場を離れて管理に移ったころから、時間が止まっているのである。
世の中、開発現場はこれだけ進んで変わっているのに、30年前自分たちが現役だった頃のやり方を強要してくるのである。
そこで・・・今回の話題。「員数合わせ」の話になる。
開発現場ではそんなものは意味をなさないのは常識である。しかし、説明しても理解してもらえないし、絶対報告しろと言われる。じゃ、どうする？
でっちあげるしかないでしょ。
単体バク数にも基準があって(大抵はソースコードの行数に係数を掛けている)、その基準値の範囲内じゃないと、これまたクレームが来て面倒くさいので、基準値内にテキトーに収まるように、でっち上げるのである。(まさに、今回の話題「員数合わせ」)
報告を受けている上層部、品質管理部は裸の王様であることも知らずに、数値だけをみて満足しているのである。
今、変化の激しいこの時代。前述のウォータフォールモデルも、もはや時代に合わないと言われている。
システムやソフトウェアを利用するエンドユーザにとって、前述のようなやりとりはもはや意味を持たない。エンドユーザに各工程のバグ数を報告したところで誰も興味を持たない。
エンドユーザにとってのシステムやソフトウェアはあるビジネス上の目的を達成するための道具に過ぎないのである。
前述のバグ数が基準値に入らないからどーだ、こーだ、と言った話は開発する側のマスタベーションに過ぎない。
エンドユーザがビジネスの目標を達成するためには、そんなもの何の役にもたたない。そんなことよりも1日でもはやく、システムを提供してもらって、ビジネスを展開したいのである。そうでないとライバルに先を越され負けてしまうのである。
そういった意味で昨今はアジャイルが主流になりつつある。アジャイルにおいては上記のような「員数合わせ」よりも、エンドユーザにいち早く、「価値を提供できること」に重きをおいていることは喜ばしい。
いいなと思ったら応援しよう！
