So-net無料ブログ作成
検索選択

エコポイントシステムは3ヶ月で実現

今年7月からはじまったエコポイントこのエコポイントシステムは3ヶ月で完成させたそうです
プロトタイプだけなら3週間で完成。

そのプラットフォームはForce.com。要件などもあやふやな状況から作り上げたとのこと。
期間限定利用のシステムでもあり、Force.comはぴったりのものだったようです。

要求開発から実装までを同時進行で進めるアジャイル開発、そしていつでも使えるPaaSという環境。こうしたものがこれからのソフトウェアの標準になっていくんでしょうね..
たーとる

「上流工程で成功する人、つまずく人」

本書でも書かれていますが要求・要件について
 「ユーザーが決めてくれない」
 「ユーザーがはっきりしない」
と”ユーザーが決めて”くれる”ものと考えている方はつまずく人に入ります。
そもそもユーザーは要求をまとめたり仕様化する(=要件)ことを本業とはしていません。基本的に要求・要件を決めて”くれる”と期待するのは無理なのです。
ではそうした要求・要件を決める能力を持つべきなのは誰なのか?それはそれを必要とする人、それを生業とする人、つまり(IT)ベンダー側となります..
たーとる

いま企業が求めているのは、ITの活用ではなく、経営とITの一体化

業務要件をSIerが見ていかなければならない理由がこの言葉でも表現できるでしょう
「いま企業が求めているのは、ITの活用ではなく、経営とITの一体化」
すべてをコンサルティング会社に持っていかれてはSIerの頑張りどころがない。SIerにとって協業者であるとともに競合者でもあると考えます。
だからSIerという表現は正しくないですね。以前にこういった表現をしました。
ビジネスインテグレータ。これがこれからのSIerの次世代の姿だと考えます。

「ITアーキテク..
たーとる

「ITアーキテクト Vol.17」

今回の特集は
 ・クラウド・コンピューティング
 ・ビジネス・センスを養うための20冊
 ・サーバ仮想化ロードマップ
 ・データ・ガバナンス
です。

データ・ガバナンスはかなり参考になるかな。
それよりも特集以外の記事が私にはとても有用でした。それは要件定義・要求開発。主に業務要件に関する部分の記述です。
10年前ならば業務要件なんてSIer側が考えるものではありませんでした。主に発注企業側がちゃんとやっていたということです。
しかしオープンシステムが当..
たーとる

エンタープライズシステムの超上流工程

本日ITアーキテクトサミット2007 Winterに参加してきました。

その中の1つのセッションで「”ITの視点”によるビジネスプロセスの最適化戦略」というものがありました。

内容としてはエンタープライズシステムの超上流(システム要件定義より前)でのITアーキテクトの役割というものです。
このブログでもビジネスインテグレータへということで紹介していますが、従来のSIerがシステム要件定義以降を担うのに対して、現在はその前の工程からの参画を求められて..

たーとる

「アジャイル開発の6原則と20のベストプラクティス」

おそらく日本語で初、OpenUPについて言及された本ではないでしょうか。
OpenUP/Basicをベースにアジャイル開発のベストプラクティスの解説がなされています。
これを読んで、実際にOpenUPを見たら自分でもLibraryとか書けるかな、と思い購入しました。
最終的にはOpenUPをベースにFDDによるプロジェクトマネジメントテンプレートを作りたいな~と思っています。
あとは要求開発と。できあがるがいつになるかはわかりませんが。

たーとる

システムインテグレータからビジネスインテグレータへ

従来、ITシステムを導入する業者をシステムインテグレータと呼んでいました。
システムインテグレータの範疇は、顧客の業務のIT化。顧客の要求を捉え、このIT化を最大の目標にしていたと思います。

今後のIT業界で目指すべきはビジネスインテグレータだろうと思います。
ビジネスインテグレータの範疇は経営戦略の実現。顧客の経営課題・経営戦略を把握し、戦略の実現を目指す。顧客の経営課題・戦略に注目し、それを実現するソリューションを提供するものです。
従来より一歩進むわ..

たーとる

”ユーザーが欲しいのはシステムではない”

”ユーザーが欲しいのはシステムではない”

