第24回「思考を変えろ！！さらばコメントアウト」
更新日：
こんにちは、森川です。
時間がないとはいえども月1回は更新しとかんと。
余談
この自社サイトは、私の実験台サイト、兼学習用サイトである。
サイトのデザインも9割は自分でやってほとんどデザイナーに作らせていないし、こうやってブログを書いたりしてSEOなどの実験台にしている。
時間はかかるけど、ほぼ全部一人でやっている。
だから見苦しいところはあると思うけど、自社サイトだから別にそれでいいと思っているし、そうやっていろいろ実験してノウハウ蓄積の場にしているからクライアントさんにも中身のある話ができるわけ。
うちは、ホームページ経由で不必要な営業の勧誘も含め、問い合わせがちょこちょこいただいている。
というのもこのサイトはページ数が結構あるのよ。
今日（2018年6月）現在のインデックスされているページ数は約150近くあり、それはこれまで何年にもわたってコツコツとやってきた我々の努力の証であり、大切な財産になっている。
ページ数もそうだけどコンテンツの内容も簡単にはマネできないと自負している。
そのおかげもあってワードによっては検索かなり上位に表示されているから、いらない営業の問い合わせがそこそこ来るのだと思う（笑）。
昔、どこかのWEB制作会社の人が話していたけど、SNSは一時的にアクセス数を増やすのに役立つ、でもSNS経由の成約率ってかなり低いし、サイトの価値の向上にはつながらない。
ベースになるのはブログ。
少しずつでもいいからブログを書いて読者にとって価値のあるコンテンツを蓄積してサイト価値を向上させる。
それをSNSを使って広めていくのが基本路線。
サイト運営で大切なことはその日々の努力ですと言っていた。
そのような話、いろいろ実験してなんかわかる気がする。
つぶやくのは簡単だけどブログの文書を一つ作るのはそんなに簡単じゃない。
Googleがそういう努力を検索順位で評価しようとしているのは非常に納得できるし、至極当然のことだと思う。
ということで、今日もコツコツがんばって書きます！！
はじめに
今回はシステムの話でオブジェクト指向の続き。
OO（オーオー）を理解するにはプログラムの考え方について根本的に変えないといけない。
前回は、「思考を変えろ！！数学的から国語的思考へ」というお題で書いた。
今回は、思考を変えろシリーズ第2弾
「思考を変えろ！！さらばコメントアウト」というお題で書いていきたい。
まず読者の方に質問です。
1. あなたの作ったシステムに機能修正が入ります。あなたはどうやって修正しますか？？
2. あなたの作ったシステムに機能追加が入ります。あなたはどうやって追加しますか？？
■Aさん
今更何を言っているのですか？？修正部分をコメントアウトして書き換えますよ。
機能追加するのであれば既存のクラスに機能追加用のメソッドを追加しますよ。
■答え
オブジェクト指向（以下OO（オーオー）と略す）を理解したいのであれば、この考え方はすべて捨ててください。
前提条件1
システム屋ならこの感覚は理解できるはず、
「どんな汚いコードでも支障なく動いているシステムには、手を加えたくない」
ＯＯ（オーオー）の考え方のベースにあるのは、この感覚です。
きちんと動いているプログラムにはなるべくコメントアウトして修正をしたくないのです。
きちんと動いているクラスにメソッドを追加したくないのです。
既存のコードに手を入れるということは、そこにバグが生まれる危険性が生じる、だからなるべく既存のコードはそのままにしておきたいという考え方です。
前提条件その2
システム屋ならこの感覚は理解できるはず、
「他人が作ったシステムには、手を加えたくない」
我々のような会社には、他の会社が作ったのだけど、その会社がなくなったので管理してくれないかというような話はよくある。
そのような他人が作ったプログラムを改修するときに、特定の箇所をコメントアウトして書き換える。
そうすると修正した場所以外へ影響及ぼし、「他のとこが変になってますけど」と怒られることがある。
「すいません」って謝るけど、自分が作ったわけではないから知らないしと心の中では舌打ちする。
「作った人しか修正・追加できようなシステムを作ったらだめなんです」
一般的に大規模なシステムになればなるほどオブジェクト指向で設計したシステム構築が必要になると言われる。
それは、上記のことが理由よね。
開発費が何億もするような大規模システムを数年で入れ替えるなんてありえないよね。
機能の改修追加を繰り返しながら少なくても10年以上は運用してことになる。
そのような運用していく中でコードがどんどんぐちゃぐちゃになってバグが発生しましたってなると大事よ。
例えば
改修時のバグが原因で請求金額が「たった0.1%」狂いました。
1,000憶の売り上げを扱う大規模システムであれば0.1%でも1憶だからね。
そしてそこに関係している人件費なんかを考えると相当な損失になる。
「すいませんでした。直ちに修正します」
ではすまされる話ではなくなる。
また、10年以上運用していくシステムを構築当時の人がずっと担当するなんてありえない。
担当者が退社することもあるし部署移動だってあるよね。
また大規模になればなるほどシステムの全体像を一人で把握できなくなってくる。
作った人がいないのでわかりませんや担当者以外が改修したからバグがでました、なんて言い訳にはならない。
上記のように大規模システムになればなるほど一つのリスクが会社にとっての致命傷になりかねない。
ＯＯ（オーオー）の設計方法は、こういうリスキーな状態を作らないようにするための設計方法である。
逆に、小規模なシステムで一時的にしか使わないようなシステムであればわざわざこんなことは考える必要はない。
例えば、
VBAでツールのような一時的に使う便利ツールを作るとする。
このような一次しのぎのためのシステムにはわざわざOO（オーオー）なんて考えるのはあまり意味がない。
まとめ
ＯＯ（オーオー）の思考方法は、「システム運用の視点」からプログラムを見ている。
運用するときにどのようにしておけば、バグが発生するリスクが低いのか。
運用するときにどのようにしておけば、改修しやすいのか。
構造化プログラミングは、この考え方は入っていないのよ。
構造化プログラミングはどちらかというと「システム構築の視点」からプログラムを見ている。
ＯＯ（オーオー）と構造化プログラミングでは視点がぜんぜん違うのよ。
こういうことを知らずにGOFに取り組むと、なんでこんな設計にするのか意味が分からないと思ってしまう。
なんでこんなめんどくさいことをするのだろうと。
以前のブログでこのジャンルは、プロのシステム屋にしか立ち入れない領域と書いたけど、それはこれが理由です。
システム運用の経験が豊富にあるのは我々のようなプロのシステム屋のみである。
運用経験がない人に「運用の視点から考えろ！」と言っても非常に難しい話なのである。
では具体的にどのように設計していくのかは、ごめん、次回もっと掘り下げて書くね。
今回は、概要のみでお許しをmOｍ
ではでは。