https://www.flickr.com/photos/visualpunch/7477997812「問題対私たち」のチームになっていくには？チーム立ち上げのころは相互参加−相互貢献−相互尊重−相互信頼がまだチーム内で醸成されていない状態であることが普通です。このタイミングでは、チームメンバーは些細な困りごとを安心して話すこともできず、仮に本丸の取り組むべき問題をチームで見つけても、チームメンバーが協力して前向きに取り組むことできないことがあります。チーム内の人と人とのコラボレーションの質が低い状態の場合は、ふりかえりの場が、無関心、他責、厄介事の押し付け、一方的な説得、ディベート（言論で打ち負かす）の言動を取りがちで、機能不全に陥ります。 では、どうやって、本丸の重要なテーマの問題にも「問題対私たち」で取り組める相互信頼のあるCool&Sexyなチームになっていくのでしょうか？ KP

前回から、書籍を辿り、TDDの再考を試みています。TDDを既に知っている、実践しているという人にとっては、TDDについて新しい発見、ジャメヴ（未視感）が起きれば幸いです。たとえTDDが不要だったとしても、不要だと判断したものが一体何だったのか知ることは欠かせません。 忘れないで、テスト駆動開発にもデザインパターンの話が出てくるよTDDはテストファーストやベイビーステップのインパクトがありすぎて、あまり目立っていないですが、書籍『テスト駆動開発』にもソフトウェアパターンの話が出てきます。そう、出てくるんですよ。 余談ですが、テスト駆動開発３部におけるSingletonパターンの説明はGoFの説明とは違ったユニークな内容になっています。（本で確認してみてね） 1回だけ設計ではなく繰り返し設計注意点ですが、テスト駆動開発においてのソフトウェアパターンは、プロジェクト初期に１回だけパターンを使って

昨年１２月に行われた和田卓人氏と『時を超えたプログラミングの道』編集長／『スクラム実践入門』著者の家永英治氏の『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談の記事第5弾をお届けします。 対談のこれまでの記事は以下になります。

ヘロヘロスクラムを見かける話懸田：さて、次の話題がたぶんテーマの根幹だと思うんですけど、そこらへん少しお願いします。 和田：ブログエントリーで一個ずつタイトル並べたみたいな感じですね。じゃあトピック「スクラムは広まったがコードや設計がダメだとエンジニアは生き生きしないのではないか？」。 家永：これはいわゆるファウラーの所のヘロヘロスクラムとかっていうキーワードですね。 和田：角さんが訳したやつ。 家永：和訳があるので、知られてはいるんだけれども、実際僕がアジャイルコーチというポジションで入ると、期待されるところの最初はまずはプロセス面を見るというところがあって、コードまで見るという機会が逆に離れてしまっている。プロセス部分にもまずフォーカスが当たるんだけれども、実際にもう一歩踏み込んでコードを見てみると、「これ大丈夫か！？」とドキッとする機会が何度もある。例えば、僕は（Ruby on）Ra

はじめに前回は、外側のテストループについて何を作ればよいかの探求について解説しました。今回は、実際に「どう作ればよいか」について、コードや設計の内側の秩序の探求について解説します。 TDDの肝は、動作するきれいなコードを目標に、テスト書いて、 実装して、学んで、リファクタリングして… を小さく繰り返し、内なるコードや設計の秩序化するステップを踏み続けることにあります。では、「動作するきれいなコード」と呼ばれる目指すべき場所は何を頼りに向かえば良いのでしょうか？ プログラミングにはコードや設計の秩序化を図るための定石が幾つか知られています。例えば、UNIXの設計判断（例：一つのプログラムには一つのことをうまくやらせる）、メタファ、名前重要、DRY原則、SOLID原則、KISSの法則、コマンドクエリの分離原則、契約による設計、オブジェクト指向のイディオム、関数型のイディオム、各種の言語やフレー

http://studiototoro.com/musukarakka-471より改変前回、スタブ・モックの使いどころの再考について触れました。そのなかで、ユニットテストのみに頼るのは、盲点が生まれるという点を指摘しました。「群盲象を評す」という寓話があります。各々の盲目の人が象の一部を触って象を語るだけでは部分でしかありませんし、盲点も消えません。 象の部分を統合して初めて全体を語れるように、一つの視点では盲点ができてしまいますが、複数の視点があればそれを防ぐことができます。 今回は、アジャイルテストの４象限を使って、テスト観点の全体像をお伝えし、次回では多重のフィードバックループについて盲点を少なくする仕組みについて解説します。 テスト駆動開発のスタイルをやめたとしても、自分たちが作り続けているプロダクトが期待通り動き続け、プロダクトがユーザや市場によりフィットしていくようにするには、

技術詳細は外側へ寄せるポイントは、中心となる対象ドメインは何か？中心から排除したい要素は何か？を考慮して区分けすることです。中心のドメインから排除したい項目の代表例が、データベースアクセスや外部Webシステムやメッセージングといった詳細の技術要素です。ドメイン駆動設計の設計判断を取り入れている場合は、オブジェクトへのアクセスするためのRepositoryのインタフェースのみを中心ドメインに入れ込み、Repositoryの実装（特定のデータベース種類やSQLなど実装詳細）は外側に追いやります。同様に、インタフェースのみを中心にいれてメッセージングや他のWebシステムのアクセス等の実装の詳細は外部に追いやります。 うまく区分けできれば、中央に残った純粋なビジネスについてのルールや状態遷移についてをユニットテストやリファクタリングを継続することができます。リファクタリングによる設計改善を継続する

Photo credit: osde8info via VisualHunt / CC BY-SAソフトウェアの設計判断は多数存在しますが、大きな影響を与え続けているもの一つにUnixの哲学があります。本日は書籍『UNIXという考え方』で紹介されている定理の一つを紹介します。 定理２：一つのプログラムには一つのことをうまくやらせる 指針もなく機能の追加修正を続けていると、はじめは短かったコードも時間経過とともに混みいった醜いコードに変貌し、担当が抜けるとやがて誰も手が付けられない恐れや憎悪の対象となってしまいます。ここまでコードが悪化すると、市場からの予期しなかった重要な要望に対して俊敏に応えることは不可能になってしまいます。 そこで、本日ご紹介の定理です。一つのプログラムには、多数混ぜ込むのではなく、一つのことだけうまくやるように絞り込み、一つ一つの小さなプログラムを組み合わせて、達成し

Photo credit: Dushan and Miae via Visual hunt / CC BY-SA今回は、前回紹介した『UNIXという考え方』の続きで、定理の一つのご紹介です。「初期から動くものをつくってフィードバックをもらって、軌道修正しながら、ゴール見つけて達成しましょう」は、アジャイルな開発でも指摘していますが、Unixの哲学でもその重要さが語られています。 定理3:できるだけ早く試作を作成する ソフトウェアを使って、誰向けに何の問題を解けばよいか、どう解けばよいか、予めはっきりと分かっているのであれば、わざわざトライアンドエラーで失敗しながら学ばなくても、一度立てた計画通りにものごとをすすめることができるでしょう。例えば半年間の開発の初期段階で仕様・設計を作成して固定し、実装・テストして完成させる計画を立てても実現できるはずです。 ところが、終盤に実際に動くものを見て