ブログ記事「ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か」の質疑応答

Social Changeの記事「ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か」 http://kuranuki.sonicgarden.jp/2012/01/post-62.html の質疑応答をまとめました。
9
Yoshihito Kuranuki / 倉貫義人 @kuranuki

ブログ書きました! RT: ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か http://t.co/SL1egUmp

2012-01-27 08:54:52

質疑応答(1)

ちょみんぐうぇい @chomingway

@kuranuki いつも興味深い記事をありがとうございます。気になったのですが、仕様をドキュメント化「しない」場合、Updateされた仕様をどう管理するかが課題になりませんでしょうか。

2012-01-27 13:23:33
Yoshihito Kuranuki / 倉貫義人 @kuranuki

@chomukyu 各社によると思いますが「仕様」の考えかたですが、SonicGardenのやり方では、プログラムに落とし込んだら、その動くソフトウェアが「正」の仕様になるという考えでいます。機能追加などでUpdateするならば、新しく作る部分の仕様を決めて、また実装します。

2012-01-27 14:02:41
ちょみんぐうぇい @chomingway

@kuranuki お答えありがとうございます。仕様書には「仕様」と「思想(なぜその仕様なのか)」が書かれると思いますが、前者はコードを正にするとして、後者のUpdate管理で工夫されている点などはありますか?(ずうずうしくすみません。差支え無ければ、で)

2012-01-27 14:29:32
Yoshihito Kuranuki / 倉貫義人 @kuranuki

@chomukyu 設計に対する「思想」は、その前にコンセプトがありきで、それはウェブサイトやマニュアルを用意するので、そこには書いてます。大切にしてるのはコンセプトで、そこを共有していれば、なぜその設計にしたのかは思い出せます。後は日々の会話ですね。ランチとかでよく議論します。

2012-01-27 14:45:32
ちょみんぐうぇい @chomingway

@kuranuki なるほど、全体の流れが理解できました。これまで「設計」と「設計書」は同一視しがちでしたが、あえて分けて考えることで、より状況に適した柔軟な対応ができますね。大変参考になりました。

2012-01-27 15:26:10

質疑応答(2)

きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

@kuranuki アジャイルにおける要求分析についてどう考えていますか?どのような言葉がいいとか、どういった手法であるとか、どのようなロールが必要とか。

2012-01-27 12:46:19
Yoshihito Kuranuki / 倉貫義人 @kuranuki

@kyon_mm 「要求分析」って、具体的に何をすることを指してますか?

2012-01-27 12:51:11
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

@kuranuki 手法はいろいろとあると思うので、一概に言えませんが、目的は顧客が達成したい内容や解決したい内容について整理し、それらの理由、目的などを明確にしていくことを指しています。Vモデルでいう要件定義書をつくる作業であったり、要件定義書を分析していく作業です。

2012-01-27 12:59:11
Yoshihito Kuranuki / 倉貫義人 @kuranuki

@kyon_mm アジャイルにおけるかどうかはさておき、受託の場合、その要求分析であれば本来はお客さん自身がすべきことだと考えてます。そのとき、外向けのサービスであれば、マーケティング活動そのものが要求分析になるんだろうと思います。

2012-01-27 13:10:24
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

@kuranuki なるほど。要求分析に「要求から仕様を漏れ無くつくる作業が入るかどうか」という点は議論がありそうなのですが、その作業自体は先のブログ「アジャイルに外部設計は必要か」で触れられている通り、外部設計にあたり、それはPOがやるものということでいいですか?

2012-01-27 13:17:46
Yoshihito Kuranuki / 倉貫義人 @kuranuki

@kyon_mm そうですね。あと「漏れなく」つくることにどこまでの意味があるのか、を考える必要があると思います。大切なのは漏れなくすることではなく、目標の達成なのであれば、進みながら要求自体も見直していくべきです。そのためには、従来の「定義して発注」から見直す必要がありますね。

2012-01-27 13:23:11
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

@kuranuki はい。僕も同意です。Wモデルにおけるテストプロセスもそうですが、要求分析もSprintやSprint間で成長し続けていくものだと思います。たぶんそこのバランス感覚が難しいんだと思っています。なにか参考資料やコツなどはありますか?

2012-01-27 13:27:43
Yoshihito Kuranuki / 倉貫義人 @kuranuki

@kyon_mm 知識のスキルではないので、やはり実際に経験を積むのが一番だと思いますが、最近ではリーンスタートアップの考えかたと、その元になった「アントレプレナーの教科書」という本を読んだことは参考になりましたね。 http://t.co/NEbCYGRP

2012-01-27 13:51:37
きょん@アジャイルコーチ、システムアーキテクト @kyon_mm

@kuranuki なるほどぉ。最近、リーンを勉強しはじめたいなぁとおもっていたのですが、やはりよい参考になりそうですね。ありがとうございます!

2012-01-27 14:05:41