プログラマの思索プログラマの思索IT業界に身をおいて、1日の労働後、心に溜まった疑問を一つずつ点検してみる。»2014/09/19「永和さんの「価値創造契約」が大苦戦を強いられている件」の記事がすごく参考になるXP祭り2014で発表された「俺の価値創造契約」の発表資料がすごく参考になるのでメモ。「この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。」という指摘はまさにその通り。cloud42エンタープライズの開発における、プロダクトオーナーとしての組織(前編)。Publickeyエンタープライズの開発における、プロダクトオーナーとしての組織(後編)。Publickey【1】僕の立場としては、アジャイル開発のビジネスモデルが確立して欲しいと思っているので、永和さんの「価値創造契約」やソニックガーデンさんの「納品のない受託開発」モデルも応援したい。資料を読むと、色々考えさせられる。したシステムはレンタル、などというビジネスモデル。3年やり始めて、受注実績は2社、3システム。テレアポ800社やっても、テレアポからの受注実績はゼロ。アジャイル開発をやりたい、という気持ちがあっても、ビジネスは別。売上を上げて、利益を確保するのは、また別のテクニックが必要なのだろう。この辺りは、最初に誰かが始めなければ、その仮説が正しいかどうかも分からない。やってみて初めて、何が必要なのか、が分かる。【2】日本企業の情報システム部門が業務システムの開発を委託する場合、彼らの開発計画に失敗や損はない。そんな予算や計画を立てたら、首になる。情報システム部門は、システムの開発を委託する場合、その投資に対する費用回収計画を作る。1年目は5千万とか1億とか投資して、その後、1年目の投資を5年で償却しながら、保守料を毎年支払っていく。その時、投資したシステムがいつ元が取れるのか、がすごく重要になってくる。受託開発がメインになりがちな、企業の社内業務システムでは、社員がどれだけ使ってくれるか、が重要だ。社員の操作頻度ないしシステム利用料から、投資したシステムの売上を計測する。その売上の累積が、費用回収計画での損益分岐点にぶち当たり、損益分岐点が前倒しになるほど、システムは成功したことになる。業務システムはさほど使ってくれないものだ。経営者が業務の効率化で導入するのであり、社員が楽しく使ってくれるために入れるのではない。普通の業務システムは、機能は豊富でも、使い勝手が悪いのが普通。すると、利用者が増えず、CIOは経営者から、あんなに高い金額で投資したのに何故システムは使われないのか、元が取れないぞ、と文句を言われがち。そんな立場にいる情報システム部門から見れば、価値創造契約は不向きなのかもしれない。システムはレンタルなので資産計上できない。お金を支払ったのに、システムは使い捨てに等しい。投資したお金は、資産にならず、その時限りの使い捨ての費用にしてしまっていいのか?そもそも、システムは重要な資産ではないのか?システムの機能改善を依頼しようとしても、チケット制の場合、社内の稟議に引っかかってしまい、なかなか発注できない、という話もありがちだ。日本の大企業では、例えば、20万円以上の仕入れは部長決裁が必要だったりするので、部長に逐一説明しなければ稟議は通らない。部長も忙しいし、詳細まで知っているわけではないから、理解できないモノは決裁してくれない。社内のシステム化方針が変わったことにより、せっかくの受託開発が中止となり、簡単に契約が破棄された、という話も、よくあるなあ、と思う。社内の基幹系業務システムは、スクラッチの受託開発よりも、ERPパッケージ製品を導入する場合が多い。スクラッチで一から作るには、情報システム部門が社内のたくさんの利用部門から要求を集めて、要件定義を確定する必要があるが、政治力がなければ、開発スコープが収束しない。普通の情報システム部門はシステム開発のマネジメント力がないから、スクラッチの受託開発は赤字になりやすい。そんなリスクを考えると、ERPをノンカスタマイズで導入し、ベンダーの保守サポートを受ける方がはるかに楽だ。【3】他にも下記の反省点が書かれていた。実際に試したからこそ、得られたノウハウ。(引用開始)失敗する前提でシステム開発をしないため、解約をメリットとして社内に説明できない。解約すれば金銭的な損害は受けないかもしれないが、再び、別の会社に発注してシステムを作り直さなければならない。運用しているシステムをERPに入れ替える方針となった。チケットの使用に承認が必要なため、あまり使われていない。チケットの使用にお客さまの社内決裁が必要となり、追加開発のために予算を確保する場合と同じフローになるという状況が発生した。最終的な仕様は弊社で決めるという『価値創造契約』のルールは受け入れられにくい。仕様は弊社で決めると言っておきながら、知っていて当たり前の業務知識についてまったく不勉強であった。開発したシステムはお客さまに納品せず、弊社の資産になるため、弊社の開発者が分かるレベルの仕様書しか残してこなかった。お客さまが自分たちのシステムとして運用していくために、必要な情報が不足した。開発時は新しいものが段階的にできていく姿を見せながらお客さまの要望を取り入れていくため、お客さまに加点法で評価していただける。運用に入ったシステムは障害発生や過去のシステムと比較して使いづらくなったなど、お客さまは減点法で評価されることが多い。システム利用料に対する成果を求められる。エンジニアの稼働に対する対価を支払うという考え方が抜けきらず、ステムの運用に入ってから、対価に対してエンジニアの稼働が少ないという不満を抱かれるケースがあった。記事を読むと、なぜ、ソニックガーデンの「納品のない受託開発」は成功したように見えるのか、不思議になる。どちらのビジネスモデルも、クラウドとRubyとアジャイル開発を前提としており、開発技術そのものは変わらない。どちらの収益の獲得方法も、受託開発からの保守利用料だ。違いが見える部分を探してみれば、開発体制とマーケットだろう。「納品のない受託開発」の開発体制は、ビジネスオーナー、プロダクトオーナー、開発チームというスクラムチームに似たような体制を作る。この体制の利点は、仕様を決める人の責任が明確であることと、システムの方向性を経営者(ビジネスオーナー)が決める事実が可視化されていることだろう。システム開発の要件定義で右往左往しづらいように思える。「納品のない受託開発」のマーケットは、ベンチャー企業のWebサービスや中小企業のWebシステムだ。社内の業務システムというエンタープライズ系のシステムが対象ではない。【5】僕の直観では、企業の基幹系業務システム開発、つまりエンタープライズ・システムの開発は、アジャイル開発に向かない気がする。「納品のない受託開発」のビジネスモデルの成功要因の一つは、エンタープライズ系のシステム開発を避けているからではないか、とも思う。鈴木雄介さんの記事を読んで思うのは、やはり、エンタープライズ系のシステム開発では、上流工程はウォーターフォール型開発で要件をある程度仕様凍結し、方式設計や分析である程度、アーキテクチャを固めることが重要なのだろう。下記の記事を読むと、開発体制の面でも、プロダクトオーナーを人ではなく組織に担当させて、組織が定期的に意思決定できる仕組みを整えている。スクラムチームに似たような開発体制を作る事が重要なのだろう。エンタープライズの開発における、プロダクトオーナーとしての組織(前編)。Publickeyエンタープライズの開発における、プロダクトオーナーとしての組織(後編)。Publickeyエンタープライズ系のシステム開発では、技術一辺倒では成功しづらい。社内の利用者を巻き込む政治力やファシリテーション力、業務ノウハウをまとめたドキュメントや利用者への手厚いマニュアルなど、技術とは別の要素の比重が高い。」を読むと、エンタープライズ系のシステム開発では、それだけでは通用しづらい面があるのだ。プログラマの思索でも、こんな赤裸々な資料を公開されている永和マネジメント様はすごく太っ腹で、すごいな、と思う。事例が少ないだけに、すごく貴重だ。【追記】9/27土に関西に倉貫さんをお呼びして、アジャイル開発のビジネスモデルについて議論します。座席はありますので、是非ご参加下さい。「確率思考の戦略論」の感想(2020.02.06)SDGsがISOのような世界基準になっている現象(2020.02.01)キャズムの感想~イノベータ理論とホールプロダクト理論(2019.06.14)IOTは組立加工工場を中央制御型工場へ変える(2019.05.31)規模の経済と経験曲線効果のメモ(2019.05.31)「Agile」カテゴリの記事Scrum@Scale入門のリンク(2019.11.09)Redmineのワークフローをバリューストリームマップで描いてみるとどう改善できるか(2019.07.03)「アジャイル時代の開発」スライド資料のリンク(2019.06.15)法律のケース問題をモデル化するアイデア(2019.02.11)「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い(2018.07.05)コメントコメントを書く名前:メールアドレス:(ウェブ上には掲載しません)アドレス(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を表示する。