必見！！プログラミングにこんまり先生が必要なたった２つの理由とは！？

プログラミングにこんなイメージはありませんか？

1. 理系スキル

2. 研究熱心

3. 面倒くさがり

4. 掃除嫌い

5. 徹夜でパソコンと格闘

ですが、最近では文系プログラマーも増えてきてます。そのため、今まで理系色の強かったプログラミングにも整理整頓が必要になってきてます。というのも、下のリンクのようなトラブルのキッカケが生まれるからです。

こんまり先生といえば、お掃除コンサルタントとして、皆さんも電車内広告で見かけませんでしたか？そのこんまり先生、プログラミングの世界でも必要になってきている理由がこちらなのです！

１．ブラック・スワンが起きる

1.1 ブラック・スワンとは？

ブラック・スワンは、直訳すると、黒い白鳥、という意味です。ハクチョウの種族は白い鳥しかいない、と長年思われてきましたが、1697年にオーストラリアで黒いハクチョウが見つかりました。このことから、ありえない事態が起こることをブラック・スワンというようになりました。

そのブラック・スワン、２００８年のリーマン・ショックや、２０１１年の東日本大震災、また、管直人政権下での原発事故などでも使われる言葉です。あまりいい意味ではありませんね。

1.2 プログラミングで起きたブラック・スワン

プログラミングの世界でも大きいブラック・スワンはあります。Y2K問題、Heartbleedバグ、Amazon S3のダウンタイムです。

Y2K問題（２０００年問題）は、その名のとおり、２０００年になった瞬間に世界中のコンピューターがおかしくなる、と世間が震撼した事件です。多くのPCでは、年を下二桁（１９８５年なら８５）で管理していました。そのため、世界のコンピューターがクラッシュしないよう、対応に追われることになりました。

Heartbleedバグとは、2014年に発覚した、OpenSSLライブラリの重大欠陥です。カナダ歳入庁、三菱UFJニコス、メニコンが実際に被害にあっています。オンラインで無償共有された暗号ソフトウェアに、バグがあったらしく、多大な個人情報漏洩に繋がったようです。

Amazon S3のダウンタイムとは、アマゾンのクラウドサービスに会社のパソコンなどのデータを預けている中、2017年にシステム障害のせいで長時間データが使えなくなった事件です。原因はアマゾンのエンジニアが、システムへのコマンド入力の際、タイプミスしたことだそうです。

1.3 ブラック・スワンへの対策とは？

これらのブラック・スワンは、Heartbleedはどうなのか調べてませんが、他は、初歩的なミスが原因です。ですが、人間、完全にミスしない人はいるのでしょうか？サイコパスくらいしかノーミスで集中力を保つだけの体力がある人はいないと思います。潔癖症は、キャパオーバーするとミスどころではなくなるでしょう。

人の構造を無視した命令をしてノーミスを強要するのは、パワハラに近い行為です。ノーミスが求められる職業に関しては、それなりの休憩や事前セーフネットがあるはずです。なら、ミスをする人間だけが集まってもミスをしないのと同じ効果をつければいいのではないのでしょうか？

どうすればいいかというと、後からミスを直せばいいのです。となると、プログラミングを最終チェックすればいい、という話になるのですが、そう単純ではありません。というのも、大きいシステムだと、複数のフォルダや統括フォルダにそれぞれのプログラミングコードを置くからです。

ブラック・スワン対策として、それぞれのフォルダのコードを全てチェックし、コード同士の主従関係など、依存関係を把握するのに、一人の人間が一日で終わらせることはできるのでしょうか？さらに、ライブラリという、外部のコードも綯（な）い交ぜになると、管理しきれません。

1.4 整理整頓しないとブラック・スワン対策が難しくなる

これらのコード間の絡まり、一人の人間が一日で解くことができなければ、複数人で長期間かけることになります。そうなると、一人の人間の記憶力の限界により、依存関係を忘れてしまいます。また、複数人でチェックすると、互いの連絡の齟齬（そご）により、意図しない見落としが出てきます。

直感的にパッと見てエラーを修正できるのがベストです。そのためには、コードの読みやすさもそうなのですが、まずは、階層構造を整理整頓することが必要です。これをリファクタリングと言います。ダブっている余分なコードをなるべく無くし、エラー修正する箇所をなるべく減らせる構造にするのです。

また、相関関係も整理対象です。例えば、増税したから景気が悪くなる、雨が降ればタクシー不足になる、というのは分かりやすいですが、風が吹けば桶屋が儲かる、や、油の値上げと電気代の値上げの関係が分からず、実は両方とも円安や資源買い占めのせい、というのは見えにくいですよね？

導入にあげたリンク先を見れば分かりますが、パソコンのエンジンにあたるOSを変えた瞬間に、様々なソフトウェアが使えなくなり、故障してます。しかも、復旧が未だに終わっていません。エラーコードを単純に見ただけでは、ソフトウェアに起きた問題が分からなくなってしまっているのです。

２．容量を食いやすくなる

2.1 整理整頓しないブラック・スワン対策とは

ブラック・スワン対策のためにプログラミングコードを修正するのは、作家であるプログラマーの思想を冒涜する行為だ、という人が中にはいるかも知れません。その思想の場合、それぞれのコードには人権があり、民主主義国家としては、製作者の平等権、自由権を保証すべきだ、という考えなのでしょう。

もし、各々が好き勝手なコードを書き、かつ、ブラック・スワンを起こさないようにするならどうするのでしょうか？Anacondaというソフトがあります。これは、各々がPython、Rubyなど好きな言語で好きなコードを書いても、階層構造を辿ってブラック・スワンを抑えてくれるツールです。

