『【読書】オブジェクト指向でなぜつくるのか』

2010年03月22日 posted by ohno-satoru

【読書】オブジェクト指向でなぜつくるのか

テーマ：読書

お久しぶりです、大野悟です。
みなさんお元気でしょうか。

今回ご紹介するのは、ちょっとコンピューター屋さんっぽい本です。

コンピューターが苦手な方は本のタイトルを聞いただけで
読む気がなくなってしまうと思うのですが、今回お話ししたいのは
コンピューターの話ではありません。

オブジェクト指向でなぜつくるのか

この本は、オブジェクト指向と呼ばれる比較的現代的な設計方法についての本です。
なので、読者の層としてはプログラマーだったりＳＥ（システムエンジニア）だったりします。
そんな本を大野悟として紹介したくなったのは、実社会の問題としてすごくリンクする点が多かったからです。
もちろん、オブジェクト指向を知りたいコンピューター屋さんの方ははじめに呼んで欲しい本です。

でも、せっかくですから皆さんにも少しだけコンピュータのことと、
その歴史を知ってほしいと思います。

コンピューターというのは、「機械語」という言葉をしゃべります。
そして「機械語」という言葉しかしゃべってくれません。
さらにコンピューターは指示されたことしかやってくれません。
不具合が起きるのも指示が悪かったせいです（涙）

実際にはコンピューターはしゃべってくれるはずがないので、
理解するということをしゃべると表現しています。
僕たちコンピュータ屋さんは寂しがりですから擬人化するのかもしれませんニコニコ

名前の通り機械語というのは機械のための言葉なのでこんなことになります。

A10010
8B160210
01D0
A10410

適当に打ったんじゃないですよ！これでしか意味が通じないんです。

これではあまりにも人間が理解するのに大変なので人間がわかりやすい
言葉で書いてそれを機械語に翻訳しようということになります。
さっきも言ったとおりコンピューターは一切の融通が利かないので
人間側が折れてわざわざ翻訳するということになるわけです。

さっきの機械語をわかりやすくするとこうなります。

MOV AX, X
MOV DX, Y
ADD AX, DX
MOV Z, AX

それでも普通にみれば意味不明です。
でも、ＡＤＤとか追加するという英語も出てきて機械語よりはましになりました。
これが低級言語です。
別に卑しいという意味での低級ではなくて、機械に近い言葉という意味でそう呼ばれます。
逆に低級言語を使いこなせる人こそ、機械を限界まで使いこなせると言うことにもつながります。

それでも普通の人にはわかりにくくて仕方がありません。
そこでもっとわかりやすい言葉を書いて、機械語に変換しようとなるわけです。
（一度低級言語に変換してから、機械語に変換するのが普通ですにひひ

）
それが高級言語と呼ばれるものです。
さっきと同じことを高級言語に書いてみるとこうなります。

Z=X+Y

数学の式みたいになりましたね。
ＸとＹを足してＺに入れます（＝は同じという意味ではなくて、同じになるようにする、
つまり代入するという意味になります）
気分的には「Ｚ←X+Z」ということです。

こんな高級言語が開発されたのが１９５０年代の初めです。
高級言語という割に５０年以上生きていることになります。

それでもコンピューターを操る言葉は難しいと言うことで、当時は
世の中の情報処理のスピードにプログラマーの数が追いつかない状況になると
１９６０年代の終わりにはＮＡＴＯ（北大西洋条約機構）の国際会議で
「２０世紀末には世界の総人口がプログラマーになっても、
増大するソフトウエアの需要に追いつかない」という「ソフトウエア危機」が
宣言されたくらいです！

２０世紀が無事おわってよかったと思います。
こうなっていたら人間はコンピューターにお仕えする人生しか送れなくなってしまいます。
これをどうやって回避したのかというと、徹底的な効率化でした。

さて、今まで本の中で紹介されるコンピューターの歴史をわかりやすく紹介したのですが
遠くからこの流れをみていると経営に似ているような気がしてきませんか？

指示されたことをきちんとやる人　＝　現場の人
経営者からの指示を現場の人にわかりやすく伝える人　＝　責任者
やりたいことをきちんと伝える人　＝　経営者

