ビジネススクールで受講した「テクノベート・シンキング」の学びを全12回でまとめるシリーズ、その2。
前回の第1回では、なぜIT畑にいる私がこの科目を取ったのか、という受講動機と、ICTの進化が自分の仕事にもたらす変化について書いた。今回は同じく第1回の事前課題として出された、もう一つの骨のある宿題について書く。Scratchでプログラムを作り、そのアルゴリズムをフローチャートに表すという課題だ。
結論から言うと──盛り込みすぎて、やりすぎた。でもそのおかげで、自分の中の「使えるスキル」と「足りないスキル」がくっきり見えた。その記録を残しておく。
事前課題：Scratchで対話型プログラムを作る
第1回の事前課題では、Scratchでプログラムを作ってフローチャートを描く課題があった。ざっくり言えば、ユーザーの入力に応じて適切な情報を返す対話型のプログラムだ。
普通に読めば、入力された文字列を条件分岐で判定して、対応する結果を表示する。それで要件は満たせる。素直に書けば、たぶん30行以下のシンプルなプログラムだ。
ところが私は、その「素直」を選ばなかった。
「教科書を全部やってから課題に取り組む」を選んだ結果
事前課題に取り組む前に、教科書『Scratchで学ぶプログラミングとアルゴリズムの基本 改訂第2版』を最初から最後まで全部やった。演習問題も含めて。
開発未経験だという自覚はあったから、まず基礎をきちんと固めたかった。シラバスにも初学者は教科書を含めて相当な予習時間が必要と書いてあって、これは丁寧にやらないとマズいやつだ、と判断した。
結果としてその選択は正しかった。Scratchの基本構文・変数・リスト・条件分岐・繰り返し・メッセージング・ブロック定義といったパーツが、自分の手の中で一通り使える状態になった。
ただ、それと引き換えに副作用があった。「全部のパーツが使える」ということは、「全部のパーツを使いたくなる」ということでもある。これが、後の”やりすぎ”につながっていく。
この「全部できるからこそ全部やりたくなる」という衝動は、開発未経験ならではのものだったかもしれない。経験者なら「要件に対して十分かどうか」で線を引けるのだろう。でも初めてプログラミングの世界に足を踏み入れた私にとっては、使えるようになったパーツが目の前にあると、それを組み合わせてみたくなる誘惑が強すぎた。まるでレゴを全部のパーツを使って組み立てたくなる子どものように。
要件以上に作り込んでしまった
最終的に私が作ったプログラムは、要件をはるかに超えるものになっていた。入力のバリエーションへの対応、視覚的な演出、ユーザーフィードバックの収集と集計──「これは事前課題なんだぞ」と自分にツッコミたくなるレベルで機能を盛り込んだ。
そして提出資料のフローチャートも、当然それに比例して膨らんだ。想定されていたであろうシンプルなフローチャートとは程遠い、複数ブロックに分かれた大作になってしまった。
……これは事前課題なのだ。
振り返ってみると、やりすぎた理由は明確だ。「要件を満たすために必要な最小構成は何か」という問いを立てずに、「教科書で学んだことを全部使ってみたい」という気持ちで動いていた。ビジネスの世界で言えば「スコープ管理ができていない」状態そのものだ。プロジェクトマネジメントでは口酸っぱく言われることなのに、自分が手を動かす側に回った瞬間にそれを忘れる。この体験は、かなり刺さった。
やりすぎたけど、ベーススキルはちゃんと活きた
とはいえ、やりすぎたなりに気づいたこともある。むしろこっちの気づきが大きかった。
長年インフラの設計・運用をしてきた経験で身についた「考え方の癖」が、Scratchというまったく違う世界でもちゃんと活きていたのだ。具体的にはこの3つ。
癖①：処理を部品化する（再利用性）
処理を全部ブロック定義として独立させた。同じ処理を何度も書かない、という発想は、インフラの構成管理やスクリプトを書くときの基本そのもので、無意識に手が動いた。
結果として、メインのフローはブロック呼び出しが並ぶだけのスッキリした構造になり、修正があってもそのブロック1つをいじれば済む状態になった。
これは「プログラミングを知っていたから」ではなく、「システム運用で培った”同じことを二度書くな”という感覚」がそのまま使えたということだ。技術の領域が変わっても、設計思想のレベルでは通用するものがある。この発見は自信になった。
癖②：状態を変数で持って初期化を徹底する（構造化）
状態はすべて変数として明示的に定義し、プログラム開始時に初期化処理を一発で走らせるようにした。
これは、運用設計で「冪等性」「再実行可能性」を意識する癖がそのまま出たやつだ。「同じ条件で何度動かしても同じ結果になる」状態を保つ、という考え方は、Scratchだろうがインフラだろうが共通だった。
冪等性なんて言葉、普通にプログラミングを学んだ人は最初には出会わないかもしれない。でもインフラ運用では当たり前の概念だ。自分のバックグラウンドが、まったく別の文脈で自然に使えた。これは「IT畑にいる人がプログラミングを学ぶ意味」を考えるうえで、とても重要な実感だった。
癖③：拡張ポイントをデータ側に寄せる
データの追加が必要になったとき、プログラム本体には手を入れず、リストの中身を増やすだけで対応できる構造にした。データをロジックから分離して外に出した形だ。
これも、設定をコードに埋め込まず外部ファイルやテーブルに逃がす、というインフラ設計の発想と同じ。要件変更に強い構造を作ろうとする手癖が出た。
この3つの癖に共通しているのは、「将来の変更・拡張を前提にして今の設計を組む」という思考のフレームだ。インフラの世界では当たり前のことが、プログラミングの世界でも同じように通用する。IT畑の人間がプログラミングを初めて学ぶとき、ゼロからのスタートではない。すでに持っているものがある。そのことに気づけたのは、教科書を全部やってから課題に取り組んだ「やりすぎ」の副産物だった。
でも、ロジックの組み立てはまだまだだと痛感した
一方で、強烈に思い知らされたこともある。「構造化する力」と「ロジックを組む力」は別物だった。
たとえば、ループ処理を組むとき、「インデックスの初期値を0にするか1にするか」「インクリメントを比較の前に置くか後に置くか」──こういう、まさにアルゴリズムの一番基礎の部分で何度も詰まった。頭の中ではなんとなく流れが見えているのに、それをScratchのブロックとして組み立てると、思った通りに動かない。
条件分岐の入れ子も同じだった。複数の条件を漏れなく・重複なく組み立てるのに、思ったより時間がかかった。ビジネススクールで散々鍛えたはずのMECEの感覚と、プログラムのロジックを組む感覚の間には、まだ翻訳のギャップがあった。
この「翻訳のギャップ」は、もう少し掘り下げる価値がある。MECEは「漏れなく・重複なく」整理するフレームワークだが、紙の上でMECEに整理するのと、プログラムの条件分岐としてMECEに実装するのとでは、求められる精度がまったく違う。紙の上では「なんとなくMECE」で通るが、プログラムは「完全にMECE」でないと動かない。この差は、実際に手を動かして初めて体感できるものだった。
そしてフローチャートに落とすときも、実装してから図にしている自分に気づいた。本来は逆で、フローチャートで論理を整理してから実装するのが筋なのだろう。でも手を動かすほうが楽しくて、先にプログラムを完成させてしまい、そこから逆算してフローチャートを書いていた。
これは「手を動かしながら考えるタイプ」の人に共通する罠かもしれない。特にインフラ畑の人間は、設計書よりも先に検証環境で手を動かす文化に慣れている。「まず動かして、動いたものを文書化する」という順序が体に染みついている。でもテクノベート・シンキングが求めているのは、その逆──「まず論理を設計し、それを実装する」という順序だ。この科目で一番鍛えなければならないのは、ここなのかもしれない。
学び：「構造化する力」と「ロジックを組む力」は別物だった
第1回の事前課題を通して、自分の中で一番大きかった気づきはここだ。
- 構造化する力：要素を切り分けて部品化し、再利用しやすい形に整理する力
- ロジックを組む力：処理の順序・条件・繰り返しを”動く形”で正確に組み立てる力
長年のIT実務で前者は鍛えられていた。けれど後者──実際にゼロから動くロジックを組み立てる力は、設計や運用の現場では思ったほど鍛えられていなかった。誰かが書いたコードや既存の仕組みを「読んで構造を理解する」のと、「自分でゼロから組む」のは違う。今までの仕事で前者は山ほどやってきたけれど、後者の経験はほとんどなかった。それを突きつけられた課題だった。
この2つの力の違いを、もう少し日常的な言葉で言い換えてみる。構造化する力は「本棚を整理する力」に近い。ジャンル分け、サイズ順、よく読む本を手前に──整理のルールを決めて配置する力だ。一方、ロジックを組む力は「レシピを書く力」に近い。「強火で3分」「焦げ目がついたら裏返す」──手順と判断基準を、誰がやっても同じ結果になるレベルで書き下す力だ。整理が得意な人がレシピを書けるとは限らない。でも両方できる人は、ものすごく強い。
テクノベート・シンキングという科目のねらいは「論理設計は人間が行う」ことだったはず。その「論理設計」のうち、構造側はいけそう、ロジック側は要練習。自分の現在地がはっきりしただけで、初回の課題は十分ペイしたと思っている。
次回：第2回はアルゴリズム基礎とTransition Diagram
第2回ではアルゴリズム基礎をさらに掘り下げつつ、新しい概念として「Transition Diagram（画面遷移図）」が登場する。業務システムの設計でもおなじみの発想だが、改めて学んでみてどう感じたかは次回書く。
今回参考にした書籍
事前課題に取り組むうえで、最初から最後まで通読したのがこちら。開発未経験の私でもつまずかずに進められた。
アルゴリズムそのものをもう少し体系的に学びたいなら、参考図書として案内されているこちらも候補。
そして、コース全体を通しての副読本として読み続けているのがこちら。経営目線でITをどう捉えるかの引き出しを増やすのに役立っている。
