研究論文 | 第2章理論と実施計画

理論

　可食化とは、何かしらの対象物を食べ物として表現することである。本研究において、この対象物とは「ソフトウェアプログラム」を意味するが、そのプログラムのどのような性質を食べ物に変換するというのか。つまり、可食化という手法で何を表現しようとしているのか、そのテーマを決めておかねばならない。

　今回、可食化の例題として取り扱うテーマは、以下の通りである。

プログラミング初学者が書くプログラムの良し悪し

　プログラミングを学び始めたばかりの学生たちを見て気付いたのだが、彼らには、識別子の名称（変数名・関数名）やインデント（字下げ）の扱いを蔑ろにする傾向がある。口頭で注意するに留まらず、倣うべき実例を示すことで悪癖を正してもらおうとするのだが、その指導の意図を伝えきれないことが多い。「言葉」で示されても、あまり見慣れていない「プログラム」で示されても、初学者は自分の習慣の悪さを認識できないようだ。ある一定以上の長さを持つプログラムを作成し、その後もたまに修正を加えるなどという経験をすると、識別子やインデントに気を付けるようになるかもしれないが、如何せん指導の負担が大きい。より直感的に「これは悪い習慣なのか!!」と痛感してもらえるような指導方法はないものか、と考えていた頃に、可食化の応用を思いついたのだ。初学者のプログラムの良し悪しを食べ物で表現して、直感的にその良し悪しを伝えようとするものである。

図2-1 従来のメトリクス結果提示の例

図2-2 可食化によるメトリクス結果提示の例

　なお、例題を採択した経緯は「はじめに - 三つの興味（教育に関すること）」に記してある。

プログラム

プログラムの性質と良し悪し
　そもそも「プログラムの良し悪し」とは何か。様々な文献から拾い集めてきた「良いプログラム」の例をここに示そう。

実行効率の良いプログラム　移植性（ポータビリティ）の良いプログラム　見通しの良いプログラム　使い勝手の良いプログラム　反応の良いプログラム　依存性が少なく良いプログラム　可読性の良いプログラム　保守性の高い良いプログラム　気持ちの良いプログラム　...

　本来は図2-2に示したように、良いプログラムは良いスパゲッティに、悪いプログラムは悪いスパゲッティに、という単純な対応付けを実現したかった。しかし、示した通り「良いプログラム」の意味も様々であるから、その良し悪しを単純に対応付けたり一概に議論したりすることはできない。それ故に、「プログラミング初学者が書くプログラムの」と断っておき、取り扱う領域（ドメイン）を限定しておいたのである。

　また、前項で漠然と「プログラミング初学者が書くプログラムの良し悪し」と述べたが、具体的には、プログラムのどのような性質に注目すれば、その良し悪しを判断できるだろうか。プログラムの性質（指標）の種類も、良し悪しの意味と同じように多様である。本研究の簡易調査で把握した指標について付録資料[1]を付しておくが、やはりその数は多い。
初学者プログラムのための指標
　さて、このような指標群を参考にしながら「初学者のプログラムに見られる特徴をよく表す指標」を探し出し、以下のようにまとめた。
- 関数あたりの行数
  　「構造化プログラミング」や「段階的詳細化」と言われるように、ある機能を実装する際に、その機能をより小さな機能の群によって実現するという考え方がある。具体的には、ある特定の関数内のプログラム行数が多くなり過ぎないように、いくつかの関数に分解することで、プログラムの可読性（読みやすさ）を高めることに相当しよう。しかし、彼ら初学者たちのプログラムは、全ての処理を一つの関数のみで記述していたりする。ものによっては一関数で千行を超える例も見受けられた。
- 識別子の名称の長さ
  　変数名や関数名などの識別子に適切な名前を用いておくと、後々にプログラムを見なおした時や、他人にプログラムを見てもらう際に、その内容の理解を助ける大切なヒントとなる。しかし、彼らのプログラムには不適切な名前が散見される。特に、極度に短い名称を用いる例は多く、そのプログラムを書き下ろした本人でさえも、その変数や関数の役割を説明できないほどである。
- インデントのずれ具合
  　インデント（字下げ）を付けることで、プログラムの構造を把握しやすくなるものだが、彼らは全体の構造を気にする余裕がなく、インデントに注意を払わないようだ。ただ、誰かに教示されて写した部分については、教示した者によるインデントが施されていたりする。結果的に彼らのプログラムは、インデントの施し方における一貫性の欠如（インデントのずれ）が見られるのだ。
- コメントの記述量
  　識別子の名称と同様にプログラムの理解を助けるものとしてコメントが挙げられよう。適切な名称の識別子を用いたプログラムであれば、コメントがなくとも理解に苦しむことはないだろうが、初学者向けのプログラミング演習科目ではコメントの記述を推奨している場合が多い。それらの科目に倣い、プログラムの理解を助ける保険的な意味合いを込めて、コメント記述量を取り扱うことにする。