非常にいい言葉ですね。@ITのプロジェクト管理に関する連載のタイトルです。
ユーザーが欲しいのは、システムではなくそのシステムが生み出してくれる価値なのです。
ユーザー要求は必要としている価値を見出すことが重要です。どんなシステムが欲しいかなんて聞いてくるベンダーは理解していないと思ったほうがよいかもしれません。XXXということをしたい、そのためにはこういったシステムにすればよいというのが正解なのです。場合によっては..

たーとる

「失敗しないERP導入ハンドブック」

 いまさらながらなのですが、「ERPっていったい何?」と思ったので、それが理解できそうな本を読んでみました。

   「失敗しないERP導入ハンドブック」

 ERPは企業の基幹業務(購買、生産、販売、会計人事など)機能を最適化し、提供するソフトウェアである。
まあ、当たり前の回答ですね。でもその当たり前を確認したかったんです。ERPって範疇はどこまでか?って。結局”基幹業務”一般をまとめて提供するのがERPだということかな、という理解です。

..

たーとる

BPMシステムの構築には新しいスキルが必要

「X-over Devlopment Conference 2007」で日本BPM協会の横川理事は
 ”BPMシステムの構築には新しい設計スキルが必要”
と発言しました。

BPMで使用するモデル言語(BPMNなど)を理解するのは当然として、さらに業務担当者に業務のやり方を洗い出す「マインドアプローチ」が必要と述べています。

BPMに限らず、今要求開発(要求定義)で求められている能力とそれほど変わらないと思いますが、BPMを採用することで業務が変わっていくわけですから..

たーとる

「~ゴール指向による!!~システム要求管理技法」

最近の要求開発(要求定義)では、そのプロジェクトが目指すゴール(真にやりたいことはなにか)をまず明確に、という動きが体勢を占めています。これは顧客から出てくる数多くの要望がそのゴールに沿っているかどうか、沿っていないなら要望を採用しないなどの対応をしなければ、開発規模は膨らむばかりで、顧客満足度は逆に低くなっていくということから考えられたものです。
「~ゴール指向による!!~システム要求管理技法」はそういった要求開発(要求定義)をゴールとはどういったものなのか、ゴールの..

たーとる

システムの要件開発の重要性(裁判判例)

システムの要件開発の重要性を示した裁判の例がITProに掲載されていました。

誰がその要件開発をやるかという点では会社それぞれで違うでしょうが、この裁判の事例を見る限り営業もSEも開発責任者(ITアーキテクト、PM)もみんな要件開発をせず、大昔の受託気分でシステムを作ったことが見て取れます。
RFPなどが不十分なことは今の時代よくあることです。それを理解したうえで、システムを「提案」することを忘れないでください。

関連情報「IT提案力」

ソ..
たーとる

ソフトウェアプロジェクトでのSE/営業の重要性

今まで、ソフトウェアの実装・テスト、設計、プロジェクトマネジメントといろいろ本を読んできて何がソフトウェアプロジェクトを成功させる要因だろう、と考えてきました。そして結局たどり着いたのが要求開発(要件定義)といわれるフェーズの確実性だろうと思います。

まず、要求開発(要件定義)が漏れなく無駄なく的確にできなければ、その後の設計・実装がいくらうまくできても顧客満足のいくものは出来上がりません。そういった意味で「要求開発と要求管理」「要求開発」といった本が非常に役に立つと..

たーとる

要求開発アンチパターン

ITProで要求開発アンチパターンが出ています。
レガシーシステム・パラノイア」なんてなんか自分にも思い当たるところがあるな~、という感じです。
今のところ2つのページが掲載されています。

要求開発アンチパターン(1)
要求開発アンチパターン(2)

要求開発ははまり込むと本当に難しくなりますから、こういった情報を常に入手しておくべきですよね。

たーとる

「要求開発」

「BPMがビジネスを変える」で紹介したとおり、顧客企業が要件を明確にしていることは現在では少なくなっている。それでは我々IT企業は顧客企業が要件を明確にするのを待つしかないのだろうか?そんなことをしていては今後の厳しい競争に勝ち抜いていくことはできない。
そんなときに参考になるのが「要求開発」である。「要求開発」では顧客が要件を明確にしていないのはあたりまえ、顧客と一緒になって要件を”開発”していこうではないですか、という考えのもとかかれたものです。「BPMがビジネスを変え..

