要件定義を専門でやる技術者(Requirement Engineer)に関する雑感 - 勘と経験と読経
タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。 b.hatena.ne.jp 要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道 要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。 ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。 一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。 要求開発~価値ある要求を導き出す
SI案件でアジャイル開発を進めるときの勘所
みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべしステークホルダーマネジメントは重要。これはウォーターフ
ANA、国内線の旅客システムをオープン化、34年間のメインフレームの歴史に終止符 | IT Leaders
30年以上にわたり使い続けたシステムを入れ替える。企業ITに携わる人間ならば、その困難さを想像するのは難しくないはずだ。このほどANAは、8年間の歳月をかけて、国内線の予約、発券、搭乗業務を支える旅客システムをオープン化。34年間、ビジネスを支えたメインフレームに別れを告げた。プロジェクトの指揮官に話を聞く（文中敬称略）。聞き手：田口 潤 IT Leaders発行人 Photo：陶山 勉 ――今回、8年間にわたる国内旅客システムの刷新という大規模プロジェクトを終えた訳ですが、もともと、いつ頃から検討を始めたのですか？金子：“次”を考え始めたのは、2000年頃だったと思います。30年以上にわたって、メインフレームを使い続けてきましたが、そのころから限界を感じ始めていたのです。 コストについては、必要経費ですから、それほど問題視していませんでしたが、むしろ、技術者の確保には頭を悩ませていました
｢SIerでのキャリアパスを考える｣というイベントに登壇しました - GoTheDistance
403 error - Forbiddenで発表させて頂きました。発表資料をSlideShareにあげました。ご自由にダウンロードしてください。 あと、当日は結婚のお祝いということでケーキを頂いてしまいました。ひがさん、山岡さん、笠木さん、ごちそうさまでした＆ありがとうございましたー！ SIerでのキャリアパスを考える発表資料 View more presentations from Michitaka Yumoto 15分では全然伝えきれなかったので、下記によくわかる解説を加えておきます。資料の向こう側にある背景を掴んでください。 何を話そうか最後まで悩んだんですが、今までブログで僕が問題提起しているSI業界構造の問題を再認識してもらい、「問題が問題であることを認識してもらってから、次のアクションを考えてもらえるきっかけの一助に」という狙いから、上記のような資料になりました。僕が今まで問
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro
特許庁が5年前から進めてきた基幹系システムの刷新プロジェクトを中止する方針を固めたことが、日経コンピュータの取材で分かった。当初は2011年1月の稼働を予定していたが、業務分析の遅れなどから要件定義と設計が難航。稼働を3年遅らせたが、立て直すことができなかった。 政府が策定したレガシーシステムの刷新指針に基づき、特許庁は2004年10月に「業務・システム最適化計画」を策定した。この刷新指針は、特定のITベンダーとシステム保守などを長期契約することによるITコストの高止まりを解消する目的で策定されたものだった。同庁はさらに、入札に分割調達の仕組みを採用して競争原理を働かせることを目指した。 要となるシステム設計とシステム基盤の構築については、東芝ソリューションが入札予定価格の6割以下の99億2500万円で落札した。ところがプロジェクトが始まると、現行の業務やシステムを理解した職員と技術者が足
開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは？ - 達人プログラマーを目指して
皆さん、明けましておめでとうございます。昨年の後半は私自身SI業界からWeb業界へ転職したことなど仕事環境の変化があり、ブログの更新頻度も鈍りがちになってしまっていましたが、本年もどうぞよろしくお願いいたします。 さて、ちょうど、一年前のお正月にはグルーポンのおせち料理事件が話題になっていましたが、私はおせち料理の品質とIT業界における品質の問題を絡めて、以下の記事を書きました。 グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと - 達人プログラマーを目指して この記事では、一般にSIerによって開発される日本のシステムはあの事件のおせち料理のように、低い品質に甘んじているが、多くの場合、社内システムなどではそういった品質の問題が公に明らかにされることが少ないのではということを指摘しました。ただ、その時は私の希望も込めて 最近はOSSやクラウドなどの影響で社内システムもどんど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
提案依頼書に含まれる 無理難題の分類