分析設計手法のスタイルとオフショアの脅威 - 設計者の発言
顧客との打合せの場でどんどんモデリングするやり方を「その場方式」と筆者は呼んでいる。いっぽう、ユーザからヒアリングしたことをメモして持ち帰って机上でモデリングして、次回の打合せでその結果を示して検討するやり方を「持ち帰り方式」と呼んでいる。「持ち帰り方式」で対応できる案件も一定の比率で存在するので、そればかりを受注できる職場にいるのなら「その場方式」を身につける必要はない。しかし、「持ち帰り方式」の実践者はオフショアの脅威にさらされていることを知っておいたほうがいい。 ◆スクラッチ案件とリプレース案件 「持ち帰り方式」が有効なのは、メインフレームのオープン化プロジェクトを典型とする「リプレース案件」だ。顧客の生の声よりも、既存のコンピュータ内部のあり方をじっくり調査することで新システムを構想できる。もともと使っていたシステムが使いやすいものだったのであれば、新システムは「建材の刷新された住
ITアーキテクト諸君、君は本当に姉歯建築士を笑えるか? - 雑種路線でいこう
いま仕事でバンガロールにいる。インド人というのは本当に25x25くらいまで覚えているらしく、インド人のツアコンの前で1万円札を両替したら、いきなり1の位まで5桁の割り算を暗算されて、びっくりした。この調子なら、32bitや64bitの2進、10進、16進の変換なんざ一瞬であろうし、さぞ素晴らしいプログラムを書いてくれるのではないか、と期待が沸いてくる。にしても、話し始めると止まらないし、妙に聞き取りにくい英語を話す人々なので、口から生まれてきたのではないかと評されがちな私でさえ、あまり長丁場の議論はしたくない。理詰めで延々と議論が続くものだから、曖昧な仕様書を渡そうものなら、きっと著しく生産性が下がるに違いない。仕様のはっきりしているカーネルやプロトコルスタックとか、機能のはっきりしたミドルウェアとか、いまあるソフトの最適化は頼みたいけれども、業務システムとかユーザー・インターフェースとか
わたしが知らないスゴ本は、きっとあなたが読んでいる: 画面仕様書を「作らない」リスク
IT Pro の開発ドキュメントの最適化で笑わせていただいた。これ書いた人は画面仕様で酷い目に遭ったことがないんだろう。笑った箇所は次の通り。 画面仕様書をプロトタイプ・アプリケーションで代用する方法がある。Webシステムの場合は，HTMLの作り方を工夫すればプロトタイプで実際の入力手順や画面遷移も確認できるようになる。エンドユーザーにとっても，ドキュメントよりは実際の画面で確認した方が分かりやすいので，手戻りが減る。これは帳票にも同じことが言える。 あのな、HTMLで作る画面なんざ、紙芝居だよ。「ふいんき」をかもし出すだけで、そいつは「仕様」じゃねぇ！ボタン配置や文字色を目の前で変えられるものだから、いつまでたっても顧客は「ちょっとコレ直して」と言ってくるんだよ。気軽に直せるものとお金を頂戴しないと直せないものがあることをギッチリと顧客に理解していただくために、画面仕様書はどうしても必要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
