タグ

ブックマーク / watanabek.cocolog-nifty.com (5)

  • 「何を使って設計書を書いていますか?」と尋ねよう: 設計者の発言

    業務システムの複雑膨大な設計情報を効率的に管理するために、Excelのような汎用ツールではなく、専用のCADツール(システム開発用の設計情報管理ツール)を使おう。そのように主張しているのだが、反応はさまざまだ。もちろんほとんどの技術者が賛同するのだが、所属組織にそれを導入できるかどうかになるとビミョーだったりする。 専用ツールを用いることの効果のひとつが、設計の巧拙がはっきりする点だ。スキルレベルの高い組織であればそれでいいだろうが、そうでない組織は現状維持を望むかもしれない。Excel方眼紙(細かい方眼紙状に設定されたExcelシート)で設計書を書くやり方は蛇蝎のように嫌われているが、それが設計の拙さを見えにくくするための隠れ蓑として役立っていることがある。彼らはExcel方眼紙がもたらす壮大な無駄を棚に上げ、「新たなツールを導入すれば、余計な学習コストがかかる。だいいち、ツールベンダー

    「何を使って設計書を書いていますか?」と尋ねよう: 設計者の発言
    atsushifx
    atsushifx 2014/10/09
    あいての技術力をしるのに王道はない。SIerに仕事を発注したいのなら、発注者側はソフトウェア開発やプロジェクトマネジメントに関する十分な技術力が必要だろう
  • もう「チーム開発」には戻れない - 設計者の発言

    生産管理システムをひとりで開発しているわけだが、このやり方(おひとりさま開発)に慣れると、分業体制でのチーム開発がいかに非効率だったかがよくわかる。チーム開発は「設計・実装技術の未成熟さゆえの必要悪」だったのではないかとさえ思えてきて、仲間と和気藹々とやっていた昔の自分がなんだか恥ずかしい。 たとえば、いくらしっかり設計してもどうしても仕様変更が起こるものだが、これにともなう手戻りコストがチーム開発では想像以上にかさむ。自分で修正したほうが早いと思いつつ、変更作業のための指示を他人のためにまとめたりする。また、実装担当者の稼働率を上げるために、仕様がまだ不明確であるような機能をあえてあてがったりする。今となっては信じがたいほどの非効率だ。 また、自分で作って動かしてみなければ得られない気づきやアイデアがたくさんあるのだが、チーム開発では設計担当と実装担当が分かれていることが多い。それゆえ、

    もう「チーム開発」には戻れない - 設計者の発言
    atsushifx
    atsushifx 2013/04/03
    どうみてもアジャイル開発やアプレンティスシップとかの話にしか見えない。SIerどっぷりの人にもアジャイルが届いたということ。無論、Git、Jenkinsなどの開発支援ツールあってのことなので、さらにツールと自動化が大事
  • 「業務マニュアル」と「操作マニュアル」の違い - 設計者の発言

    「ユーザマニュアル」という言い方があるが、業務システム開発の文脈でこの表現は使わないほうがいい。「ユーザマニュアルを作りなさい」では、「操作マニュアルを作りなさい」なのか「業務マニュアルを作りなさい」なのか判然としないからだ。いずれも重要な設計要素ではあるが、内容も目的も異なっている。 まず「操作マニュアル」とは、パネルやページの操作方法を説明したものだ。たとえば「パネルAが表示されたなら、ボタンBを押してください。するとデータが一覧されるので、一覧のいずれかを選択状態にしてエンターキーを押せば、続くパネルCが表示されます」といった説明は「操作マニュアル」にありそうな記述だ。文章だけでなく、関連するスクリーンショットを伴うことが多い。 いっぽう「業務マニュアル」とは、文字通り「個々の業務の説明書」のことである。ここで言う「業務」とは、「受注登録業務」や「出荷指示業務」や「実棚報告業務」とい

    「業務マニュアル」と「操作マニュアル」の違い - 設計者の発言
    atsushifx
    atsushifx 2012/08/14
  • アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言

    アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ

    アジャイルの人たちは自分の優秀さに気づいていない - 設計者の発言
    atsushifx
    atsushifx 2011/08/17
  • 「DB構造の前にUIを決める」というアンチパターン - 設計者の発言

    画面定義書があるのにまともなER図がない。業務システムの開発プロジェクトがそういう状況を一瞬でも経由したのであれば、大きなリスクを抱えていると考えたほうがいい。小さな案件でない限り、デスマーチに陥る公算が高い。 喩えるなら、高層ビルの「上モノ」の図面が詳細に出来上がっているわりに「土台」の図面がないようなものだ。その点を問われ、 「ああ、ボーリング調査も土台設計も後でしっかりやるから大丈夫です。土台の図面なんてほら、専門的すぎてお客さんが見てもピンと来ないじゃないですか。お客さんが知りたいのは土台とかではなくて上モノのデザインなんですよ。なんといっても顧客の納得感が大事です」 なんて言う建築士はいない。「顧客の納得感」が重要でないと言うつもりはないが、それだけを基準にして高層ビルを設計できるのなら苦労はない。専門的な仕事の難しさは、顧客には見えないし想像もできない膨大な部分の整合性をはかる

    「DB構造の前にUIを決める」というアンチパターン - 設計者の発言
    atsushifx
    atsushifx 2011/07/28
  • 1