ビジネスプログラミング的思考とは

ビジネスプログラミング的思考は私が作った造語です。書籍はこちらより

なぜ、作ったかというと、何歳からであっても、プログラミングに挑戦すること、学ぶ事はすごく素敵だと思っていますし、教養として身につけていても、損はないと思います。

また、ビジネスプログラミング的思考は問題解決能力や論理的思考と言い換えても良いかもしれません。

人と話していると、プログラミング的思考＝コンピュータの専門家が使うもの、難しいと感じている方が多いという実感がありました。

だからこそ、日常生活やビジネスの場面でも役立つよという意味で、ビジネスプログラミング的思考という名前にさせていただきました。

プログラミング的思考は、問題解決能力や論理的思考と同義と書いてある場合もありますが、それだけでは足りないと思っています。

一昔前と違うのは、AIに最適解を求めさせたり、この部分は、コンピュータを使って、自動化させたりなど、必ずしも、人間が全ての答えをだす必要はないということです。

また、論理的思考だけでは、ビジネスの現場では、対応できない事も多々あります。

新しい問題に関しては、既存の知識では太刀打ちできない場合も多々あります。

今後、どこを自動化するのか、AIに任せるのか、そして、自分自身の力で打破するのかを考えていく必要があります。

ビジネスプログラミング的思考を深める上で

• 大きな課題は分解する
• 失敗思考
• 自動化・時短化

について、紹介します。

大きな課題は分解する

世の中にはたくさんのシステムがあります。

スマートフォンや銀行のシステムなど考えてみてもよいでしょう。

膨大なプログラムが連携して、動いています。

では、システムを作っていく時、膨大なプログラムをいきなり書いていくかというと、そうではありません。

システムと一言でいっても、たくさんの機能の組み合わせでできています。

スマートフォンを一つとっても、

• 電話帳機能
• 電話をかける機能
• アプリをインストールする機能
• 時計表示機能
• 音量を上げる、下げる機能
• カメラ機能

などなど。

小さな機能を一つずつ作っていき、最後に統合させ、一つのシステム、サービスになっています。

小さな機能の積み重ねで一つの製品になります。

大きな問題は小さく分解していく。

小さな問題の積み重ねが大きな問題になっていきます。

この考えは、いろいろなところでヒントになっていきます。 私は「ダイエットをしたい」という相談を受けます。

ダイエットをしたい。

だけだと、何をして良いのかわからないですよね。

5キロやせたい。

ではどうするか。

食事を変える。

運動をする。

など、具体的な、行動に移すことができます。今回であれば、このような図がおすすめです。

失敗思考(ABテストなど)

商品のサイクルは短くなっていて、どんどん新しいものが生み出されています。

Web広告で、AというデザインとBというデザインがあったとします。

どちらがクリックされるのか。

昔の紙媒体やテレビの媒体であれば、AとBのデザインについて、専門家同士で議論をして、Aと決めたりします。

Web広告であれば、100万円あったとします。

まずAに5万円とBに5万円、両方の広告を掲載し、Aがよかったら、残りの90万円をA広告の掲載を行います。

今では、このように、より精度の高い広告を出すことができます。

これをフローチャートに起こすと、このようになります。

専門家の議論や調査ももちろん大事です。

しかし、ITはすぐにいろいろと試すことができます。不格好経営より引用します。

よく、資格ジプシーのように、いろいろな資格を取られる方がいます。

「あれが足りない、これが足りない」だから、勉強しよう、調べようと。

だから、どんどん資格は溜まっていくのだけれども、結局収入は増えないという。

そして、まだ勉強が足りない…。

という繰り返しにハマっていきます。

でも、実際うまくいっている人を眺めていると、よくわからないけれど、試してみて、失敗か成功か、そこでの経験を次のステップに活かしていきます。結局資格の多さではありません。

マーケティングの調査なども、もちろん大事です。でも、調べている間に、時期が過ぎてしまうという事も多々あります。

開発現場のお話ですが、開発スピードの速い企業は品質が高く、遅い企業は品質が低い。という記事がとても参考になります。

速く開発する人と、ゆっくり丁寧に開発する人、どちらの品質が良いのか。

ゆっくり丁寧に開発する人のほうが、品質が良さそうな気がします。

でも、ここで明らかにしているのは、開発速度と品質はトレードオフの関係ではないということです。

私は、開発だけでなく、サービスを提供する側も、このような関係があると思っています。

Web広告での失敗思考（ABテスト）の例が顕著だと思っています。

専門家の意見を聞くことも大事ですが、とっとと、実験してみればということです。そして、そこに真実があります。

結局のところ、経営もスポーツに近いと思っています。

私は、マラソンをよくします。

マラソンの走り方をいくら学んでも、速く走れるようになることはありません。

それであれば、まず、走ってみる。

走るからこそ、足りない部分もでてきます。

すぐに歩いてしまう

足を痛めてしまう

速く走れない

などなど。

では、その問題点が明らかになった上で学ぼうとするのと、ただ学ぶだけでは、前者のほうが効果は明確です。

マラソンに関しては、こちらの書籍にまとめましたので、もしよかったら、手に取ってください。

時短・自動化

改めて、コンピュータの得意分野はなんでしょうか。

それは、同じことを、繰り返すことです。

人間と違って、計算問題を間違える事はありません。

1000問、解いても、1万問解かせても、疲れることはありません。

天気予報の情報を朝6時に取得し、降水確率50%なら、スマートフォンに通知し、それを見て、傘を持っていくという例も同じです。

エンジニアには三代美徳というものがあります。

それは、何かというと 怠惰 短気 傲慢です。

Perlというプログラミング言語の生みの親である「Larry Wall」さんが言ったものです。

「楽をしたい」と言うと、すごくネガティブに聞こえるかもしれません。

ただ、プログラミングの世界であれば、才能があると思っていますし、今の時代、求められています。

「楽をしたい」だからこそ、ここは自動化しよう。

「楽をしたい」をより具体化し、人にお願いして、自分の時間を増やそうと考えるわけです。

Webサイトの管理人で、毎日アクセス数を見て、上司に報告するとします。

行動をフローチャートで書いてみるとこのようになります。

これを、自動化すると、このように、すごくシンプルになりますし、日々の仕事が減ります。

これで、Webサイトの管理人の時間をだいぶ減らすことができます。

さらに、異常を知らせたい場合は、このようにすると、さらに気づきやすくなります。

あなたが、プログラミングを書く必要はありません。

まずは、どういう問題があるのか、どこを楽にしたいのかを明確にすることです。

そこが明確になれば、プログラマーやエンジニアの人に依頼することができます。

だからこそ、問題を解く事も大事なのですが、そもそもの問題を見つける、発見することに価値があると最近考えるようになりました。

問題を認識できれば、解決まであと一歩です。