もちろん、現場の人は機械とは違って融通が利きますから全く同じではありません。
機械は飽きもせず同じ作業をミスなくやることができますが、指示されたことしかしてくれませんから。

言いたかったのは、コンピューターが歴史としてたどってきたものの中には
実はビジネスでも生かせる考え方がたくさんあるんじゃないかってことです。
僕は本を読みながらそんなことを考えていましたにひひ

ソフトウエア危機を回避した効率化ってどういうものだったのかというと
簡単に言うとこんなことです。

多少非効率になったとしても後々見たの時にわかりにくいことをやめる。
同じようなことは再利用できるようにする。
部分部分で独立性を高めて分割できるようにする。
できるだけ省略できるようにする。

そう、ビジネスの世界でも同じようなことが行われてきています。
部署をわけたり、外注ができるようにしたり、やり方をマニュアル化（規格化）したり。

でも、これって既にビジネスの世界では当たり前になってない？と言われると
そうですよねーということになります。
つまり、この後が言いたいことな訳です。

独立して再利用が可能になった時に、どこに機能を凝縮させるかということです。

意味不明ですよね。僕も言っていて意味不明だと思いますあせる

わかりやすく説明していきますね。

これが僕の中のイメージです。
○の部分が再利用可能な部品で、それを線で繋ぐことによって１つの
プログラムというかシステムができあがっていると言うことです。

会社でもいろんな部署がつながりあって会社ができていますし、
部署の中でもいろんな人がつながりあって部署ができています。

ここで考えるのはどこに力を入れて作り上げるかということです。
要は全体として求められていることは同じなわけです。
どこでそれを支えるのか、実現するのかということになります。
つまり、○で解決するのか線で解決するのかということになります。

コンピューターの世界では○の部分が再利用可能な部品だったので
○でできる限り解決をした方が効率がいいことになります。
つまり、プログラムというものは部品を繋ぐ作業だけなら最高！という発想です。

じゃあ、ビジネスの世界だとどうなのかなぁって考えたときに、同じようにはならない
訳なんです。

大企業の発想方法で行くと、○であるサラリーマンは交換可能な部品として
線という会社だったり組織だったり特有のやり方を強くしていきます。
もちろん、○は高品質であった方がいいに違いはないのですが、
いざというときに交換可能であるように組織を作っていくわけです。

かといって、○がいなくていいわけではありません。
○がいなければ成り立たないので、交換可能な範囲でできる限り○を強くする。
これが大企業の基本的な発想方法です。

逆にコンピューターの世界のように○を強くしていくとどうなるのかというと、
人間の場合○の交換や再利用できるという特徴がなくなっていってしまいます。
なぜなら、コンピューターの世界では○は死んだり、いなくなったりすることがないからです。

そう、ビジネスの世界ではある程度の○であった方が組織として
構築するのには都合がいいのです。

じゃあ、○が死んだり、いなくなったりすることを考えなくしたらどうでしょうか。
コンピューターの世界のように線を強くすることよりも、○を強くした方が効率的です。
これは個人事業主だったり、町のお店のような中小企業にいえることです。
自分が死んだり、いなくなったりしたときはその時！として○がいなくなることを恐れない。
だからこそ○を強くできる訳です。

つまり、小さな会社をやるからには、大企業のような○を大きくできない制限
（交換可能であることを捨てられない）ではできない所までやり遂げないと
小さな会社の強みを実現できないってことです。

もちろん、○が最強になったとしても線を無視できるのかというとそんなことはありません。
今の世の中では○単体でできることは限られていますし、ヨーク見ると
○の中に同じ○と線でできた構造が隠れていることがほとんどだからです。

どちらの世界にもいえることは、○と線の強さのバランスを変えているということです。
○と線がなければ成り立たないのですから当たり前と言えば当たり前です。
ただ場合や状況に合わせて○と線の強さが変わっていると言うことがミソです。

この考え方は、ビジネスの世界に持ち込むと凄く面白いことがわかります。

例えばお客さんがケガをしたときにどのように対応するかという問題があったとします。

