プログラマの思索プログラマの思索IT業界に身をおいて、1日の労働後、心に溜まった疑問を一つずつ点検してみる。受託開発中心のSIで、顧客折衝が多いSEやシステム提案の機会が多いPMにとっては必須の本だろうと思う。感想をラフなメモ書き。普通のシステム提案プロセスでは、発注者がRFIを作ってベンダーに提示し、ベンダーは実現するシステムの内容や見積金額をRFPで発注者に提案する。日本ならば、ユーザ企業がITを使って経営革新や新しいビジネス戦略を行うための道具としてITを使いたいので、ベンダーにシステム構築だけでなく、ITを使ったソリューション、つまりコンサルティングも求める時は多い。SIが作ったシステムの運用保守もユーザ企業ではなくSI任せになりやすい。してもユーザ企業がSIへ丸投げしてしまいがちという日本特有の特徴が出るように思われる。システム提案プロセスの問題としては、ユーザ企業にとってもSIにとっても、お互いにWin-Winの関係を作るにはRFPをどのように作り、選定するためにどのように使うか、ということがあげられるだろう。ユーザ企業は自分たちのビジネスに合致するシステム構築のために、どんな観点でSIベンダーを選定すべきなのか?SIは、売上や利益のためだけでなく、顧客と共存共栄していくために、システム提案プロセスでどんな点に注意すべきなのか?この本では、RFPをSIの営業が使う道具だけでなく、発注者がSIが書いたRFPを見抜く観点も提供している点で面白い。著者の経験談が含まれているケーススタディのコラムが断然面白い。いくつか興味深い箇所だけ書き留めておく。【2】慢心を詫び再構築を依頼するユーザ企業が既存ベンダーを見切るかどうかいつも見極めているよ、というお話。あるユーザ企業のSCMは度重なるシステム追加で複雑化し、いつか抜本的な再構築が必要になると、開発を請け負ったSIは思っていた。SIからは過去の経緯もありずっと言い出せなかったが、ユーザ企業の動きに何やら不穏な動きがあるように見えた。そこで、SIのチーム内で議論した所、意見が2分されたが、再構築する方向で提案することにした。SIは再構築の提案をユーザ企業に持って行き、なかなか再構築を切り出せなかったお詫びと提案をお話した。すると、ユーザ企業のマネージャは、実は既に4社ほど当たって、再構築の提案をもらっていた。その提案を貴社から来るのをずっと待っていた、と。既存ベンダーはユーザ企業の基幹システムを一度作れば、なかなか離れられなくなるという自惚れを抱きがちだが、実はユーザ企業も賢いんだよ、という指摘。逆に言えば、新規営業のベンダーも既存ベンダーの隙を狙う機会はある。【3】RFIで受注ベンダーを絞り込むある部品メーカーの調達システムにおけるベンダー選定のお話。そのシステムはかなり特殊な部品を調達管理するために、普通のパッケージ製品には向いていないということが分かった。いう事情を書かないでRFIをSIへ送ると、見当違いのRFPが届いて、ユーザ企業も困る。そこで、RFIに、業務が分かる人向けにこういう特徴を持つEDIが欲しいと書いて、20社ほどのベンダーに送ってみた。すると、各社のRFPは効果てきめんで差が歴然としていた。一般のEDIソリューションという的外れなRFPもあれば、見事に的を得たEDIソリューションを提供するRFPもあるし、こちらの業務の特徴や問題を推測してRFIに書かなかった部分まで提案してくるRFPもあった、とのこと。RFPのうちの1社は、特注品に特化した調達EDIを扱う開発部隊を持っていたことまで分かったとのこと。このケーススタディでは、ユーザ企業もRFIをきちんと書かかなければ、ユーザ企業の要望に本当に見合うSIは見つからないということ。人間のお見合いみたいなもので、いくら安い提案をされても、ユーザ企業の要望に釣り合わなければ、お互いが不幸になる。個別指導塾のユーザ企業に、教育ソリューションを持つ有力SIベンダーがシステム提案にやってきた。ところが、その提案内容は、集合教育を想定したソリューションであり、ユーザ企業の要望に全く合致しておらず、座がいっぺんにしらけてしまった。その原因は、ベンダーが今売り込み中のパッケージ製品を売るために、安易に考えて自分たちのソリューションを押し付けたのが真相らしい。ユーザ企業にとっても、有力SIベンダーの脱落は選択肢を狭めてしまうということで痛い損失だった、と。他業界の営業マンでも、顧客は欲しがっていないのに、自分たちの商品の押し売りはよく見受けられる。当たり前とはいえ、SIの商品は数百万~数億円もする高い買い物だからこそ、的はずれな提案は禁物。【5】良い提案書とは以下の9つの条件があるらしい。・形式要件を満たす・依頼内容に対して正しく回答しているここまでは最低ライン。・RFPの漏れやあいまいさをフォローしている付加価値の部分。システムを実現する(フィージビリティ)上でどの部分が課題なのか、そしてその課題に対してどんな対策があり、その対策の効果はどう評価されるか、などを書くことが大事。いわゆるアーキテクトの観点が重視される。・具体性があり分かりやすい差別化の部分。業務系基幹システムは具体的な代物が想像しにくい。「使いやすい」「処理速度が速い」「サポートが充実」などを具体的に分かりやすく実例や場面をRFPで説明するとよい。アーキテクトの観点に含まれる。・良い話だけでなくリスクも考慮しているバランス感覚の部分。「動かないコンピュータ」という日経の記事が流行したが、夢の部分だけ語った提案書は嘘臭い。システムを実現できたら、利点もあるが、逆にリスクや弱点もあるという観点もRFPに入れると、バランスが取れたものになる。いわゆるアーキテクチャ設計のトレードオフの観点。・よく考え、悩んだ形跡がある信頼感、技術力の証明の部分。できるSEは、要件を仕様化する時に、行間を読み解いて、実装方法だけでなく、仕様が矛盾したり不整合の部分を洗い出して突き詰めていく。ユーザ企業の課題を完全に解決できる正解はないし、全てを解決しようとするのはコストや納期の観点で非現実的ということはよくある。いう試行錯誤を経たRFPは、苦心の跡を見つけることができ、プレゼンの場で鋭いツッコミに遭遇しても、ごまかしや言い逃れではない真摯な回答をしてくれるので、ユーザ企業も高く評価する。アーキテクトやストラテジストの観点が重視される。・見積金額の根拠に合理性がある・熱意が感じられる・お客様の視点で書かれているこれらも必須ポイント。【6】実は当て馬ではなかった複数ベンダーによるコンペは、当て馬になるSIや出来レースのコンペがあったりする。既存ベンダーが圧倒的に有利な立場にいる時は特にそう。いえ、ユーザ企業の要望と釣り合いが合うSIが受注しなければ、お互いに不幸だったりする。ベンダーA社はユーザ企業のシステムを20年もサポートしてきたが、最近いくつかの問題を起こした上に、ユーザ企業の信頼関係を損なっていた。とある案件で、A社以外にも数社のベンダーがコンペに参加したが、どのベンダーも消極的だった。著者はユーザ企業の立場でRFPの作成支援をしていたが、このままでは期待しているC社が脱落してしまうと懸念を抱いた。そこで、著者はQ&Aの終了後帰り間際に、C社のリーダーの肩をしっかり掴み、あなたが思っている以上にお客様は貴社に期待していますよ、と囁いた。すると、C社リーダーはびっくりしたものの、真意を察し、後日再びQ&Aの場で再提案した。すると、その議論は白熱して、夜遅くまで及ぶ中身の濃い議論になった、と。出来レースであっても、既存ベンダーとユーザ企業の関係は実は信頼関係が崩れていたりする。営業ではよくあることだが、自分たちの技術力を示して、種を蒔いておくことは大事。【7】リアルな見積が安さに勝つ3社のコンペで、著者がリアルな見積り金額を提示して受注できたケーススタディ。お客様はこっそり著者へ予算金額を伝えて便宜を図ろうとしたが、著者は何を思ったか、ちゃんと見積りを計算しますから大丈夫です、と断ったらしい。著者は後で後悔したが、腹を決めて一からスケジュールを作り見積りを計算してみた。4ヶ月の工程で、要件定義のヒヤリングはいつやって、どんなミーティングを開き、どんな成果物をどれくらい作るか、を具体的に現実的に計画を立てていくうちに見えてきた。コンペでは、著者を含む3社ともお客様の予算の枠内の数値になったけれど、著者が受注できた。後で聞くと、他のA社はお客様の予算金額に合わせてざっくり90%で見積り、B社は無理をしても受注したいがために値引きして合わせてきたらしい。お客様に、著者がお客様の予算の枠外で高かったらどう判断するか聞いた所、著者が作ったRFPとその計画書はとてもリアリティがあり魅力的だったので、予算の枠内に収まる再提案をお願いしたでしょう。他の2社とは格が違っていたから判断しやすかった、と。この話では、SIがリアリティのある見積りをすればお客様も理解してくれるし、逆にリアルな見積ができなければ、SIは最初から失敗案件を受注してしまうことを意味している。お客様の要望に見合ったシステムを開発できる技術力を持つSIをお客様も欲しがっているし、システムの実現可能性(フィージビリティ)に見合った見積りでなければ、お客様もSIも不幸という指摘。システム提案で改めて思うのは、システム提案は、ビジネスや業務に詳しいだけでなく、システムの実現可能性(フィージビリティ)を突き詰めて考えることができるアーキテクトの観点も必要なこと。たくさんの技術の選択肢から最適なものを選択し、組み立てる能力が必要とされる。他のケーススタディも興味深いので読んでみると良いだろうと思う。「確率思考の戦略論」の感想(2020.02.06)SDGsがISOのような世界基準になっている現象(2020.02.01)キャズムの感想~イノベータ理論とホールプロダクト理論(2019.06.14)IOTは組立加工工場を中央制御型工場へ変える(2019.05.31)規模の経済と経験曲線効果のメモ(2019.05.31)コメントコメントを書く名前:メールアドレス:(ウェブ上には掲載しません)アドレス(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を表示する。