現在、エンジニアパートナー（正社員）を募集中です。 !!
パート社員も募集中しています。家業や育児の合間に過去の経験を活かしませんか。
在宅勤務制度や子育て休暇制度により、ライフスタイルに応じた勤務ができます。
詳しくは、こちらをご覧下さい。
遅くまで、残業をしていて、肩がこるとき、なにがしかの、慣性を感じる。
ハードウエアの慣性は、タイソウ小さい、３０年に６桁進む。
ソフトウエアのそれは、タイヘン巨大だ。
ソフトウエアの生産現場では、この慣性のために、身動きがとれない。
現場は、３０年前と、どのくらい変わっただろうか。
人月の神話は、まだ、残っている。
夜９時から仕事場へ行き、パソコンを起動。
「windows/system32/config/system が見つからない」
との表示!! 嫌な予感が・・・。 久しぶりの起動障害です。WIndows XPのCDを準備して、さあ、戦闘開始：
- 修復セットアップ
- 回復コンソール
- 再インストール
「天災は忘れた頃にやって来る」
我が尊敬する寺田寅彦先生の言葉です。「形あるものは壊れる」分かっていても普段の備えがおろそかになりがちです。でも、良かったです。データパーティションが無事で。明日はデータパーティションの重要なフォルダを全てNASに移動せねば。「スープの冷めない間に」。
今年もJFPUG主催のファンクションポイント法(FP法)のセミナーに参加します。大阪では年２回しか開催されないので何としても参加したいと思っています。１２月にもありますが暮は何かと忙しく昨年は結局行けませんでした。昨年は紹介コースだけの受講でしたが、今年は演習コースも受講する予定です。
工学と呼ばれる分野の対象には通常、定量的な測定法が存在します。重さ、大きさ、速さ、電圧、電流、等々です。でも、ソフトウェア工学はどうでしょう。ソフトウェアの規模は一体どうして計量するのでしょうか？ 正味、精度の確かな計量方法は存在しません。しかし、だからと言って「数えないで良い！」ことにはなりません。「とにかく数える」ことが大切です。
LOC(ステップ数)やFP(ファンクションポイント)は数少ないソフトウェア規模の計量値です。「どちらが良いか？」など余り考える必要はないと思います。LOCは物理的なソースコード行数を、FPは論理的な機能得点を表現しています。木造住宅に例えると、使用する木材の量がLOCで、延床面積や間取りがFPと言うところでしょうか。両者ともに木造住宅の規模を表している事に変わりありません。但し、FPはプラットフォームや実装言語に依存しないという長所があります(あくまで理想的にですが・・・)。また、エンドユーザにとっても、木材の量やLOCよりも、延床面積・間取りやFPの方が分かり易いと思います(FPが認知されるまでには、まだ時間がかかりますが・・・)。
FP法は既に四半世紀以上の歴史があり、その計量法はCPM(Counting Practice Manual)という形で標準化が進んでいます。標準化が進むに従い、誰が数えても同じ計量法が確立されようとしています。これが、現在のFP法の進展段階と言えます。よく「FPを数えて何になる」という人がいますが、これは誤りです。確かに、FPは少なくない誤差もあり、FPを数えたからと言って、生産性や工数が直ぐに分かると言うものではありません。ですが、FPを数えると少なくとも、ソフトウェアの規模を比較する事はできます。そして、社内に専任のFP計量係を設置すれば、FPの精度は増し、実績データの蓄積により、作業時間やLOCとの相関可能なデータが集まれば、これは明らかに自分達だけの「銀の弾丸」になりえます。
私には５歳になる息子がいます。やっと数える事を憶え、物の多い少ないが分かるようになったところです。彼はこれから演算や関数、そしてもっと複雑な数学を操る事ができるようになるでしょう。彼の計量センスは「まず数える事」から始まるのです。ソフトウェアの見積もりとして、KKD(勘と経験と度胸)に依らず、工学的アプローチを選択するのなら、まず、数えなければ何も始りません。
