東京オリンピックの延期に学ぶべきリスク管理
東京オリンピックが延期になりましたね。
多くの方の利権が絡む問題で、イベントで行っても世界最大と言えるプロジェクトです。
プロジェクトマネージメントの観点から言えば、リスク管理はしておくべきこと。
今更、バタバタ焦りまくっているのも滑稽に感じます。
さて、本件に関してはコロナパニックで、世界同時に動けなくなったわけですから延期自体はどうしようもなかったと言えます。
しかし、これから東京で全てのイベント会場を予約しながら開催に向けるのは、あまり現実的ではないでしょう。
かといってロンドンなどの他の都市開催も、正直準備で無理な話。
もし、私だったら、今回は、日本中のイベント会場を貸し切ったジャパンオリンピックに切り替えます。
マラソンが札幌になりましたが、これをもっと行えばいいだけの話。
いろいろ融通も効きやすくなるでしょう。
そもそも、今後のオリンピックは、開催をグローバルにしても良いのではないでしょうか。
それぞれの国によって人気な競技は異なるわけですから、開催が得意な競技は別の国で開催しても良いのではないでしょうか。
例えば、日本でテコンドーやるより、韓国でやった方が客の入りはいいでしょう。
お金が絡む話だから、簡単ではないでしょうが、いつもいつも一つの都市でやろうとするから無理が出るのだと思います。
複数の都市で開催すれば、調整も効きやすくなりますし、何か問題があっても一部の競技を取りやめるだけで規模を小さくして開催するなどの手段も取れるようになるかもしれません。
.NET Frameworkとは？
.NET Frameowrkとは、何なのか？
これを一言で説明するのは、難しいですが、あえて一言で言うのであればMicrosoftがサポートする様々な言語を実行するためのアプリケーション実行環境です。
.NET Frameworkは、大きく以下の２つからなります。
1, CLR (Common Language Runtime)
メモリ管理、アセンブリのロード（後述）、例外処理、スレッドの同期など
2, FCL (Framework Class Library)
基本クラスライブラリ。
多くの人は、FCLで実装を行い、 CLR上で実行すると言う流れになります。
Windows上で実行する場合には、Visual Studioをインストールして開発すると、それほど意識することなく実行することになります。
と言ったところで、何を言っているのか分からないでしょうから、詳細に見ていきます。
CLRとは、日本語訳だと共通言語実行環境です。
例えば、ここにC++が得意なエンジニアとC#が得意なエンジニアがいたとします。
この二人が協力してプログラムを書こうとした時に、どちらかの言語に合わせて開発をしようとすると、一方のエンジニアの生産性が落ちることになります。
これを解決するのがCLRです。
CLRは、C++やC#などの様々な言語で開発したとしても、それらを全て共通の中間言語であるIL（Intermediate Language）とメタデータにコンパイルします。
メタデータは、クラスの型やInterfaceが記述してあるデータ群です。
そしてアプリケーション実行時に、このILとメタデータをネイティブ言語にコンパイルしながら、実行することで、どの言語でも実行できる環境を提供します。
この時に利用するコンパイラをJITコンパイラ (Just in compiler）と呼びます。
FCLとは、.NET Framework上で動かすプログラムの基本クラスライブラリ群です。
CLRで実行するにあたって、共通に利用するようなクラスが多数用意されています。
例えば、HTTPのクライアントのためのHttpClientクラスなどは、多くのユーザーが利用するようなクラスです。
このような基本的なクラスを提供するのがFCLになります。
よって、多くの人は、FCLで実装 → CLRで実行と言う流れになるわけです。
プログラムが書けないエンジニアが成立するのは、上司がそれを良しとするからだ。
IT系の大企業に入ると、なぜかプログラムの書けないエンジニアが大量に存在する。
先輩エンジニアが書けないものだから、新人エンジニアも書く技術を学べずに書ける人がどんどん減って行く。
時に書ける人がいるが、大体は独学で学んでいる貴重な存在だ。
結果、少数のプログラムが書ける人に技術的な仕事が全部丸投げされ、プロマネが大量に存在する状況が発生する。
実際問題、業務の大半が社内調整になっており、開発は委託に丸投げなわけだから、これで業務が回らないか？と言うとそう言うわけでも無い。
しかし、効率が悪いのは火を見るより明らかだ。
設計の良し悪しも分からなければ、要件定義しているくせに実現手段が分かっていないから、コストもよく分からない。
結果、問題が発生しても「なんとかしろ」と子会社に電話をかけて終わりだ。
QCDを改善しようにも、どこの品質が悪いのか。どう改善するのかなんて分からないから、CとDしか見なくなる。
気がつけばQは、取り返しがつかないことになっている。
これが起きる根本的な原因は、大企業特有の社内調整と委託丸投げ体質だが、それだけでは無い。
プログラムが書けないエンジニアの存在を良しとしている会社側にも大いに問題がある。
シリコンバレーの大企業に行っても、確かにマネージメント業務に忙殺されている人たちはいるが、彼らは元エンジニア。バリバリにプログラムが書けるのだ。
日本の企業は、基本的に簡単に解雇にしないから、プログラムが書けないエンジニアでも割り切って使って行くしか無い。
ならばプログラムが書けないエンジニアに対しては、叱責するべきなのである。
「なぜ書けないのか？」「プログラムを書けるようになれ！」
会社側が教育するかどうかなんて関係ない。
ITの世界は自分で勉強だ。
ノルマとして書かざる終えない状況を作り上げ、できない人は評価を下げ、できる人は評価するシステムを作らないと、日本と世界のIT技術の差は開くばかりである。
優秀な人に仕事が集まる。人は、それをワンマンチームと呼ぶ。
「優秀な人に仕事が集まる」と言うのは世の中で良く聞く話です。
実際問題、パレートの法則もあるから実際に仕事を８割の仕事をこなしているのは、上の２割である。と言われています。
はっきり言いますが、これは間違いです。
役割分担の明確化ができていないから、このような状況が発生しているに過ぎません。
日本の管理職の無能さを盾に、これを正当化されては堪らない。
簡単な例は、スポーツです。
例えば、バスケットボールの場合、果たして上の２割しか仕事をしていないか？
あり得ません。
そう言うチームは、ワンマンチームと呼ばれ、結局のところ強豪チームにはなれません。
確かにエースは存在しますし、バスケなどでは得点が一部に偏る場合がありますが、ディフェンスにおいては全員が仕事をしないと成立しません。
アシスト、リバウンド、スティール、ブロック、スクリーン、コート上でのリーダーシップなど様々なことを行う必要があり、それぞれ役割があります。
そしてそれぞれを専門の選手が行います。
複数のポジションをこなせる選手もいますが、基本は専門ポジションです。
結果として、強豪チームが形成されます。
確かに、優秀な選手が一人で複数ポジションこなせる場合もありますが、それを基本的にさせません。
複数こなせる ＝ 一人で全てを完璧にこなせる では無いからです。
一つ一つの質を下げて全体を成立させているに過ぎません。
代わりに下手でも専門の選手を決めて、割り切ってそのポジションを代替させます。
そうしないと、属人化が排除されず、いつまでもワンマンチームが解消されないからです。結果、ポイントガード、シューティングガード、スモールフォーワード、パワーフォワード、センターと役割が分かれます。
仕事でも同じです。
開発、マネージメント、リーダーシップ、プレゼン、対外交渉などなんでもできる方がいます。
しかし、どれか一つにポジションを集中させて、他のポジションには下手でも別の人を割り当てます。
誰をエースに吸えるか？を考えるのであれば、それを含めてチーム構成を編成するべきです。
そして、それぞれで専門選手が配置された強豪チームが形成されます。
さらにチームとして、それぞれ強みができてから、他のポジションを覚えさせて複数ポジションを皆ができるようにします。
結果、オールラウンダープレイヤーが量産されます。
これをしないで、場当たり的にできる人に仕事をぶん投げているのは、管理職の部下育成の怠惰の言い訳にすぎない...
生産性を上げたいならば、部下に権利を委譲しろ！
大手企業の場合、大企業病が問題になります。
じゃあ大企業とは具体的に何なのか。
中に入ってみると分かりますが、大企業は、恐ろしいほどの社内手続きと社内調整というくだらない仕事に忙殺されて
結果、行動に移すまでに膨大な時間がかかります。
例えば、今年の計画の資料を半年以上かけて作る場合もあります。
今年の計画が出来上がった頃には、今年が終わりかける始末（馬鹿すぎる...）。
じゃあ、なんでこんなことが発生するのか？
要は権限が分散しすぎていたり、中間管理職に実質的に権限が無いため、結局各部署や一番上の管理職まで行かないと（場合によっては取締役とか）許可が下りないためです。
そのために、各部署や上司に説明するための社内資料の作成、膨大な数の手続きと複数の上司の印鑑を求められます。
社内資料は、課長、部長、本部長、...とどこまでもエンドレスのフィードバックを受けて資料を更新し続ける始末。
社内手続きと印鑑は、複雑化しすぎていいて、ちょっと不慣れな仕事だと社内手続きの手順を調べるために数日過ぎることもざらです。
しかも、担当部署がどこかも曖昧で盥回しされることも良くあります。
一例を挙げれば、USBメモリの購買申請をする際に、amazonでボタン一つで買えるものが、社内の購買手続きと複数の上司の印鑑をもらうために１ヶ月かかり、実際に買うものの値段の十倍以上の人件費がかかけて買うことすらある。
９０００円のUSBメモリ１つに人件費見るもの馬鹿らしくなる時間を経過します。
（大手は人の単価も高いから合計すると１００万以上かかっている気がする...）
社員のやる気を根本から失わせる害悪としか言えない、酷い状況と言えます。
言わずもがな、もっと一人一人に権限を以上してしまえば、社内手続きも簡略化され、無駄が無くなります。
amazonでボタン一つで買えるのに、部長の上まで印鑑もらった挙句、購買部門に印鑑もらう手続きを、社員がボタン一つで買えれば素晴らしい生産性向上です。
日本では、「生産性向上」と言った途端、残業だけなくして、実際の業務量は同じ。
本社社員が働かなくなり、子会社にしわ寄せして終わりです。
政府の意向に迎合するのも結構ですが、内部プロセスをもっと見直せと思ってしまいます。
ホウレンソウしない部下がいるのは、上司に問題があるからだ。
ビジネスの基本は「ホウ・レン・ソウ」とよく言われます。
これができない部下がいた場合に、「あの部下はなってない」と怒る人がいらっしゃいますが、その原因は、基本的に上司にあります。
例えば、子供は困ったことがあったら、まず親に相談しますよね。
嬉しいことや悲しいことがあっても報告します。
自分で判断できないことがあったら連絡します。
これは、親子間で信頼関係が成立しているから、自然と行っているものです。
反対に虐待する親であったり、何も解決してくれない親の場合、子供は助けを求めなくなります。
テストの点が悪い時に怒鳴り散らして具体的な解決策も出してくれない親では、ストレスの種が増えるだけですからテスト用紙をゴミ箱に丸めて捨てて、なかったことにするだけです。
仕事でも同じことが言えます。
「ホウ・レン・ソウ」をすることによって、状態が改善すると考えれば、上司にいちいち指摘されなくても行います。
コミュニケーションを取りたいと思える相手ならば自ら望んで行うものです。
逆に言えば、部下が「ホウ・レン・ソウ」してこないのは、上司がコミュニケーションをしたくないような相手だからです。
人間の自然な考えとして嫌いな相手は、「ホウ・レン・ソウ」を可能な限りしなくて済む方法を考え始めます。
そして、行くつく先は、自動車業界で発生したような燃費不正問題です。
そこを履き違えている方は、たとえ部下を叱って、部下が「ホウ・レン・ソウ」して来るようになったとしても、その「ホウ・レン・ソウ」は、都合の良い情報だけに書き換えられた偽りの情報であることを理解しておくべきだと思います。
