2019年11月08日(金)0ブックマーク

開発がわからないでは済まされない時代! 経営層や事業責任者が知っておくべき開発手法の見極め方

経営ハッカー編集部
シェア0
ツイート
ブックマーク0
後で読む
開発がわからないでは済まされない時代! 経営層や事業責任者が知っておくべき開発手法の見極め方

JQの下田です。
プロジェクトマネジメント支援事業を軸に会社経営をしています。

最近、事業やプロジェクトの現場において、「アジャイルで開発を進めよう!」という話をよく耳にします。アジャイル開発とは、短期間で実装とテストを繰り返し、だんだんと完成形に近づけていく開発手法です。

たしかに、アジャイルは注目されている開発手法ですし、短期間で実際に手を動かしながら要件を固めてプロダクトを作っていくこの手法は、一見とても理想的な進め方に見えます。

しかしながら、アジャイルには適した条件があり、その条件を満たしていなければ間違いなくそのプロジェクトは失敗します。実際、私はプロジェクトマネジメントの現場で数多くの失敗を目にしてきました。

それらの失敗要因を探ってみると、ほとんどがアジャイル開発を進められる条件を満たしていないために起こっています。そこで今回は、アジャイル開発を成功させる3つの条件を紹介します。

 

目次

    条件① 前提として、チームメンバーに十分なスキルがある

    1つ目の条件は、チームそのものについてです。

    アジャイル開発は、

    1. エンジニアやデザイナーがプロダクトオーナーの「実現したいこと」をヒアリング
    2. 実際にプロトタイプを作る
    3. 確認とフィードバックを繰り返す
    4. プロダクトを完成させる

    というプロセスを踏んで開発を進めていく手法です。

    そのため、エンジニアやデザイナーがそれに対応できる技術やコミュニケーションスキルを持っている必要があります

    たとえば、アプリケーションのモックアップを作る場面。
    アサインされたデザイナーは、プロダクトオーナーからの依頼を噛み砕いて実現したい内容をイメージし、いろいろな事例とともにデザイン案を提案できなくてはいけません。

    しかし、アサインされたデザイナーのスキルが不十分だったらどうでしょうか。
    「これはどうやって操作したらいいの?」「戻るボタンが設置されてなくない?」など、開発において議論したい内容以前のところでつまづき、話にならないなんてことが起こり得ます。

    ちなみにこれは、プロダクトオーナー側のスキルに対しても同様のことが言えます
    スキルのある優秀なデザイナーから良い提案が出されたとして、ほとんど知識のないプロダクトオーナーは正しくフィードバックできるでしょうか。

    こうした観点から、プロダクトオーナーがしっかりとした論拠を持って判断できるかが重要とされるのです。これは、知識だけでなくプロダクトに対する思い入れも問われていると言えます。

    アジャイルは、プロダクトオーナーの確認とフィードバックを受けて作っていくというサイクルが適切に回ってはじめて成り立つ開発手法です。双方に十分なスキルがなければ、このサイクルが生まれず、アジャイルは成り立ちません

     

    条件② 5名以下のスモールチームである

    2つ目の条件は、開発規模についてです。

    実際にものを作りながら進めるアジャイル開発において、作らなくてはいけないものが多い場合には、アジャイルは成立しません

    たとえば、100画面を作らなくてはいけない開発案件があるとしましょう。
    短い期間でたくさんのものを作らなくてはいけない場合、多くの人がアサインされることになります。そもそも、1人のプロダクトオーナーが100画面の要件を決めたり、レビューしたりするのは無理です。

    仮に5人のプロダクトオーナーをアサインして5つのチームを作って分担したとします。すると今度は5チーム間での整合性チェックが発生し、要件定義や設計のどこかでスケジュールを合流させる必要が生じます。そうなってくると、もうウォーターフォール開発に近くなってしまいます。

    1人のプロダクトオーナーがコントロールできるのは、せいぜい横で話しながら調整ができる範囲です。規模の大きさの目安として、エンジニアやデザイナーの人数は2〜3人がベスト、5人以上集まったら大きいと思っていいでしょう

     

    条件③ 他システムと連携の必要がない

    最後の条件は、開発内容についてです。

    他システム、特に基幹システムと連携するような場合は、アジャイルの開発にしてはいけません。大体において、基幹システムは従来型のウォーターフォールで開発していて、保守管理においても同様です。そうなると、新たなサービス開発側のみをアジャイルで進めるのは困難です。

    なぜなら、基幹システムは品質をしっかりと保つ必要があるため、仕様変更がある場合には、

    1. 仕様変更によってどんな影響があるのかをきちんと調査
    2. 見積りを出し、発注をもらってから開発を開始
    3. 導入前にテストを実施
    4. テストで問題がなければ実装

    というプロセスを踏みます。そのような流れのなか、新たなサービスの開発側でインターフェースの仕様をアジャイルによってコロコロ変えられたら困るのも当然ですし、そもそもできません。これはもう、基幹システムという特性上仕方がないのです。

    条件②の規模と関連することですが、連携せずとも、基幹システムと似たような業務システム系はどうしても開発規模が大きくなります。これらは、そもそもアジャイル開発が難しい開発内容であることは理解しておきましょう。
     

    まとめ

    以上が、アジャイル開発に必要な3つの条件です。

    紹介した条件のうち、どれか1つでも満たしていない場合には、そのプロジェクトのアジャイル開発はうまくいかないので、従来のウォーターフォール開発で進めることを強くおすすめします。
     

    シェア0
    ツイート
    ブックマーク0
    後で読む

    この記事の関連キーワード

    ボタンをクリックすると、キーワードをフォローできます。

    関連する事例記事

    • インタビュー・コラム11月15日経営ハッカー編集部

      令和時代のテクノロジーと新しい経済のありかたとは?面白法人カヤック柳澤大輔代表×「らぼっと」のGROOVE X家永佳奈氏

      0ブックマーク
    • インタビュー・コラム11月11日経営ハッカー編集部

      経営をもっとシンプルに!NPSとeNPSで顧客ロイヤリティと従業員エンゲージメントを一気に改善する方法~株式会社Emotion Tech

      2ブックマーク
    • インタビュー・コラム10月28日経営ハッカー編集部

      IPOに導いた上場企業CFO13人が明かす「IPO虎の巻」

      2ブックマーク
    • インタビュー・コラム10月28日経営ハッカー編集部

      会社と個人の歪んだ関係を「ストーリー経営」で立て直す!日本型雇用の根本問題に斬りこむ株式会社YourVerse長谷川氏に聞く

      1ブックマーク
    • インタビュー・コラム10月26日経営ハッカー編集部

      火災保険と地震保険は年末調整で控除される?知っておくべき基礎知識

      0ブックマーク
    関連記事一覧