経営者、管理者にとってのアジャイル開発
Embedded Files
ホーム＝＞グループ見出しページ＝＞詳細ページ
経営者、管理者にとってのアジャイル開発
コンテンツ
はじめに
何故アジャイル開発が良いのか？
アジャイル開発は、ソフトウェア開発での「トヨタ生産方式（ＴＰＳ）」
フラット化する世界に合致した開発手法
２１世紀に向けた新たな動き
参考資料
アジャイル・マニフェスト（2001）
マニフェストの思想を支える重要な方針（原理）
アジャイル開発経験事例報告（あるエンジニアの声）
パイロット・プロジェクトの外部評価
アジャイル・エンジニア育成コース体系
はじめに
2002年9月18日コネチカット州ノーウォークでのFASB（米国、財務会計基準番議会）とIASBEC、国際会計基準審議会）の合意に基ずき同年10月29日に将来の会計基準の収数化に向けた“きが交わされました。2004年10月にはASB」（日本、企業会計基準委員会）とIASB間で共同プロジェクトの立ち上げが合意されて、いよいよ2009年4月1日以降の事業年度から会計コンバージェンスの下、新会計基準が適用されます。
特にこの新会計基準では、ソフトウエア明発に対して「工事契約に関する会計基準」として、工事進行基準を優先的に適応し、乳を満たす場合には強制される様になりました。
とは言え、従来からのウォーターフォール型ソフトウエア開発ではどの様に工事進行基準に適応できるでしょうか？
プログラミング工程が80%完了と報告を受けても、経営者、管理者として、素直に受け入れる事が可能でしょうか？どの様に精級な進捗報告を入手しても、残り20%の残作業中に問題が発生することは無いでしょうかっまだ確実に工期通りに工事が完了する
保証があるでしょうか？
残念ながら従来のウォーターフォール型ソフトウエア開発手法では、この株な問いかけに対して、明快な回答を提供する事が出来ません。既に皆様お気付きの通り、ソフトウエア開発作業が「見える化』されなければ、この問題を解決する事が出来ません。
ソフトウエア開発作業の『見える化』とは、稼動するプログラム（コード）が全システムの予想ブログラム本数の内の何本が完了したか？と言った形での進歩管理が望まれます。がその様な事が可能なのか？という疑問ももたれると思います。
今世紀に入って（2000年以降）欧米で提唱されておりますアジャイル開発は、このソフトウエア開発作業の「見える化』が可能になります。
また、1週間とか2週間と言ったイタレーション（反復での)で開発作業が進行いたしますので、月末、四半期末での工事進行基準での収益、原価の把握（収益認識基準）が容易になります。
まだまだこのほかにも経営者、管理者にとってのメリットがあります。当資料は経営者、管理者の皆様にアジャイル開発がどのようなメリットをもたらすか？この素晴らしいソフトウエア開発手法を導入する為には、何が必要か？を出来るだけ解り易く紹介いたします。
我々NPOドットNET分散開発ソフトビア・センターでは、このアジャイル開発エンジニアの育成とこの新しい開発手法をより効果的にピジネス・フィールドで適用できるツール等の研究開発を目的として、岐阜県大垣市のソフトピアジャパン内に設立いたしました。
我が国のビジネス-システム向けアジャイル開発の提点となるべく活動を展開いたしております。
ご興味のある方は、是非一度当NPOの開発プロジェクト・ルームを見学ださい。歓迎いたしております。
1．何故アジャイル開発がよいのか？
ウォーターフォール型開発の問題ー１
来のウォーターフォール型ソフトウエア開発とは、システムの要件を整理した後、システムの設計を行い。その設計者に沿ってプログラムを開発し、完成したプログラムをテストして最終的には対象システム全体での統合テストを完了して、納品（サービス提供）稼動されます。この様に水が高い所から低い所に向かって流れるように作業が進展していく事からウォーターフォール型開発と言う名称があります。
この手法の最大の問題点は、プロジェクトの最終段階である統合テストが実施されるまで、そのシステム（ビジネス・プロセス）が成立するか？破綻するか？が断できない事であり、万がートラブルが発生すると、逆順に作業工程を湯って原因の追究と解決をしなければなりません。
その分、時間と人工と言う多大なコストが掛かります。経営資源がトラブルの解消と言う後ろ向きな作業に費やされる事になります。
一方アジャイル開発では、基本的な手順として、重要度の高いプロセス、リスクが見込まれるプロセスなどクリティカル・パスからプログラムが作成され、作成されたプログラムは完成後難度と無く統合テストが繰り返される為、プロジェクト（工期）の終了時点までに完成度が高まります。
またプロジェクト開始直後からそのシステム（ビジネス・プロセス）が成立するか？綻するか？を判定できますので、プロジェクト投資の安全性をプロジェクト開始直後に担保できます。
２．何故アジャイル開発がよいのか？
ウォーターフォール型開発の問題-2
プログラム開発の『見える化』
従来のウォーターフォール型ソフトウエア開発で皆様どの様に作業進歩を把握、管理されているでしょうか？また従来の手法で満足（納得）出来るでしょうか？如何に精数な管理を行なっても設計工程が60%完了しましたとか、プログラミング工程が80%完了しましたと言った報告で、そのシステムが納期（工期）通りに完成して、当初（ユーザー要求通り)の機能を提供できると言う事を最終テスト以前に確信を持って言い切れるでしょうか？
残念ながら、現在のウォーターフォール型ソフトウエア開発では否としか言えない無いのでは、ないかと思います。この最大の問題は、作業工程が『見える化』出来ない事に起因しております。どの様に考えても現在のウォーターフォール型ソフトウエア開発では、不可能でしょう。それは前述いたしました様に、プロジェクトの最終工程の統合テストを行なうまで、何が完成して、何が機能していないのか？プロジェクトの途中では判定できないからです。
またこの様な流れ作業的な進め方で、完了の基準を途中に求める事が困難である為です。従って、従来のウォーターフォール型ソフトウエア開発では、便宣的に流れる作業の完了（目に見える成果物ではなく）をもって、進歩を把援せざるおえません。
一方、アジャイル開発では、毎週、動くプログラムの完成をもって作業の進捗を把在いたしますので、明確な進度を把握できます。
また今週の作業予定はタスクボードにポストイットに記入されて貼られておりますので、チームの全員が目で見て進捗が把握できますし、作業完了もバーンダウン・チャートにより動くプログラム（就合デストデア）本数によってカウントされます。
３．アジャイル開発は、ソフトウェア開発での「トヨタ生産方式」
「経済財政改革の基本方針2007」では、重要課題として労働生産性を5年間で50%増にすることを目標にしており2007年5月には、「サービス産業生産性協議会」（牛尾治朗代表幹事）が発足しました。この様な大きな流れの中で、今後、具体的にどの様にすべきか？がソフトウェア産業として課題となります。またサービス産業の分野でも、製造業にて着実に生産性向上を実現しているトヨタ生産方式(TPS)が着目され実際に導入されて成果を上げております。
一方で我々ソフトウエア産業では、3Kや5K、最近では7Kと言った言葉が噛かれ、労働生産性どころか、若手の情報産業離れで有能な人材を確保することも困難になってきております。
欧米でのアジャイル開発には九種の手法が存在しますが、どの手法の説明でもアジャイル開発の基本はトヨタ生産方式(TPS)である事が書かれております。1983年に出版されたTPSの英語訳本より欧米では、このTPSを研究していろいろな分野に適用して来ました。ソフトウエア開発の分野で適用された手法がアジャイル開発です。因みにアジャイル開発の一手法の名称であるスクラム(Scrum)とはTPSの中で説明されているスクラムを語源といたしております。
アジャイル開発の基本はTPSで言われる現場、現実、現物の現場（開発チーム）主体でのソフトウエア開発です。また製造業の生産工程で言われている単能工(ウォーターフォール型開発）から多能工（アジャイル開発）へのソフトウエア・エンジニアの変華で有ります。
当NPOでのパイロット・プロジェクトの実績からも開発チーム主体（プロジェクト・マネジャー不在）でのプロジェクト運営が実現でき、高品質なプログラム作成を残業や休日出勤無で、納期（計画）通りのソフトウエア開発が可能です。結果的に生産性、品質、お客様からの信頼感が飛躍的に向上いたしました。
４．アジャイル開発と「トヨタ生産方式（ＴＰＳ）」
５．フラット化する世界に合致した開発手法
5ヶ国以上で出版され世界的なベストセラーになりましたトーマス・フリードマン著作の「フラット化する世界」をお読みになられた方は多いと思います。その著作の中で述べられているフラット化する世界とは、コミュニティーネットワーク、イノベーション、コラボレーションと言う言葉がキーワードになっております。アジャイル開発はまさにこの考え方と同じ視点に立ったソフトウエア開発手法です。
従ってアジャイル開発の導入は、単にエンジニアがこの手法をマスターすると言うことでは有りません。経営者、管理者も意識変革を求められます。全てが開発チームという単位で語られます。如何にチームの生産性をマギンマイズするか？が求められます。
従来のプロジェクト管理者ではなく、チーム（組織）や個人（エンジニア）をモチベートし動かず真のファシリテーターが求められる新しい管理者像です。ここまで苦いてくれば、既にお判りと思いますが、エンジニア自身の新しい技術の習得のみならず、経営者、管理者の意識変革、受託開発ビジネス・プロセスの変革、ソフトウエア開発プロセスの変面など情報企業にとってまた企業内の情報システム部門にとって大きな変革を要求されている事です。そのベネフィットは低コスト、高品質、納期連子（短納期）でのニーサー満足度の向上できるシステム開発です。
当NPOでのトライアルでは、一般の企業と異なり上下関係（上司と部下）の無い組織の中でのアシャイル開発ですが、現場主義に徹するアジャイル開発は、充分機能いたしました。
６．２１世紀に向けた新たな動き
NPOは我が国アジャイル開発の先駆的企業であるテクノロジックアート社（長瀬名秀 代表取締役）と共にアジャイル開発手法をビジネス・システム開発分野での定着の為に他に貸同いただける企業様と協力してAgileinBusiness.orgを立ち上げました。
ビジネスシステム分野でのアジャイル開発を導入中の皆様にアジャイル開発、ソフトウエア生産技術など関連する情報の提供と経験事例の共有を促進したいと考えております。
また当NPOで試験的に経験いたしましたアジャイル開発の為の各種ツール、メンドロジーについても情報提供いたします。
現時点で提供可能なメニューは、
アジャイル明発の為のシステム要件検証ツール「ラビッド・モックアップ・ビルダー」
タカヤ社他と共同研究
アジャイル開発の為のユーザー要求早期定メンドロシー「アジャイル・デザイン・プランニング・セッション」
戦踏スタッフ・サービス社と共同研究
効果的なアジャイル開発チーム編成検討支援ツール「ESBI』
Elリサーチ社と共同研究
効果的な分散アジャイル開発チーム運営支援ツール「ライブ・スクラム」
ATMC社と共同研究
７．参考資料
ジャイル開発のご理解を深めていただく為に、2001年に米国でアジャイル開発の先駆者が集まり採択されましたアジャイル・マニュフェストとそのマニュフェストの思想を支える方針の原文（英語）と解説を付加したその和訳を添付いたします。
また、当NPOにてアジャイル開発を体験したエンジニアの感想と当NPOが開発し岐阜県にて実施しておりますアジャイル・エンジニアを育成する研修コース体系も添付いたします。
８．アジャイル・マニュフェスト（２００１）
アジャイル・マニュフェスト（2001）
我々は自ら実践し、また実装しようとしている人を支援することを通して、よりよいソフトウエア開発の方法を見出そうとしている。この活動をとおして我々は下記のようなことを価値あるものと考えるに至った。
プロセスやツールよりも、個人や相互関係を。
ツールも大事であるが、一人のエース・ブログラマーより平均的なプログラマーのチームワーク。
包括的なドキュメントよりも、働くソフトウエアを。
ドキュメントのないプログラムは最悪、しかしドキュメントが多い物よりは少ない物の方が良い。
契約折街よりも、顧客とのコラボレーションを。
成功するプロジェクトは顧客を巻き込み、定期的に顧客にフィードバックする事。
計画に従うことよりも、変化への対応を。
良い計画とは詳細な2週間の計画と荒い3ヶ月の予定であり、それ以上はメモ。直近2週間の計画を変更する事は、あらゆる点で大変困難である。
これは太字の項目をより重視すると言うことであり、細字の部分を無視して良いと言う事ではない。
９．マニュフェストの思想を支える重要な方針（原理）
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
我々の最優先事項は素早いそして継続的な価値あるソフトウェアの提供を通して顧客の満足を得る事である。
Welcome changing requirements, even late in development. Agile process harness change for the customer's competitive advantage.
開発局面の後半でも要求変更を歓迎する。アジャイルなプロセスを願容の競争優位の為の変化に利用する。
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
稼動するソフトウエアをより短かい期間を優先して、数週間から数ヶ月で定期的に提供する。
Business people and developers must work together daily throughout the project.
プロジェクト期間を通して業務ユーザーと開発者は共同して作業をしなければならない。
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
やる気のある個人を集めてプロジェクトを組織し、彼らが必要とする環境と支援を与え、仕事が完了するまで信頼する。
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
部門内、間のコミュニケーションで最も効率的かつ効果的な手法は、フェイスツーフェイスの会話である。
Working software is the primary measure of progress.
ソフトウエアが正常に機能するということが進払の基本的な評価である。
Agile processes promote sustainable development.
アジャイルプロセスは持続可能な開発を促進する。
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
スポンサー、開発者、ユーザーは無期限かつ不断に保守できるようにしなければならない。
Continuous attention to technical excellent and good design enhances agility.
技術的に優れた良い設計に継続的に配慮する事は機敏性（アジリティー）を増長させる。
Simplicity- the art of maximizing the amount of work not done- is essential.
簡素が基本一しない仕事の極大化の美学-
The best architectures, requirements, and designs emerge from self-organizing teams.
最良の構想、要求仕様、設計は自己統制された（自律的）チームより出現する。
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
定期的にチームが振り返りを行い、より効果的に出来る方法を思案し、チームの行動に協調と調整が働く。
１0．アジャイル開発経験事例報告（あるエンジニアの声）
アジャイル開発の効果：
コーディングの生産性は変わらないが、開発作業内で手戻りが無く、結果的に早く完了できる。
体験した感想：とにかく頭が疲れる。集中する。
品質が高くなる。
技術的な問題や、方式で悩む時間が少ないので効率は良い。
気を抜く暇がないので、稼働率は高い。
二人でやっているので、生産性は倍まではいかない。ただし品質が高いので、改修やテスト時の修正工数は少なくなる
ベアプロ／クロスファンクションによりソースコードレベルで情報を共有するため、自然に 可読性／ロシックのシンプルさが感じられる実装となる。
随時に動かしながら機能拡張をするため、潜在バゲンデグレードのリスクは低い。
実装が不慣れな要員がいても、ペアの粗み合わせにより品質の高い実装が可能となる。
作業の完了が、視覚的に理解できる。実装の成果がすぐに見れる。
スタンドアップミーティング／振り返り／タスクの割り振りによりメンバー全員が全休の作業を見せる。可会を持ち回りすることにより参加意識が強調される。
人に見られているのに、適当な（動けばいい）コーディングはできない。
悩んでいる時間が少ない。（臨時相談／調査）
具体的な目標を随時持つことができる。
タスク担当を明確にすることにより、責任囲の当事者倉誠を持つことができる。
１1．アジャイル開発経験事例報告（あるエンジニアの声）
アジャイル開発の効果：
生産性が上がった（体感）。
体験した感想：個人のコミュニケーション能力が高く問われる
二人で作業を行っているため、単他ミスも少なく精度が高い。
思った以上に疲れる。気を抜く服がない。
１2．パイロット・プロジェクトの外部評価
パイロットP」(OJT)発注者（JQ上場企業）
岐阜のエンジニアのスキルは高く優秀ですね。
今までにこんなに早く（期間的）動作するプログラムをリリースいただいた、ことは経験していません。
納期遅れが全く無く、システム開発の見える化ができているのは素晴らしい。
発注者側の提示が遅くなり、開発チームへ毎回ご迷惑をかけ申し訳ございません。
日々の進歩ならびにタスク毎に進歩が明らかになっており、渡く信頼できる。
今回発注したシステム以外にも岐阜のチームにお願いしたい。
これほど早く、我々のシステムを理解した組織は他にありません。
最終納品はまだまだ数ヶ月先ですが、映する事などの心配は全くしておりません。
納品ドキュメントは責回体の標準仕様ドキュメントで結構です。
我々の会社にもアジャイル開発の説明をして欲しい。
「こんなに凄い規模・事例が日本にできたことは驚くべきことです。」
近藤 技術コンサルタント/日本マイクロソフト株式会社
１3．パイロット・プロジェクトの外部評価
大根 繁氏（株式会社一副社長専任コンサルタント）
アジャイルプロセス協議会副会長兼運営委貝長
電子協フトウェアエンジニアリング技術専門委員会委員
IPASEC 見手法部会委員
現場主義を徹底している様ですね。正に成功するパターンに岐阜のチームは入っている。
岐阜をアジャイル開発拠点化へ協力しましょう。この岐阜モデルをベースに日本全国に展開できますね。
遠隔地分散アジャイル開発へのチャレンジをしている企業・団体がありますので、是非岐阜を紹介します。
長瀬 嘉秀氏（株式会社テクノロジックアート 代表取締役）
SOIECJTC1 SC32/G2委員
情報処理相互運用技術協会(INTAP)オープン分散処理委員
電子商取引推進協議会(ECOMIXMLEDI標準化調査委貝
明星大学情報学部講師
特定非営利活動法人UMLモデリング推進協議会 理事
アジャイルプロセス協議会副会長
OSF日本ベンダ協議会DCE技術検討委貝会主査
岐阜のチームはアジャイル開発で確実に日本のトップレベルに達している。
１4．アジャイル・エンジニア育成コース体系
１5．アジャイル・エンジニア育成コース体系
コンサルティング・サービスのメニュー
ソフトウェア開発プロセスのアジャイル開発導入に因るリエンジニアリングのコンサルテーション
アジャイル・エンジニア育成の為のOJTトレーニングの指導
アジャイル開発導入の為の管理者（ファシリテーター）育成の指導
指導コンサルタント：
戸田 孝一郎（米国スクラムアライアンス認定の公認スクラムマスター）
開発プロセス・リエンジニアリングのコンサルテーション
三井 伸行
アジャイル・エンジニア育成のコンサルテーション
Page updated
Google Sites
Report abuse