RFPの作成方法がわからない！＠IT情報マネジメント：システム部門Q＆A（12）1/3
質問 どうやってRFPを作成・評価すればいいのか？ ベンダにシステム開発を依頼するときには、RFP（提案依頼書）を作成するべきだといわれていますが、高度な情報技術者がいない中小企業では困難です。RFPにはどのような意義があり、どのように作成すればよいのでしょうか。また、提出された提案をどう評価すればよいのでしょうか。 発注側の担当者が、情報システムに対して成熟度の低い場合、適切なRFPを作成するのは現実には困難で、コンサルタントの協力が必要になります。しかし、RFPを作成することは、情報化戦略を明確にすることでもあり、RFP作成により成熟度の向上にもつながるのですから、将来的には自社で作成できるようにすることが望まれます。 そもそもRFPとは何か？ RFP（Request For Proposal：提案依頼書）とは、発注者が開発するべき情報システムの要件をベンダ（情報システム開発業務の受託
遅いコードを貯蓄する - Backnumbers: Steps to Phantasien
2005-08-21 遅いコードを貯蓄する 私は仕事柄, 書いたコードに実行速度を要求されることがある. 本当はいつも要求されていて, たまにそれに応えるという方が正しいかもしれない... とにかく, 権力者(上司, 顧客, 同僚)から "遅いので速くしろ" というお言葉を日常的に頂く. とはいえできる範囲の高速化は既に済んでいる. 無い袖は振れない. まわりからの圧力を前にすると, 高速化の余地あるコードがある種の資産に思えてくる. 高速化の "余地" にも色々ある. 直せは確実に速くなる性質の良いもの. 複雑さ故に速くなる "かもしれない" ように見える 不確実性の高い不良債権, まだプロファイルをとっていない未公開株のストックオプション, など. そこで, 優良な財をなす投資の方法 ... つまり遅くてかつ簡単に高速化できるコードを書く方法を, いくつか提案しておく. アクセサ変数を
「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)：An Agile Way：オルタナティブ・ブログ
前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、 テスト容易性： EoT = Ease of Testing 変更容易性： EoC = Ease of Changing という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト
[結] 2005年8月 - 結城浩の日記 - テストが困難な性質
目次 2005年8月31日 - Perl版の「メモ化(memoization), 再帰関数定義関数, 最小不動点」 / スマトラ沖地震・津波 / 2005年8月30日 - Windowsで、手早くPerl6で遊ぶ / 他の人から学べない「何か」 / 2005年8月29日 - ミルズの外科手術チーム / 2005年8月27日 - POPFile / 2005年8月26日 - 今日も仕事 / 2005年8月25日 - 今日も仕事 / 2005年8月24日 - 今日も仕事 / 人月はなぜ神話か / 2005年8月23日 - 説明文を書く2つのフェーズ / 秋は勉強の季節 / 2005年8月22日 - 仕事 / プログラマのダイエット / 2005年8月21日 - ジェネリクス・クイズ(2) / 2005年8月19日 - ジェネリクス・クイズ(1) / テストが困難な性質 / 2005年8月18日
開発現場で学べること（4）
エンジニアは日々現場で学ぶ 開発現場で学べること 第4回 最良のシステム設計書とは？ クロノス 山野寛 2004/1/28 エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。 ■要求定義から開発フェイズへ移行 前回（「第3回 システム開発の真の目的を見失わない 」）までわれわれの開発チームは、ある某サービス業を営む企業Aの要求定義をまとめる作業を行ってきた。その作業も3カ月間でようやく無事に終了し、いよいよ本格的な開発フェイズへと移行した。 開発フェイズではまず初めに、設計手段の統一化を図るため、メンバー全員で設計書の標準化を行うミーティングを実施した。われわれはこのミーティングで、クラス間の静的な関連の記述にはクラス図を、また動的な関連の記述にはシ
コレだけ準備すれば分散開発に失敗しない
分散開発はまだリスクが高い 最近、多くの開発現場で海外を含めた分散開発の話を耳にするようになりました。筆者の周りでは、特に中国やインドをはじめとするアジアの事例を非常に多く聞くようになりました。しかし、あまり多くの成功事例を耳にしないのもまた事実です。これはやはり、まだこのビジネスモデル自体が成熟しておらず、手法などが手探り状態であることが最大の原因だと思われます。つまり、「分散開発では何をしたらいいのか？ どんな手法を用いればいいのか？ 何に気を付ければうまくいくのか？」といった要素がまだまだ見えておらず、いわば地雷原の先頭を歩いているような状態であるといえます。よって、分散環境での開発というのは、まだまだリスクの高い開発の体制であるといわざるを得ないようです。 そこで今回は、われわれが体験した分散開発事例のノウハウをできるだけ多くの読者（開発企業）に見てもらうことによって、「どの辺りに
開発プロセスの功罪 - カレーなる辛口Javaな加齢日記
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Swebok に尽きるかな．ウォーターフォールモデルとかPMBOKとかCMMとかCMMIとかRUPとか，その手の「何とか標準」などは大抵は論外だ．そう言ったものが「役に立つ」「きっと適用できる」と主張する人達もたしかにいる．しかし面白いことに奇妙な偶然が見られるのだ．役に立つと主張する人はソフトウエア開発経験が全く，或いはほとんどなく，下手をすると"hello world"さえも書いたことが無い*1．逆に優れた開発者で役に立つと主張する人はまずいない．なんとも奇妙な偶然だ． 以前，とある企業の方々と話をしたが，彼らは興味深い意見の持ち主だった．書類重視でウォーターフォールモデル，低レベルプログラマの大量投入による大量生産．おそらくは『上流行程神話』の信奉者．品質もメンテナンス性も全てドキュメントでなんとかし
＠IT：初めてのプロジェクトリーダー
ソフトウェア開発チームを構成するメンバーは大きく2つの種類に分かれます。開発者とリーダーです。開発者にさまざまなスキルが必要なように、リーダーにもさまざまなスキルが必要です。多様なスキルの中で最も習得が難しいとされているのは、開発者と違う視点を持つことです。もし、（教科書どおりにやっているはずなのに）いまあなたがリーダーとしていま一つだと感じているのであれば、開発メンバーから、リーダーへの視点の切り替えが上手に行われていない可能性があります。 この連載を通じて私がお手伝いしたいのは、視点の切り替えです。切り替えというよりは、「もう1つの視点を持つ」といった方が適切かもしれません。メンバーとして、開発者としてプロジェクトチームに貢献してきたあなたが、リーダーとしてチームに貢献するために追加すべき視点を持つにはどうすればよいか？ 次の3つの切り口で説明していきたいと思います。 3つの切り口：「
Team Room
by William Pietri XPをこれから始めてみようと思っている人達は、開発部屋がどんな状態か興味を持っているはずです。(XPを知らない人は、この資料の後ろの方の用語集にある簡単な説明を見てください。) ここでは、５人で九ヶ月かけたプロジェクトで撮影した写真を説明していきます。 私達の顧客の機密に関わる部分は写真をぼかしてあります。 質問や、もっと良い方法などの情報は筆者まで。 概要 最初の写真では、開発部屋におけるおもな機材に番号をふってみました。自然光を取入れ、机は木製にし、高い天井の部屋を選んだことで快適な労働環境を実現しています。 写真からもわかるように、最も広い壁側にはプロジェクトに関する様々な情報が掲示されています。 顧客 写真には写っていませんが左側には顧客(Product Manager)が座ります 開発中のストーリ その週に開発するストーリが詳細記述と共に掲示さ
oresign.jp - このウェブサイトは販売用です！ - oresign リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
OBB vs AABB - Radium Software Development
iPhoneの一般修理店は予約なしでも来店できる？ 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