一番最悪なのは、対応が一切できないこと。
つまり、○でも線でもその対応能力がないことです。

逆に言うと対応すると言うことは、線として対応するか、○として対応するか、あるいは
○と線の両方で対応するかしか方法がないわけです。

線で対応すると言うことはどういうことかというと、マニュアル化することです。
事前に救急箱を用意しておく、搬送先の病院と連携をとるとかです。

じゃあ、○で対応すると言うことはどういうことかというと、人が走ると言うことです。
気がついた人が急いで薬局にって必要なものを調達するとか
自分の持っていた絆創膏をプレゼントするとかです。
もちろん実現するためには、○の人に自由な裁量がないとできません。
（それを支えるのは線の役割です）

両方の場合は、救急箱を用意しておいて○の人が急いで渡しに行くとかです。
薬局が遠くにしかなければ、○の人が解決できる範囲が狭くなっちゃいますから。

いずれの場合でもケガをしたお客さんとしては、問題は解決するわけです。
でも、お客さんの感じる気持ちはどうでしょうか。

ケガをすることが容易に想像できる場所で、対応策が用意されていなかったら
お客さんは怒るでしょう。線として行っておくべき対応がされていないってね。

では、突然の場合はどうでしょうか。
線で対応することだけを考えると、ケガのしそうな場所に救急箱を
おいておけばいいですよね。凄いなとは思いますが、かなり感謝の気持ちが
起きません（笑）

逆に○で対応する、つまりスタッフの人が走って買ってきてくれることの方が
ありがとうという気持ちになります。もちろん、○の人が対応できるだけの自由度を
線が提供することと、○が自ら動こうとしないと実現はしないですけどね。

実はお客さんからすれば、問題が同じように解決されたとしても、
どうやって解決されたのかの方が重要ってことです。

起業をしようとビジネスモデルを考えるときに、新しいことをしようとだけ
考えるのではなくて、新しい解決方法も一緒に考えた方がいいのと一緒です。

僕の中では、問題を組織（線）として解決した方がいいのか、それとも
組織に属する個人（○）として解決した方がいいのかとよく考えます。
お客さんが感じたことが全てですから。

話の方向が本の内容からだいぶ抽象的なところにずれてしまったので、
最後にプログラミングの最近のトレンドを紹介しようと思います。

それは、ＸＰ（エクストリーム・プログラミング）とよばれています。
和訳すると「究極なプログラミング」、「極端なプログラミング」となります。

このプログラム手法の中で定義されている４つの重要要素は以下の通りです。

コミュニケーション
シンプルさ
フィードバック
勇気

なんだこれ！と思った方、かなりいい感性をしています。
なぜなら今までの常識を覆すやり方だからです。

今までのプログラミング手法は管理側からの視点で行われてきました。
しかし、プログラマーの潜在能力を高めるには管理されているのでは無理と考え
現場側からの視点で発案された開発手法です。

このなかでも、好き勝手にはできないような線が１２個決められています。

計画ゲーム
小さなリリース
メタファー
シンプルデザイン
テスティング
リファクタリング（完成済みでも、随時、改善処置を行う。）
ペアプログラミング
共同所有権（全員が断り無く修正できるが、全ての責任を全員が担う。）
継続的インテグレーション（完成するたび、すぐに結合テストを行う）
週４０時間労働
オンサイト顧客
コーディング標準

このＸＰは○を重視して線の役割を小さくしたものです。
つまり、○の方が向いてる、画期的なシステムや小さなシステムに向いています。

このＸＰにはこんなルールもあるんですよ（笑）

「単体テストに成功したら鐘を鳴らして皆で喜べ」
「お菓子を食べながらプログラミングをしましょう」

納期重視というよりも、いいものが作りたい！という気持ちの表れな気がします。

ちなみに、ＸＰのような開発手法を総称してアジャイル開発と呼びます。
文章を作るよりも顔をつきあわせようぜ！というノリなので自社案件にはいいですけど
お客さんの依頼で作るものにＸＰを導入してうまくいくかは
参加する人の個性にかかってくるんでしょうねーショック！