構造化プログラミングとゾルトラーク (T3:Pt0:Ch00)
テーマT1:Pt1で『システムづくりの人間学』の紹介を執筆中、構造化プログラミングに触れている短文に出くわし、それが引き金となってふわっと考えた他愛もないヨタ話です。
『葬送のフリーレン』を知らない・読んだことないという人にはごめんなさい。
構造化プログラミング
「構造化プログラミング」と言われても、聞いたことないよ(。´･ω･)？ とか、言葉は聞いたことあるけど何なのそれ(。´･ω･)？ という人のために、用語の説明から（といっても実は結構めんどくさい用語なので、かんたんに）。
用語のこと
日本語では「構造化プログラミング」という用語が浸透していますが、筆者は「構造化プログラミング？の“化”って何だ？」とずっとモヤモヤしていました。――気がします。
原語(英語)は "structured programming" で、「構造を持ったプログラムを書く」とも「プログラミングの仕方・過程(結果としての成果物)に構造が見て取れる」とも解釈できそう（英語学的に可能な解釈をつぶさに調べたわけではありません）。
その辺のモヤモヤはただ自分の受け止め方だけのことではなかったようなのですが、それは別の機会に（ありません）。
めんどくさくない程度に、概要
「構造化プログラミング」のよく知られている“定義”は、「連接(逐次)、選択(分岐)、反復 の限られた制御構文だけでプログラムを書こうぜ」というものです。
連接(逐次) は一続きの命令群
選択(分岐) は条件の値によって実行する命令群/経路を選ぶこと（if文の類）
反復(繰り返し、ループ) は同じ命令群/経路を繰り返し実行すること（while文, for文の類）
大昔のプログラミング言語には、制御の流れを指示/変更する構文がif文とgoto文しかない、コードブロックという概念(構文)がない、というものが多く、そうした言語では「条件が真の場合のコードはここからここまでだよ」とか「ここからここまでが反復だよ。反復はこの条件を満たす間続くよ」というのが見かけから判断しづらいプログラムになりがちでした。
goto文は単に指示されたジャンプ先に制御を移すだけなので、悪く言えば“行儀の悪い”コード（反復の途中にジャンプする、など）もたやすく書けてしまいますし、プログラム(手続きや関数)中の任意の箇所に制御を移せるせいでコードが読みづらく手を入れづらくなりやすい――「スパゲッティコード」(この言葉、今も生きてますね……)を作りやすいという問題がありました。
1960年代末の「gotoは止めよう」という提言を皮切りに、論争が巻き起こったりはしたらしいものの、（豊富な制御構文を具えた言語の普及に従って）「構造化プログラミング」が次第に普及していきました。
筆者がプログラマー修行を始めた頃には“浸透”していたと思います。ただ、当時の身の回りのプログラミング言語がすべて先述の制御構文を具えていたわけでもありません。研修で習ったCobolや、少し勉強したBasic (gw-basic系統)にはgoto文しかありませんでした。
Cobolに続いて研修を受けたCは、教科書からして「while, forを使いたまえ」と言っていましたし、講師の先輩にも「gotoは使わないように」と教わったような記憶もあります。
だから「ifとgotoしか制御構文がない言語」や「gotoを使うプログラミング」は知っていますが、仕事では専らCを使ったので、じきに「限られた制御構文だけ使うプログラミング」に慣れました。たまにその制御構文が窮屈に感じることはありましたが、「制御構文の枠組みを“行儀よく”守る中で、枠組みの制約から外れることをする」という考え方ができるようになっていきました。
（滅多にありませんが、特殊な条件の下ではgotoを使った方が考えやすい・書きやすい、ロジックがすっきりしたプログラムが書けることがあります）
ゾルトラーク
……というようなことを、『システムづくりの人間学』の構造化プログラミングの話題を読んで思い出してから、ふと、今アニメにもなっている人気漫画『葬送のフリーレン』に出てくる魔法・ゾルトラークにたとえられるんじゃないかな、と思ったのでした。
作中世界には千年以上生きるエルフや数百年は生きる魔族が登場します。そうした長命種の者にとって、ゾルトラークという魔法は80年前に開発された“比較的新しい魔法”です。
それを踏まえて、主人公フリーレンは弟子フェルンに向かってこんなことを言います。
「エルフにとっては比較的新しい魔法だから、どうしても一瞬、ほんの誤差のような時間だけれども思考する分だけ遅れが生じる」
「でもフェルンたちには、生まれたときからあって当たり前のもの。その身に刻まれていて当然の魔法使いの基礎だ」
“それ”がない時代には、プログラムのロジックを組み立てるのに苦労していたかも知れない（完全に想像）。こんがらがったコードもわりと簡単に生み出せてしまっていた。
“それ”が発明されて、プログラムを考えやすくなった（相対的・比較的）。どんどん普及して筆者たちの世代には“当たり前”になった。
もっと若い世代にとっては「そんなの当たり前」どころか「それを使わずにロジックを組み立てるなどできるのですか、フリーレン様」というくらいのものになっている（んだと思いたい）……
筆者より以前の「古い世代(もしかしたら筆者たちも含む？)」が“それ”を使うのに「どうしても一瞬、ほんの誤差のような時間だけれども」思考の手間が入るとは言いませんが。
（余談ですが、今やプログラミング言語はそのずっと先、“データやロジックをどれだけ抽象化できるか”みたいなところにまで行っているようです。プログラミング（を考える時）の労力や、関心事への集中という観点からも目覚ましい“進化”ですね）
念のため
ゾルトラークという“フィクションの中の魔法”（の作中世界での影響など）になぞらえてみる、というお話であって、「構造化プログラミングは“魔法”である」という主張ではありません。
オチ？
オチ？➀。
書いてから、「ゾルトラークに例えるならデザインパターンなのでは」という気もしてきましたが、プログラミングの歴史と『フリーレン』の世界の魔法の歴史が対応づけられるね、という話ではないのでセーフ。
オチ？②。
「構造化プログラミング」でググってみると、教育機関や初心者向け記事をはじめとして1,000万件近くヒット(2023年11月末現在)。
それだけ、基礎の基礎として「その身に刻んでおくべき」超重要概念、ということなんでしょう。
オチ？③。
読み返してみると「構造化プログラミング」という語句と「限られた制御構文だけ使うプログラミング」とをなんだか使い分けていますね（しかも「構造化プログラミング」は括弧に入れて使っている）。
自分の「モヤモヤ」が表れているようです。
蛇足。
「どのカテゴリにも属さない記事」を早くも書くことになるとは思っていませんでした……
参考
(2023-12-04 R001)
この記事が気に入ったらサポートをしてみませんか？