ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。
目次
ソフトウェアをつくる上で「やるべきこと」は何か
ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。
最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。
一人でつくる場合も、大勢でつくる場合も、実際はもっと色々あるかもしれませんが、ざっくり考えるとこんな感じで３つに分けることができます。
実際に作っていくとわかりますが、アプローチを考えることとプログラミングしていくことは一方通行ではなく、行ったり来たりで実現していくのが最も効率が良いやり方で、それはアジャイルと呼ばれています。
アジャイル開発に「外部設計」はあるのか
アジャイル開発で「外部設計」がないと思ってるなら間違いだ。「外部設計」はフェーズの名前ではなく「何を作るか」を決める役割のことだと思えば、モノ作りには必要なものだとわかる。
https://twitter.com/#!/kuranuki/status/162184317823496192
アジャイル開発では、少人数のチームで「多能工」という考えかたのもとで、一人のプログラマが多くの役割をもちます。そして、工程を分けること無く、実際に動くソフトウェアを中心に開発を進めていきます。
ではアジャイル開発で、ウォーターフォールでいう「外部設計」は無いのかというと、そんなことはありません。「外部設計」という「期間」は無いですが、「外部設計」に相当する「役割」は存在します。
「外部設計」とは「何を作るか」を決めることです。例えば、ある機能を追加しようとしたときに、どんな画面遷移をするとか、画面の中の配置はどうするとか、つまり、「プログラムをどう作れば良いか」を決めることです。それがないとモノ作りはできません。
プログラムがどのように動作すれば正しいか、を示したそれを「仕様」と呼びます。「仕様」は必ず必要ですが、それが「ドキュメント」でなければいけないかというと、また別の話です。SonicGardenの開発スタイルでは、ドキュメント化までしないで以下のようなホワイトボードで「仕様」を共有しています。この後、Pivotal Trackerにチケット化し、すぐにプログラミングに入ります。
スクラムでいうプロダクトオーナーの大きな役割の一つが、この仕様を決めることで、すなわち正解を決めることで、それはとてつもなく大変なことです。なぜなら正解と言ってもビジネス的な観点から本当の正解かどうかはわかりません。そんな中で決断をしなければいけないのは大変な訳ですが、アジャイルであれば、もし正解でなかったら直せば良いのです。
アジャイル開発が変化するビジネスに対応できるというのは、こういうことなのです。
「要件定義」とは何だったのか？
どんな問題を解決するのか、ビジョンやゴールを決める役割ですよね。「目的設定」って感じですか。 RT @toshi_yoshimoto: ちなみにウォーターフォールにおける「要件定義」は、どんな言葉がいいでしょう？ RT @kuranuki: 「外部設計」って言葉がよくないよな。
https://twitter.com/#!/kuranuki/status/162303438758219776
ウォーターフォールには「要件定義」という工程があります。それに対応する言葉があるか、というご質問に上記のように答えましたが、その後少し考えて、違うのかもしれないと思ってきました。
「要件定義」という工程は、誰のためのものだったのか、本当にソフトウェアを作る上で必要な工程なのか、常識を捨てて論理的に考えてみました。
そのソフトウェアで、どんな問題を解決するのか、どんなことを便利にする機能を作るべきか、というのは、「外部設計」で仕様を決める前に必要です。目指すゴールや、つくったソフトウェアによってなしえるビジョンを決めることと、どんな機能を作るのかを決めることが必要な「役割」です。
それを「要件定義」と呼ぶかというと違和感があります。実は「要件定義」なんてのは、一括発注で請け負いたいシステムインテグレーター（SIer）側だけの理屈ではないか、と考えています。そもそも、全ての要件を「定義」しようとするものではないのではないでしょうか。
どんな機能が必要かなんてことは、ソフトウェアを使うユーザがいる限り変わってくるし、立ち上げのタイミングか拡大のタイミングかなどのビジネスの状況によって変わってくるはずです。一度で決まるものではなく、少しずつ決めていくものです。
リーンスタートアップで言う「顧客開発」をするのは、この役割の一環です。顧客からのフィードバックを受けながら、必要な機能は何かを変えていきます。よくいうピボットするというのはこの役割の中でのことです。それ以外の変更はただの試行錯誤です。
ソフトウェアを作るためには、「仕様を決めること」「プログラミング」の他に、顧客（ターゲット）は誰かを考えて、ビジネスプランを検討し、そして出来たソフトウェアをプロモーションするという役割が必要です。それは「マーケティング」そのものです。
よって「要件定義」なんてものはなく、マーケティングがあって、それを推進するのはビジネスオーナーと呼ばれる役割だと考えています。
スタートアップするには、ハスラーとハッカーとデザイナーの３人いると良いといいます。つまり、それはこの３つの役割に相当するのです。
アジャイルの文脈であれば、下の２つの役割の中での話で、リーンスタートアップの文脈であれば、それにビジネスオーナーの役割を加えた話であることがわかります。これらを工程の期間で分けるのではなく、役割分担の中で渾然一体となって進めていくことで、ビジネスを成功させる確率を高めるように思います。
SonicGardenの「納品のない受託」ソフトウェアパートナーシップモデルでは、ビジネスオーナー向けプランとプロダクトオーナー向けプランの２種類を用意しています。くわしくはお問い合わせください。
あわせて読むと良いかも：プログラマと漫画家〜「何を作る」のか考えたいプログラマと「どう作る」を追求するプログラマ
