首都圏に約20店舗を展開するスーパーマーケットの基幹システムをリプレース（交換）するという大規模プロジェクトに参加した屋敷(やす)。17年というキャリアに加え、高い技術力とリーダーシップを兼ね備える屋敷は、開発リーダーとして慌ただしくも充実した毎日を送っていた。

ある日、屋敷は開発言語であるJavaのframeworkに不備を見つけ、元請企業のシステムエンジニアで共通基盤チームの藤尾に報告した。
だが屋敷が指摘した箇所を改修するには参照プログラムをすべて変更しなければならず、現状の体制では納期までに完了するのは到底不可能な作業量だった。
このようなケースでは通常、プログラマーは対応方針が決定されるまで作業をストップして待機する。しかし屋敷は「普通の」プログラマーではなかった。不具合の影響を最小限にとどめる別の改修方法を提案したのである。
これは対応策を思いあぐねていた藤尾を唸らせるほど、画期的な手法であった。

早速、屋敷が提案した手法により改修が進められた。作業負荷を最小限に抑えたその手法により、プログラムは作成期限を遵守することに成功したのである。
その後、プログラミング工程も期日どおり完了した。

だがプログラムはテスト工程に入り、チームは新たな問題を抱えることとなる。

プログラムテストでは仕様書に基づいてテストを行い、実施結果の証拠をエビデンスとして残すが、今回の開発メンバーである劉のエビデンスに不備があるとしてレビュー者から指摘が上がったのである。本プロジェクトではエビデンスの記載ルールをあらかじめ決めていた。
劉が残したエビデンスは一応のルールに則ってはいたが、データの関連性がまったく読み取れず、プログラムが仕様どおりに動作することを証明できるものではなかったのだ。

指摘を受け戸惑う劉に、屋敷は冷静に声をかけ、エビデンスの内容を確認する。
するとテストを実施した時点のデータではなく、別のプログラムが実行された後のデータをエビデンスとして残していたことが明らかになった。ハピテクのビジネスパートナーである劉は、プログラムテストの経験はあるが、エビデンスの目的やルールを誰に指導されることもなくほとんど独学で作成してきたのであった。屋敷はテストエビデンスの作成目的、観点、手法を一から劉に教えこみ、自らの作業を抱えながらも劉のエビデンス再作成のためのテストを一緒に行っていく。
これにより劉のスキルは劇的に向上し、プロジェクトも期限内に無事完了することができた。
以降、劉の作成したエビデンスがレビュー者から指摘を受けることはなくなった。
誰であれ（それが社外のビジネスパートナーであっても）、共にプロジェクトに邁進する仲間を大切にする。
屋敷はハピテクの哲学を見事に体現してみせたのである。