アジャイルプロセスにデザイナーは必要か 前編

「アジャイル的なプロセスでやりたいのですが対応できますか?」

最近、このようなご要望をよくいただきます。継続的に顧客満足度を上げる活動を行いたいから、開発を効率的にやりたいから、など目的はそれぞれあるようです。今回は、アジャイルプロセスとデザイン/デザイナーの関係について考えてみたいと思いますが、少々長くなるため、2回に分けて、「アジャイルの本質と浸透しない理由」と「アジャイル導入の必要性からどうデザイナーをプロセスに取り組むか」を記載します。

 

アジャイルとは?

ソフトウェア開発の一つの手法(プロセス)です。色々とこのプロセスを導入することでメリットがあるのですが、わたしは「改善しつづける意識」にアジャイルの本質があると考えています。

近年、IT業界の競争はますます激化し、技術も急速に変化してきました。そういった中で、いかにしてビジネス環境に適した開発プロセスを作るか、という発想からアジャイルという概念は生まれました。アジャイルの概念を組む開発プロセスのひとつに、スクラムプロセスがあります。スクラムでは、開発期間をスプリントという2週間という単位で区切り、開発工程をひと通り行うようにしています。2週間毎に、そのスプリントで行った作業内容チェックや取り組み方に改善点がないかなどを振り返ることで、チーム内で改善をし続けることが可能になるのです。

私は、リリース時期厳守が最重要目的のウォーターフォール型も、長期にわたりアップデートを繰り返すスクラムプロセス型も、どちらのプロセスもプロジェクトマネージャーとして指揮した経験があります。その経験からすると、アジャイル型が適しているのは、ソフトウェアやWebサービスのような長期的にシステムを運営し続け、継続的に機能拡張や品質を向上させていくことが重要なプロジェクトでしょう。おそらく、広告向けの期間限定のサイトや一度作ったら変化が不要なものには、そこまで効果を発揮することはないと思います。

さて、冒頭に「改善し続ける意識」と書きましたが、良いソフトウェアを作るために重要なこととは何でしょうか。私は、良いソフトウェアをつくれる”チームをつくる”ことが最も大事だと考えています。どのような職業でも、作業でも、効率化することで、チームのパフォーマンスは何倍もあがります。特に、多くの人が関わる組織ですと効率性の差は顕著にソフトやサービスの品質として表れます。スクラムプロセスでは、短期間で改善を繰り返すための会議体が厳密に定義されており、それに基づいて運営すると、前スプリントより今スプリント、今スプリントよりも次のスプリントと、どんどんチームの効率は向上していきます。その結果、次第に良いプロダクトを作り続ける組織ができあがっていきます。

アジャイルを導入する理由を問いなおすと、最終的には「良い物を作るため」となります。開発コストの削減や開発期間の短縮は、アジャイルを導入する目的にはなりません。結果的にそうなる可能性はありますが、あくまで「良い物を作るため」です。

 

 

アジャイル開発があまり浸透していない理由

アジャイル開発という言葉が流行りだしてから10年以上経ちましたが、廃れるどころか浸透している実感がありません。なぜでしょうか。前項の良い物を作るためのプロセスであればどんどん導入すればいいはずです。なぜ導入が進んでいないのでしょうか。

理由その1)IT業界の構造的理由

まず挙げられるのは、日本のIT業界の構造がアジャイルにマッチしていないという点が挙げられます。欧米のソフトウェアは、社外の開発ベンダーにアウトソースするよりも、自社で開発することが多いです。もちろん外部のパートナーと開発することもありますが、日本の発注者自信がソフトウェア開発経験なく丸投げというケースは稀です。また、一次受け二次受けといったITゼネコンの構造も、日本特有の形でしょう。下の図は、社内で開発部隊を持つインハウスとアウトソースをする場合の違いを端的に表したものです。

process_comparison

こうしてみると、発注者側からすると、コストが安く、成果が見えやすい”アウトソース”を採用することは合理的に見えます。多少の仕様変更や追加要件も、アウトソース先がまきとり、なんとかやりきって成果を出してくれる。そのような期待からアウトソースによる開発が多くされている背景には隠れています。

しかし、リリースした後、次の改善を行う際に以下のような問題が発生します。

  • リリース直後にユーザーからのフィードバックが殺到しすぐに改善しなければならない。しかし、追加開発の見積をするために2週間も要してしまった
  • その間に、開発のキーマンがプロジェクトから離れてしまい、機動性が著しく落ちてしまった
  • さらに、初期開発時の仕様変更や追加要件で無理を共用してしまったため、保守的な見積で想定よりもだいぶコストが高くなってしまった
  • しかし、設計のコアから委託していたため、ベンダーを変更することもできず、ベンダーロックイン状態に・・・。
  • そして、サービスはなかなか改善されず、気がついたらサービス終了のお知らせ。

日本の多くの企業がこのような状況に直面しているのではないでしょうか。

一方、インハウスでの開発ですと、社内に開発チームを抱えるためコストは高くなります。必要なスキルを持つ人に変える、といったことも簡単にはできません。しかし、社内の組織のため、アウトプットももちろん重視されますが、プロセスも評価できます。そうなると、何か新しい方法に取り組んだり、今と違うことに挑んだりと、チャレンジの機会を推奨することにもつながってきます。結果としてチームは効率性を増していき、そのノウハウは社内に残ります。不運にもそのサービスを閉じることになってもチームは社内に残り続けるため、次のサービスをうみ出す時にいきてきます。長期的に経営を考えると、インハウスの合理性も見えてきませんか?

 

理由その2)職種の縦割り組織

次に、職種ごとに分けられた部門間の壁も、アジャイルが浸透しない理由の一つです。再度、日本と欧米の比較になりますが、欧米の開発チームには、企画(Program Manager, Product Owner)やデザイナー(Graphic Designer, UI Designer, Interaction Designer)が同じプロジェクトメンバーとして参加します。スプリントレビューやプランニングの場にも実装者以外の関係者が同席し、同じチームとして動くことが望ましいとされています。一方、日本の企業ですと、企画は企画部、開発は開発部、デザイナーはデザイン部、と職業ごとに組織が別れ、同じ社内であるにもかかわらず部門ごとの方針で動くというのが普通では無いでしょうか。

こうなると、それぞれ別の職種の人にタスクを割り振る場合、形式上の手続きやコミュニケーションギャップが生じます。小さいこのような積み重ねは、最終的にソフトウェアの品質に大きく影響してきます。開発部隊以外の職種も巻き込んで行かなければ、部分的にアジャイル化しても改善の効果は限定的でしょう。

 

次回は、そのような環境下でもなおアジャイルが期待される背景と、どうすればアジャイルを導入できるか、そして、デザイナーをチームに入れるメリットをご説明します。

伊東大輝

伊東 大輝

http://zeppelin.co.jp/

慶應義塾大学総合政策学部卒業。大学卒業後ソニー株式会社に入社し、国内向けB2Bビジネスの営業に従事。その後、国内のネットワークサービス新規事業の立ち上げ、グローバルに展開するPlaystation Network系サービスの企画・プロジェクトマネジメントを行う。 2013年9月ZEPPELINに乗船。セールス、スクラム開発、チームビルディング、プログラムマネジメント、プロダクトオーナー、新規事業企画などの豊富なビジネス経験を活かし、様々なプロジェクトを牽引すると共に、外部研修会での講師も務める。

伊東 大輝 の記事一覧

RECOMMEND

View all