ロングテール時代のSInot found
1業務9万8000円，超低価格のオーダーメイド・システム開発「ギョイゾー！」，スターロジックが開始
システムインテグレータのスターロジックは2008年4月28日，1業務あたり9万8000円でオーダーメイドによるシステム開発を請け負うサービスを開始した。名称は「ギョイゾー！（GyoiZo!）」。見積管理や会員管理といった業務が9万8000円でIT化できるという。 「ギョイゾー！」では9万8000円でシステム化する1つの業務を「インフォセット」と呼ぶ。インフォセットは請求書などの書類（帳票）と，それに関する作成・承認・修正・取り消し・削除などの機能からなる。またさまざまな検索条件でデータをCSVファイルとして出力でき，Excelなどで自由に分析，加工できる。 システムは，顧客との打合せから1週間前後で納品する。納入されたシステムに対しユーザーが納得しない場合は「利用開始から90日間であれば全額返金する」（スターロジック）という。 インフォセットを追加する場合，「インフォセットすくすく成長オプ
さんぱつ - ブログは死なず、ただ放置されるのみ。
忙しい日々が続いていたが、隙間ができたので今日は休暇を取った。で、長らくほったらかしにしていたボサボサに伸びた髪を切りに馴染みの理髪店へ。これからの剣道の稽古では汗まみれになるだろうから、ばっさりと短く。 髪を切ってもらいながら、マスターと話をする。 オレ こういうマンツーマンでやる仕事はなんか憧れますねえ。 マスター え、なんで？ オレ 仕事がね、最終的なお客さんの顔が見えなくて、で、直のお客さんと話すわけですけど、直のお客さんがやりたいことと、お客さんの会社の意向とが一致してないと感じるときがあるんですね。 マスター ふんふん。 オレ じゃあ、どうするか、っていうと、まあこっちから提案もするけど、最終的には直のお客さんが決定して、そういうとき、なんか、だれもうれしくない感じの仕事なときがあって。 マスター ははぁ。 オレ で、できあがったとき、なんか達成感がないなあ、とか思うんですな。
【Q＆A】ソフトウェア開発における効果的な顧客コミュニケーション
質問：われわれは顧客とのコミュニケーションに苦労しています。現在、ソフトウェアの機能を固めている段階ですが、プロトタイプの一部の機能がうまく動きません。顧客を怒らせずにこの問題を伝えるにはどうすればよいでしょう。また、機能の詰め込み過ぎを避ける方法はありますか。 質問を読んでまず、あなたと顧客の間では定期的な対話が行われていないという印象を受けた。 「プロセス」の一部として、各ステップごとに顧客に関与してもらうべきだろう。何かができていないことを開発サイクルの後期になってから発見すると、最初のプロトタイプを見てすぐに発見するよりも、対処が困難になってしまう。アジャイル手法を取り入れて顧客と仕事をすれば、工程の進行とともに多数の小規模な変更や見直しを頻繁に行い、実装の細部を手直ししていける。その積み重ねの中でおのずと機能が完成することになる。ふたを開けてみたら機能が期待外れだったという事態は
【考察】要求と品質の関係性 - プログラマの思索
「成功する要求仕様 失敗する要求仕様」を興味深く読んでいくうちに、「要求と品質の間にはどんな関係性があるのか？」が疑問として上がってきた。 要求と品質について考察してみる。 【要求エラーの種類】 「成功する要求仕様 失敗する要求仕様」では、いわゆる要件定義のプロセスを要求マネジメントと呼び、その重要性を強調している。 成功したプロジェクトでは開発コストの10～20%、失敗したプロジェクトでは5%以下という統計があるらしい。 「成功する要求仕様 失敗する要求仕様」では、要求マネジメントを下記のプロセスと定義している。 但しシーケンシャルとは限らない。 1.要求の導き出し ↓ 2.要求のトリアージ ↓ 3.要求の仕様化 そして、要求マネジメントで発生する要求エラーを下記として定義している。 【A】認識エラー 要求の導き出しプロセスで発生する「要求として認識されなかった」エラー。 いわゆる要求漏
RFP作成術【前編】：ベンダーとユーザーの悩み
ベンダーに自分の要求を伝えられるか？ベンダーの力を引き出せるか？妥当な金額で発注できるか？トラブルの芽は摘んであるか？それは“RFP（提案依頼書）の作り方”にかかっている。「プロジェクトが失敗したのは，ベンダー選びを間違えたから」。そんな苦い経験を繰り返さないための，“良いベンダーと出会う”技術を事例から明らかにする。 今度こそ良いベンダーと一緒にシステムを作りたい――そんな思いから，複数のベンダーに提案を募る開発案件が増えてきた。 学習塾の京進は，かつて馴染みのベンダーから納入されたシステムの品質が悪く，苦労した。この苦い経験から，5月に稼働させた「スクールワン顧客対応システム」では，ベンダー選定時に細心の注意を払った。この案件では，アプリケーション開発に加えて，全社システム基盤の整備も視野に入れていたため，絶対に失敗できなかった。 7社をピックアップし，RFPを発行して提案を募った。担
オフショア時代を乗り切る明確な要求仕様作成術
正確で明確な「要求仕様」を作成するのは非常に難しい。それがオフショア開発となればなおさらである。 開発技術の発展により，従来よりも変更に強く，速くシステムを作ることは可能になった。しかし，実物を作らずに「紙上」だけで仕様を正確に定義するのは，いまだにとても難しい。 システム化の対象業務も様々で，近年では経理システムのように定型なものは少なくなった。要求を出す側のユーザーでも，アプリケーションを作成して初めて仕様が見えてくるといったことはよくあることだ。 システムに対する業務的な要求が，時間の流れによって変わってしまうこともよくある。チェンジビジョン代表の平鍋健児氏は，このことをで「ムービングターゲット」，つまり動く標的という言葉で説明している。 オフショア開発の場合，それが顕著になる。日本人同士のように，電車で移動すれば顔を合わせられる位置にいても，仕様に対する意識の違いや，仕様そのものの
基本設計での要件定義変更数357件、東証の次世代売買システム開発
システム開発における上流工程の問題をテーマとした「要求シンポジウム」（主催：独立行政法人 情報処理推進機構、NTTデータ）の第2回が1月23日、都内で開催された。特別講演を行ったのは、東京証券取引所 常務取締役（最高情報責任者） 鈴木義伯氏。「東証次世代システム開発の上流工程と課題」と題し、現在構築中の次世代売買システムにおける開発プロセスの改善について講演を行った。 東証が構築中の売買システムは2010年の稼働を予定しており、現在は詳細設計の段階にある。開発の上流工程で品質の作りこみを行うことにプロセス改善の力点を置いていると鈴木氏は言い、要件定義から基本設計段階の作業について、具体的な数値を挙げながら話を進めた。 プロセス改善の取り組みとして、鈴木氏はいくつかのポイントを指摘する。1つは、発注者責任の明確化。今回のプロジェクトでは、ベンダを選定する際に、詳細入札仕様書（RFP約1500
［3カ月のEA導入編］第1回：君，EA詳しいよね？
「横山さん，確かEAについて詳しかったよね？」――。 筆者が担当する製造業A社の情報システム部・山田次長（仮名）から，こう声を掛けられた。ある年の秋のことである。筆者は当時，プリセールス（提案）主体のITアーキテクトを担当していた。勤務する日本IBMでは，EAに関するワーキング・グループのリーダーも務めていた。そのことを聞きつけた山田次長が，冒頭のように声を掛けてきたのだ。どうやら山田次長は，自社の情報システムの将来を考えたときに，EAが役に立つと思ったようである。 「そろそろやってみるかな」。ワーキング・グループによる研究も半年を過ぎていたので，筆者も実践に活かしたいと思っていた。そんな矢先だったので，山田次長を全面的に支援しようと決意した。 EAのスキルを活かしてみたい ちなみにEAとは，Enterprise Architectureの略で，ビジネス戦略とIT戦略を結び付ける手法のこと
ライター矢沢の著作日記[12] 夢の印税生活
「矢沢さん、ライターやってるんですって。いいなぁ。夢の印税生活じゃないですか！」と言う友人が多くいます。これは、誤解です。コンピュータ関連のライターは、残念ながら夢の印税生活と呼ばれるほど儲かりません。夢の印税生活は、「夢」なのです。今回は、ライターの収入についてお話させていただきます。これからライターをやってみたいと思っている人に、少しでも参考になる情報を提供できれば幸いです。 ライターって儲かるの？ ライターでどのくらいの収入が得られるかは、人によって様々でしょう。私の経験の範囲では、コンピュータ雑誌やWeb記事の原稿料は、1ページあたり1万円～3万円です。コンピュータ書の印税は、定価の8％～12％程度です。原稿料を2万円/ページ、印税を10％として、年間の収入を計算してみましょう。 【雑誌やWeb記事】 10ページ/月×2万円/ページ×12ヶ月/年＝240万円/年 【書籍】 2,00
2007-12-23_22-28 - 生きてま2 改 - オブラブクリコン2007資料UP
オブLOVEクリコン2007 LT資料UP まず感想より、自分の資料のUPを先にする。 オブラブクリコン2007のLT資料をSlideshareに公開した。 今回のLTの目的はTRICHORDの宣伝と、狩野モデルの紹介、そして実際に来場者を交えて試してみることだった。ネタはちょっと前にネットでも流れてた狩野モデル(狩野分析法)について。こちらの方は、ScrumのCertified Product Owner(CPO)経由で知ったそうですが、私はMike Cohnの執筆したAgile Estimating And Planning(AEP)で知った。Mike Cohnは1990年後半からScrumを実践しており、バリバリのCertified Scrum TrainerでCertified Scrum Masterトレーニングの講師も勤めているし、AEPはScrum Masterの参考書籍にも
作るシステムより人に着目－－読売新聞東京本社ほか
唯一、論文形式で受賞したのが、読売新聞東京本社を代表とする「ユーザー要求を引き出す分析手法の研究」だ。近年、大きな課題になっているシステム構築の上流工程であるユーザー要求段階で、どうやって真のニーズを引き出すかというテーマ性と実現性のバランスが評価された。 「ユーザー要求を引き出す分析手法の研究」は、富士通のユーザー会であるFUJITSUファミリ会LS研究委員会分科会が、1年をかけた研究をまとめた論文だ。読売新聞東京本社制作局技術一部の武田臣司主任をリーダーに、15社15人が参加し、06年3月に発表した。 論文のテーマは、システム構築の上流工程である要求定義をいかに確かなものにするか。システム構築の成否は、上流工程、なかでもユーザー要求をどう定義するかにかかっているとされる。ベンダーへの“丸投げ”体質を改め、本当に必要なシステムを作るために、多くのユーザー企業が要求定義力の強化に乗り出して
それでいくら儲けるの？ 狩野分析法だけではうまくいかないよ - masayang's diary
狩野分析法の記事はCertified Scrum Product Owner Trainingで一番印象に残った要件分類手法だったので真っ先に書いてみたが、あれほどの反響があるとは... ブックマークのコメントを見ても「使えそう」という声が多い。 でも、「狩野分析法」は利用者の声をもとに要件（フィーチャ）の優先度をつけるのには役立つかもしれないが、それだけでAgile開発につなげるのは正解とはいえない。利用者が要求するフィーチャ＝事業として儲かるフィーチャ、とは限らないからだ。 基本は「そのフィーチャでいくら儲けるのか」「そのフィーチャ開発にいくらかかるのか」の分析であろう。 それでいくら儲けるの？ フィーチャ毎に「それでいくら儲けるのか」を考える。 簡単なようで、難しい。 自分がお世話になっている日本の某お客さんのところでは以前から実行している。経営層の人が「この要件を書いたのは誰？ お
第6回 RFPの書き方：要件を確実に伝える表現のコツ
前回「RFPの書き方：どんなインターネットショップなのか？」では、「何を作りたいか」「何を目指すのか」など頭に思い描くシステムの完成イメージをRFPという形で文書にまとめて表現することの大切さや、およそどのようなことを書いたらよいのかという点について話を進めました。今回は、「どのように表現するか」ということについて、書き手の立場で注意すべき点について説明していきます。 どこまで詳細なRFPを作成すればよいか RFPを作成するのに当たり、まずはどこまで詳細に記述すべきかを明確にしておく必要があります。例えば、日曜大工仕事が得意なあなたの元に、友人から「本が増え過ぎたので机の横に置く本棚を1つ作ってくれないか。必要な費用は前もって払うから」という依頼があったとしましょう。当然、あなたはどのような本棚を望んでいるのか確認をすることでしょう。しかし、その友人は忙し過ぎて満足に説明する時間も取れず、
狩野さん的なアレ。 - 設計と実装の狭間で。
迷ったら狩野さん！...狩野分析法による優先度付け と、あります。おお、スゲェ。何となく分り易そうな感じ。 でも、いくつか釈然としない部分が例の表の中にはあったりする。 具体的には、以下の二つ。 # L...Linear(性能) * なくてもよいが、あればあるほど良い。 # E...Exciter(魅力) * いわゆる差別化ポイント。 Lは、ホントに無くても良いの？ そもそも、LとEになる為の条件にもしっくりこない感があったり。 と言う訳で、迷ったら原典に当たれと昔の偉い人は言っていた気がする。 で、狩野さんて、どこの狩野さん？ Scrumとかそういうコンテキストで、英語だと、どうやら「The Kano Model」とかそんな感じらしい。 で、結局この人なんかな…。 狩野紀昭 カノウ ノリアキ KANO Noriaki でも、Amazonみると、どうも違う様な…。合っている言えば合っている
ユーザーが欲しいのはシステムではない ― ＠IT情報マネジメント
要求定義の不備で大量の仕様変更が発生、プロジェクトは火の車に……。そんな事態を防ぐため、体系化された要求定義の方法論を提供するのが「MOYA」だ。本連載では、MOYAの手法を活用して顧客の「隠れた要求」を引き出す方法を解説していく。 お客さまが本当に望んでいるもの 「人はドリルが欲しいのではない、穴が開けたいのだ」 この言葉（あるいは似たような言葉）を聞いたことがある方は多いのではないでしょうか。これはニーズについて語られた有名な言葉で、欲しいのは商品ではなく欲求を満たすことであって、商品はその手段であるというものです。 システムを作る際にも、同じことがいえます。 「人はシステムが欲しいのではなく、業務をより良くしたいのだ」 といったところでしょうか。 つまり、こんな機能が欲しいというお客さまの要求（と思われる発言）は、その機能自体が欲しいわけではなく、その機能が提供している何かの価値が欲
ユーザーの「思い」は、1つだけではない
顧客側の意見がバラバラなのは、当たり前 前回は、要求定義を行う際に有用な思考ツールとして、XYZ公式をご紹介しました。今回は「リッチピクチャー」というツールを取り上げます。 まずは前回に引き続き、結婚相談所を営む顧客へのシステム提案のケースを用いて説明していきましょう。以下のケーススタディをご覧ください。 あなたはいま、「会員に対するアドバイザーのカウンセリング時間が少ない」という課題に取り組んでいます。適切なシステム要求を抽出するためには、課題をしっかり把握した上でソリューションを提案しなくてはなりません。あなたはこの「カウンセリング時間が少ない」という課題の状況をより具体的に理解するために、関係者にヒアリングを行うことにしました。 まずこの結婚相談所のオーナーである社長に、なぜカウンセリング時間が少ないことが問題であるのかを尋ねました。 「カウンセリングは、わが社のなかでも大切な業務な
迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: Team Roles at Work: Belbin, R. M.: 本
2008-01-20
