ビジネススクールで受講した「テクノベート・シンキング」の学びを全12回でまとめるシリーズ、その3。
前回はScratchで対話型プログラムを作った話を書いた。今回は第2回の授業内容から、もう少し踏み込んだプログラミングの話と、ICTの基礎知識について書く。
条件分岐の次に来るもの──「リスト」と「ループ」
第2回の事前課題は、ユーザーからの入力を受け取り、リスト（配列）に格納して処理するプログラムを作るというものだった。
前回の課題が「入力に応じて分岐する」プログラムだったのに対して、今回は「リスト」と「ループ」が主役。配列にデータを貯めて、それを順番に処理する──プログラミングのもっとも基本的な構造を体験する課題だ。
条件分岐だけのプログラムは「今、目の前の1つの入力をどう処理するか」しか扱えない。でもリストとループが加わった瞬間、「複数のデータを貯めて、まとめて処理する」ことが可能になる。この飛躍は小さいようでいて、プログラミングの可能性を根本から変えるものだった。
「ユーザーの入力は信用しない」──IT畑の鉄則が自然に出た
課題の要件自体はシンプルだった。しかし、いざ作り始めると「入力をそのまま受け取って格納する」だけでは気持ちが悪かった。普段の仕事で「ユーザーの入力は信用しない」という原則を嫌というほど叩き込まれてきたからだ。
結果、要件以上の機能を入れてしまった。重複入力のチェック、マスターデータとの照合による既知・未知の判定、例外データの別管理──課題で求められていたわけではないが、自然に手が動いた。
入力バリデーションとは「分類して、検証して、例外を処理する」こと
入力バリデーションの本質は、入力をそのまま受け入れるのではなく、分類し、検証し、例外を適切に処理するという一連の設計思想だ。
インフラの運用設計では、これが日常だ。監視システムのパラメータ入力、構成管理ツールの設定値、デプロイスクリプトの引数──どの場面でも「入力値を信用せず、必ず検証してから処理に進む」という原則が徹底されている。
たとえば、同じデータの二重登録を弾く処理は、サーバー管理で「同じホスト名を二重に登録しない」制約と同じだ。マスターデータと照合して既知・未知を振り分ける処理は、「許可リストに載っていないIPアドレスの通信をどう扱うか」という設計と本質的に同じ。Scratchというシンプルな環境でも、こうした実務の設計思想がそのまま使えることに驚いた。
「5回聞いて終わり」と「有効回答が5つになったら終わり」の違い
バリデーションを入れることで、ループの設計が根本的に変わる。
バリデーションなしなら「5回聞いて5回記録して終わり」で済む。しかしバリデーションありだと、無効な入力（重複など）が来たらカウンターを進めずにもう一度聞き直す必要がある。つまり、「5回聞いて終わり」ではなく「有効回答が5つになったら終わり」。些細な違いに見えるが、ループの終了条件がまったく変わる。
この発想の転換は、実務でも頻繁に出会う。バッチ処理で「100件処理したら終わり」と「100件正常に処理したら終わり」では、エラーハンドリングの設計がまるで違う。Scratchの課題でこの感覚を掴めたのは、想定以上の収穫だった。
フローチャートで「複雑さ」が可視化される
作ったプログラムのフローチャートを描いてみて、改めて驚いたのは分岐の深さだった。
メインのループの中に、まず重複チェックの分岐がある。さらにその後にマスターデータとの照合の分岐がある。つまり、ループの中に分岐が2段ネストしている。さらにループの外にも別の条件分岐とループがある。フローチャートは横にも縦にも広がって、A4用紙では1枚に収まらなかった。
前回の課題では「実装してからフローチャートに落としている自分」を反省した。今回は意識的に先にフローチャートを描いてから実装する順序を守ってみた。結果、ループの設計でハマる時間が大幅に減った。フローチャートの段階で「ここの分岐、漏れてるな」と気づけるからだ。
この経験で実感したのは、条件が1つ増えるだけで、フローチャートの複雑さが一気に上がるということ。「ちゃんと動くプログラム」と「想定外に耐えるプログラム」の間にある距離感を、ビジュアルプログラミングという簡易的な環境で体感できた。逆に言えば、バリデーションを入れないプログラムがどれだけ脆いかを想像できるようになったのは、この課題の大きな収穫だった。
「関心の分離」──データの役割が違えば、置き場所も分ける
今回のプログラムでは、複数のリストを役割ごとに分けて管理した。マスターデータ、ユーザー入力データ、例外データをそれぞれ独立したリストに持つ構造だ。
なぜこうしたかというと、「データの役割が違うものは、別の場所に持つ」という考え方が自然に出たからだ。インフラ設計で言う「関心の分離（Separation of Concerns）」と同じ発想で、マスターデータと入力データと例外データをそれぞれ独立させた。
こうしておくと、たとえばマスターデータを拡張したいときも、データの中身を追加するだけでプログラム本体には手を入れなくて済む。前回の課題で「拡張ポイントをデータ側に寄せる」癖がついていたので、今回もその構造が自然に出た。
これは実務における設計原則そのものだ。マスターテーブルとトランザクションテーブルを分ける、正常系のログと異常系のログを分ける──規模は違えど、考え方の根っこは同じ。「シンプルな環境で自然に出る設計癖は、実務で身についた設計原則の反映」だと気づけたのは面白かった。
第2回で学んだICT関連知識の基礎
第2回ではプログラミング課題に加えて、授業の中でICT関連技術の基礎──システムアーキテクチャやネットワークの考え方も扱われた。
ここはインフラが専門の私にとっては馴染みのある領域だった。ただ、それをビジネスの文脈で語り直す、というのが新鮮だった。
技術者の「当たり前」をビジネスの言葉にする難しさ
たとえば、サーバーとクライアントの関係、クラウドとオンプレミスの違い──こういった話は日常業務で当たり前のように使っているけれど、「なぜその構成を選ぶのか」をビジネス判断として説明する訓練はあまりしてこなかった。
具体的に困る場面は3つある。
1つ目は、クラウドとオンプレミスの選定理由を問われたとき。技術者同士なら「スケーラビリティが」「可用性が」で通じる。でも経営層に対しては「なぜ初期投資を抑えてランニングコストに切り替えるのか」「データの所在が法的にどう影響するか」というビジネスの言葉に翻訳しなければ伝わらない。
2つ目は、セキュリティ対策のコストを正当化するとき。「ファイアウォールを入れましょう」「多要素認証にしましょう」──それ自体は正しいが、経営層が知りたいのは「それをやらなかった場合のビジネスリスクはいくらか」であって、技術の仕組みではない。リスクを金額で語れないと、セキュリティ投資の優先順位が上がらない。
3つ目は、システム障害の影響を説明するとき。「DNS障害でサービスが全面停止」と報告しても、経営層には「DNSが何か」から説明が要る。「電話帳が壊れたので全社員が電話をかけられなくなった」くらいまで翻訳して初めて伝わる。
授業では、まさにこういった「技術とビジネスの翻訳」を意識したディスカッションが行われた。技術を知らない受講生が「なぜクラウドを選ぶのか」を自分の言葉で語ろうとする姿を見て、私は逆に「技術を知っているがゆえにビジネス言語への翻訳をサボってきた自分」に気づかされた。
この科目でICT基礎を改めて学ぶ意味は、技術を知らない人に技術の判断を説明できるようになることだと実感した回だった。知識としては知っていることでも、「説明できる」と「理解している」の間にはかなりの距離がある。
条件分岐→リスト+ループ→データ処理──積み上がる基礎部品
第2回の課題を通じて強く感じたのは、プログラミングの基礎部品が一つ増えるだけで、できることの幅が劇的に変わるということだ。
前回は条件分岐だけだった。「もしAならB、そうでなければC」──処理を分けることはできるが、扱えるデータは1つだけ。今回はそこにリストとループが加わって、「複数のデータを貯めて、まとめて処理する」ことができるようになった。
この延長線上にあるのが、データの照合であり、重複排除であり、例外処理だ。マスターデータとの照合は「データベース検索」の原型だし、重複チェックは「一意性制約」の原型。例外データの別管理は「例外処理」の原型。ビジュアルプログラミングで作った小さなプログラムだが、やっていることの本質は、実際の業務システムで日常的に行われている処理と同じだった。
振り返ると、ここでの経験が第3回以降のソートアルゴリズムやリコメンド設計に直接つながっていく。リストの中身を並べ替える（ソート）、リストの中から条件に合うものを選ぶ（フィルタリング）、複数のリストを突き合わせる（結合）──これらはすべて、今回のリスト操作の延長線上にある。
そしてもう一つ。入力バリデーションという「当たり前」がプログラミング初学者にとっては「当たり前ではない」ことを知れたのも大きかった。IT畑にいると、入力値を検証するのは空気を吸うように自然なことだ。でも授業で他の受講生の課題を見ると、バリデーションなしでも十分に動くプログラムを作っている人が多かった。「動く」と「堅牢に動く」の差を意識するかどうかは、経験から来る。逆に言えば、その経験がない人に対して「なぜバリデーションが必要か」を説明できるようになることが、技術者としてのコミュニケーション力だと感じた。
次回：Transition Diagram──画面遷移図でUXの構造問題を可視化する
同じく第2回の後半で学んだのが「Transition Diagram（画面遷移図）」。サービスの画面遷移を整理する課題だったが、やってみたら予想以上に深い分析になった。次回はその話を書く。