タグ

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

  • 「プログラミングへのこだわり」を方向づける - 設計者の発言

    業務システムの生産性や保守性を高めるための基は「コードを1行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 いっぽう、そんな方針と明らかにそぐわない人たちがいる。彼らはプログラミングそのものに強いこだわりを持っていて、より良いコードをより多く生み出すことに生きがいを感じる人たちだ。チャーミングな彼らの姿を個別案件の開発現場で見るたびに、私はキャスティングの失敗事例を見る思いがして切なくなる。 それは全国チェーンの外店の厨房に、新しい料理を生み出すことに情熱を覚える若者が働いているようなものだ。彼がどう工夫しても、全国一律の料理メニューを改変するのは難しいだろう。そんな才能あふれた若者には、部の企画部門で働いてもらったほうがい

    「プログラミングへのこだわり」を方向づける - 設計者の発言
  • 「ユース・ファースト」なシステム開発 - 設計者の発言

    「販売管理システム」や「生産管理システム」といった基幹システムを開発する場合、基設計よりプログラミングを先行させるアジャイル系のスタイルは向かない。「動くシステム」は「動くプログラムの集まり」ではある。しかし、「動くプログラム」を作って集めたものが「動くシステム」であるとは限らない。そのシステムは、各部屋の住み心地がいいわりに、完成した翌日に自重で崩壊するマンションのようなシロモノであり得る。一般に、一定以上複雑な工学的構築物向けに、組み立てながら基設計をまとめるといったカジュアルな手法は通用しない。 ただしこれは「レファレンス・システム」を用いない場合の話。ここでいう「レファレンス・システム」とは、オープンパッケージとして提供される「完成していて実際に動くシステム」のことである。オープンパッケージであるゆえに、データモデルや業務マニュアルといった基設計情報も添付されている。そういう

    「ユース・ファースト」なシステム開発 - 設計者の発言
    scorelessdraw
    scorelessdraw 2008/12/30
    「レファレンス・システム」
  • 少人数開発と「能力プール」 - 設計者の発言

    ■少人数プロジェクトが儲かる理由 開発案件の最終利益率とプロジェクトメンバー数には一定の相関がある。開発に関わったメンバーの数が少ないほど、一般に利益率は高い。実際に数字で調べてみたわけではないが、筆者の過去の経験からも確信できるし、そのように思い当たる人も多いだろう。 その理由は単純である。メンバーが多いほど、メンバー間の情報伝達のためのコスト(情報コスト)が飛躍的に増えるためだ。指示やいわゆるホウレンソウのための初期コストだけでなく、訂正や伝達ミスにともなうさまざまな後追いコストが、人数の多いプロジェクトほど大きくなる。メンバーが2人のときに情報コストが1だとすれば、(1人のときなら0)、人数に従って次のようにコストは増えてゆく。 2人  1 3人  3 4人  6 5人 10 :  : n人 n(n-1)/2 たとえこの事実が理解されていたとしても、これらのコストを考慮して工数積み上

    少人数開発と「能力プール」 - 設計者の発言
  • 代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言

    データモデリングでは、複合キーに代わって単一項目の代理キー(サロゲートキー)を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル(基方針)」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される(つまり、商品と倉庫の組み合わせで棚が決まる)ことになっているとする(在庫管理では典型的な業務要件だ)。この関係をデータモデルで表すとモデル1のようになる。横浜第1倉庫でA01の棚に保管されることになっている商品100の現在庫が250個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル2のようになる。 2つのモデルの形式上の違いはどこにあるのだろう。モデル1では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ

    代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
  • 振込手数料と消費税の仕訳 - 設計者の発言

  • 売掛金と消費税の仕訳 - 設計者の発言

    「CONCEPTWARE/財務管理」の改訂版(近日公開予定)に関する話題。初版に関して、近所の飲み友達で辣腕のシステムコンサルタントである杉氏から、メールで詳細なレポートをいただいた。今回はその中から消費税の扱いに関する筆者の間違いを恥をしのんで紹介したい。読者の業務知識の勉強に役に立てばうれしい。 ◆消費税は売上計上と同時に認識される 一般に財務管理システムでは、営業管理システム(販売管理システム)で保持されている売上情報や請求情報を参照しつつ、回収実績を登録するようになっている。「CONCEPTWARE/財務管理」の初版では、回収の際に消費税額を登録するようになっていた。つまり、ある新規顧客に対して1万円が課税取引として売上計上されたとすると、次のように仕訳される仕様になっていた。 【売上時】 2/25 売掛金  10,000/売上   10,000 【回収時】 4/15 現金(等)

    売掛金と消費税の仕訳 - 設計者の発言
  • 1