僕がITに興味を持った理由
最初は、物理学を通してコンピュータの利便性を知った。
物理学ではよく「方程式はあるけれど解けない」という状況に出会う。
例えば、
ax² + bx + c = 0
という方程式を解くとき、因数分解すれば解が得られる。
(現実の物理学では主に多項式ではなく微分方程式というものを解く必要がある。)
高校物理のような単純なモデルや状況であればそれでよい。
しかし、僕が対象にしたかったのは、もっとリアルで現実に近い状況だった。
空気抵抗もある。物体は運動の過程で回転したり削れたりもする。
そのように複雑な状況をモデル化すればするほど、どうなるか？
方程式が複雑になるのだ。
たとえば、
ax¹⁰⁰ + bx⁹⁹ + ... = 0
のような方程式になったら、人間の手ではもう解けない。
それでも答えがほしいとき、どうするか？
一つひとつ値を代入して確かめていくしかない。
そうすればいつかは答えにたどり着けるが、膨大な工数がかかる。
しかも、人の手でやるならミスもある。寿命が尽きても計算が終わらない。
現実的ではない。
それをやってくれるのがコンピュータだ。
プログラムを書きさえすれば、自動で決められたパターン分だけ計算してくれる。
それによって、朝に定式化したものが、昼には結果として得られているようになった。
この「単純なことをものすごい速度で正確にやってくれる」能力に、わくわくしたのを覚えている。
なぜなら、以前は複雑な自然現象を定式化しても、解く手段がなく、アニメーションや軌跡を描くこともできなかったから。
だから、定式化する意欲すら削がれていた。
だが、コンピュータが方程式を解いてくれるとわかると、
好きなだけ自然現象をモデル化できる。しかもその先の予測まで行える。
この「自分の発想がどこまでも具現化される」可能性に、僕の好奇心や試してみたい気持ちがが止まらなくなった。
定式化は自由である。
プロペラの回転と浮力の関係、回転を与えたボールが空気抵抗と重力でカーブする軌跡、光速で移動する粒子の放射線の強さ など
あらゆる現象を方程式で記述できる。
日常やビジネスにも応用できる。
物流倉庫の段ボールの流れ、製造ラインの効率、人流の最適化 など
これらもすべて数理モデルとして定式化可能だ。
自分が知りたいもの、自分の頭の中にある実験室の現象に「解」を与えてくれるのがコンピュータ。
だからこそ、僕はコンピュータに興味を持ち、それを仕事にしたいと思った。
ビジネス活用への課題
そんな自分でも、今は「ほとんどのIT業界はつまらない」と感じている。
IT業界とは、ITをビジネスに活用することを支援する業界だ。
大手銀行のシステムエンジニアとして働いていたとき、「あれ、意外と面白くないな」と気づいた。
当時はエンジニアの給与も高く、IT業界が盛り上がっていた。
それでも僕は「仕事だし、つまらなくても仕方ない」と覚悟していた。
だって、楽しそうに働いている人を見たことがなかったからだ。
僕にとってITは、「個人で楽しむもの」だった。
以下では、自分の金融システムエンジニアとして働いて、どのようにモチベーションが下がっていったかを書く。
すでにエンジニアを雇っている管理職や、これから雇おうと考えている方にも参考になると思う。
ツールが使い辛すぎる問題
支給されたPCはWindows10だったが、使っていたソフトはNotesのバージョン9。
サポート終了目前の代物だ。(2024年にサポート終了した。)
(ちなみにATM内部のOSはWindows vistaを使っていた。)
しかも仕様が最悪。
下の画像のように、項目ごとに記事を作成できたりする。
これが非常に使いにくい。
まず、1プロジェクトあたり30枚以上もの仕様書・報告書をこのNotes上で作成する必要があるのだが、
Excelを1行直すだけの作業だが、
「NotesボートからExcelをダウンロード → 編集 → 再度アップロード → メール報告」
という手順が必要なのである。
これが30ファイル超。
Excel編集とアップロードだけで一日が終わることもある。
しかし納期は変わらないから、結局残業してメイン業務を進める羽目になる。
本来は、Notes上でExcel編集が可能なのだが、自分の現場では、一定時間経過すると内容がリセットされるという、やばめのバグ付きだったので、その機能は使えなかった。
この時点でモチベーションがダダ下がりである。
「Notesの仕様がめんどくさいから」という理由だけで、貴重な時間が奪われる。
本来なら定時で帰って自分の開発を進めたり、カフェでのんびりしたかったのに。
時間が経つと、これら不満は、そんな運用を採用している経営層や、それを当然としている社員たちに向かった。
さらに厄介なのは、「俺も苦労して育った」理論で新しい意見を潰してくる年長者たち。
しかし、そのマネジメント代償として若手が「指示待ち人間」か「転職者」のどちらかに分かれていった。
業務内容がつまらない
コア業務自体は興味を持てた。
だが、それを邪魔する無駄な検証や、勘違いしたリーダーが山ほどいた。
当時僕が担当していたのは「内国為替システム」である。
内国為替システムとは、ATMを介して行われる国内の決済処理全般を担当するものである。
当時のプロジェクトは、銀行支店の事務員向けに、取引明細を定期的にプリントアウトするシステムの開発であった。
すでにプリンタや取引データは存在してるので、僕の役割はCOBOLでそれを加工し、定期的にプリント処理を行うプログラムを作ることだ。
ここまでは悪くないが、これをリリースするために非常にめんどくさい作業をさせられたのを覚えている。
まず、検証作業だ。
検証作業とは、作成されたプログラムがうまく動作するかの確認作業である。
普通に考えたら、これは必要な作業である。適量であれば。
銀行業界に共通して言えることは、やつらは安全に固執するあまり、検証をやりすぎる。
やればやるほどいいと考えている節がある。
銀行は安全第一を通り越して「検証至上主義」になっている。
そしてそれらは「やってOKでした」と報告するだけではないのだ。
証拠として残す必要がある。
店舗のカテゴリ（本店、統合店など）ごとに関係ないテストをやらされたり、 その証拠をすべてNotesに張り付け、スキャンしてPDF化し、報告書を作る。(本来は、コードの内容に沿ってテストをすればいいのだが、店舗のカテゴリはコードとは全く関係なかった。)
例えば、if分で i <= 10 という処理があったとする。
この検証に対して、i = 1、9、10 あたりのパターンで試せばいいものを、i = 5は特別だから、 i = 7も大事だから、などという理由でテストケースを増やされるようなものだ。
そしてその作業を行うためには、例のNotesにプリントし、その結果をノリづけで張り付けスキャンでPDF出力し、全通り証拠として載せる。
さらに細かい点を指摘されれば、またダウンロード→編集→アップロードの繰り返し。
この作業が無駄すぎて嫌になったのを覚えている。
どうせ先方も見ていない。
ここら辺のタイミングから自分は、「SIerはこれらのくだらない無駄な作業を“仕事”だと思ってるな」と確信した。
自分たちでシステムを握って、無駄な業務を膨れ上がらさせ、工数をせしめる。
そんなクリエイティブの欠片もない仕事だと思った。
ただプリントするだけのシステム開発だが、これで3か月とかかける。
金銭的には得をするかもしれないが、得られるのは「やった風の報告書」だけ。
3か月に見合わない価値をあたかも頑張ってる風を装い提出する。
そのずるい態度・やり方も気に入らなかった。
そんな虚無な仕事を前提としている上司たちにもまったく尊敬の念は持てなくなった。
また、上司たちはそろいもそろって既婚者だ。
彼らにとって重要なのは仕事の改善ではなく「収入の安定」。
それゆえ、上の人に対する意見を言えない。社内の立場が下がることを恐れているから。
佞臣となり、思想を捨て、ただのイエスマンへとなり下がる。
それと同時に部下からの信頼は著しく失われる。
コア業務は興味深いものの、95％は無駄な人間関係と不要な作業であった。
それゆえ、やる価値・やるメリットを見いだせなかった。
これでお金をもらうくらいなら生活保護のほうがマシだと本気で思っていた。
銀行のシステム自体も、なくなった方がいいんじゃないかとも考えている。
銀行側も顧客の顔色、政府の顔色をうかがい、ベンダに対して強がることしかできないから、システム更改もどん詰まりになっている。
安全性を捨てるリスクを負えない者は、安全という錘と共に沈む。
現場の高齢化も、「若者がやりたくない業界」だという証拠だ。
僕は、世代交代できずに滅ぶのもまた一局だと考えている。
私は、そうなったときのために、一応複数銀行の口座を結構な数 分散して預けている。
ビジネスモデルがつまらない
金融とは、経済の根幹を支えるものであり、人々の信頼を前提として成り立っている「お金」とは、非常に奥の深い概念である。
しかし、システムエンジニアはそんなことを知る必要はない。
ただの取引の連続、数字の移動を処理するだけだ。
チャネルが法人・個人・店舗をはじめ多種多様であり、手数料の取り方も多種多様なため、それによってシステムの複雑性が増している。それだけの話だ。
それゆえ、「何のために作っているのか」「なぜ作っているのか」という本質が浅くなる。
これでは社会的意義も見いだせない。
人間がつまらない
使命感。
社会を良くしたい。
興味を追求する。
部下に良い影響を与えられるような人物になりたい。
そのような崇高な在り方を持っているリーダーはいなかった。
全員が目の前の価値の無い仕事で精一杯で内省する時間がない。
たまに口だけ偉そうなことを言う人もいたが、まるで改善プロセスを示すことはできない政治家のようだった。
「いつか頑張っていれば報われる」と思考停止で信じており、それを周りにも強いる。
しかし、誰もが「頑張っても報われるのか？」と疑念を抱いている環境では、その言葉は説得力を持たない。
発言している本人も報われることを確信しておらず、報われない際の戦略も持っていない。
つまり、沈みゆく船を放置する船長である。
やつらの口癖は、「やらなければならないから、やっている」だった。
ただ、従うだけ。
上司は自分に期待していたようだが、自分は「こんな人間にはなりたくないな」と考えていた。
人として尊敬できなかった。
ベンダの大半はそう
ベンダの大半は、顧客要求に従ってそのままシステムを開発するビジネスモデルである。
日銭はもらえるものの、持続可能ではない。
結局、当人にしかわからない複雑なシステムが完成し、それゆえトラブル対応に時間がかかり、デスマーチ状態。
終わったところで誰にも感謝されないどころか、下手をすれば損害賠償を請求される始末。
頭の悪い顧客も、その要求を呑んでしまうSIer側も、自分から見れば全員ありえないし、センスがないと考えるようになった。
これを「努力している」とか「頑張っている」とは全く思わない。むしろ軽蔑している。
しょぼいシステム改修しかできないくせに、無駄にストレスをためて他人や部下にぶつけている。
「自分も管理できていない、ただの言いなり」としか見えない。
つまり、ベンダの大半はありえないことをして社会を悪くしている。
そういうのは、それが好きな連中だけでやっていてほしい。
ITの本質とは
ITの本質は、スケール感と自動化である。
現在成功しているIT企業は、ほとんどがこの2つを実践している。
スケール感とは、同じ品質・同じ価格といった同一の製品やサービスを、広範囲に提供することを意味する。
インターネットを通じたITサービスを活用・開発することで、全世界の人々に製品情報を届けることが可能になる。
自動化とは、製造工程等の生産の自動化である。
例えばAmazonは、サイトをインターネットを通じて全世界にサービスを展開している。
そして、注文のあった商品が倉庫内から取り出されるが、倉庫は無人でロボットがすべて荷物を運ぶ仕組みを構築している。
自動化の仕組みがあるからこそ、全世界にスケールしたことで生じる大量の需要を捌くことができる。
この「自動化」と「スケール感」という2つの性質は、株式会社という仕組みとも整合性が良い。
だからこそ、資本主義社会においてここまでの成功を収めることができた。
（詳しくは別の機会に記事にしたい。）
1980年代の銀行は、当時最新のITを取り入れ、預金関連の事務を自動化し、ATMによってその機能を全国にスケールさせていった。
だからこそ、多くの人々が楽にそのサービスを享受できる。
だが、今はどうだろうか。
スケールが終わった後に待ち受けているのは、競合他社による経済戦争である。
銀行は重要な機関ゆえ、法律でビジネス内容が大幅に制限されている。
そのため、他行との競争優位性を出すことが難しい。
多くの人にとって、三菱UFJを使うか、りそな銀行を使うかなど、どっちでもいいのだ。
競争優位性を出せないビジネス競争の行き着く先は、低価格競争である。
いかに低価格・低利子でお金を貸し付けるか。
自動化とスケールが終わった後の市場では、全員が無理をしてしのぎを削る。
そのしわ寄せはエンジニアにも来る。
IT投資の抑制により、SIerに支払われる報酬は減らされる。
しかし、顔色をうかがうことしかできないベンダーは、「それでもいいですよ」といい顔をして、自分たちの価値を下げる自殺行為を行う。
それでもエンジニアの仕事量は変わらず、現場はサービス残業が増加し、ブラック化していく。
自分はその仕組みに気づいていたし、上司に相談もした。
しかし、「そのような話は管轄外だ」と、上司は考えることも話を聞くことも放棄していた。
この時点で、「こいつは組織を束ねる器じゃない。俺がリーダーになった方がましだな」と考えるようになった。
結局、交渉力も責任も取れない上席はスパイと同じで、いない方がマシである。
従うしかない人間は、市場が低価格化し競争優位を保てなくなるタイミングにも気づけない。
構造問題には目を向けようともしない。
そのしっぺ返しは、「若手が定着しない」という形で返ってくる。
ひどい場合、管理職側が「最近の若者は根性がない」と言ってしまう。
しかし、現実は「考えることを放棄した人間の代償」なのである。
ITの本質である自動化とスケール感。
これをキーワードにビジネスを展開できていれば、まだ新しい道はあったかもしれない。
ITをもっとクリエイティブな仕事にしたい
結局、僕はそのような組織を変えるつもりはなく、関わるのをやめれば問題は解決すると考え、転職した。
この後の出会いによって自分は救われた。
別の記事で書きたいが、新たな製造業のDX部門では、優秀なエンジニアとの出会いがあり、そこでOSSの文化などに触れた。
OSSとは、Linux、Docker、Grafana等をはじめとする、インターネット上で無料で手に入るテクノロジー達である。
それらは各OSSのコミュニティの中で醸成され、ユーザーに認められて育っていく。
OSSの世界観では、エンジニアたちは自由に発想し、その機能を実装する。
さらにユーザーたちは仲間とともに、新しい考えや情報を共有していく。
そこにはリスペクトがあり、脳をフル活用する感覚がある。
自分がこれまで身につけてきた数学・物理学の知識を活用できる環境があり、自分でその環境を作ることもできる。
「もっとサーバをわかりやすく監視したい」と考えたら、そのテクノロジーを開発する。
「もっとサーバの監視結果を解析して傾向を出したい」と考えたら、そのテクノロジーを開発する。
「もっとデータを圧縮できるテクノロジーを思いついたから実装したい」と考えたら、そのテクノロジーを開発する。
そして、その過程の中で仲間が集まり、コミュニケーションが生まれていく。
このコミュニティ感が好きだった。
自分で考え、自分で実装し、そのプロセスで仲間が増えていく感じが好きだった。
自分の場合、「自由に発想する」ことこそが最もエネルギーが高まる。
これは、ITの歴史の中でもよくある“謎の現象”である。
詳しくは以下のページを確認してほしい。
「伽藍とバザール」はシステム開発手法に関する論文である。
簡単に言うと、トップダウンで開発を進める伽藍方式と、個人が自由に開発して統合するバザール方式、どちらの品質が高くなるかという議論である。
伽藍方式は現在のSIer方式に近く、計画的で、納期・責任などを各々が負って開発する。
一方でバザール方式は、各エンジニアが好きな機能を好きなように追加する。
また、エンジニアはそれらに対して責任を負わない。
OSSの思想もこれに近い。
結果は、バザール方式の方が生産性が高いことが証明された。
多くのエンジニアが給料をもらいながら計画的に作るシステムよりも、無料で自由に開発されたOSS(PythonやNginxなど)の方がクオリティが高いのである。
なぜこのようなことが生じるのか。
それは、開発する際の燃料（モチベーション）の出所が違うからだ。
伽藍方式では、出世や生活の維持といった、本来ITとは関係のないところからモチベーションが生まれてくる。
だからこそ、そのレベルは低く、最低限にとどまる。
このエネルギーに陥っている人間は、罰を与えることで動かすのが常套手段である。
それゆえ、従業員は罰を受けない最低ラインを攻め続ける、低空飛行のやり取りが繰り広げられる。
一方で、バザール方式はクリエイティブや好奇心によるエネルギーである。
これは終わりがない。
気になること、好きなことを徹底的に追求する。そのエネルギーは無限大だ。
だからこそ、お金をもらっていないのに、ここまでOSSが普及しているのである。
問題点
しかし、最大の問題は、バザール方式では生活できないことだ。
クリエイティブであることのデメリットは、「予測不可能」「責任を取らない」という点である。
多くのビジネスでは、これらは許容されない。
自由なクリエイティブの方が生産性は高いが、ビジネスの原理原則である「責任」「納期」などがそれを阻んでいる。
自分はこの現状に対して、バザール方式になるように社会を変えるつもりはない。
一方で、SIerのような人間とは関わりたくないと思っている。
ただ、このクリエイティブの気持ちよさは普及していきたい。
それゆえに出した結論は、「クリエイティブを追求しながら無理やり生活してみる」である。
その結果、貧困になっても仕方がない。
現在はありがたいことにITコンサルタント等の仕事が入っている。
自分がコンサルをする際に重視しているのは、「自由に先方を観察できること」である。
例えば、物流業界の経営者からIT化の要望があったことがある。
自分は、ただおすすめのツールを紹介して実装する、などはしない。
まずは、その要望が理にかなっているかどうかを徹底的に観察する。
(多くのクライアントは、自分の依頼が正しいのか不安を抱いている。
その不安を抱えながらエンジニアに仕事を依頼する。)
会社の事務所だけでなく、倉庫・センター・トラック整備場・トラックドライバーへの聞き込みなど、すべて行う。
各従業員がどのようなスケジュールでどのようなツールを使っていて、何がやりづらいかは1人残らずヒアリングを行う。
経営者や役員レベルでも、そこまでの粒度で従業員の役割を把握しているパターンは少ない。
しかし、IT化をする場合は、そのレベルまで見たうえで要件を決めた方が、全員が幸せになれる答えが見つかるのだ。
ここまでやるからこそ、当初のIT化の要望が理にかなっていないことが浮き彫りになる。
逆に、自分の提案が現実的でない場合も修正することができる。
そのため、「上から目線の強制的なIT導入による現場の不満」も解消できる。
自分と企業、お互いに理解を深め合うことができるのだ。
こっちのほうが、不満も少ない。
今は自由に発想して、楽しんで仕事ができている。
自由というのは、ITに関してだけではない。
コンサルに入った際は、先方のビジネスモデルに興味が湧くので、自由に調査させてもらえなければ依頼は受けない。
まとめ
これらが自分が今までのキャリアの中で培ってきた、ビジネス感と思想である。
より、ITを使った自由な発想がしたい人は多いと思う。
今後も、思ったことを発信していきたい。