システムの作り方を知らないのは、教わっていないから。

本を1冊出すとなると、自分たちが書いた原稿を何度も何度も読み返すことになる。
僕の場合は編集さんに最初の原稿を渡すまでに、6回から20回くらいは読む（章による）。読んでその度に直しているし、その後ゲラができてからも、当然誤字脱字をチェックする。

そうやって読み返している最中、しみじみと思ったことがある。
かなり傲慢なことを承知で、それを書いておく。


お客さんのプロジェクトについて、相談にのっていると、
1)
「もう○○は済んでいます」とおっしゃるのだが、現物を見せていただくと、全然違うことをやっている。例えば「業務課題の洗い出しは済んでいるとおっしゃっても、その資料を見せていただくと「現行システムで使いづらいこと一覧」だったりする。
2)
○○を全く検討してないのに、それよりずっと後でやるべき××を一生懸命検討している。一番典型的なのは、将来どんな業務にしたいのかをほとんど考えていないのに、パッケージ選定を一生懸命やっている。

みたいなことがたくさんある。
なんでこんなことになっちゃんてんだろう？とよく思うし、せっかく相談に来てくださったのだから「いやいや本来はこういうことを検討すべきで・・」とサンプルの資料を見せながら、その場でレクチャーすることが多い。

とはいえ、そういった事態がしょっちゅう起こるのは、当然なことなのかもしれない。
いまや多くの会社でITをテコにした改革をやっているにも関わらず、ほとんどの人は「ITをテコにした変革プロジェクトのやり方」を誰からも教わっていないのだから。

経理部の人は仕訳の切り方や決算の締め方を先輩から教わる。
営業の人は売り方を先輩から教わらないことも多いけど、凄腕営業マンを見て盗む。
でもシステムの作り方って、誰も教えてくれないことが多い。
エンジニアであれば、プログラミングの仕方は教わるけど、それと「組織において、有効なシステムを作る方法」とは、かなり別種のスキルなんですよね。

営業みたいに見て盗もうにも、お手本になるようなシステム構築プロジェクトがほとんど社内に存在しなかったりする。
成功にせよ失敗にせよ、プロジェクト事例の共有がほとんど行われてない。今どきのITベンチャーみたいなところは別として、普通の大企業でプロジェクト事例を共有して、勉強会を開いている会社をマジで一つも知らない。


つまりプログラミングとかプロジェクトマネジメントじゃなくて、「システムをテコにビジネスを良くする方法」だとか「システムを作ってもらう方法」は教えられたことがない。教えてもらう機会も皆無だ。
本当はシステムのプロであるSIer（システムインテグレーター）が教えた方がいいと思うんだけど、彼らはそういうのやらないみたいだ（顧客への教育を自分たちの仕事だと思っていないし、人様に教えられるほど、ノウハウを言語化できてないという可能性もある。

やり方を教わっていないので、ちぐはぐなことを一生懸命、真面目にやってしまっている。極めて単純な話だ。
僕自身は「優れたやり方」を20年前に教わって、もう血肉になっていて、無知だったころの自分をすっかり忘れて、「これが常識でしょ」くらいに思っている。
だから自力で試行錯誤している様子を見ると「いやいや、そうじゃないでしょ」と思ってしまう。

でもこれは知識がある側の傲慢だ。自分だって転職する前は「優れたやり方」を知らなかったので、相談に来られる方々と同じ様に、試行錯誤しながらやっていた。忘れているだけだ。

この5年くらいは日本のビジネス界でもようやくITやソフトウェアの重要性が理解され、アジャイルだDXだと、色んな話が飛び交っている。
だがそれらは応用編。バタ足を習ってないのに、「バタフライってかっこいいよね」などと話している状態だ。
そんなことに飛びつく前に、王道のやり方をまず学んでほしいと思う。
そしてやっぱりこの本（システムを作らせる技術）は10年前に出すべきだったんだろうな、とも。