データサイエンスなどでプログラマーが増え、ライブラリという共有コードが出回るようになります。RubyからPythonライブラリを起動したり、PythonからRubyライブラリを起動したり、という関係が複雑に絡み合ってますが、それを自動管理してくれるのです。

ただ、これには重大な欠点があり、容量をかなり消費する、という問題があります。Aさんの部屋にBさんの私物が溜まり、Bさんの部屋にAさんの私物が溜まるイメージでしょうか。お互いに掃除したくても、他人の私物を勝手に捨てられずに困っている、という状況です。

2.2 整理整頓には劣る

互いの不要な私物を完全に清掃するためには、結局リファクタリングが必要です。そもそも、言語を超えてコードが依存しあっている状況が危険なのです。互いの共通の意味を持つコードを外すなど、無駄なコードをどんどん削減し、共有部分専用のコードを別にしないと、コードの機動力がなくなります。

日本でプログラミングの整理整頓が進まない理由

では、こんなに整理整頓が重要なら、今すぐやればいいじゃないか、という声が聞こえてきそうです。でも、現実には進みません。その理由を、初心者として考えてみました。

• その１：納期が間に合わない

プログラマーに対して、発注する側は極力お金をかけたがりません。安くて高品質を求めているからです。そうすれば、少しでも儲けが出ますからね。残業が当たり前、という環境です。きれいなコードを書く価値を企業側が見いだせていないのでしょう。

企業側が価値を見出すのは、利益と社内政治、慣習です。民主主義がもたらす社内政治により、多数決を通じて互いがウィンウィンとなる妥協点を探った結果、実際の社内効率よりも、見てくれの良さを重んじる風習が出来てしまいます。また、役員や株主たちに還元される利益が、六本木の飲み屋に消えます。

末端のプログラマーが寝る間も惜しんで自殺や過労死間近な状況の中、上級国民は、新しい漫画が生まれるなどの文化的価値にお金を使いません。六本木や歌舞伎町などの飲み屋に経済がどんどん回され、次の成長投資などにお金が流れなくなるのが、今の日本の悲しい現実でしょう。

• その２：人材が足りない

では、プログラマー側に問題がないかといえば、そういうこともありません。リファクタリングに強いプログラマーが圧倒的に不足していることも問題です。技術力を極めるオタクの能力である理系スキルに加え、全体像を把握して的確に差配するリーダースキルも重要となります。

この両方を兼ね備えたプログラマーが、果たして日本にどれくらいいるのでしょうか？ベテラン含め、そこまでいないのではないか、と思ってます。理系には、「研究熱心、面倒くさがり、掃除嫌い、汚い研究室に籠（こも）る」というイメージがありますが、これは、本来プログラマーにも必須なスキルだと思います。

探究心に自分の能力を全部振り切った結果、掃除や対人スキルなど他のスキルにエネルギーを割く余裕がなくなるのも当然でしょう。人間の血液の量は一定量しかないですし、他のことをやらせれば、途端に本来のスキルが弱くなるか、佳人薄命のように、過労死するリスクは上がることでしょう。

こういう人たちのために、リーダースキルを持つ人たちが、掃除や対人スキルなど、弱点をカバーしていったほうが、組織としては強くなるのかも知れません。「研究熱心、面倒くさがり、掃除嫌い、汚い研究室に籠（こも）る」を差別だと捉えて、弱点のカバーを怠るのは本末転倒でしょう。

• その３：ベテラン特有のおごり

プログラマーが掃除や対人スキルが弱いのは別に問題視するわけではありません。ですが、対人スキルがなくても、最低限他者への態度を粗悪にしないことは重要です。特に、ベテランが、自分の長年の経験やクセに驕（おご）り、他の人の工程への迷惑を考えないのは問題です。

プログラマーに限らず、こういう我流の職人タイプ、いませんか？一作業員としては優秀かも知れないけど、他の作業員との連携作業のときに自分の工程で足を引っ張る人。新人ならば注意して軌道修正するのは比較的簡単ですが、経験を積みすぎて後輩上司の命令に逆ギレして迷惑をかけますよね。

作業の現場監督は、作業工程を体で一通り把握しないといけないので、どうしても職人の中からの出世になりがちです。しかし、リーダースキルを経験するわけでもなく、工程全体の調整ができるわけでもありません。現場監督も割と希少人種になりやすいでしょう。

これがプログラミングに蔓延（はびこ）ったせいで、私は、PHPというプログラミング言語自体のバグに悩まされ、MySQLの再開通が未だに出来ていません。最後にツケを払うのは、エンドユーザーなのです。WindowsからUbuntuに変えなければいい、というツッコミは、ベテランの驕（おご）りだと思います。

まとめ

２１世紀にもなり、宇宙進出を人類は本格的に考えなければならなくなりました。そのような中、人類が宇宙への冒険をする前に、地球上のあらゆる既知の問題を整理整頓をする必要があります。プログラミングの整理整頓はその第一歩であり、AIの発展、学問整理、AIに頼らない人類の高知能化が求められます。

シャア＝アズナブルがスパロボシリーズで抱いた宇宙進出への思想を、人類はクリアしなければなりません。それが次元上昇であり、プログラミングの思想も強化していかなければならないのです。いつまでも酒池肉林に溺れる子孫のループを繰り返しては、シャア＝アズナブルに人類は腐敗している、と見倣（みな）されかねません。