ルールを決める権利を放棄する日本人

子供の頃、民主主義とは多数決で物事を決めることだと思っていた。ホームルームの時間に何か決めごとがあると、まず、議長がみんなから意見を聞き意見がが出尽くしたところで多数決を取る。

昔を振り返ると、学校のホームルームでは議論が発熱することはあまりなく、意見を言う生徒も大抵は決まっていた。いつも自分の意見を言わない者もいた。たまに自分が議長になったときなど、なかなか意見がでない状況で誰かを指名して無理矢理意見を言わせるのがイヤでしようがなかった。

「なぜ、最初から多数決を取らないのだろう」と思ったものだ。

ところが最近になって、そうは思わなくなった。何で物事を決める際に議論をしつくさなければいけないのか何となく分かってきたような気がする。

例えば、組込みソフト開発において、プロジェクト内でコーディングルール・コーティングスタイルを決めるというシチュエーションを例に取って考えてみよう。

自分の経験ではプロジェクトに「コーディングルールを決めてください」とお願いすると、サッとできてくるチームとコーディングルール・コーディングスタイルを提示してあげなければいつまでたっても出来てこないチームの二通りがある。

ちなみにサッとできているチームも、必ずしもプロジェクト内で十分にディスカッションしているとは限らない。率先してコーディングルール・コーディングスタイルはこうあるべきと主張する一人のエンジニアの考えを丸呑みしてしまっていることも多い。

これは、ホームルームの時間に議長が意見を求めても、一部の人しか発言しない状況とよく似ている。発言してその案が採用されたときに言い出しっぺとして「自分自身に責任が降りかかってくるのではないか」という恐怖心があるのではないだろうか。

民主主義で物事を決めるということは、参加者が自分の意見を発言するという権利を行使してディスカッションの場に提示し、自分の意見の正当性を主張し、意見が一つにまとまらなかったら多数決で決定するということだと思う。

なぜ、少数意見も含めて議論をし尽くしてから多数決を取らなければいけないかと言えば、議長は会議の参加者が自分の意見を発言するという権利を出来る限り平等に行使できるように気を配らなければいけないからだ。

ようするに少数意見であっても発言させないのはアンフェア－だから、議論をし尽くさないで多数決を取ってはいけないのだ。

でも日本人は「さあ、発言してください」と会議で口火を切ると大抵の場合黙っている。黙っているということは発言できる権利を放棄しているということになる。

発言の権利を放棄してしまったということは、無条件に決めごとに従うと宣言したようなものだ。日本人はこの権利を放棄しているという感覚が分かっていない。

例えば、自分たちでコーディングルールやコーディングスタイルを決められないチームに、ベースとなるコーディングルールやコーディングスタイルを提示すると、いったんはそれに従おうとするが、しばらくしてルールに逸脱する者が現れても、それを注意したり、自分たちで是正しようとしない。ルールからの逸脱を外部の誰かから指摘されない限り、是正しようとしない。

これは日本人の気質だと言ってしまえばひと言で終わってしまうが、民主主義を自分たちで勝ち取った権利であると考える人たちからみればルールを自分たちで決める権利を放棄したのに、指定されたルールに従わない実にアンフェア－な人々に見えるに違いない。

自分たちでルールを決めることに消極的な組織はルールに振り回される傾向がある。ルールを決める際に議論に参加していないため、「そのルールがなぜ決まったのか」、「どうしてそうしなければいけないのか」についての思慮が足りない。だから、ルールを守る方も守らせる方も重箱の隅をつつき合ってはちょっとした逸脱について過敏に反応したりする。

ISO9001の外部監査、内部監査などで是正を食らわないことだけを争点に水掛け論をしている光景を目にすると、品質マネジメントシステムがキチンと機能しているかどうかを確認していることを忘れているのではないかと感じる。

原理原則を理解せずにルールに振り回されている日本の技術者は大勢いいる。このような技術者は他人にバグを見つけてもらっても「ありがとう」とは言わないし思わない。

『アメリカ人と日本人』の記事で書いたように、日本人は「あたたかい人間関係の中のやさしい一員」としてものづくりに有利な面を持っていると思う。しかし、「創造性と個性にあふれた強い個人」の人たちとも一緒に仕事をしなければいけないし、「創造性と個性にあふれた強い個人」が作ったルールに従わなければいけない場面も多々ある。

【よくある日本のプロジェクト】
・ルールを自分で決められない（ルールを決める権利を放棄してしまう）
・ルールからの逸脱を是正することができない（自制できない）

なぜ、これがいけないのかといえば、ルールを自分で決められず、ルールからの逸脱を是正することができないプロジェクトや組織は品質の高いソフトウェアをアウトプットできない可能性が高いからだ。30万行を超えるような規模のソフトウェア開発では特にそう思う。

ルールがあっても形骸化する組織やプロジェクトはルールの作成時の議論に積極的参加していない（権利を行使していない）か、ルールの本質を理解していないからだ。

そう考えるとすでに存在するルールをプロジェクトに適用する際には、最初にその本質も含めてプロジェクトに対して最初にキチンと説明してから適用しないとフェアーではないということになる。開発の途中からルールへの遵守を求められたら、それはフェアーではないと主張しなければいけない。

組織はプロジェクトに対してルールを理解させるトレーニングを提供する義務がある。そして、いったんルールの意味を理解したのならば、対象者に資格を与えルールからの逸脱を監視して、場合によっては資格を剥奪しなければならない。

こういうまどろっこしいことを一切省略して、プログラマーの能力を最大限に引き出し、ソフトウェアシステムの完成度を高めるという開発手法もある。優秀なエンジニアの集団にルールを押しつけるよりも、このような方法でプロジェクトのパフォーマンスを上げる方を優先させた方が結果的に品質が上がる場合もある。

しかし、このような技術者個人に依存するやり方では組織は常に一定の水準のソフトウェア品質を担保できるとはいえないし、その組織が品質の高いソフトウェアをアウトプットできることを内外に示すことができない。ルールやプロセスやプロセス内で実施する活動を規定せずにソフトウェア品質を高めるしくみがないとダメだ。でも、人間がキーボードをたたきながらソフトウェアを作っている限り、そんな都合のいい方法はないだろう。

日本人もルールに正面から向き合うくせをつけて、ルールを自分たちで決める権利についてよく考え、頭の中で権利と義務と責任について常日頃整理しておかないと、グローバルマーケットでものづくりはできないと思う。