どうしてシステム開発はうまくいかないのか。
エンジニアのビジネス理解力が不足しているから、と言われますが、非エンジニアのプログラミング理解力不足も同様に要因。むしろそちらの方が問題なのではないかと感じる本を見つけました。
実況！ビジネス力養成講座 プログラミング/システム 著者：岡嶋 裕史 出版：日経BP
ノーコードで開発できるからとあぐらをかいていてはいけません。DXは、攻めのITシステムを高速でリリース・変化・改善させていくことでもあり、この本に書かれているプログラミングにまつわる知識、そしてプログラミングを勉強する必要性は理解しておくべきです。
初？非エンジニア側の言葉で書かれたプログラミング本【本の概要】
DX関連の本は60冊以上読み漁ってきましたが、大半がプログラミングそのものには触れていません。
「プログラミングなどの技術面は専門家に頼めばいい」
という暗黙の了解があるからなのか、もしくはDX関連の本の多くが専門家たちの営業本であるからなのか、読者が専門家でないことを想定しているからなのか、原因は分かりませんが、とにかく技術については触れられていません。
実はこの「技術のことは専門家に」と容易にブラックボックス化してしまう姿勢こそ、システム開発がうまくいかない元凶なのかもしれません。
この本は「エンジニアと非エンジニアの架け橋を目指した」という説明通り、プログラミング・技術のことがわかりやすく説明されています。たしかに、プログラミングとは何かについて書かれている本はありますが、なぜプログラミングを学ばないとビジネスに転用できないのか、について書かれている本はありませんでした。
そして、非エンジニアにもわかる言葉で書かれていることが特徴です。たとえば「ライブラリ」の説明。
ライブラリは「これはみんなが使いそうなプログラムだ」というのをまとめたものです。たとえば、ファイルを開いて読み書きしたり、画面上に指定の絵を描いたりといったプログラムは、多くのソフトウェアで必要ですし、無数のプログラマが書いてきました。
実況！ビジネス力養成講座 プログラミング/システム 著者：岡嶋 裕史 出版：日経BP
みんなが書くものであり、かつ誰が書いても同じになりそうなものであれば、再利用するのが吉です。そこで、汎用性・再利用性の高いものをまとめてライブラリを作ります。数学用のライブラリ、描画用のライブラリなど多岐にわたるライブラリが存在します。
WEBで調べるとなかなかこのようにスッと入ってくる説明がありません。例えばウィキペディアですと
汎用性の高い複数のプログラムを再利用可能な形でひとまとまりにしたものである。ライブラリと呼ぶときは、それ単体ではプログラムとして動作させることはできない、つまり実行ファイルではない場合がある。ライブラリは他のプログラムに何らかの機能を提供するコードの集まりといえる。
ウィキペディア フリー百科事典「ライブラリ」の説明
と書かれています。言ってることは確かに同じですが「単体では動かない？」「実行ファイルじゃない？」「何らかの機能？」と疑問がどんどん積み重なり、エンジニアでなければ頭に入ってきづらい説明が並んでいます。
と言って、プログラミングの勉強そのものをはじめればいいのかと言うと、どのくらい勉強すればもろもろ理解できるようになるのか先が読めません。まずはこの本で概要・重要なポイントを半日でつかむことをお勧めします。
DX時代、システムを手足のように使い倒すことを求められる時代において、プログラミング理解は絶対必要です。詳しくは本書で勉強いただくとして、ここからは本書に書かれていた重要なポイントについてお話していきます。
コンピューターは未就学児の社員、と捉える
本書冒頭で「コンピューターは未就学児である」と表現しています。
つまり、未就学児にもわかるレベルでかみ砕いた指示を出さないと、コンピューターは動かないということです。
たとえば「歯を磨け」という指示も、相手が小学生であれば「歯を磨きなさい」という一言で済みます。ですが、未就学児で歯を磨くという概念そのものを知らない相手に話す場合はどうでしょう。
・歯ブラシとは何かを教える
・歯ブラシの握り方を教える
・歯磨き粉とは何かを教える
・歯磨き粉の付け方を教える
・歯磨き粉の量を教える
・歯の磨き方を教える
1つずつ丁寧に教えなければ、歯を磨くというタスクをこなすことができません。(最初は親が磨いてあげるところからスタートするのが実際ですが)
かつ、これがコンピューター相手の場合はさらに細かい指示が必要です。
・歯磨き粉の量は何cmなのか
・どの歯から磨くのか
・磨く際の歯ブラシの角度はどうするのか
プログラミングする際は、さらに細かい指示が必要になることを加味すると、コンピューターは未就学児以下とも言えます。
そしてこの、未就学児以下のコンピューターに、すべてを、細かく抜け漏れなく指示することがプログラミングです。
未就学児に「お鍋を見ておいてね」と指示しても「こうなったらスイッチを切るんだよ」という指示まで細かく伝えないと出来ません。お鍋が噴きこぼれても、一酸化炭素を生成しても、指示がなければスイッチを切らず、ただただ見ているだけ。未就学児以下のコンピューターはとにかくすべて細かく指示出来ない限り、望む仕事をしてくれないのです。
さらにプログラミングは「上から順番に」実行されていきます。例えば未就学児にトイレの使い方を指示するとしたら、
・トイレに入る
・服を脱ぐ
・便座に座る
・用を足す
・服を整える
・水洗を実行する
という順番になります。この順番が崩れれば、トイレはめちゃくちゃになってしまいます。つまり、指示の粒度と同時に、順番も慎重に考えないといけないのです。
システム・アプリを作るとき、自分でプログラミングを組まないまでも、プログラミングに求められる粒度やルールを理解していないと適切な指示・要望が出せません。
店長が、店員の業務を経験していないと的確に業務を回すことができなくなるのと同じです。店員の業務を知らないと、店員の負担を見積もることができませんし、それによって人を増やすほうがいいのか減らすほうがいいのかもわかりません。シフトをどう組むべきかもわかりませんし、あたらしくスキル開発が必要なのか、どんな商品なら任せていいのかなど分かりません。
すると、店員にどこまで任せられるのか分からず、店長がすべき業務に集中できなくなります。つまり、プログラミングを理解しないということは、コンピューターに任せる仕事と量を適切に見積もることが出来ず、人間がすべき仕事に人間を集中させることができないのと同じです。
先日の記事でもお伝えしましたが、上司がプログラミングを理解しないと、進捗ばかり管理するしかなくなり、エンジニアは進捗がゴールになってしまうため、進捗を簡単に稼げるタスクばかりをこなしてしまうという悪循環の要因になります。すると難しいコアタスクが後回しになり、全体に影響する大きなバグが発生し炎上するという流れです。
まとめると、コンピューターとは未就学児以下の社員だということです。
もちろん計算が非常に早いなどの特殊能力はあるため、有能扱いされがちなのですが、実態は未就学児以下なのです。そんな未就学児以下の社員にあった指示の出し方を勉強しないということはマネジメントを放棄しているのと同じです。
外国人の社員ができたら、多少なりとも英語の勉強をするはずです。コンピューターの未就学児以下の社員ができたら、彼らの言葉を勉強するのは当然であるはずです。
だからシステム開発は最初からうまくいかない
プログラミングを理解しないから、どのぐらい作業が発生するのか、なにが出来て出来ないのかが理解できないというお話でした。このことを踏まえると、システム開発がうまくいかない理由がさらに明確になってきます。
海外と比べて、日本の経営者はプログラミングを勉強してみようともしない傾向があると言います。海外はレガシー企業の経営者が率先してウェビナーやカンファレンスに参加して勉強すると言います。
つまり、日本の場合、システムの構想をする経営者が、コンピューターは未就学児以下であるというイメージがなく、何でもできるスーパーエリートくらいのイメージで捉えてしまっている可能性があります。すると、未就学児以下に期待してはいけないレベル以上の要望を期待してしまいます。
その要望を受け、部門同士で要件定義をはじめますが、この部門の人間たちもシステム部門をのぞいてプログラミング理解がありません。するとコンピューターに対し「売り上げに直結しないおもちゃだ」と懐疑的になり、責任のなすりつけあいがはじまります。結果、発生する業務を最小限に抑えた、コンピューターが担当する業務がもりもりのシステム要件になります。
さらに設計段階で、プログラミング理解がない経営層から「最近ブロックチェーンが話題のようだね。生産性も創造性も上げることができしかも低コストと聞いている。なぜうちは採用しないんだ？」とお達しがくだり、システム構想と関係のない技術が組み込まれ、かつその技術を活用した新しい機能を考えなければいけなくなります。
ステークホルダーのプログラミング理解がないことで、これだけシステム開発がうまくいかなくなる流れが産まれてしまうのです。
さらに輪をかけて、システム構想の段階で「何をしていいかわからないけど、とりあえずスタートする」というよくある事象があります。この事象、よくよく考えてみると、システムを開発する人たちにコンサルティングも依頼しているのと同じです。不勉強にプラスして、考える労力すら省いているということになります。
また、プログラミング理解がないことの問題は「どちらが上か」という綱引きを引き起こしてしまうところにあるように感じています。
システムを開発するということは、付随してあたらしいオフライン業務が発生するということです。つまり、システム開発側が業務内容を決める立場になるともいえます。この時、ビジネス側は、ビジネスを知らないシステム開発側がいきなり上流に立ってしまうことに、少なからず戸惑いを感じるはずです。すると、ビジネス部門が上だ！とマウンティングがはじまり、現行ビジネスの補佐的なシステム開発がはじまってしまうわけです。
システム開発側が上か、ビジネス側が上かという構図が問題なわけですが、この問題を解消するのはお互いがお互いのことを理解するために勉強することに尽きます。そしてどちらかと言えば、ビジネス側がプログラミングを学ぼうとしていないことのほうが多いのではないでしょうか。
まとめ「むずかしい言葉を捨てることからはじめよう」
非エンジニアもプログラミングを勉強すべき理由についてお話してきました。
●コンピューターは未就学児以下の社員。高速処理など優秀な面は多いけど、相当細かく指示を出さないと仕事ができないことを理解する意味でも、プログラミングを勉強すべき。
●プログラミングを勉強しないと、コンピューター社員の負担や任せるべき仕事がわからない。すると人間は人間がすべき業務に集中するという未来が実現できない。
●プログラミングを理解しないことで、システム開発が頓挫する理由が積み重なる。英語以上に、プログラミングを勉強しなければいけない時代がもう来ている。
この本によって、さらに細かくプログラミング・技術周りの事象について理解することが出来ました。実際にプログラミングを書き、何かを作ってみる経験も積まねばというモチベーションも上がりました。
ですが、この本の一番の収穫は「やっぱりむずかしい言葉を使わなくても、わかるように説明することってできるんだな」という理解が得られたことです。
エンジニア側もビジネス側も、お互い日本語という共通言語があるにもかかわらず、お互いが理解しづらい言葉で会話をしているような状況をよく見かけます。「この言葉がわからないなんて勉強不足だな」とお互いが綱引きをしているような、そんなイメージです。
もちろん、勉強するのは当たり前。マストですが、そろそろお互い、マウンティングを捨て相手がわかる言葉でコミュニケーションする努力をしはじめてもいいのではないでしょうか。
まずはビジネス側の人間はこの本を読む。この本が、エンジニアと非エンジニアをつなぐ「プロトコル」としての役割を果たしてくれるはずです。(プロトコルについてもわかりやすく説明されていますので、読んでみてください。)
参考：
実況！ビジネス力養成講座 プログラミング/システム 著者：岡嶋 裕史 出版：日経BP
執筆者
リビルダーズ編集部
