教養としてのプログラミング ②~何者かになりたいビジネスマンの明日が変わる(かも)~
どうも、コンニチハ。さかわきと言います。
2022年からG's ACADEMY(https://gsacademy.jp/)という起業を目指す人間向けのエンジニア（プログラミング）スクールにお世話になり等々のくだりは第一弾で記載したので割愛します！
まだ初回を読まれていない方は是非コチラからどうぞ！背景から書いているので目を通していただいた方が有難いです。
さて、この記事ではビジネスマンの以下3点の問題解決や行動の後押しになります。
１．今の会社での仕事をもっと成功させたい！
２．もっとイケてるビジネスマンになりたい！
３．新規事業を始めて自分が価値を作りたい！
”マインドセット編"、”考え方編”、"チームワーク編”と書いていく予定でして、今回が真ん中の考え方編です。
僕がプログラミングを通して実際のビジネスシーンでも役に立つと思った内容を記事にしています。
Thinking/考え方編
コードは嘘を吐かない
データサイエンスの世界では "(ゴミを入れたら、ゴミが出てくる)" という言葉があるようですが、プログラミングのコードはもっと正直な世界だと思います。
何故なら、人間がコードを最初に書く訳ですが、書いたものを実行するのはコンピューター側です。このコンピューターに機転なんていうものはなく、寸分の狂いもなく最初から最後まで順番に彼らが理解できる規則で読み取り実行するからです。
回りくどくなってしまったのですが、原因は人間側（特に自分）にあるということです。自分を責める必要まではないのですが、何かうまくいかないときはまず自分が何をやったのかを振り返って最善を尽くすことが大事だとだと思いました。
また、プログラムの場合は自分たちのコードに不備があると"エラー"が表示されるのですが、考え方によっては親切なんですよね。現状では上手くいかないという問題が分かるということは、これを改善すれば上手くいく、もっと伸びしろがあることの裏返しです。「エラー、ようこそーっ！」と思えるメンタリティーもまた大事ですね。
質問の流儀。課題に対する解像度は高いか？
皆さんは人生の中で答えにくい質問に出逢ったことはないでしょうか？
バツが悪くて答えづらいではなく、例えば想定される質問者に合った答えがいくつもあって答えにくいアレです。
口頭での質問なら文脈が分かりやすく、すぐさまレスポンスができるので問題は起きにくいと考えています。
一方でプログラミングをしているとテキストベースでの質問がとても多く発生します。何故かというと、コードを貼り合い解消するというケースが多々出てくるからです。
自分の質問に答えてもらおうとしたとき、他人の時間を削っている且つ善意で答えてもらっているという意識が重要です。（他人の質問が自分の利益に繋がるとは限らない中で回答してくれているケースが多いため）
これは普段のビジネスの場でも同じことが当てはまると思います。
１．何にが問題なのか？
２．何をゴールにしているのか？
３．今まで自分が試したことは何なのか？
４．その結果、現状どんなことが起こってしまっているのか？
５．いつまでに助けてほしいのか？
このへんを読み手に伝わるように端的にまとめる必要があります。
つまり、自分のやりたいことの解像度が高くないと誰も助けようがないということです。
これは自分で調べものをするときも同じことが言えると考えています。解像度の高い人は適切な言語化ができているため検索でもヒットしやすい言葉で調べることができます。
昨今発展してきているＡＩでも同じことが言えると思います。解像度の高いプロンプト（指示）をすることで意図した回答が手に入るものです。
全ては組み合わせ
新しいことを始めたり、進めようとすると必ずこんな声が上がってくることを鮮明に覚えています。
「それは前例がない」（新しいもの＝分からないもの＝大変/判断無理）
「それ〇〇のパクリじゃない？」（新しいもの＝超斬新なもの＝発明級）「新商品で残るは千三つ」（新しいもの＝報われないもの＝やる価値なし）
前提となる考え方を知ってしまうと全てナンセンスに聞こえてきます。
その前提とは、”新しいものは全て組み合わせ”ということです。そして本当に新しいことをやろうとする場合、究極やることはシンプルなんだと気付かされます。
そして前の記事の背景でお話したようにプログラミング/インターネットのことを知ると殆どのサービスはオープンソースです。あるものとあるものを組み合わせて新しいものを創るのは当たり前のことなのです。
つまり、恐らく周りの人の慎重(?)な発言はある種のマインドブロックがあるだけだと思います。
「前例がない」なんて言うのは、組み合わせである以上ほとんどのことが分かっているも同然です。自分たちの業界や市場のルールや慣習の中でどのようにフィットさせるかが大事ですね。
「それ○○のパクリじゃない？」は、もう当たり前です。なぜなら何もかもが大体パクリ合いから成り立っているからです。（もちろん超えてはいけないパクリもありますよ！）
「新商品で残るのは千三つ」、これは少し毛色が違うと思っています。プロダクトは、今あるものやアイディアからの組み合わせで完成できます。しかし、プロダクトがサービスとして受け入れられるかは別の話です。
つまり、ここは覚悟の問題です。大事なのでもう一回言っておきます。”覚悟の問題”をクリアすることで初めて新しいプロダクトはサービスとして受け入れられ浸透します。やるなら、めげずにやり続けましょう！
一つずつ解決(エラーも何事も)
何か問題が起こったときに皆さんはどうされるでしょうか？
プログラミングのコーディングでは、開発者ツールで親切にも問題（エラー）が起こったら全てを書き出してくれます。（もう嫌になるくらいご丁寧に。。笑）
エラーをクリアしないとプロダクトは動きません。しかし、裏を返せば、一つずつクリアすれば、必ず上手くいきます。
僕自身、ここでの学びは２つありました。
１つは、問題って大体自分に原因がある。ないと思っていても関連していることは必ずある。自分を責めろ！という訳ではありません。ただ原因自分論のように一度立ち返るという考え方は大事だと思いました。
２つ目は、全てを一発でクリアするような解決策はほぼない。異論は認めます。現にたまに一つ解決するだけで全ての歯車が噛みあう、なんてことは起こります。ただ、考え方として全部を一気に解決するものをウンウン悩むよりかは、問題の全部と全体像を掴んだうえで一つ一つクリアする。これが一番早くて確実かもしれないなと思った次第です。
やはりこの章も気軽に読むには長くなってしまったため、ここで一旦考え方編をまとめます。
とにかく一旦やる。完璧を求めすぎない。
誰から何を言われようと諦めない、持ってるもので具現化する。
何だったら他人や世間に展開しないものは「無」に等しい。晒す。
全ての即時換金を求めず、自分の施せることは喜んでやる。
何でも分かる！できる！手を付けるかは好奇心次第。
次のチームワーク編が最後です！実は最近はここが一番言いたいところだったのに最後になってしまいました。。また次の更新でお会いしましょう！
この記事が気に入ったらサポートをしてみませんか？