エンジニア必須スキル : 物事を抽象化・概念化する

Java なんかで「抽象クラス」とか出てきたりするアレ。抽象化するってのは、異なるもの同士の中から共通する要素を抜き出して概念化する行為だ。

Cat クラスと Dog クラスの抽象クラスを作るなら Animal クラス、というように、猫も犬もまとめて表現するなら「動物」といえるから、Animal クラスを作り、「鳴く」とか「聞く」とかいう行為を抽象メソッドとして宣言するのだ。猫なら「ニャー」だし、犬なら「ワン」。鳴き方は違えど、鳴くという行為自体は同じ。抽象化とはそういうこと。

同じように、技術的な知識も概念を意識して覚えたり、上司からの指示や顧客要件も概念的な部分を取り違えないようにすることが大事だ。そうすれば、適切なメソッド分割ができるようになるし、顧客要望を字面どおり実現するだけではなく、こちらからより簡単でやりやすいソリューションを提案できたりするようになる。

どうしてそうなれるのかというと、概念化したり抽象化したりするということは、「要するにそれはどういうことか」をまとめる作業であり、このスキルが身につけば全体を俯瞰する力が付くからだ。

「メソッド」という単語を「処理を書くところ」ぐらいにしか認識しないままだと、どんな処理も1ヶ所に書いてしまう。そうではなく、method という英単語の語源にまで遡って、メソッドという単語が指し示す概念を整理してみる。

メソッドの語源はギリシャ語で、「道筋に沿って行くこと」らしい。英単語の意味としては「方法」とか「順序」とかいうらしい。ぼんやりとメソッドという言葉の意味が湧いてきたと思う。なにやら規則正しく順序立てて進めるっぽい雰囲気だ。この「概念」を漠然と持つことが大事だ。

そうすると、より相応しい日本語訳に気が付く。「手続き」だ。メソッドは「手続き」のことであり、「手続き」を書くところだ。

そして、前回少し用語として挙げた「単一責務の原則」を思い起こすと、一連の手続きは一つのことしかやらせないようにするのが、正しいメソッドの分割方法だと気付く。

では手続きをどう分けていくか。

例えばファイルを読み書きする一連の処理を考える。

「ファイルの存在を確認し、ファイルがあればそのファイルを開き、1行ずつテキストを取り出し、指定の単語が見付かったら別の単語に置換し、元のファイル名の末尾に「replaced」と付けて保存する。」

例えばこんなことをしたいとして、何をどう分割していくかと考える。

こんな時は「要するに？」を考える。要するに何をしたいのか、一言で説明できる範囲が、メソッドの分割単位になるだろう。

だから、「要するにファイルがあるか知りたい」であり、「ファイルを開きたい」だ。「要するに行ごとにテキストを取り出したい」のだし、「要するにテキストの中から指定の文字列を探したい」のだ。

こうして考えていくと、「要するに」で表現した一つひとつの処理は、手前の処理に依存しないようにメソッド分割できることが分かるであろう。メソッドの宣言部分だけ書くとしたら、こんな風にできる。

boolean isExists(String fileName)
File openFile(String fileName)
String[] readLines(File file)
boolean findString(String target, String pattern)
String replaceString(String target, String pattern, String replace)

いきなり Replace できるのでは…とかいう指摘もあるとは思うが、ひとまず考え方として。こうやって分割したメソッドたちをどういう順番で、どういう条件の時に呼ぶかを、Main メソッドに書いてあげればいい。

「要するに」を突き詰めていくと、物事をより単純化して見られるようになるので、単純化して組み合わせを考えていき、細かな手続きは各メソッド内に隠蔽してしまえば、可読性の高いコードになると思う。

人の話を聞く時も、概念化や抽象化が大事だ。

こういう画面が欲しくてこういう機能が欲しくて、という顧客要望も、「要するにどうしたいのか・どうなりたいのか」を引き出すようにヒアリングしていくと、実は全く違う、ファイル取り込みと集計結果の表示機能だけ作ってあげれば十分だった、というような、全く違うけどより効果的なソリューションを提案できる。そしてそれは往々にして、字面どおり言われたことをするだけの時より楽だったりする。

ある書類を作るよう言われた時も、「この資料を使って上司は何がしたいのか」、「要するに何のための資料なのか」を自分でよくよく考えると、変えてはいけない部分、省略して良いこと、情報のまとめ方や粒度が的確に判断できるようになる。もしかしたら上司の指示の抜け漏れに気が付けるかもしれないし、これもまた違うやり方で楽に結果を出せるようになるかもしれない。

相手の話を抽象化して概念的な部分を捉えようとすることは、回り回って自分が楽になることばかりであるし、その方がただ相手の言うことを字面どおり受け取るよりも、相手のためになる結果を生むのだ。

勿論、プログラムは白黒ハッキリ付けていくものだから、細部は正確に把握すべきだが、「要するにどういうことを実現したいのか」といった上位概念を頭から離してはいけない。