説明

ハマチって理解できる人はみただけで納得するのに理解できない人は意味不明なツールなんだろうなぁとおもう今日この頃。なので敢えて説明にチャレンジしてみましょう（笑）
まず、プログラムを作るときに一番無駄な時間とは？当然テスト＆デバッグ時間でしょう。という事は無駄を減らすにはここを減らす事が重要なんですね。
では自分や他の人のプログラムがちゃんと出来ていたとして、すべてのテストはそれで完全にクリアできるか？っていう問題。（まぁちゃんとの定義は難しいので単体としてはまともに動く状況って事で考えましょう）
事前に連携してテストしていない場合はこの段階であっちこっちを修正するんです。
”仕様変更”という名前のプログラムの修正が複数のプログラムへ影響を及ぼすのもよく知られた話ですね。
ここで重要なポイントは「単独のプログラムと連携している状態のプログラムの視点の違い」なんです。
何で複数のプログラムが連携する必要があるの？って言う事。
複数のプログラムがあって、複数の属性のユーザが居て、それらが連携している理由。そこにはプログラムを超えた”何か”が存在しています。それが業務フローではないかと考えたわけですね。
ある業務をするときにきっかけのユーザからそれを受けたユーザに情報がわたり最後のユーザが処理をすると・・・このためにプログラムはその処理を書いているわけです。
（実際の開発では業務フローを明らかにして、それに対して画面を作り、機能を設計していくという開発が実際には多いかなぁ）
開発していく時の作業の中で、業務フローと画面、画面と機能の間には連携が可能なのに対して、業務フローと機能は完全にユーザと画面により分断された状態になっています。
業務フローを表現するためにいくつかの機能をまたいで実装しているわけです。
これが”仕様変更”に弱い最大の原因だと考えたのです
実際の開発でも画面単体、機能単体の変更は大きな問題にならずに処理できているはず
この分断された業務フローを統合された状態に維持するために開発されたのがハマチ＆ブリです。