非エンジニアがプログラミングを学ぶメリット
プログラミングを学習しはじめて3ヶ月が経過しました。
今朝方、スクールで用意されている「模擬実践」的なカリキュラムをすべて終えたところです。内容は簡単なWebアプリのマークアップから、JSを用いた簡単な非同期処理などを自力でやってみる、といったものです。
いままでやってきたものを全て暗記・かつマスターしていてスラスラできる とは正直なところ言い難いです。
それでも、概ね理屈を理解していて、基本的な考え方や不明点の調べ方だとかエラーの見つけ方なんかを学んできたようなイメージです。
今日は非エンジニアがプログラミングを学ぶメリットについて考えたので書いていきます。
ロジカルシンキングが身に付く
コンピュータに指示を出すプログラミングにおいて、ロジックは絶対的な土台となります。
アプリに同じコードを書いたのに、あの人のiPhoneと私のiPhoneで違う動きをすることは基本的にはありません。（OSなど環境は同一と仮定しておきます）
アルゴリズムの三大要素
プログラミングはアルゴリズムを記述するもので、アルゴリズムの基本構造は「順次実行」「条件分岐」「繰り返し」の3つです。
よくある料理の例えで言えば以下のようになります。
順次実行
まず野菜を食べやすいサイズに切ります。
その後、油をひいたフライパンで炒めます。
これは「順次実行」ですね。野菜を炒めてから切ると違う結果になってしまいます。
条件分岐
肉を炒め、赤い部分がほとんど無くなったら火を止めます。
これが条件分岐です。これをプログラミング風に言うと以下のようになります。
処理が終了するまで、1秒に1回、肉の色をチェックする
肉の大部分が赤いならば、継続して炒める
肉の大部分が赤くなければ、火を止め、処理を終了する
繰り返し
たまねぎをみじん切りにします。
これが繰り返し処理です。もう少し詳しく書くと以下のようになります。
たまねぎを5mm角になるよう包丁を入れる
たまねぎ全体が5mm角になるように処理を継続する
全体が5mm角になったら、処理を終了する
ちなみに余談ですが、「ぶんぶんチョッパー」メソッドを使うと手順は簡略化可能です。
bunbun_chopper(onion)のようにたまねぎを引数として渡してやると上記の繰り返しとだいたい同様の結果が得られます。
三大要素を応用する
これらの三大要素を活用すると、とりわけ仕事において、非エンジニアの意思決定プロセス・他者とのディスカッションや協働において円滑に進めることができる場面があります。
たとえば以下のような感じ。条件分岐を示しながら深掘りを繰り返すことを順次実行するイメージです。
【検討】システム改修を行うかどうか、条件分岐を考えながら検討する。
【案1】改修をする場合
メリット（不具合が解消される）
デメリット（コストがかかる、他の仕事が少し後ろ倒しになる）
【案2】改修をしない場合
メリット（コストが浮く）
デメリット（不具合が放置される）
【案1-1】改修をし、不具合が解消されると仮定した場合
不具合改修によるコスト改善が、改修コストを超えられるか？
超えられると考える根拠は？
超えられないと考える根拠は？
超えられない理由を排除する方法は？
不具合改修により顧客へのサービス価値が上がるか？
……以下省略
このように条件分岐の考え方を軸にすると、〇〇の場合／そうでない場合…のように条件を分割しながら思考を進めていくことができます。
そんなもん、非エンジニアでも出来るわい！と思う方は、おそらくすでにこの考え方が身についているのでしょう。
人は多くの場合、自分の視点からしかモノが見えないので、「困っているんだから改修してほしい」とか、「コストが回収できないと思うからやらない」といった片方の意見（というか感情）で考えてしまいがちです。
そんなときに体系立てて議論を先に進めるには、ロジカルに考えていくことが大事になってくるでしょう。
いわゆるMECEに組み立てることが苦手な人にも、この考え方は取り入れやすいのでおすすめです。
合理的なトラブルシューティング力
ソフトウェア開発の大部分の時間はエラーと闘っている、といっても過言ではないかもしれません。
例えばA→B→Cという動きをしてほしい！と思って、それを実装すること自体は、検索すればすぐにやり方が見つかるでしょう。
しかし、エラー発生時はそうもいきません。
よくあるエラーであればエラーコードやメッセージでググれば解決するでしょうが、マイナーなエラーや汎用的すぎるエラーでは、自環境に適した対策がすぐに見つからないこともあります。
で、そこで重要になるのがトラブルシューティングの力でしょう。
トラブルシューティングの考え方には大きく2種類あると思っていて、ひとつが「ステップオン型」、もうひとつは「仮説検証型」とでも呼びましょう。
ステップオン型
たとえばLINEのようなチャットアプリを作るとして、「送信ボタンを押しても相手にメッセージが届かない」という問題があるとしましょう。
この時のトラブルシューティングとしては、ざっくり言うと「どこまでが上手くいっていて、どこで上手くいっていないか」を探すところから始まります。
メッセージはフォームに入力できているか
フォームは正しい宛先に内容を送信しているか
送信したリクエストにメッセージがきちんと含まれているか
送り先の相手やルーム情報がリクエストに含まれているか
ざっくり上記のようなイメージです。
つまり、最初から順を追って確認していきます。
時間はかかりますが確実に問題点を突き止めることができます（理論上は）。
仮説検証型
たとえば「カレーがおいしくない」という問題があったとします。
この問題は、ステップオン型の解決が難しいです。
野菜を炒めた時点では、おいしい
肉を炒めた時点では、おいしい
水を入れて煮込んだとき、おいしい
ルーを入れたら、おいしくない！
みたいに、途中まで上手くいっていたのに急にコケるわけではないからです。
そこで、この場合はまず仮説を立てて対策を試します。
野菜を切るサイズが小さすぎて全部溶けてしまっているから、大きめに切ろうか
肉に火が通りすぎて硬いから、もう少し軽めに炒めるようにしようか
そもそも水の量を計ってなくてシャバシャバだったかも。水はちゃんと測ろう
のように、いろいろな仮説を立てつつ、「次はこうしてみよう」と検証を重ねていきます。
問題に合わせたトラブルシュートを行う意識
さて、この2つの検証方法を把握しておくと、誤ったトラブルシュートに無駄な時間と労力を割かずに対応できる場合があります。
ルーを入れる前のカレーの味見をするといった無駄な工程を省ける感じです。
いきなり仮説検証は徒労に終わるケースも
例えば家のテレビの電源が入らなくなったときに、いきなり仮説検証で「中の配線が壊れているかもしれない！」といってサービスマンを読んだり、自分で分解（禁止ですけど）して直そうとするのは、徒労に終わる可能性が高いでしょう。
まずやるべきは「コンセントが刺さっているか確認」です。これはステップオン型検証の第一歩です。実際の家電系のコールセンターでも徹底してこれを案内していて、実際にこれで改善するケースもあるようです。
余談ですが、コールセンターのアドバイザーの案内が「コンセントが刺さっているか確認してください」だと、お客さんは「そんな初歩的なミスのはずがない」と言って対応してくれないことがあります。
そこでアドバイザーは「コンセントを一度抜いて刺し直してください」と言ったりします。すると、仮にお客さん側でコンセントが抜けていることに気づいたとしても「コンセントを刺し直したら電源が入った」と報告することができるので面子が保たれ、気持ちよく応対を終えられる
的な有名なハックがありますね。
なにも考えずステップオン型もよくない
例えば腹痛で病院に行ったとします。
腹痛に脂汗をかきながら腹痛の旨を伝えると、医者にこう言われます。
「腹痛ですか。では順番に確認しましょう…3日前に食べたものを全部言ってください…では2日前は…昨日は……なるほど……」
質問に答えながら、患者であるあなたはこう思うかも知れません。
「いや…なんかこう、痛みの種類からアタリをつけるとか、痛む位置を詳しく尋ねるとか、なんか検査するとか、いろいろあるやろ……!(脂汗)」
ここでは医者に期待されるムーブとしては「痛みの種類や強さ、位置などから大まかなアタリをつけていき、その仮説を証明しうる質問をしていく」という順序でしょう。
このように、ステップオン型と仮説検証型のどちらでスタートするかは案外重要で、どちらを使うべきかはよく考える必要があります。
幸い、プログラミングのエラー対応なんかは基本的にどっちも使います。
エラーメッセージをもとに仮説検証してみたり、どうにもならないとステップオンで対応してみたり。
逆に、自分が書いたわけではない大きなアプリなんかは、ステップオン型で動きを確認しながらでないと、仮説すら思い浮かばない。なんてこともあるでしょう。
このように、プログラミングをやっていると必然的に出会う「トラブルとの向き合い方」は、日常的な（非ITの）仕事でも役にたつ考え方です。
まとめ
プログラミングは、コードに関する知識を蓄えてカタカタ打つモノと思われがちですが、実は物事への向き合い方や考え方が鍛えられる側面が強いと思います。
プログラマにならなくても、プログラミングに触れることで現代社会でいろいろな仕事をするうえでも役立つ学びがたくさんあります。
ということで、プログラミングを3ヶ月勉強してきて感じた、「プログラマじゃない人がプログラミングを学んで感じたメリット」でした。
最後までお読みいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか？