ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か

ソフトウェアをつくるための3つの役割〜アジャイルに外部設計は必要か

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

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

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

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

一人でつくる場合も、大勢でつくる場合も、実際はもっと色々あるかもしれませんが、ざっくり考えるとこんな感じで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での質疑応答を追記しました

倉貫 義人

株式会社ソニックガーデン代表取締役社長。経営を通じた自身の体験と思考をログとして残しています。「こんな経営もあるんだ」と、新たな視点を得てもらえるとうれしいです。

ニュースレター

ブログの更新情報や、ここだけの執筆裏話など、3ヶ月に1度のペースでお届けします。

購読する
書影: 私はロボットではありません
倉貫書房の新刊

私はロボットではありません

長瀬光弘 著

「嫌な未来なら変えればいい」

あなたの毎日にも、きっと繋がる。株式会社ソニックガーデン代表倉貫義人のブログ「Social Change!」のノベライズ化第一弾。

BASEで注文する
ページ上部へ