シアトルで実践する「プログラミング的思考」[7] ～分解する（２）ソフトウェアの分解

分解する（１）のおさらい

分解する（１）責任で分ける、ではコンピュータシステム全体が物理的なハードウェアから、個々の問題を解決するアプリケーションまで「責任」を軸に分けられているようすを解説しました。

ハードウェア層、ドライバ層、そしてオペレーティングシステムの上で動くアプリケーションが、一般的なプログラミングの成果物です。問題によってはハードウェアを含めた全体を解決（ソリューション）として開発することもあります。コンピュータにつなげてペンとタブレットで絵を描くソリューションなどはそれに該当します。ここでは「ソフトウェアのみで構築されるソリューション」について解説します。次に問題とソリューションの分解についてみていきます。

ソフトウェア部品と責任の割り当て

ひとつの「人間の問題に対する解決（ソリューション）」には多くのソフトウェア部品が利用されます。それぞれの部品を「コンポーネント」と呼ぶこともありますし、別の呼び方があるかもしれません。どちらにしろ、特定の「責任」を担うソフトウェア部品をいくつも作成し、さらに既存のものを再利用し、それらを合わせてひとつの解決として構成します。

この考え方では、プログラムのどの部分がどんなことに責任を持つべきかを探ります。例えば「人が数値計算をする苦労を軽減するソリューション」として電卓アプリを作るとします。どんなソフトウェア部品に分解されるでしょうか。間違いなく「数の計算を担当する」ソフトウェア部品が必要になりますね。このプログラム部品は「正確に素早く計算する」という機能について責任を持ちます。ひとつの責任とそれを担当する「数の計算をするコンポーネント」が定まりました。

さらにこの計算機アプリは分数や平方根などを数式として表すことが出来るとしましょう。その場合、数式の編集機能に特化したコンポーネントが必要かもしれません。このソフトウェア部品は、数値演算は全くできなくても良いのです。それは上述の「数の計算をするコンポーネント」の責任です。数式編集の責任については「数式編集コンポーネント」を作ることのなりそうです。

ところで編集機能にはよくUndo機能(操作をしなかった状態に戻す)が付いているものが一般的で、ユーザもそれを期待しているでしょう。「数式編集コンポーネント」にも同様の機能があると良いですが、この場合数式編集コンポーネントがUndo機能にも責任を持つべきでしょうか？答えはノーです。この場合、Undo機能にのみ責任を持つ別に「Undo機能コンポーネント（サブコンポーネント）」を作り、「数式編集コンポーネント」が「Undo機能コンポーネント」を利用して数式編集でのUndo機能を実現します。

このようにしてソリューションを責任の境界線で分解して、その責任を負うコンポーネントを定める。それらを組む合わせて最終的にソリューションを完成させ、ユーザが数値計算をする苦労する問題を解決するのです。

分解の考えは必要か？

ところでこの分解の思考は、ソフトウェア開発で絶対に必要なのでしょうか？実は趣味レベルのプログラミング、そして初心者向けのプログラミング教室などでは、少なくとも始めの頃はさほど重要ではないかもしれません。プロのソフトウェアエンジニアも、試作品プログラムを作る際には分解してコンポーネントに分けることはあまり優先的には考えません（試作は提案中の解決が実現可能か、どのぐらい開発コストがかかるか、を探ることがその目的になります）。

ですが実際に稼働するソリューションを開発する場合は分解をします。まず1点目として、規模の大きいソフトウェア開発では、ひとりではなくチームで作業を進めていくのが一般的なので、全責任に応じて分解されていることは作業効率の点で望ましいのです。チームのメンバーがコンポーネント単位で開発を進め、完成に近いコンポーネントをお互い統合していく、というのが一般的な作業の流れです。

2点目として品質のために分解が必要になります。ソリューションの信頼性は、当然ながら個々のソフトウエア部品の品質に依存しています。複雑なソリューションであればあるほど、それを構成するコンポーネントの品質が重要になります。コンポーネントは全て一様に高い品質だとは限りません。コンポーネントによっては技術的に難しいものもあるでしょう。その際、全体の中で安定している部分を増やす（不安定な部分を減らしていく）ように開発していきます。

ソフトウェア開発が出来る人材は遅かれ早かれ、効果的に分解することが出来るスキルが求められるようになるでしょう。

Scratch や micro:bit などでプログラミング練習をする際にも「責任の定義」と「責任の割り当て」に着目することは「分解」の理解に役に立ちます。こういった小規模のシステムの場合は「関数」を「プログラム部品」として扱うのが良いでしょう。関数をひとつ作る度に「この関数は何に責任を持つのか？」自問すべきでしょう（チームで答えるとなお良しです）。

ベストプラクティス（最良慣行）として「ひとつの関数にひとつの責任」というものがあります。慣れないうちは「あれもこれも出来る関数」を作りがちですが、関数の再利用の仕方をしっかり習得しこのベストプラクティスのルールを守るようにすると、プロのように分解できるようになるでしょう。