たーとる

「アジャイル開発手法FDD」

先日の「アジャイルソフトウェアマネジメント」の内容をうけ、アジャイル開発手法そのものをもう一度勉強しなおしてみました。
ターゲットは「FDD」。「アジャイルソフトウェアマネジメント」でも主要開発手法として取り上げていたのでFDDにしました。

XPなどはかなり先鋭的なアジャイル開発手法ですが、FDDであれば従来の開発手法から乗り換えるにはちょうど良いレベルではないかとおもわれます。従来の手法で言えばユースケース駆動型開発に近いかな。ユースケースでもより細かいレベルをフィー..

たーとる

「要求開発と要求管理」

ソフトウェア要求の続編的な位置づけの本、「要求開発と要求管理」です。
今回の本は、いかにして顧客の要求を聞きだすか、要求漏れをなくすかを主題に掛かれたものです。ソフトウェア要求開発の全体のプロセスについては前書「ソフトウェア要求」を読まれることをお勧めします。

要求管理については若干記述が少ないのが難点ですが、こうしたものは要求管理ツールに管理させるのが一番であるということから記述が少ないものと考えます。実際の運用でもそういったツールの導入をお勧めいたします。

要求..

たーとる

デブサミ20071日目 第2セッション

デブサミ20071日目 第2セッション

要件の構造化~ツールで効率化する要件の分析と管理~

スピーカー:藤原 佑之 日本コンピュウェア株式会社営業技術本部

 [注意事項:主観が入っていますので、そのまま転用しないでください]

開発プロジェクトの現状
 成功プロジェクト:29%
 問題プロジェクト:53%
 失敗プロジェクト:18%

 問題点の発生工程:圧倒的に上流工程に多い
 問題点の発見工程:下流工程に多い => 不具合修正コストが増加

 約50..

たーとる

「ソフトウェア要求」

今回紹介する本は「ソフトウェア要求 顧客が望むシステムとは」です。
今までの「要求開発」や「要求仕様のまとめ」は要求開発(要件定義)工程だけをターゲットにした内容でしたが、今回の本は要求開発は当然のこと、要求変更管理についても説明しています。そういった意味で”プロジェクト管理”にカテゴリーしています。
 要求開発(要件定義)でカバーしている範囲は「要求開発」とほぼ同じで、「要求開発」とこの本を読めば、要求開発(要件定義)のベストプラクティスはほぼ網羅されたと思ってよいと思い..

たーとる

「BPMNによるビジネスプロセスモデリング入門」

 要求開発(要件定義)関連でもう1冊。
 「BPMNによるビジネスプロセスモデリング入門」という本を紹介します。
 みなさんは業務フローなどを今までどのような形式で記述されていますか?ExcelPowerPointで、とかUMLでとかいろいろな形式で記述されていると思います。
 BPMNは業務フローの統一記述形式で、ツールによってはBPEL4WSなどに自動変換してくれるので、要求開発(要件定義)から実装までを一連の図で実現できることになります。また、ツールとしてでなくても..

たーとる

「要求仕様のまとめ方」

本来、要求開発(要件定義)を行うのは発注者側であるべきですが、「要求開発」でも紹介したとおり事実上、受注者側と発注者側が協力して業務要件から機能要件・システム要件を開発するしかないというのが実態です。では、そういったときにどのような資料をまとめればよいか、どういったポイントがあるかを紹介した本が「要求仕様のまとめ方」です。一応”若手SEのための”とありますので、今まで要件定義に参加したことのないSE/開発者でもわかる内容だと思います。この本を読んで、かつ「要求開発」を読めば..

たーとる

「要求開発」

アーキテクトという分類には若干ふさわしくない部分もありますが、今回は「要求開発」という本を紹介します。

 要件定義・という言葉はありますが、「要求開発」という言葉に惹かれこの本を読んでみました。定義ではなく、開発という言葉を使うのは、システムの要求(要件)は決まっていることを文書化するのではなく、ビジネス要求から作り出すものだという考えに基づいているものです。ですからこの本のターゲットは、”ビジネス要件定義”の後・”システム設計”の前のフェーズとなっています。

..
たーとる
メッセージを送る

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。