　ここまで説明した四つの指標を用いて、初学者のプログラムの良し悪しを判定することにする。なお、誤解を招いてはならないので弁明しておくが、これらの悪い特徴が初学者全員に見られるわけではない。
スパゲッティプログラム
　序論でも何度か触れている通り、プログラムを「スパゲッティ」として写像することにしたのだが、その経緯に触れる。

　唐突だが「スパゲッティプログラム」という言葉を紹介したい。「構造化プログラミング」が盛んに叫ばれるよりも前、ソフトウェアは職人技（素人では簡単に為し得ない複雑なプログラミング）によって実現されていた。しかし、時代の流れとともにソフトウェア開発の規模も膨張し、職人技で記述されていたプログラムは、もはや手のつけようのないものと化していた。その「複雑極まりないプログラム」つまり保守性が著しく欠けたプログラムのことを「スパゲッティプログラム」と呼び習わすのである。

　さて、関連研究[1]では、ソフトウェアプログラムを「都市」というメタファで表現したが、それに代わる、さらに直感的なメタファはないものかと疑問を感じていた。「都市」から最初に連想したのは「道路」であったが、同じく建造物であり面白みに欠ける。少し飛躍を試みようとして、たまたまお腹を空かしていたことを理由に「食べ物」を連想。その日の午前中に購入した「納豆」を思い出したが、癖もあり、人によって好みが分かれるものでもあるから、より人気のあるものはないだろうか、と。そうして思い至ったのが「スパゲッティ」である。事前に「スパゲッティプログラム」という言葉を知っていたこともあり、この着想を得た瞬間に「これだ!!」と感じたのだった。

図2-3 「都市」から「スパゲッティ」への連想経緯

スパゲッティ

スパゲッティの世界

　スパゲッティの織り成す広大な世界をご存知だろうか。研究を開始した当初の私は、この単純な食材なら研究で取り扱うことも容易かろうと考えていたのだが、それは見当違いであった。歴史・地域性・製法・調理法など、この一節では語りきれないほど多彩な様相を見せてくれる食材なのである。本項では、その調査のほんの一部のみを垣間見ていただこう。（各項目は参考文献[3] [4] [5]に得たものである。）

歴史
　スパゲッティの起源には諸説があり、未だに明らかにされていないが、いずれの説も、とうもろこし粉や豆粉などを水で練って食料とする文化が存在したと説明している。最初は主婦・料理人による手作りに始まり、やがて職人が生まれ、人力の圧力機も登場。さらに産業革命とともに蒸気機関による製造自動化が実現され、さらに電動機に遷って全工程を自動化し、今に至る。
地域性
　イタリア国土は南北に伸びる形をしており、南北でその気候が異なるのだが、北イタリアの気候では原料のデュラム小麦を栽培できない。代わりに軟質小麦に卵を加える事で生地を作るため、南北でスパゲッティの特徴も異なってくる。（ただし、乾燥パスタが普及した現在はその限りではない。）また各地方の近隣諸国に影響を受けたソースがあり、そのソースと合わせたスパゲッティ料理自体やその名称にも地域性が見られる。
製法
　金属製の型に生地を押し込むことでスパゲッティを作り出すのだが、その金属の種類（ブロンズ製かテフロン製か）によってもスパゲッティの性質（表面の凹凸具合）が変化する。また、原料はデュラム小麦100%とし、色付けする場合には自然食品のみ用いることができる、とイタリアにおけるパスタの法律に記載されていたり。

　加えて、スパゲッティに関するアンケート調査や、ゆで時間や待ち時間に関する調理実験を行い、スパゲッティにまつわる知見を蓄積していった。また、研究を始めた頃から、機会を見つけては積極的にスパゲッティを食べるようにしていた。付録資料[2]に掲載する通り、店内で15種、他の調理済みのものを7種、自主調理を16種、計38種類を食し、さらに調理実験や研究室内での自炊も重なり、スパゲッティは私の主食になってしまった。もはや完全な蛇足だが、今ではお気に入りの銘柄（バリラ No.5）を5kg単位で購入するようになり、今日も研究室にてアル・デンテの悦びを噛み締めている。

図2-4 実験で24時間放置したスパゲッティ

図2-5 スパゲッティ・コレクション

図2-6 バリラ No.5 1.7mm（5kg）

