オブジェクト思考?

NO IMAGE

オブジェクト指向といえば、何か難しい話なのでは…?と思わず距離を置きたくなってしまいますが、それほど考え込むようなことでもないのです。

あまり興味のない人にとって見れば、こんな話は何にも役に立たないかもしれませんが、一つの考え方として覚えておくことにこしたことはありません。意外とプログラミング以外の仕事で役に立つ場面があるかもしれません。

もう5年以上も前の話になりますが、プログラミングをかじっていたとき、このオブジェクト指向というものに出会いました。初めて、「オブジェクト指向」という名称を聞いた時、新しいプログラミング言語のことだと思ったのも今では懐かしいです。(あながち間違いではありませんが)

そもそも、オブジェクト指向なんなのか?ということですが、これは、システム開発を楽にするための技術です。もっと具体的に言うと、昔、書いたプログラムを再利用できるのです。

まったく同じ要件であれば、システムそのまま再利用してしまえばいいのですが、クライアントによって要件は千差万別で、すべての要件を満たした上で、まったく同じシステムをほしがる会社はありません。同じ業種だとしてもその会社ごとにやり方や考え方が異なります。経営理念が同じ会社だとしても、そこにいる人たちの指向性が違えば、おのずと要件も変わってくるのですから。

オブジェクト指向についての詳しい説明は、「オブジェクト指向」でググってもらえばいくらでも出てくるので、ここでは省きます。

今回、タイトルにわざわざ「オブジェクト思考」と銘打ったのは、この考え方が、一般の業務でもかなり役に立つ考え方だからです。

オブジェクト指向で開発を進めるときにまずはじめにやることは、業務分析です。今行っている業務を基本的な動作にまで落とし込んで、考えていきます。

たとえば、おいしいご飯を炊ける炊飯ジャーの制御システムを作るとします。

おいしいご飯の炊き方は、「はじめチョロチョロ、中パッパ、赤子泣いてもふた取るな」という原則が存在しており、その原則に従って考えてみると、

  1. 弱火で加熱する(はじめチョロチョロ)
  2. 強火で加熱する(中パッパ)
  3. 蒸らす(赤子泣いてもふた取るな)

といった一連の動作が見えてきます。電子炊飯器などといった便利なものがなかった時代、みんなカマドでご飯を炊いていたんです。

今の電子炊飯器には、この原則が組み込まれているわけですが、これも「ご飯をおいしくたく」という一連の動作を分析した結果、プログラムが書けるようになるわけです。

ここからもわかるように、業務分析のポイントは、全体を把握してから部分を切り出していくところにあります。プロセスだけを把握するわけです。

プログラムの分野だけに限らず、この手法は、さまざまなところで応用が利ききます。

たとえば、おいしい料理とまずい料理の違いを見るときや、儲かる会社と儲からない会社の違いを見るとき、成功する人と失敗する人の違いや、モテるひととモテない人の違いなどなど…人が行ういかなることも、プロセスを見ていくと、たいていのことは分かってしまうものです。

結果が芳しくない時、必ずプロセスのどこかに問題が潜んでいることは明らかですが、それをうまく把握するためには、こうした分析手法はとても役に立ちます。逆に、良好な結果のプロセスを分析し、クラス化しておけば、似たような結果が求められるケースの場合にそのクラスをそのまま再利用できるわけです。

たとえば、先ほどの電子炊飯器の例を使って、今度は、パンを焼いてみます。

  1. パン生地を炊飯器に入れる
  2. 常温で1次発酵させる
  3. 温めて2次発酵(“蒸らす”を再利用)
  4. 取り出しガスを抜く
  5. パン生地を炊飯器に入れ焼く(“強火で加熱する”を再利用)

だいたいこんな感じでしょうか、さっきご飯を炊くときに使った部分が2つも再利用できました。

ちなみに、電子炊飯器でパンを焼く方法については、以前テレビでも紹介していましたので、本気でパンを焼きたい人はググってください。

同じように、ケーキも焼けますし、カステラだって作れます。結果は違いますが、プロセスは部分的に再利用可能なところがいくつもあります。

こういう思考法を持っていると、答えを導くまでのスピードが全然違います。特に、求められる答えが人によって違うようなケース(コンサルティングなど)の場合は、恐ろしく力を発揮します。

システム開発だけに使っているのはもったいないぐらいすばらしい概念なので、これこそ、ほかの分野で再利用すべきだということです。