「なぜ糞システムができあがるか？」の答えは、「一つ前の仕事をしている」に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則（Garbage In, Garbage Out）に従う。 では、どうすればよいか？ 「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○％ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具（システム）を“
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
自宅サーバのインフラ設計書を公開します。 Design paper of the home server（抜粋） 昨夜にTwitterで公開したら予想外に反響があったので、ちゃんとエントリに残すことにしました。クラックされるおそれがあるので、細かい部分は公開できないことをご了承ください。 内容はこんな感じ。 要件概要 機器仕様 ネットワーク設計 ソフトウェアスタック設計 共通基盤設計 サーバ詳細設計 上記にバックアップ設計や運用管理まわり*1を加えれば、インフラの設計書はだいたいこんな感じではないかと思います。 インフラの要件定義は難しい 一方で、インフラの要件定義は十分に標準化が進んでおらず、会社やチームによって文化がかなり違います。特に受託開発（SI）の場合は、お客様の中にインフラに詳しい人がいなくて調整に苦労することも多いと思います。費用と可用性のトレードオフの部分はなかなか伝わりづ
業務ロジックや画面といった機能要求が明確だからと安心してはいけない。性能や運用性といった非機能要求を明らかにできなければ“道半ば” である。その不備は7割に上る。意識を高め，スキルを磨くことが急務だ。 「この応答速度では遅い」「バッチではなくオンラインでないと業務に支障を来たす」──。金属チタン製造大手の東邦チタニウムは2008年5月，生産管理システムを稼働させた。ところが2年1カ月を要した開発プロジェクトでは，冒頭のような要求仕様の変更が相次いだ。そのため当初洗い出した要求を見直し，一度作ったプログラムの改修を余儀なくされた。 変更になったのは，例えばこんな要求である（図1）。当初，268の機能について，応答時間を「一律3秒以内，長くても5秒」としていた。しかしユーザー・テストの段階で，参照系の機能は5秒では遅いことが判明した。更新系機能の場合は，その画面のボタンをクリックすると一連の業
ある企業では、設置以来丸5年を経過したシステムが、サーバ150台を数えるほどになっていました。そこで、ハード、ミドルウェア等を最新版へアップグレードし、さらにVMwareなどの仮想化ソフトウェアの採用を検討しながら、サーバ群を一気に13台に集約させようと考えました。 今回は、ユーザ企業はいかにして事業要件からプロジェクト発足のための未来図を作り、予算を確保し、案件化していくのかをストーリーをわかりやすくするために、架空のプロジェクトを利用して、案件の定義付け、ハード、OSの選択、プロジェクト化まで凝縮して紹介したいと思います。 案件の誕生まで あるユーザ企業が、この連載の第1回に記載したポリシーで事業サービスを提供していましたが、システム的には丸5年目を迎え、Webサーバが100台と、Webサーバが参照するためのDBサーバが50台を数えるまでに増大。これらの設置、監視、保守に関しては全て外
そこで数年前からずっと考えて試行錯誤をしているのが、営業プロセスと開発プロセスの一体化です。製販一致といえばいいでしょうか。もっと言ってしまうと「商談の一部に要件定義という作業を組み込んでしまう」というものです。つまり受注前に要件定義を完了してしまうということです。 システム開発について論じられる際に、意図的なのか無意識なのかはわかりませんが無視されているのが契約の問題です。いくら開発側が素晴らしいと思うものを作ったとしても、お客様が受け容れてくれなければ1円の価値もないのです。ですから、どういうものを納品すればいくらの価値があるのかというのを合意する必要があります。その合意を見える化したものが契約書です。 ここで「何が出来上がるかはやってみないとわからないけど、とにかく一緒に頑張りましょうよ」という契約にするというのももちろん可能です。それは役務の提供ということになります。要するに成果を
多様な立場のメンバーが集まる会議では，合意形成は一筋縄ではいかない。成功のカギは，メンバー1人ひとりの参画意識を高め，結論に責任感を持たせること。システム開発の上流工程での会議を例に，現場経験で培った実践ノウハウを紹介する。 目次
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
スケジュール通りに進まず一向に終わりの見えないプロジェクト、無事カットオーバーを迎えたがほとんど利用されないまま何年も放置されているシステム、稼動直後からトラブルを発生し利用者に大混乱を引き起こすシステム、運用が複雑で機能拡張もままならないシステム……このようなシステムの話題がたびたびメディアで取り上げられている。 このような失敗プロジェクトには、そもそもシステムに求められる要件を十分に詰めきれないままSIerへの発注を行ってしまったものや、要件を明確にしたつもりでいても、SIerとの間での意思疎通が図れず、要件に関する認識に違いが生じたことに原因があるものが多い。 このように要件が曖昧なままシステム設計/構築を始めると、完成間近になって「こんなはずではなかった」ということになる。慌てて機能の追加や変更を要求することになるが後の祭りである。影響範囲が大きく仕様変更を繰り返す。これではいつま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
