ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計(外部設計)」「詳細設計(内部設計)」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。

設計 図面 手 住宅 インテリア  - 写真素材
(c) 2K写真素材 PIXTA

ソフトウェアをつくる上で「やるべきこと」は何か

ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。

最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。

一人でつくる場合も、大勢でつくる場合も、実際はもっと色々あるかもしれませんが、ざっくり考えるとこんな感じで3つに分けることができます。

実際に作っていくとわかりますが、アプローチを考えることとプログラミングしていくことは一方通行ではなく、行ったり来たりで実現していくのが最も効率が良いやり方で、それはアジャイルと呼ばれています。

アジャイル開発に「外部設計」はあるのか

アジャイル開発で「外部設計」がないと思ってるなら間違いだ。「外部設計」はフェーズの名前ではなく「何を作るか」を決める役割のことだと思えば、モノ作りには必要なものだとわかる。
https://twitter.com/#!/kuranuki/status/162184317823496192

アジャイル開発では、少人数のチームで「多能工」という考えかたのもとで、一人のプログラマが多くの役割をもちます。そして、工程を分けること無く、実際に動くソフトウェアを中心に開発を進めていきます。

ではアジャイル開発で、ウォーターフォールでいう「外部設計」は無いのかというと、そんなことはありません。「外部設計」という「期間」は無いですが、「外部設計」に相当する「役割」は存在します。

「外部設計」とは「何を作るか」を決めることです。例えば、ある機能を追加しようとしたときに、どんな画面遷移をするとか、画面の中の配置はどうするとか、つまり、「プログラムをどう作れば良いか」を決めることです。それがないとモノ作りはできません。

プログラムがどのように動作すれば正しいか、を示したそれを「仕様」と呼びます。「仕様」は必ず必要ですが、それが「ドキュメント」でなければいけないかというと、また別の話です。SonicGardenの開発スタイルでは、ドキュメント化までしないで以下のようなホワイトボードで「仕様」を共有しています。この後、Pivotal Trackerにチケット化し、すぐにプログラミングに入ります。

スクラムでいうプロダクトオーナーの大きな役割の一つが、この仕様を決めることで、すなわち正解を決めることで、それはとてつもなく大変なことです。なぜなら正解と言ってもビジネス的な観点から本当の正解かどうかはわかりません。そんな中で決断をしなければいけないのは大変な訳ですが、アジャイルであれば、もし正解でなかったら直せば良いのです。

アジャイル開発が変化するビジネスに対応できるというのは、こういうことなのです。

「要件定義」とは何だったのか?

どんな問題を解決するのか、ビジョンやゴールを決める役割ですよね。「目的設定」って感じですか。 RT @toshi_yoshimoto: ちなみにウォーターフォールにおける「要件定義」は、どんな言葉がいいでしょう? RT @kuranuki: 「外部設計」って言葉がよくないよな。
https://twitter.com/#!/kuranuki/status/162303438758219776

ウォーターフォールには「要件定義」という工程があります。それに対応する言葉があるか、というご質問に上記のように答えましたが、その後少し考えて、違うのかもしれないと思ってきました。

「要件定義」という工程は、誰のためのものだったのか、本当にソフトウェアを作る上で必要な工程なのか、常識を捨てて論理的に考えてみました。

そのソフトウェアで、どんな問題を解決するのか、どんなことを便利にする機能を作るべきか、というのは、「外部設計」で仕様を決める前に必要です。目指すゴールや、つくったソフトウェアによってなしえるビジョンを決めることと、どんな機能を作るのかを決めることが必要な「役割」です。

それを「要件定義」と呼ぶかというと違和感があります。実は「要件定義」なんてのは、一括発注で請け負いたいシステムインテグレーター(SIer)側だけの理屈ではないか、と考えています。そもそも、全ての要件を「定義」しようとするものではないのではないでしょうか。

どんな機能が必要かなんてことは、ソフトウェアを使うユーザがいる限り変わってくるし、立ち上げのタイミングか拡大のタイミングかなどのビジネスの状況によって変わってくるはずです。一度で決まるものではなく、少しずつ決めていくものです。

リーンスタートアップで言う「顧客開発」をするのは、この役割の一環です。顧客からのフィードバックを受けながら、必要な機能は何かを変えていきます。よくいうピボットするというのはこの役割の中でのことです。それ以外の変更はただの試行錯誤です。

ソフトウェアを作るためには、「仕様を決めること」「プログラミング」の他に、顧客(ターゲット)は誰かを考えて、ビジネスプランを検討し、そして出来たソフトウェアをプロモーションするという役割が必要です。それは「マーケティング」そのものです。

よって「要件定義」なんてものはなく、マーケティングがあって、それを推進するのはビジネスオーナーと呼ばれる役割だと考えています。

スタートアップするには、ハスラーとハッカーとデザイナーの3人いると良いといいます。つまり、それはこの3つの役割に相当するのです。

アジャイルの文脈であれば、下の2つの役割の中での話で、リーンスタートアップの文脈であれば、それにビジネスオーナーの役割を加えた話であることがわかります。これらを工程の期間で分けるのではなく、役割分担の中で渾然一体となって進めていくことで、ビジネスを成功させる確率を高めるように思います。

SonicGardenの「納品のない受託」ソフトウェアパートナーシップモデルでは、ビジネスオーナー向けプランとプロダクトオーナー向けプランの2種類を用意しています。くわしくはお問い合わせください。

あわせて読むと良いかも:プログラマと漫画家〜「何を作る」のか考えたいプログラマと「どう作る」を追求するプログラマ

Twitterでの質疑応答を追記しました

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Content from Twitter