スパゲッティの性質と良し悪し
　一言に表現する「スパゲッティ」だが、その姿が多様であるということをお分かりいただけたのではないだろうか。そして、プログラムについての議論と同じように、スパゲッティの良し悪しについてもまた様々な解釈があるものだ。コストパフォーマンスの良さ、保存性能の良さ、味の良さなどなど。スパゲッティに関する調査で洗い出した、それらの指標群（一部抜粋）を次に示そう。
- 品質（銘柄、材料、製造法、etc.）
- ゆで時間、作り置き時間
- 食感、コシ、歯応え、弾力感
- 太さ、長さ、形状
- 値段、料理名
- 風味、香り、味、塩加減
- もつれ具合
- 乾きやすさ（オリーブオイル量）
- ...

写像

　ここまで、本研究における論旨の構成要素であるプログラムとスパゲッティについて述べてきた。最後に、それらをどのように写像するか（対応付けるか）について述べ、また、写像を実現する仕組みについても説明し、序論 - メトリクスの新しい枠組みの提案で述べた主張の論拠を示す。

指標同士の対応付け

　上で示した「プログラムの性質」及び「スパゲッティの性質」の知見に基づき、それらの指標同士の対応付けについて以下の通り提案する。これにより、（初学者としての）良いプログラムは良いスパゲッティに、悪いプログラムは悪いスパゲッティに写像することができるはずである。

プログラムの指標	スパゲッティの指標
関数あたりの行数	作り置き時間
識別子の名称の長さ	スパゲッティ料理の名称
インデントのずれ具合	ゆで時間のばらつき
コメントの記述量	オリーブオイル量

関数あたりの行数 → 作り置き時間
　構造化を蔑ろにして一つの関数内に膨大なプログラムを記述することがあるのだが、この場合「関数あたりの行数」は大きくなる。そのような「悪いプログラム」の場合は、作り置き時間を長くし、水分が蒸発して乾燥した「悪いスパゲッティ」として表現する。ちょうど、「プログラムのまとまり」を「スパゲッティのまとまり」として上手く喩えられているはずである。逆に、適切に構造化されたプログラム、つまり「良いプログラム」の場合は、作り置き時間を短くし、できたての「良いスパゲッティ」として表現する。
識別子の名称の長さ → スパゲッティ料理の名称
　変数名や関数名の平均長を算出し、それを「識別子の名称の長さ」として扱う。その長さが極端に短いまたは長い「悪いプログラム」の場合、スパゲッティ料理の名称も極端に短くまたは長くし、「悪いスパゲッティ」として表現する。適切な長さの「良いプログラム」の場合、料理名も適切な長さの分かりやすいものにし、「良いスパゲッティ」として表現する。これは単なる名称であり、食感に対して直接影響を及ぼすものではないが、名称はその料理の印象を与える意味で重要な情報であり、間接的に食感への影響があると捉え、この指標を採用した。
インデントのずれ具合 → ゆで時間のばらつき
　インデントの付け方に一貫性がない「悪いプログラム」は、ゆでの浅い麺とゆで過ぎの麺とが混同したような、ゆで時間のばらつきがある「悪いスパゲッティ」として表現する。逆に一貫性がある「良いプログラム」は、ゆで時間も統一された「良いプログラム」として表現する。
コメントの記述量 → オリーブオイル量
　ゆで上げたスパゲッティを放置しておくと、水分が蒸発して乾燥してしまうが、その乾燥を防ぐためにバターやオリーブオイルを絡ませることがある。コメントが、プログラムに込められた意味を逃がさない（忘れない）ようにするための備忘録だと考えれば、水分を逃さないためのオリーブオイルに相当しよう。コメントがない場合は、オリーブオイルを一切使わないため水分の蒸発しやすいスパゲッティ、適度にコメントが記述されているプログラムの場合は、オリーブオイルを適量絡めたスパゲッティ、コメントが多すぎる場合は、プログラムを読む妨げになると考え、オリーブオイル漬けのスパゲッティとして表現する。また、オリーブオイル量という指標は、一つ目の指標「作り置き時間」に干渉するものである。多少作り置き時間が長くとも、オリーブオイルが絡まっておれば乾燥を遅らせることができてしまうのだ。ただ、プログラムの悪い点をコメントの記述によって補っていると捉えれば、むしろ都合の良い干渉なのかもしれない。（採用の成否は実験によって示すことにしよう。）

写像という構造

　次に、この対応付けを実現するための構造について述べる。

　ソフトウェアメトリクスの研究に取り組む身として、その長短を知っておくべきだろうと考え、既存のメトリクスツールを試用してみたことがある。具体的には、それぞれ図1-1や図1-2として示していた、「SourceMonitor」[6]及び「Eclipse Metrics plugin」[7]だが、いずれもソフトウェアプログラムを入力とし、数値やグラフを出力する「仕組み」だ。また、今回開発する可食化のためのメトリクスツールは、ソフトウェアプログラムを入力とし、スパゲッティを出力する「仕組み」である。

