【新人教育】ＩＴってなに？ -1-
というわけで、4/1～4/2にかけて新人教育をしてきました。というか、私の担当分がこの２日間というだけで、まだまだ続くんですけども、とにもかくにも私の担当分は終わりました。疲れた。
疲れたと言うのは、私の行う教育は"一切座らないで、ずっと歩き続ける"からです。「座ればいいじゃん」と言ってしまえばそれまでなんですけど、それは私個人の教育理念（？）に反します。
まぁ、そんな大げさなものでは無いんですけど、私は一人ひとりの顔色や仕草から、色んな情報を読み取ります。「寒そう」「暑そう」「眠そう」「退屈そう」「わからなさそう」etc.…そういう情報を読み取り、都度調整をしているのです。
そして、そのためにはどうしても全員の顔を見て回る必要があります。
なので、教卓…というかずっと前にいるだけでなく、常に部屋中を歩き回って全員の顔色を窺いますし、座って奥が見えないようなポジション取りはしません。
で。
結局、８時間歩きっぱなし。
リアルお遍路さんモード。
おかげで、今日は筋肉痛＋腰痛です。
さて。
今回はその新人くんたちにむけて、この業界「ＩＴ業界」の根本的なありかたについてお話してきました。たぶん、この業界人のだれもがそんなこと考えてないと思うけど、私なりの解釈を加え、なんだったら経営者にだって説教できるくらいの内容を、わかりやすーく解説しています。
ＩＴって何の略？
と聞かれて答えられない人は少ないと思います。まぁ新人くんのなかには「インターネット…なんとか」とか言ってる子もいましたけど、まぁ今のご時世、当たり前になりすぎてわざわざ正式名称なんて知ろうとしないのかもしれませんね。
いえ、別にいいんです。今までは。
これから知ってくれれば、全然かまいません。
ＩＴとは、Information Technology（情報技術）の略ですね。もっと具体的にいうと、「情報を取り扱う技術」です。当然、プログラミング技術のことではありません。システム開発の技術でもありません。「情報」を取り扱いさえすれば、全てのことに長けていなければならない技術です（かなり拡大解釈を加えていますけれど、それくらいの覚悟が無ければ、システム開発における情報すらまともに取り扱えないことでしょう）。
そもそも、ビジネスは情報戦です。
正しい情報をつかんだものが勝利に近くなり、誤った情報を握らされたものが損を引く、そういう世界です。「情報の取り扱い」に長けると言うことは、ビジネスを制すると言うことでもあります。
そういった軍師のような存在を各企業からアウトソージングしたものが、今のＩＴ業界を形作っているのです。
みんな、何の技術を求めているの？
しかし、学生が就活をするうえでこの業界をターゲットに加えた時、多くの子たちは「プログラミング」と言う技術を身につけ、ソフトウェアあるいはサービスを作り、世に送り出すイメージを募らせていたのではないでしょうか。そして、それだけしか見ていなかったのではないでしょうか。
まぁ、それすらも責められません。
私も、学生時代はそのくらいしか考えていませんでした。
裏を返せば、会社説明会をはじめ、採用担当をされている方々は、そういったことを前面に出して、本質的な部分を学生には教えようとしてこなかったわけです。言い方は悪くなりますが、情報操作／情報隠蔽を行ってきたことになります。
もちろん、そこに悪意が無いのは理解しています。それに、プログラミングは確かにするでしょうし、嘘をついているわけではありません。ですが、それが全てであるように錯覚させてしまっているのは紛れもない事実だと思います。
ですが、私はこの誤解を与え続けていることに、とても不満を覚えています。たしかにプログラミングはするでしょう。新しいソフトウェアを作り、世に送り出し、多くの人に使ってもらう。便利だと言ってもらう。夢は広がります。
ですが、そんな日の当たる面しかありませんでしたか？
実際には、ブラックすれすれな仕事のさせ方を強要し、裏で「残業しませんとかって最近の若いやつは…」なんていう上司がいたりしませんか？
少なくとも、私はそんな現場を毎年毎年、数多く見てきましたよ。今でもそういうった現場は多いです。働き方改革に伴い、コンプライアンスを超えさせない企業は格段に増えましたが、それでも法定ギリギリまで働かせている現場はあります。そもそも「年６回までは残業80hまで働かせていい」なんて考え方している上司が、未だにあちらこちらに蔓延っています。
そんな上司もアレですし、収益さえ出れば、そんな上司を野放しにするような経営者もアレですが、でも実際にはそういう社会なんです。権力的弱者をこき使って甘い汁を吸い、企業財政を賄おうとする…そんな企業が多い業界なんです。
もちろん、学生たちに現実を話せと言っているわけではありません。
夢を語り、期待に胸を膨らませてほしいと私も思っています。であるならば、いつまで「業務の進め方」を改善しようともせず、残業なしでは成立しないようなカビたプロセスに固執しているのでしょう。そんなやり方しか考えられない上司なんて滅んでしまえばいいとさえ思っています。
…おっと、脱線してしまいました。
実際問題として、「プログラミングを行える割合」と言うのは、１つのプロジェクトの期間のうち、およそ15～60%といったところです。幅があるのは、開発手法（開発モデルとも）によって大きく異なるためです。
いわゆるエンタープライズ向けのウォーターフォール開発モデルを用いれば、設計４割、テスト５割、実装１割なんて言われています。設計を疎かにして、早々にプログラミングに着手し、炎上するようなプロジェクト、炎上しないまでも担当者に負担を強いているプロジェクトでは、実装が３割を超えているのではないでしょうか。
アジャイルともなれば、あまりドキュメンテーションに重きを置かなくなるし、テストも自動化するところが多いので、プログラミングに割く割合がぐっと増えて５割をオーバーするところもあるみたいですが、それでも残りは設計とテストに割り当てられます。
つまり、プログラミング『だけ』ができても、他ができなければビジネスが成立しないと言うことです。プログラムさえ作っていれば、なんとなーくアプリケーションが売れるとか、ふんわーりSIerが大金払ってくれるとか、そんなことは絶対にありません。
プログラミング技術は、ただの「実現手段の１つ」です。
それ以上でも、それ以下でもありません。
もっと言えば、プログラミング技術はまったくもってクリエイティブなものではありません。クリエイティブなのは設計フェーズまでです。設計書を作成する／しないに関わらず、設計を構築するフェーズまでが何かを生み出しているのであって、プログラミングは設計内容を理解し、翻訳する"作業"でしかないのです。
その証拠に、プログラミングだけしか行えない人を、仮に「プログラマー」と呼ぶと定義した場合、その平均収入は、他のＩＴ業界エンジニアと比べた時に、決して高くないことがわかります。
ちなみに、参考にしたのが転職エージェントのサイトのものだったので、SE（システムエンジニア）とプログラマーがいっしょくたにまとめられていますが、これはＩＴ業界にある昔からの悪しき風習がそうさせているのでしょう。
この業界の中堅企業以下は、新人であっても、プログラミングしかできなくても、「SE」を名乗らせます。エンジニアリングの欠片も知らなくても、SEなのです。
なぜなら、「PG（プログラマー）」と「SE（システムエンジニア）」との間には、単価（月あたりの価格）に差が出るところが多いからです。
これは厚生労働省が平成28年に発表した賃金構造基本統計調査を参考に算出されたものです。このように、厳密には（設計ができなくても、エンジニアリングを理解していなくても）SEと名乗った方が、お客さまに請求できる額も底上げできるので、多くのＩＴ企業がいわゆる"不正"を行います。とはいえ、採用する方もわかってて「許容額の範囲内だから」「やることさえやってくれれば」と黙認しているので、ただの慣習だと思っていいでしょう。
そういう意味では、もう今となっては、「悪いこと」ですらないのかもしれません。まぁ私は事実でない時点で嫌いですけど。
なので、大手SIerで調達部門が厳しいところを相手にするでもない限りは、エンジニアもプログラマーも似たり寄ったりな扱いを受けます。差別化されるのはリーダーシップがはれるエンジニア、あるいはマネージャーくらいではないでしょうか。その他、専門性がある人は、その内容によって価格帯がかわります。
そして、その専門性の価値、お客さまが支払う価格によって、自らの収入も変化してくるのです。
収入の高さは、難易度の高さでもありますが、同時に「需要に対する供給の多さ」も影響します。
また、あくまで平均収入なので、本当にスペシャリストになれば、プログラマーでも1000万超えている人はいるのでしょう。しかし、それを新人に期待するのは少々酷というものです。
多くの学生がこの業界の門戸と叩くとき、やはりプログラミングを中心に据えて入ってくることでしょう。ほとんどの人がそうだと思います。そうすると、プログラマー人口がものすごく多くなるわけです。
これはヒエラルキーにおける最底辺…裾野くらいの割合になります。
どこの企業でも、多くの場合「リーダー不足、マネージャー不足」が謳われています。年功序列だけで、役割を上げていく体質の企業が多く、ほとんどの場合、しっかりとした教育を行わないからです。
結果、名ばかりのリーダー、名ばかりのマネージャーがエンジニアから選出され、素人に毛が生えた程度のマネジメントで、現場を荒らし、
「プロジェクトとして失敗する」
「プロジェクトとして成功（？）しても、全員が疲弊し、精神を削る」
という形で終わっていくのです。このプロジェクトの成功（利益が出たから成功と呼んでいるだけで、こんなもの成功でもなんでもない）のおかげで、日本のＩＴ企業の多くは何とか生き残っています。その裏で、毎年何百、何千、何万人ものエンジニアやプログラマーが身体を壊し、精神を病み、退職や転職をしていっていると言う事実は、誰も語ろうとしません。
しかも、それでいいと思っているから、リーダーやマネージャーの不足に対する施策として「外から連れてくる」…すなわち中途採用に力を入れるわけです。
ですが殆どの場合、よほど実力主義的な報酬制度にでもなっていない限り、"そこそこ"の人しか入社しません。間違って"優秀な"人が入社しても、数年で退職してしまいます。育成をしなさすぎるがゆえに、そんな人たちが上に山ほどいて足枷になってしまうがために、その人の優秀さに周囲がついていけず、優秀な人だけがストレスを抱え続けてしまうからです。
結果、十把一絡げの横並び的な人材だらけになって、さらに企業の成長が滞り、そうこうしているうちに不況が来ると、潰れていってしまうわけです。
Ｂ２ＢのＩＴ業界はサービス業と知れ
パッケージ製品やサブスクリプションを利用したサービス展開をしているソフトウェア開発についてはいったん置いておくとしますが、Ｂ２Ｂの受注生産を行っているＩＴ企業は、それが組込みであれ、アプリケーションであれ、WEBサービスであれ、皆一様にサービス業と思った方がいいでしょう。
少なくとも、第三次産業です。製造業（第二次産業）ではありません。
言い換えれば、ネズミの国の中の人…はいないんだっけ、ネズミの国の人と同じと言うことです。すなわち
『お客さまが満足を得られなければ、企業は経営を維持できない』
と言うことです。すべてが満足度で評価され、運用される業界。それがサービス業です。アミューズメント施設にせよ、飲食店にせよ、なんならオンラインサロンにせよ、提供するものは違えど、そのどれもが「顧客満足」の有無によってリピート率が変化し、そのリピート率の大小で企業の寿命が決定します。
凄い技術があっても、満足できない製品は買いません。
奇麗なコードを書いても、満足できない製品は買いません。
みなさんもそうですよね。たとえば、ある車を買うとします。
「最高の素材で、最新技術を駆使したモデルなので、
時速は10km/hしか出ないけど、1億で買ってください。さぁ金払え」
と言われて、みなさんは買いますか？
欲しいブランドバッグがあったとして、
「世界のセレブが大金をはたいてでも欲しがる、世界最高の素材で
予約が５年待ちになるような有名デザイナーがてがけた、
世界に１０個しかないバッグです。
ただし、耐久性は基準以下です。１度使えば壊れるかもしれません。
デザイン重視で、機能的には最悪です。でも、1億よこせ」
と言われて、皆さんは買いますか？
私なら、１億持っていたとしても、嫌ですね。
目的を果たせない、必要な機能が足りていない、すなわち満足できない製品を買えと言われて、買いたいと思うでしょうか。プログラミング技術しか追い求めないプログラマーと言うのは、そういうことです。それは、「機能仕様の実現」には貢献できるでしょうけど、１㍉もビジネスはできないと言うことです。
もちろん、適材適所という概念に基づき、プログラマーを最大限活用できるリーダーやマネージャーがいれば、きれいに棲み分けもできたのでしょう。けれども、そこで先ほどの問題が立ちはだかるのです。そう
「年功序列」と「育成のできない企業体質」
です。ひょっとすると、
「不勉強を悪びれない上司、経営層」
なんてのも背景としてはあるのかもしれません。自分より優秀な人間が出てきたら、今の自分の地位を脅かされるかもしれないと思って、あえて育成等をしないのかもしれません。
しかも、ここ10年くらいでは、「育成できないなら、外部から優秀な人材を引き抜いてくればいいじゃなーい」という発想に染まり、ヘッドハンターにとっては需要があって嬉しいでしょうが、ますます社内で育成する土壌は失われて行きました。
当然、そんな企業風土では、優秀であればあるほど、その人材は企業を見限って転職していきます。残るのは優秀ではない、鳴かず飛ばずの二流三流社員ばかりに選別されていくことでしょう。
現在、企業の平均寿命がおよそ２４年と言われていますが、ひょっとするとそうした淘汰が行われて不良在庫となった人材だけになってしまい、経営が成り立たないところまで破綻するまでに、およそ２４年ほどを要する…ということなのかもしれません。
話しは戻って。
Ｂ２ＢのＩＴ企業にわざわざ仕事の話…つまりはソフトウェアの開発を依頼しに来る企業…お客さまと言うのは、何を『目的』としているのでしょう。
今言ったように「ソフトウェアを開発してもらうために」来ているのでしょうか？
いいえ、違います。
ＩＴ企業に依頼にくるお客さまは、現在の事業や業務で困ったことが起きており、その困った事情を自社内で解決できないのです。その解決をＩＴ企業に依頼しているのです。たまたま、その実現方法の心当たりに、「ソフトウェア」を使うことで解決できるのではないかと思って、依頼に来ているにすぎません。
では、なぜソフトウェアだと解決できると思ったのでしょう。おそらくは、ソフトウェアやソフトウェア工学の素人であるお客さまが、それでもＩＴ企業に依頼しようと思ったのは、なぜなのでしょう。
それは、大別して２つです。
①人の手で行うと効率的ではないから、改善したい
言い換えると、効率的に変化させることでコスト低減等を図りたい
②人の手で行うと、ミスや漏れが出るから、改善したい
機械的に実施してもらえれば、ミスや漏れが確実になくなる*1
*1…バグ等が存在しない、正しいアプリケーションの場合に限る
つまり、「情報のやり取りを迅速に行いたい」「情報の取り扱いでミスをなくしたい」と言うことです。その実現のためにＩＴ企業は存在を許されていると言っても過言ではありません。逆に、それができないＩＴ企業、エンジニアは存在していません。
日本人は情報を知らなさすぎる
日本語には「情報」という言葉に類する単語が他にありません。「知識」は人が知る、あるいは識るものであって、ただそこに存在する「情報」とは全く異なります。
ですが、日本語でいう「情報」を訳すと、英語では色々出てくるのです。
ところで、ちょっと話は変わって（よく脱線しますが）、「空・雨・傘」フレームワークってご存じですか？
マッキンゼーの日本支社が作り上げた問題解決フレームワークで、コンサル業界にいると必ず耳にする、と言われている言葉です。
この考え方と先ほどの「情報」の英単語３種が、私は思考の在り方としてとても類似しているな、と思っているのです。えぇ、間違ってたらゴメンナサイ。
日々生成される事実をそのまま蓄積する素材としての「事実情報」(Data)。
以前も書いたと思いますが、データベースの「データ」はここからきてますし、ビッグデータの「データ」もここからきています。このことからもわかるように、「データ」は素材であり、未加工でなくてはなりません。データベースの設計をする際に、データベースへINSERTする機能の中で、既に加工して登録しようとする設計があれば、おそらくそれはデータベースのことを理解していないなんちゃってＤＢＡ（Database Administrator）かもしれません。
その、素材であるDataをなんらかの基準に基づき構造や体系を与え、抽出し、整理する「情報」(Information)。
ＩＴ企業が、その昔 Information Technology と言われたのは、データを蓄積し、そのデータを整理、集計、編集、加工することがソフトウェアの目的であったからでしょう。今も、開発されるソフトウェアの大半は、Informationを使いこなすものばかりですね。
そして、与えられたInformationを必要性に基づき取捨選択し、内容を分析し、価値判断を与えられた「情報」(Intelligence)。
アメリカの外交や国策の決定に必要な諜報・謀略活動などを行う中央情報局(ＣＩＡ)は、Central Intelligence Agencyの略。ＡＩも Artificial Intelligence の略である以上、この先、ＡＩが全盛になれば、ＩＴは
「Information Technology ではなく、
Intelligence Technology である」
と呼ばれる時代が来るのかもしれません。そして、それはそう遠くない未来のことかもしれませんね。
「空」は、まさしく Data…すなわち事実情報のことです。
「雨」は、過去の多くの経験則から予測できる解釈情報です。つまり、多くの雨雲が出ていれば、雨が降ってきた…という Data から、おそらく今回も降るだろう…と言う解釈ができる、すなわちInforamtion…要約情報となるわけです。
その解決方法として、「出かけない」「交通機関を使う」「誰かの傘に入る」等、様々な選択肢の中から、最も妥当な最適解を選ぶ、価値ある情報に変化させたものがIntelligence、すなわち知性ある情報（または知性によって導き出された情報）となります。
もともと、ＩＴと言う技術そのものが欧米から輸入した技術です。日本が開発、発案したものではありません。であれば、欧米の「情報」という言葉の源流についても、知っておくべきです。勝手に日本の「情報」という言葉１つに当てはめ、なんとなく分かった気になっているだけでは、正しい理解は得られません。
だから情報の取り扱い方って重要
散々「情報」という単語の源流について触れましたが、じゃあ、具体的にどうすればいいのかという話になるわけですが、別にソフトウェア開発の中における情報の取り扱いについてのみ言ったわけではありません。
そう、ありとあらゆるビジネスの中で、あるいはプライベートも含むすべての人生、活動の中で、「情報の取り扱い」は大事になってきます。
考えてみてください。
たとえば、サッカー。これから試合だと言うワンシーンで、みなさんは控室に集合しています。おそらくは監督が今日の試合の戦略や作戦を伝え、レギュラーの発表なんかもしているかも知れません。相手の出方にあわせて、いくつかの対策も説明するでしょう。
では、監督が、控室で何一つ発言しなかったらどうでしょう。
レギュラーが誰なのかもわかりません。ポジションもフォーメーションも教えてくれません。作戦はおろか、行動指針もわかりません。そんな状態で試合しろって言われてできますか？あるいはできたとして、勝てますか？
たとえば、営業。あるコンペで競合他社を蹴散らし、仕事を取ってこなければなりません。そんな状況の時に、何１つ資料を作らず、コンペの場で何一つ発言しない。こんな状況で、お客さまは自分たちを選んでくれるでしょうか。
たとえば、夫婦間のやり取り。「今日なに食べたい？」と奥さんが聞いて来ました。旦那はそっけなく「なんでもいい」としか言わない…そんな状況が何年も続いて、本当に奥さんはストレスをためないでいられるでしょうか。しかも、（今日は暑いから、さっぱりしたものにしようかしら…）と気を利かせてサッパリした料理を作ってくれたにもかかわらず、一口すすって「俺、今日はガッツリしたもの食いたかったんだよなぁ…」なんて旦那に愚痴を言われたらどうでしょう。
『情報』を正しく取り扱わないと、確実に問題になる…と言うのはわかっていただけましたでしょうか。
設計書１つ作成するにしてもそうです。
ある設計書の中で、
「〇〇ボタン押下時、正しく登録処理が動作する」
と書かれた設計書を見て、プログラマーは本当に、設計者の意図したとおりの完璧なプログラムを作成することができるでしょうか？
こんなの
「いい塩梅でよろしく！！」
と言われているのと同じです。
「正しく」のように形容詞を用いた説明文は、かならず具体性の伴わない表現となってしまい、読み手に複数の解釈ができてしまう可能性を与えます。
２つの選択肢を与えれば、品質上の正解率50%。
３つの選択肢を与えれば、品質上の正解率33%。
５つの選択肢を与えれば、品質上の正解率20%です。もうそんなの情報の取り扱いと言うレベルにおいて、読み手次第ではあるのですが正解ルートを選択する可能性なんて、極小となってしまうのではないでしょうか。
プログラミングだけがどんなに優れていても、こうして設計書の『情報』が損なわれていれば、結局のところ、品質が劣化し、お客様が満足するようなプロダクトにはならなくなっていきます。そして、プロジェクトが破綻し、お客さまの不満は蓄積され、コストは大幅に膨らみ、赤字化し、それでも受注時の契約を一方的には気もできないので、
エンジニアに全負担を背負わせてなんとか完了させようとする
という事態を引き起こしたり、巻き込まれたりしていくのです。
「情報を取り扱う技術」の大切さがわかっていないエンジニア、上司、経営者がいる会社では、必ずそうしたプロジェクトが年間数件～数十件起きているでしょう。起きる理由がそこにあるからです。
自分がそうなりたくないのであれば、まずは「情報」に関わることすべてに対して、神経を張り巡らせる癖をつけるようにしましょう。
いきなりすべてができるようになる必要はありません。いきなりすべての情報が集まるなんて恵まれた環境にいると言うのも稀有なことでしょう。ですから、まずは
①今ある情報から仮説を立てる
ただし、今後も情報は集め続ける
②情報が増減、あるいは更新されるたびに仮説を再検討する
③可能な限り、自らの仮説に基づいて判断する
④自らの仮説と判断が正しいかを周囲に確認する
自分一人だけの狭い知見で行動までは起こさない
起こすときはすべて自己責任のつもりでやる
という癖をつけられるよう努力しましょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。