ソフトウェア開発期間短縮の取組み Initiative to Shorten Software Development Time 荒屋吉恒 * 青井敏昭 ** 下川一郎 *** 土田清一 ** Yoshinobu Araya Toshiaki Aoi Ichiro Shimokawa Kiyokazu Tsuchida * ** *** ソリューション & ソフトウェアグループ アプライアンスソフトウェア事業部 第三開発部 品質保証部 ソフト品質保証部 品質保証部 保証技術部 PFU の製品を市場にいち早く提供し，お客様のビジネス機会創出に貢献することを目的に，ソフトウェア開 発においてアジャイル開発の要素を取り入れ開発期間を短縮する取り組みを実施した． 本開発期間短縮の取り組み実施における課題解決や改善効果について紹介する． We adopted agile development methodology for software development in an initiative to shorten the development time. Our aim was to be quick in providing PFU products to the market and to contribute to the creation of business opportunities for clients. The following outlines issue solutions and improvements in this initiative to shorten development time. １ まえがき ソフトウェア製品の開発に大きな影響を与える要因と 2 取り組みの背景と狙い ２. １ 背景 してビジネスの変化と技術変革のスピードがある．急速 これまで PFU は，長く業界の主流となっているウォー に多様化し変化する市場ニーズと最新技術に対応し，短 ターフォール型開発モデルを採用してきた．このモデル 期間で製品を開発して，いち早く市場に投入できれば， は， 「要求定義」 「基本設計」 「詳細設計」 「プログラミング」 お客様のビジネス機会の創出により貢献できる． ところが，昨今のように急速に進展する技術，激しく 「テスト」 「運用テスト」の工程で開発を進め，前工程が 完了しないと次工程に進まないことで品質を確保し，前 変化する市場ニーズという環境下において，これまで 工程への後戻り（手戻り）を最小限にする特長がある． PFU が採用してきた品質積み上げに特長があるウォー ところが，このウォーターフォール型開発モデルでは， ターフォール型開発モデルでは，開発スピードと変化へ 以下のとおり開発スピードと変化への対応という課題が の対応という点で課題が見えてきた． あった． そこで，｢俊敏な｣ ｢機敏な｣ という意味を持つアジャ （１）開発スピードに関する課題 イル（agile）型の開発モデルに着目し，品質確保に加え PFU は，長年にわたり採用してきたウォーターフォー 開発期間を短縮する PFU 独自のアジャイル型開発モデ ル型開発モデルについて，様々な開発スピードアップの ルの構築を 2008 年 10 月から開始した． 取り組みを実施してきた．しかし，急速に変化する市場 本稿ではこの取り組みを始めるに至った経緯，製品開 ニーズと最新技術への対応には，まだまだ開発スピード 発への適用事例とその成果，および今後の展開などを紹 が不足しており，更に製品を早く市場に投入するために， 介する． 開発期間を半減する必要があると考えていた． また，PFU 内のビジネスにおいても開発スピードアッ プの要件があった．ソフトウェア製品の開発部門は，こ 34 PFU Tech. Rev.,22, 1,pp.34-40 （05,2011） ソフトウェア開発期間短縮の取組み こ数年，社内他部門と連携して相乗効果を生み出すこと を狙いとした製品づくりを推進しており，イメージス ●表—１ アジャイル型開発の特徴（ウォーターフォール型開発との 比較）● キャナや情報 KIOSK（キオスク）端末などの PFU ハー ドウェア製品を核としたソリューションの製品化を進め ていた．こうしたケースではハードウェア製品と組み合 開発手法 アジャイル型開発 型開発 ポリシー 計画，プロセス，ツ 変化への対応，人と ールを重視 のチームワークを重 わせてソフトウェア製品を出荷するが，ハードウェア毎 に要件が異なる上に，出荷時期が重なり同時並行による ウォーターフォール 比較項目 視 プロジェクトの完了 数週間程度の小さな 開発が必要となった事例があった．イメージスキャナと まで一連のタスクで 期間単位を反復して キオスクの両方のお客様に同時に製品を提供するために 開発 開発 所定のドキュメント プロジェクトの成功 は必ず作成する に価値のないドキュ は，より一層スピードを上げてソフトウェアを開発する 開発期間単位 ドキュメント化 必要があった． メント作成を極限ま （２）変化への対応に関する課題 ウォーターフォール型開発モデルは，要求定義の段階 で省く 要件の承認 から着実に品質を確保して行くが，要求自体が変更され ると，手戻りにより大幅な納期変更を余儀なくされると いう欠点があった．昨今の変化の激しい市場動向から， 顧客，関係者はドキ 顧客，関係者はドキ ュメントで要件を確 ュメントではなく動 認する くソフトウェアで要 件を確認する 要求変更への対応 プロジェクトの初期 要件はビジネス環境 段階で確定した要件 の変化などに応じて は基本的に変わらな 途中で変化すること いことが前提 が前提 プロジェクト初期段 全体計画をイテレー の変更など，PFU ではコントロールできない事象が発 階の計画を遵守でき ションに分割．イテ 生したケースがある．市場ニーズに応えるためには，こ るように管理する レーション毎に計画 要求自体を変更せざるを得ない状況に陥るケースが増え ていた． 実際に，動作 OS の変更，連携する他社ソフトウェア プロジェクト管理 を立て，出来高とプ れら事象に追従する必要があると判断し，当初決定した ロジェクト状況に応 要求を変更し対応するといった状況が発生した．また， じて臨機応変に管理 最終の運用テスト段階で，市場動向の変化を察知した場 する 合や市場ニーズとのずれが判明した場合もあり，同じく 変化に柔軟に対応できる 要求を変更せざるを得ない状況があった． ２）数週間程度の小さな開発単位とすることで，設 ２. ２ 狙い 計ドキュメントを削減できる（コミュニケーショ ンにより品質確保できる） このような開発期間半減，変化への柔軟な対応という 課題に対して，従来の取り組みの延長では対応が困難で ３）数週間程度の小さな開発単位とすることで，早 あり，抜本的な対策として，ウォーターフォール型に替 い段階から顧客に動作するソフトウェアを確認し わる新たな開発モデルを確立する必要があると考えた． てもらえる（問題の早期摘出と対処が可能） そこで，PFU が着目したのがアジャイル型開発モデル である． アジャイル型には， 「エクストリーム・プログラミン グ」 ， 「スクラム」など様々な手法がある．その多くは反 これらの特徴を取り入れることにより，開発期間の半 減を実現する開発モデルを確立することを目的に活動を 開始した．なお，当然のことながら開発期間を半減して も，従来通り品質は確保することが大前提である． 復（イテレーション）と呼ぶ数週間程度の短い開発期間 単位を採用し，この間に動作検証可能な成果物を得るこ とを繰り返して開発を進めることでリスクを最小化す る． 3 PFU アジャイルの構築 一般に提唱されているアジャイル型開発を教科書通り これら手法の特徴を，ウォーターフォール型と対比し 導入するだけでは必ず期待通りの成果を上げることはで て表－１に整理した．特にアジャイル型に着目した点は きない．特に，アジャイルを適用した事例は特定顧客向 下記である． けアプリケーションが多いのに対して，PFU は一般市 １）数週間程度の短い開発を繰り返すことにより， PFU Tech. Rev.,22, 1,（05,2011） 場向けの製品を開発（市場調査の結果を製品要求事項と 35 ソフトウェア開発期間短縮の取組み する）していることから，顧客をどのように捉えるかと イテレーション 1【機能 1】 イテレーション 2【機能 2】 開発部門 いう課題もあった．また，これまで培ってきた PFU の 設計 技術力や組織風土を融合したモデルとする必要もあると 考え，PFU 独自のアジャイル型開発手法「PFU アジャ 実装 テスト 要素に分割し，１ヶ月を超えない単位（一つのイテレー ションと呼ぶ）で一つの機能や項目要素の開発を完成さ る． る． 品証部門 検証 ●表—２ PFU アジャイルの特徴と QCD の効果● せ，これを繰り返すことで，製品全体の開発を完了させ より，レビューを通じて進捗と品質の見極めも容易とな ST ●図—１ PFU アジャイルの概要図● （Fig.1-Schematic of PFU agile development） 一般的にアジャイル型開発は，開発対象を機能や項目 置し，最小化した結果，２週間が妥当と考えた．これに 総合検証 ふりかえり会 （１）２週間単位のイテレーション設定 目作成，テストとし，各工程のレビューを数日間隔で配 ･･･ キックオフ会 アジャイルの概要図を示し，以下にその特長を説明する． ション内の工程を，設計，ソースコード作成，テスト項 テスト 品証部門 検証 このように記す． ）の構築に取り組んだ．図−１に PFU ンを設定することとした．その理由は，一つのイテレー 実装 開発／品証部門レビュー イル」 （一般のアジャイル型開発と識別するため，以降， PFU アジャイルでは 2 週間を基本としたイテレーショ 設計 特長 品質 コスト 納期 1 2 週間単位のイテレーション設定 − ◯ ◯ 2 設計の簡略化と待ち時間の排除 − ◯ ◯ 3 仮想顧客の割り当て ◯ ◯ ◯ ◯ ◯ ◯ イテレーション毎のキックオフ会 4 とふりかえり会 ※ ◯：効果あり．−：影響なし （２）設計書の簡略化と待ち時間の排除 従来は，機能設計と構成設計の二つの設計工程があっ たが，これを一本化し，設計書を簡略化した．この簡略 の総合検証を担当する． （４）イテレーションごとのキックオフ会とふりかえり 化により，設計書作成に費やしていた時間を，チームに 会 よる設計内容の検討時間に振り向けた．これにより，設 アジャイル開発を適用するにあたりチームワークは欠 計が充実すると共に，設計書完成待ち，レビュー待ちと かせない事項である．この点では，PFU は技術を追求 いった待ち時間がなくなり，開発メンバーの効率を落と する風土に加え，自律人材の創出に注力しており，現場 すことなく作業を進めることができる． 交流や見える化運動による自発的なコミュニケーション なお，最終的に確定した設計内容は各イテレーション の醸成が組織風土として根付いてきた．その風土もあり， の終了後に，保守を見据えて必ず正式な設計書として文 アジャイル開発の検討を始めた時点から，各イテレー 書化するルールとした． ションの開始時， 終了時に， それぞれ「キックオフ会」 「ふ （３）仮想顧客の割り当て りかえり会」と呼ぶミーティングを設けることが必要と 開発の早い段階から動作するソフトウェアを顧客に確 の認識で関係者が一致した．この二つのミーティングに 認してもらうことがアジャイルの長所であるが，前述の より，上手くいったこと，失敗したことについてチーム とおり PFU では市場調査の結果を要求事項としている メンバーで活発に話し合い，次のイテレーションでの改 ことから開発段階では実際の顧客はいない．そこで，仮 善に繋げ，それを繰り返す． 想顧客として品質保証部門（以降，品証部門と記す）が 以上のような特長により，品質を確保した上で，開発 担当することとした．品証部門は，開発した製品を第三 期間を短縮することができると考え，PFU アジャイル 者視点で検証する部門であり，これまでは最終工程の運 の実証実験に着手した．表－２に特長と期待効果を示す． 用テストを担当していたが，今回の PFU アジャイルで は，仮想顧客として開発部門と一体となって源流から品 質保証に取り組むこととした．イテレーションごとに開 4 PFU アジャイルの実証実験 発された機能を第三者視点で検証し，イテレーション単 PFU アジャイルの実証実験は，最初，自社ハードウェ 位で品質積み上げを行ったうえで，最終的に製品として アの状態監視や資源配布を制御する集中管理製品の開発 36 PFU Tech. Rev.,22, 1, （05,2011） ソフトウェア開発期間短縮の取組み プロジェクトから始めた．開発メンバーは短工期，低コ スト，高品質を目指して試行錯誤を繰り返し，ベースと えて実装しがちだった過剰な作り込みを排除した． （４）設計書の簡略化 なる方法論をみがき上げた．以降，開発体制の異なる別 設計書は形式にこだわらず，関係者が議論できる内容 プロジェクトにも適用拡大し試行と改善を重ねている． に留め，検討時間を増やすことで設計内容を充実させた． 以下ではこれら適用プロジェクトの取り組み内容と成果 その際のメモ（紙） ，ホワイトボードの記述内容を電子 を紹介する． 化して設計書を補う情報として蓄積した．また， イテレー ションの成果物（プログラム）を実際に動作させること ４. １ 自社ハードウェア集中管理製品での適用 自社ハードウェア集中管理製品の開発プロジェクト は，対象とするハードウェア製品が異なる複数製品を並 で詳細仕様を関係者間で確認し合った．その結果，関係 者の仕様理解が深まるという副次的な効果も得られた． （５）開発量のコントロール 行開発しており，慢性的な工数不足や一方の製品開発が 一般的にコーディング量が小さいほどバグ（誤り）を 遅延すると他方にも影響が波及するといった様々な問題 作り込む可能性は低減するが，コーディング量が小さけ を抱えていた．こうした問題を根本的に解決するために れば生産性は上がらない．このプロジェクトでは何回か は，これまでのやり方の延長線上の改善では限界がある イテレーションを繰り返す中で，一回のイテレーション と判断し，従来型の開発プロセスとは全く異なるアジャ におけるコーディング量を調整し，品質と生産性のバラ イル型開発に挑戦することを決めた．本プロジェクトで ンスからメンバー一人当たりの最適値を算出し，見積り の取り組み内容を以下に記す． の目安を決めた． （１）KPT 注１） を用いたイテレーション毎のふりかえり 会 （６）イテレーションの分割 一つのイテレーションで開発する項目は，開発対象を このプロジェクトでは KPT 法を使ってイテレーショ 機能や要素に分割して決定するが，単純に分割するとイ ン毎のふりかえり会を実施し，良かったこと・上手くで テレーションごとの独立性が保たれない．項目分割はア きたこと，問題点，問題解決のための施策をチームメン ジャイル開発の重要ポイントであり，高度な技術を必要 バーで話し合った．ふりかえり会で決めた施策は次のイ とする．適用にあたり開発対象に精通し，かつ熟練した テレーションで直ぐに実行し，その効果も直ぐに判るた 開発者をチームに加え，イテレーションを繰り返す中で め，PDCA サイクル 注２） が短縮され，従来に比べ改善ス ピードが格段に向上した． （２）開発人員と開発環境のフル活用 2 週間毎に要求の変化と進捗状況を勘案し，開発人員 と開発環境が十分活用できるように開発計画を適宜見直 最適な分割方法を探求した．これにより機能や項目要素 の相互依存や独立性を見極めた分割ができ，以降の開発 で発生するイテレーション間の相互影響や手戻りを排除 した． （７）第三者レビューと早い段階での検証実施 した．次に開発を計画している機能の仕様決定が停滞し 仮想顧客として第三者視点で検証する品証部門を加 ている場合は，次回以降のイテレーションで開発するこ え，多角的な視点で設計及びテスト項目をレビューし， ととし，直近のイテレーションは別機能の開発に注力す 後工程での手戻りを防止した．さらに，イテレーション ることで開発メンバーに極力待ち時間が生じないよう努 毎に完結した機能を早い段階から品証部門が検証するこ めた． とで，早期仕様決定と品質確保に寄与した．なお，設計 （３）過剰機能の排除 製品として提供する機能を複数の単純化した要素に分 段階から品証部門のノウハウを共有したことで，お客様 視点の思考がチームに根付くという効果もあった． 解し，重要な要素から順に実装した．単純な要素を必要 なだけ積み上げていくことにより，従来は仕様変更に備 注１） KPT 法：KPT は，Keep，Problem，Try の頭文字であり， Keep は良かったのでこれからも続けたいこと，Problem は問 題だったこと，Try はこれからやってみたいことの三つの観点 で活動をふりかえる手法である． 注２） PDCA サイクル：Plan-Do-Check-Action サイクルの略．計画， 実行，評価，改善の管理サイクルの意味． PFU Tech. Rev.,22, 1,（05,2011） ４. ２ 開発拠点が分散する製品プロジェクトでの 適用 実証実験の次ステップとして，開発部門と品証部門の 拠点が分散した製品開発プロジェクトでの適用を試み た．アジャイル型開発はチークワークを重視することか ら，適用の前提として一つの拠点に集まり開発すること が望ましいとされている．PFU の主たる開発拠点は東 37 ソフトウェア開発期間短縮の取組み 京地区と石川地区に分散しており，チーム間の連携を強 とで PFU アジャイルの取り組みを海外部門と共有でき 化することで PFU アジャイルが分散開発で適用できる た． かどうかを検証した． （１）チーム間の連携 （２）コミュニケーションの醸成 言葉の違いについては現地通訳を介して進めることは 拠点が離れたチーム間で行うレビューや打ち合わせは できるが，通訳を介し，かつ電話会議が主流の環境で実 環境確保の面から，臨機応変に日程調整することは難し 施するレビューや打ち合わせでは，内容を説明するにあ い．連携が必要となるスケジュールは，キックオフ会で たり，議論の要点や資料の説明箇所をその都度確認する 必ず調整し，事前に TV 会議や電話会議などの環境を確 必要があり，意思疎通が図りにくかった． 保することで確実なチーム連携を行い，検討遅延のリス 拠点が離れすぎているため，一時的な要員の拠点集結 クを解消した．また，初回のイテレーションは関係者が も困難であり，コミュニケーションを醸成しスムーズな 一拠点に集まり対面で作業（キックオフ，設計レビュー， 意思疎通をおこなう環境が必要となった． テスト項目レビュー，ふりかえり会）を実施し，イテレー 開発拠点が 1 箇所の場合は，関係者が物理的に，場， ション開発の進め方やチーム間の思いを共有したこと 資料，検討結果などを共有している．海外との電話会議 で，活発なコミュニケーションが取れるようになりチー では，場は共有できるが，資料や検討結果は各々が準備 ム間の連携が強化された． し言葉でのみ説明していたことから，これらを各拠点の （２）拠点集結による連携 画面で共有しながらコミュニケーションできるツールを 拠点間で連携してスピード解決が要求されるトラブル 選定し活用した． や，短期間に集中検討して結論を出す必要がある案件な 結果，説明箇所や指摘を逐次画面共有しながらリアル どの対応は，直接対面で連携できない分散開発の弱点と タイムで確認することができ，その場で指摘した内容を いえる． 双方合意のうえ即レビュー資料へ反映することが可能と 即効性を必要とする案件は解決に時間をかけるとイテ なった．画面を共有して進められることで，議論の要点 レーションへの影響が大きいことから，分散開発であっ が視覚的に分かるようになり作業効率も向上した．なお， ても必要に応じて関係者が各拠点に集まり連携を強化す 対面での作業ができることから国内の分散開発で行った ることで，問題の解決を迅速化した． 「一時的な要員の拠点集結」のリスク対策としても有効 となった． ４. ３ 海外開発製品への展開 国内の分散開発において適用の目処が付いたことか ら，海外のグループ会社で開発している製品をターゲッ トに，海外拠点との分散開発（海外の開発部門と国内の 品証部門）についても適用できるか検証した． （１）PFU アジャイルの伝承 5 取組成果 適用した三つの製品開発プロジェクトにおける取組成 果について，定量的評価と定性的評価を行ったので以下 に報告する． 海外展開を行うにあたり品証部門が現地に入り，PFU アジャイルの仕組みを教育した．また初回のイテレー ション開発時は現地入りした担当者がキックオフ会，各 種レビュー会，ふりかえり会に参画すると共に，実務を 通して訓練して作業プロセスの共有化を図った． 第 2 回のイテレーションは国内から海外開発者と遠隔 ５. １ QCD 向上成果 適用した三つの製品開発プロジェクトにおける QCD 向上成果を図－２に示す． Ｄ：開発期間（月数）で 26 ～ 33 ％短縮， Ｑ：品質（設 計～プログラミング工程で検出した不具合指摘数割合） で設計やテスト項目レビューを実施することで海外拠点 で 18 ～ 29 ％前倒し， Ｃ：生産性（開発量／人月）で 1.5 におけるコミュニケーション課題を抽出した（詳細は次 ～ 2.3 倍の向上が見られ，PFU アジャイルの有効性が 項に記す） ．第 3 回のイテレーションは海外展開におけ 確認できた． る課題解決の場と位置づけ，再度現地入りして，レビュー や打ち合わせ時のコミュニケーションを改善したことで 意思疎通が強化されると共に打ち合わせ結果の理解も深 まった．また，イテレーションを重ね実践を体験したこ 38 ５. ２ 現場の声 各適用プロジェクトの現場担当者の声をヒヤリングし た（表－３参照） ． PFU Tech. Rev.,22, 1, （05,2011） ソフトウェア開発期間短縮の取組み ● A プロジェクトの QCD 26％短縮 1 Q：品質 新手法 設計 プログラミング 0.74 従来手法 プログラミング ０％ 新手法 C：生産性 （※従来手法を 1 として比較） 1.5 29％前倒し 設計 従来手法 デバッグ テスト D：期間 （※従来手法を 1 として比較） 20％ 40％ 60％ 1 テスト デバッグ 80％ （コスト 30％削減） 100％ 従来手法 新手法 ● B プロジェクトの QCD 30％短縮 1 Q：品質 新手法 設計 プログラミング 0.7 従来手法 プログラミング ０％ 新手法 C：生産性 （※従来手法を 1 として比較） 2.3 29％前倒し 設計 従来手法 デバッグ テスト D：期間 （※従来手法を 1 として比較） 20％ デバッグ 40％ 60％ 1 テスト 80％ （コスト 57％削減） 100％ 従来手法 新手法 ● C プロジェクトの QCD D：期間 （※従来手法を 1 として比較） 33％短縮 1 Q：品質 新手法 設計 0.67 従来手法 設計 従来手法 ０％ 新手法 デバッグ プログラミング C：生産性 （※従来手法を 1 として比較） テスト 1.7 18％前倒し プログラミング 20％ 40％ デバッグ 60％ テスト 80％ 100％ 1 （コスト 40％削減） 従来手法 新手法 ●図—２ 実証実験での QCD 向上効果● （Fig.2-Effects of improving QCD through demonstration tests） ●表—３ プロジェクトの現場担当者の声● PFU アジャイルに取り組んだ多くの開発者から改善 の実感が報告されており，次回以降の適用継続や他製品 現場担当者の声 1 2 検証が素早くできた． 開発期間が短いのでアラームが早く上がり，開発の停滞がな かった． イテレーション毎にふりかえりが実施されるので，改善・効 3 4 5 開発への展開が期待されている． イテレーション毎の開発量が小さいので問題検出後，修正・ 6 今後の取り組み PFU アジャイルは，QCD 向上成果は確認できたが， 果検証の機会が多かった（ふりかえりで気づいたことをすぐ 開発期間半減という目標はまだ達成できておらず，継続 に次イテレーションで改善できた）． して期間短縮の取組が必要である．また，開発対象をイ 開発の区切りが常に近くにあり，成果が見えてモチベーショ テレーション毎に分割できる技術の形式知化や，見積り ンアップにつながった（ゴールが分かりやすくやる気がでた）． 精度の向上など，実証実験を通して得られた課題につい 品証部門のレビューへの参加で技術者以外の観点でレビュー て分析し PFU アジャイルの改善を進めて行くと共に， ができた（上流工程の品質確保ができた）． 成果やノウハウを社内で共有し，更に PFU アジャイル の適用シーンを拡大していく． PFU Tech. Rev.,22, 1,（05,2011） 39 ソフトウェア開発期間短縮の取組み 7 むすび PFU アジャイルの実証実験では，約 30 ％の開発期 として活用することで，開発担当者のモチベーション向 上効果や，開発部門と品証部門とのコミュニケーション の活性化効果も生んでいる．本手法の適用拡大を通じ， 間短縮を達成し，この手法が顧客要求に基づくアプリ こうした開発現場の仕事の達成感ややりがい向上につな ケーション開発だけでなく，一般市場向け製品の開発に げることができれば，さらなる自律的な組織集団の進化 対しても十分に適用可能であることが分かった．また， に寄与できる． 同時に品質確保の前倒しや生産性向上といった面でも有 効性を確認することができた． 今後は 6 章で述べた課題の解決に取り組み，｢PFU ア ジャイル｣ を PFU ソフトウェア開発の標準手法として 一方，PFU アジャイルは，開発期間短縮で生み出さ 確立し普及させていくことで，ビジネスの変化や技術革 れた時間を，新技術開発のための投資や国内外技術者と 新のスピードに対応した製品をいち早く市場投入し，お の交流に振り向けるなど，開発現場にとって有益な時間 客様のビジネス機会の創出に貢献していきたい． 40 PFU Tech. Rev.,22, 1, （05,2011）
© Copyright 2024 Paperzz