図2-7 SourceMonitorによる数値・グラフへの変換	図2-8 Eclipse Metrics pluginによる数値への変換
図2-9 今回開発するメトリクスツールによるスパゲッティへの変換

　先に示した既存の二例と同じようにして「可食化のツール」を開発するだけで良いのだが、果たして本当にそれで良いだろうか。何かあるものを入力として別のあるものを出力する構造、つまり、何かあるものを別のあるものに対応付けて写像する構造が、どの例にも見られるではないか。この構造を括り出して抽象化すれば、また別のメトリクスツールを開発する際の便（再利用性）を高められるはずである。ちなみにここでは、元のプログラムを「写像元」、メトリクスツールを「写像役」、スパゲッティを「写像先」と表現することにする。

図2-10 抽象化した「写像」の仕組み

　一度、抽象的な話に持ち込んでおきながら、また具体的な話に戻るようで恐縮だが、ソフトウェアプログラムをスパゲッティへ写像することについて、より詳細に表した図2-11を示す。前項（指標同士の対応付け）で示した四つの対応付けを参照しながら、図中の写像関係を見ていただきたい。

図2-11 スパゲッティへの写像（詳細）

　図2-9では、まるで一枚岩のような写像役であったが、それは前項で示した通り四つの対応付けに分解できる。また「関数あたりの行数」については、さらに三つの写像（「行数計測」「メソッド数計測」「÷」）に分解できることから、図2-11のように表現することができたのだ。さて、この図をまた抽象化してみると、図2-12のようになる。

図2-12 抽象化した写像の構造

　本研究で実現しようとしている「プログラムをスパゲッティに変換する」という行為が、ここで述べた抽象的な構造「写像」のみで構成できるという点をご理解いただけたであろう。次項では、この抽象化（汎化）により議論できる「大切なこと」について述べよう。

メトリクスグラフ
　図2-11を見ていると、ノード（写像元・写像役・写像先）とアーク（繋ぎ役）によって構成されるグラフであることに気付く。また、その繋ぎ役には方向性があり、かつ、特定二組のノード間を結ぶアークは複数存在し得ることから、これは多重有向グラフであり、今後これを「メトリクスグラフ」と呼び表すことにする。

　大切なことは、ノードやアークといった構成要素（小さな部品）のみによって、あらゆるメトリクスの写像関係を表現できるという構造にある。言い換えれば、その部品群をソフトウェアとして実装できさえすれば、あらゆるメトリクスツールを実現できるのだ。最後に、この「メトリクスグラフ」こそが、提案したい枠組みであるということをここに宣言し、以上を、序論 - メトリクスの新しい枠組みの提案で示した主張の論拠とする。

計画

　上述した理論を根拠として論旨の主張を行いたい。その主張のための計画を本項に示す。

評価実験による有効性の実証

　以下は、第一の論旨（「可食化」の提案）に関する実施計画である。

　写像 - 指標同士の対応付けで示した写像関係に従って、プログラムをスパゲッティとして可食化し、食べる行為を通して直感的な理解が得られるということを実証したい。実際には、被験者に試食及びアンケート評価実験を実施し、可視化と可食化の双方に対して「直感的な理解・認知」のしやすさを評価してもらう。その結果を統計的に分析し、直感的な情報表現として可食化が有効かどうかを判定する。この実験の詳細については、第4章実験をご参照いただきたい。

枠組みによるメトリクスツールの実現

　以下は、第二の論旨（メトリクスの新しい枠組みの提案）に関する実施計画である。

　理論で示した枠組み「メトリクスグラフ」を援用した新しいメトリクスツールを開発し、当初の主張である「あらゆるメトリクスツールを実現できる」ことを実証したい。まずは、メトリクスツールを開発するための計画として、その構成要素を明らかにし、それぞれの役割も簡単に述べておく。ここで説明し切らない詳細については、第3章道具と作成物をご参照いただきたい。

図2-13 メトリクスグラフの例

写像役（ノード）
　ある一定の規則に従って、入力を出力に変換するものである。数学的に言えばベクトル値関数（多入力・多出力を許す関数）に相当する。例えば、「3」と「4」を入力して「加算」という規則に従い「7」を出力するものは、この写像役にあたる。
写像元（ノード）
　写像役に「入力するもの」がこれに相当する。つまり、メトリクスの計測対象となるものである。例として、人体やソフトウェアプログラムなどが挙げられよう。
写像先（ノード）
　写像役から「出力されるもの」がこれに相当する。つまり、メトリクスの計測結果を意味するものである。例として、ログファイルやスパゲッティなどが挙げられよう。
繋ぎ役（アーク）
　上記三種類のノードを接続するためのものである。数学的概念で言えば関数の合成に似ている。具体的には、あるノードの出力値をあるノードの入力値として引き渡す役割を担う。