プログラマの思索プログラマの思索IT業界に身をおいて、1日の労働後、心に溜まった疑問を一つずつ点検してみる。»2014/05/18エンタープライズアジャイルは「アジャイル開発が大人になった姿」らしい日経コンピュータ2014年5月号の記事にエンタープライズアジャイルの記事があったのでメモ。【1】日本でもアジャイル開発の流れが来ている、という記事。平鍋さんが「エンタープライズアジャイルについて、アジャイル開発が成熟した大人になったことの現れ」と評価している文章が興味深かった。事例はいくつかあがっていた。」本にあるような日本発の事例や運用ノウハウが紹介されていなかったのは残念かな。僕は、RUPの案件に開発者として携わった経験があるが、正直、WF型開発と何ら変わらない印象を持っているので、RUPそのままでは日本には受け入れ難いだろうと思っている。【2】記事を読んで、エンタープライズアジャイル、つまり、基幹系業務システムの開発にアジャイル開発を導入して成功させるには、少なくとも2点は抑えるべきポイントがあると思う。一つ目は、全体見積りや開発スコープが未確定になりやすい問題をどのように解決するか。一つは、請負契約と委任契約の2つの契約スタイルをどのように使い分けて契約すべきか。【2-1】前者は、アジャイル開発では、頻繁にVerUpしながら機能を拡張し、品質を改善していく開発スタイルなので、全体見積りができず、開発スコープが未確定になりやすいこと。普通は、ユーザ企業が年間の予算を立てて、その予算枠内で開発するから、最初に全体見積りが必要になる。リーンスタートアップのように、まずはWebサービスをとにかく作って提供し、ユーザの反応を見ながら機能拡張していく開発スタイルは、基幹系業務システムの開発には流石に合わない。ユーザ企業の情報システム部門からは、必ず、システムの全体見積りを問われるからだ。最初に要件定義で、システム全体の開発スコープを確定させるわけではないので、開発スコープがあいまいになりやすい。すると、スコープクリープという問題が発生しやすい。リーンスタートアップでは、最初にシステムのゴールを確定せず、状況に応じてゴールを変える。基幹系業務システム開発では、ゴール不明のシステムは、投資対効果(ROI)を計測しにくい。投資対効果を考え、数年先を見据えたビジネスモデルを提示しなければ、そのままでは受け入れ難い。【2-2】前者の問題については、ハイブリッドアジャイル開発やウォータースクラムフォールという開発スタイルである程度解決されている。要件定義や外部設計のレベルまできちんとモデリングして、見積りや開発スコープを確定してから、アジャイル開発を実践する方が安全だ。ウォータースクラムフォールのような手法は、大規模なWF型開発において、要件定義~外部設計や委任契約で作業して、外部設計終了後に再見積し、開発工程以降は請負契約で進めていく手法の考えとほぼ同じだと思う。外部設計レベルまで実施しなければ、開発スコープの確定はできないのだ。」の本を立ち読みしただけにすぎないので完全に理解していないけれど、DADもSAFeも、ウォータースクラムフォールに似た開発スタイルのように感じた。【2-3】後者の問題の本質は、アジャイル開発は本来、請負契約が向いているのか、委任契約が向いているのか、という話だと思う。請負契約はSIに成果物責任があり、瑕疵担保責任も負う。委任契約は、SIに成果物責任はなく、工数ベースの作業に過ぎず、作業報告書だけでSIがお金をもらえる。普通は、アジャイル開発は委任契約が向いていて、成果物を明確に定義する請負契約は相容れないと言われていた。日経コンピュータの事例でも、すべての開発作業を委任契約している事例もあった。プログラマの思索しかし、僕は、本来はアジャイル開発は請負契約が向いていると思う。1~数ヶ月のサイクルで請負契約を結んで、順次リリースしていくスタイルが向いていると思う。アジャイル開発は現物主義だ。1イテレーションないし1スプリントが完了した後には、必ず「出荷可能な成果物」が作られる前提だ。イテレーションのサイクルで次々にリリースしていく「小規模リリース」こそがアジャイル開発の本質だ、と僕は思っている。1ヶ月で成果の出ない開発は、アジャイルではない。1ヶ月でリリース対象の成果物が作れない開発はアジャイルではない、と思う。リリースできる成果物があるからそ、ユーザもスプリントデモでレビューできるし、開発チームも、自分たちの作業や技術のフィードバックを得て、次のイテレーションへ改善していくことができる。すると、1スプリントの単位で作る対象をスプリント計画時に立てて、開発スコープを確定しておけば、成果物責任のある請負契約を実現することもできるはずだ。実際、Scrumでも、スプリント実行中の期間は、スコープは固定だ。途中からの割り込みは受け付けられないのが基本だ。すると、1ヶ月単位の請負契約を小刻みに契約している開発スタイルがアジャイル開発に向いているのではないか、と思う。「最初にシステム全体の見積りや開発スコープを確定できない」問題があるので、最初の数イテレーションは、要件定義と外部設計を行う期間を別途設けるのが現実的だと思う。XPやScrumでも、新しいフレームワークなどの技術を検証したり、開発環境を整えるだけで成果物を出さないという、Zeroリリースないしアーキテクチャスパイクという特別なイテレーションを持つ。最初の数イテレーションは、新しいフレームワークやクラウド環境でプロトタイピング開発したり、要件スコープを概算見積もりできるレベルまで要件定義と設計を行うようにすると良いと思う。【3】いわゆるハイブリッドアジャイル開発については、以前Blogで、考えられるパターンについて書いてみた。プログラマの思索ハイブリッドアジャイル開発の中でも、ウォータースクラムフォールは一番使われる開発スタイル。保守作業でも、上限となる工数をあらかじめ決めておき、実施中に要件の優先順位を入れ替えながら順次リリースしていく「リーンWF」というやり方もある。「リーンWF」も請負契約でやりやすい開発スタイルだ。他にも色々考えられると思う。業務系エンジニアが生き抜くのは難しい時代になった(2019.06.16)IOTは組立加工工場を中央制御型工場へ変える(2019.05.31)規模の経済と経験曲線効果のメモ(2019.05.31)IT企業が経済学者を雇い始めた理由が面白い(2019.04.22)ポーターの競争戦略の考え方(2018.11.16)コメントコメントを書く名前:メールアドレス:(ウェブ上には掲載しません)アドレス(URL):この情報を登録するコメントは記事投稿者が公開するまで表示されません。License:このBlogに書いてある内容を実践する場合、すべて自己責任で行ってください。日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。Redmineによるタスクマネジメント実践技法Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。実践ソフトウェアアーキテクチャソフトウェアアーキテクチャとは何か、アーキテクトの役割は何か、という命題について解説した本。ソフトウェア開発を突き進めると、目に見えない秩序、つまりソフトウェアアーキテクチャの存在にぶち当たる。ソフトウェアアーキテクチャは必ずソフトウェアプロダクトラインにぶつかるように、この本の内容の背後にもソフトウェアプロダクトラインが隠れている。selection)データベース設計を具体例を元に、物理設計や論理設計、データモデルパターンなど網羅的に解説した本。IDEF1のER図はやや取っつきにくいが、一般的なDOAの設計手法はこの本1冊で十分と思う。SELECTION)SEの観点で業務システムに関する業務ノウハウをまとめた本。め、支払サイト、EB連携などの日本特有の業務ノウハウを、SEにとって必要な内容として網羅的にまとめられている。ソフトウェア開発の実践)アジャイル開発におけるテスト管理、リリース管理、ビルド管理などの観点を詳しく解説した本。アジャイルテストの4象限の図は、とても分かりやすい。変化に強い大規模開発を成功させる14のベストプラクティス」と共に、Agile2.0時代においてアジャイル開発に関する必読の書籍の一つ。Archive)XPが出た2000年初頭に出現した初期のAgile開発では、その利点は受け入れられたものの、スケールアップが難しいなどの弱点を言われ続けてきた。Agile開発を大規模プロジェクトへ応用してみようとする動きがある。この本はまさに「アジャイル開発をスケールアップするには何が必要なのか」というプラクティスを具体的に説明しているのが秀逸。手続き型言語と発想が全く異なる点を詳細に説明している。Haskellのプログラムを書く前にこの本で思想を押さえておくと良い。Archive―ソフトウェア開発の課題)構成管理のパターン集。メインラインモデルに関して唯一説明されている構成管理の本。要求をどのようにまとめていくか、解説した本。第5章「変更への対応に関する選択肢」では、結局、アジャイル開発とメインラインモデルで運用している場合はタスクブランチが最適な解決策だと詳しく説明されている。【第2版】PMBOKを初心者向けに解説した本だが、中身はとても詳しく説明されているのでお勧め。プロジェクト管理のノウハウはアジャイル開発に簡単に応用できるので、知っていると理論的に補強できて強みになる。入門Git分散バージョン管理Gitの解説本。Gitの使い方だけでなく、オープンソースの主流の開発手法であるパッチベースの開発フローについても詳しく説明されているのでお勧め。分散バージョン管理Mercurialの唯一の解説本。MercurialのWindowsクライアントTortoiseHgを使いこなすなら、この本は必須。家計簿、プロジェクト管理、医療などの実例をDOAで解説した本。Railsで作れば、業務設計のノウハウも理解できるだろう。開発のプロジェクト管理本の中で3本の指に入る本。マイクロソフト社でのプロジェクト管理の実体験を通じて、プロジェクト管理のライフサイクルに沿ったノウハウが説明されている。本番用ソフトウェア製品の設計とデプロイのためにリリース作業や本番運用、スケールアップに関する技術書。アジャイル開発では頻繁にリリースできる技術力を前提とするため、この本に書かれているノウハウはとても貴重。小規模リリースが何故優れているのか、技術面だけでなくビジネス面でも説明されています。―アジャイルとオブジェクト指向によるソフトウェアイノベーションM.ファウラーが在籍するThoughtWorks社のエッセー。随筆のように書かれていて分かりにくい部分があるが、それらのアイデアは非常に優れていると思う。オブジェクト指向の次に来るIT技術の将来性を語っている。~価値あるソフトウェアを育てる概念と技法~Scrumを実践する時の必読書。イテレーション計画や工数見積もりのノウハウが書かれている。――ソフトウェア開発・プロジェクト管理活用ガイドTracをプロジェクト管理としてどのように使うか、挿話を交えて分かりやすく説明されています。Linux/Windows対応Redmineのインストール方法について詳細に説明されています。-もっと手軽にプロジェクト管理!RedmineをAmazonEC2で稼働する技術が説明されています。現場リーダーや開発者の観点でRedmineをどのように運用すべきか、少し触れられています。PerlはJavaやCと違い、短く書くことを洗練する方向が向いている。ファウラーが業務系Webシステムの設計思想を語り尽くした本。Javaと.NET共に解説しているのが大きな特徴。.NETの本質を理解したいなら、この本が一番いい。(自己実現編))ドラッカーの経験談も含まれた自己実現のための本。現代の全てのホワイトカラーの仕事にマネジメントが必ず含まれているという指摘は鋭い。Language)古いけど、Rubyの生みの親が書いたRuby解説書。書き方の初歩や実行の仕方から、デザインパターンや設計手法、Rubyの隠された機能まで解説している。デザインパターンはRubyのAPIに組み込まれているため、Javaよりもはるかに理解しやすい気がする。最高のチームづくりと革新的な製品の法則アジャイル開発の手法を取り入れた製品開発に関する本。キャリアを考える技術・つくる技術ビジネスリーダーになる人のための転職術の本。キャリア戦略を考える時、担当者、ミドルマネジメント、トップマネジメントにはマネジメントという仕事の断層があるという指摘はどこの業界でも通用する。プロジェクト提唱者の羽生さんが書いた本。後半のプロジェクト管理の章は経験に裏打ちされた話で重みがある。リーンソフトウエア開発~アジャイル開発を実践する22の方法~トヨタ生産方式をソフトウェア開発に応用させた本。「決定をできるだけ遅らせる」「プロセスの無駄を徹底的に省く」等の主張は目から鱗が落ちる。Foundations)数々のユースケース解説本の中で内容がピカイチ。ユースケースの粒度や詳細化の方法が詳しく書かれている。(ブルーバックス)意図を正しく伝えるための表現テクニックを解説した本。プレゼン資料の構成のヒントになる。(朝日文庫)分かりやすい日本語の文章を書くためのテクニックを解説した本。時代を超えたプログラミングの基本原則を説明している唯一の本。Principleやコンポーネントの基本原則も解説されている唯一の本。agile!)日本人が書いたテスト駆動の紹介本。Injectionやトヨタ生産方式の比較などにも触れている。頁数だけでなく内容も分厚い本です。アンチパターン―ソフトウェア危篤患者の救出プログラミング、アーキテクチャ、プロジェクト管理で頻繁に経験する失敗例をアンチパターンとしてまとめたカタログ本。気軽に読めて笑えるが、我に戻ると悲しくなる時がある。デッドライン―ソフト開発を成功に導く101の法則ガモフが書いた物理学の物語を真似て書かれたプロジェクト管理の空想物語。ソフトウェアを開発するチームの運営手法について考えさせられる物語。Series)オブジェクト指向モデリングを突き詰めると結局読まざるを得なくなる。手軽に理解できるらしい。使いがC言語を理解するための本。プログラミング言語の進化の歴史を垣間見る事ができる。オブジェクト指向における再利用のためのデザインパターン言わずと知れたデザインパターン元本。再利用絡みの話は全てこの本のアイデアを元にしている。添付CDにあるhtml化されたデザインパターンカタログが意外と役立つ。Series)ファウラー本で最も読みやすく実践的な本。Javaでオブエジェクト指向プログラムを書くなら、この本をバイブルにすべし。オブジェクト指向分析設計と反復型開発入門プログラマが最も悩む「メソッド配置」は「GRASPパターン」で解決できる。実践UMLは初版で勉強したが、版を重ねるほど内容が濃くなっている。業務別データベース設計のためのデータモデリング入門DOAの観点で書かれた業務設計・データモデリングの本。渡辺さん独特の説明がとても分かりやすい。Railsが流行して更にDOAの必要性が高まったように思う。DBさえできればすぐにWebアプリを作れるから。システムのためのデータモデリング日本人が書いたアナパタ。(日経ITプロフェッショナルBOOKS)やっと出た!まともに使えるUMLモデリング本RSSを表示する。