だいたい最初に変だと思わない？このファンクションポイント法は1979年にIBMのアルブレヒトさんが発表して1984年には現在に近い形になっているというんでしょ。ならば今ファンクションポイント法がなぜ注目されるのか？というところで疑問に思うハズなんだ。そりゃたしかにしれっと書いてある。ビジネスアプリケーションはメインフレーム上のCOBOLで開発するのが普通だ、とされていたときは行数でシステムの規模を比較したので問題なかったが、オープンシステムへの移行、オブジェクト指向を中心とする言語の多様化、CASEツールの普及で、行数の比較は意味が無くなった、とね。ここで変だと思うべきなんだ。だって、アルブレヒトさんが発表した1979年に、しかもIBMでそんな問題が起こっていたと思うかい？IBM-PCの登場が1981年。C++の教育機関への配布が1983年。アルブレヒトさんがファンクションポイント法を考えたときの問題意識は、少なくともプラットフォームが多様化した、とか開発技法が多様化したではないはず。コンピュータネタ、目次へアルブレヒトさんがそれ以外に何をしていたか調べられなかったので、彼がファンクションポイント法で何をしようとしたのか本当は良く分からないんだけど、考えられるのは、プログラム規模を行数で測るとき、言語による違いを補正しようとしたこと。COBOL,FORTRANはそれぞれ、1959,1954の生まれだが、60年代以降、様々な言語が生まれてきた。APLが1964年,PL/Iが1965年、FORTHが1968年、ついでにPascalが1970年、C言語が1973年。確かに別々の言語で書かれたプログラムの規模を行数だけで比べるのは無理があるなあ、と感じたんじゃないかな。それで「異なる言語で書かれたプログラムの規模を行数で算出した場合のばらつきを補正するためにファンクションポイント法が作られた」という可能性が考えやすい。納まりがいいのは1979年に誕生したAda。これは可読性を重視したので行数で図ると生産性が低く見えるみたい。それを弁護するために、ファンクションポイント法を作った、なんだけど、残念ながらAdaを作ったのはフランス人。アルブレヒトはドイツ系の名前。それはなさそうです。なお、孫引きだけど、一定のファンクションを実現するに必要な行数は、アセンブラ320：Ｃ160：コボル108：フォートラン108：ＰＬ／Ｉ91：パスカル80、だったかなあ。あやふやだけど15年前の記憶なのでゴメン。
いずれにせよファンクションポイント法は「言語」レベル「コーディング」レベルで用いられるものとして生まれ、多分1984年の段階でもそうでしょう。で、そのとき既に「現在に近い形」であるとするなら、要するに「プログラムの規模」を計る以上のものではないと思われる。今ファンクションポイント法が気にしているらしい「多様化したプラットフォーム上のシステム全体の規模」なんて想像もしていないはず。
1979年というとUNIXは生まれていたから、マルチプラットフォームを考えに入れていてもおかしくないのでは、と思うかもしれないけど、アルブレヒトさんはIBMの人。気にしてなかったと思う。IBM版UNIXであるAIXが発表されたのは1986年。だからファンクションポイント法はプラットフォームの違いをどーたら、という考えを入れているわけがないと考えられるわけだ。ファンクションポイント法のユーザー団体がであるIFPUGができたのは1986年、ってことだよねえ。今までのことを考えると、IFPUGが唱え、現代までつながっているファンクションポイント法は、アルブレヒトさんの直系ではなく別のところから出てきた。つまり、何らかのニーズに基づいて計測法を探しているうちに再発見されたもの、と考えるのが妥当でしょう。都合良く引っ張ってきたもの、と言ってもいいかもしれない。IFPUGのキーマンとしてアルブレヒトさんがいるのでなければね。
ようするにファンクションポイント法はアルブレヒトさんのオリジナルを換骨奪胎したもの。もし彼らが「そんなつもりはない」と主張するようであれば、「そんなことも気が付いていないほど頭の悪い人が考えたもの、使えるわけがないじゃない」。ハイ、それまでヨ。（逝去した植木等さんに敬意を表しているつもり。）じゃあ、彼らは何のためにファンクションポイント法を持ち出してきたか。1986年って、何がムーブメントになっていたんだろう。海外の話だからシグマ計画(1985〜1990)は関係ないとして。ここでIFPUGが主張するファンクションポイント法とやらの用語で理解しにくいのを思い出してみると、システムの規模は「ユーザ視点」から見るというのがまず引っかかる。「アプリケーション境界」が何の疑問もなく定義できるというのも納得しがたい。で、ここだけは勘なんだけど、これって業務パッケージソフトならきれいに当てはまらない？なるほどメインフレーム上の業務パッケージの雄SAP R/2は1980年代から1990年代初頭に隆盛。ダウンサイジングしたプラットフォームのR/3は1992年発表。なんかしっくりくる。
ファンクションポイント法は業務パッケージソフトのために作られたのではないか？と仮説を立てて用語を再解釈してみてちょうだい。今まで理解が困難だった部分が癪に障るほど良く分かるから。「ユーザ視点」という、その場の都合によって何とでも変わるもの。これって業務パッケージのセールストークから引っ張ってきたんじゃないかねえ。「重要なのはユーザーから見える機能です。実現方法は副次的な問題です。ですから自社開発にこだわらず、業務パッケージを使いましょう。」いかにもじゃありませんか。しかし業務パッケージとなると表計算ソフトのようにインストールしてさあ使ってください、とはいかない。何らかのカスタマイズが必要となる。そこでカスタマイズを有償で提供する時の算出根拠として、内部論理ファイルは「ユーザーに見える」などとご都合主義を使う。確かにパッケージソフトベンダーがカスタマイズ時の見積もりを立てるときに「内部ファイルをこれだけいじりますので」と言えばユーザーに見えるようになる。だから「ユーザ視点」で見えるのだと言いたいらしい。
「アプリケーション境界」もパッケージソフトへの適用を前提とすれば、すっきりと分離できる。オリジナルの提供機能はアプリケーション境界内、計表追加は境界外。境界をまたぐのでお金がかかります。ああ分かりやすい。するとなぜ、ReadOnlyのファイルはアプリケーション境界外とするのか分かる。既存システムから業務パッケージにインポートするファイルだから。Updateするファイルはアプリケーション境界内なので、カスタマイズ工賃が変わる。これが（多分アルブレヒトさんオリジナルに近いと思われる）NESMA概算法でバッチ処理を計測するとなると、プログラム毎のI/Oを数えて、だから納得しやすいが、IFPUGの方法だと、どんな処理をしようが、インプット３つで計表１つなら、計表１つのファンクションというものすごく安く見積もられるものになる。ならば、業務パッケージを導入した方がおトクですよ、になる。なるほどファンクションポイント法を導入したいということは、業務パッケージを導入したいからなのね。ならファンクションポイント法なんて言わず、はじめから「業務パッケージ導入推進法」と言って頂戴よ。
とりあえずファンクションポイントを計測する、というのであれば計測しやすいシステム、つまり業務パッケージのカスタマイズに近い「既存のシステムに、少数の出力計表を追加する」とか「制度対応で出力する数値の計算方法を変える」という計算しやすいシステムに適用するんではどうかな。役に立たないって？うーん。業務パッケージのカスタマイズ価格の妥当性を検証するのには使えるかもね。制度対応で複数のシステムに手を入れた時、業務パッケージだけ頭抜けて高かったりしたら、それは一言値切りましょう。
ファンクションポイント法がユーザーの利便性や耐障害性（耐障害性が高い方がファンクションポイントは低くなる・・・ユーザーから障害回復が見えないので）を無視するという批判は言い飽きたし、どうやら向こうも自覚しているようなので繰り返さないけど、ファンクションポイント法は業務パッケージソフト推進／カスタマイズ見積もり手法である、と納得したところで限界は見えたね。私そんなに変なこと言ってないでしょ。突拍子もない考えとも思わない。少なくとも国内ではことごとく失敗しているファンクションポイント法が自分ちでは導入できる、という考えほど突拍子もないものではないと思うよ。
でも、できそうもない、と分かっているファンクションポイント法を皆さんどうしてやりたがるのかね。多分「万能業務パッケージソフト」というものにあこがれているのだと思うよ。で、全てのシステムは「万能業務パッケージソフト」のカスタマイズだ、と思いたがっているんだろう。emacsってそういう方向を目指してません？OracleがPeopleSoftを買収したのもそれを目指してか？でも大変だと思います。smalltalkはシステム環境をカスタマイズしてアプリケーションにするという発想で、万能パッケージソフトだったと解釈してよいかもしれませんが、到底普及したとは言い難い。今ではMS-Excelが万能業務パッケージソフトのイメージかな。マクロでメニューからカスタマイズして、業務処理を行います、と。これなら、ワーク用のシートもタブとして表示されるから、内部論理ファイルも「ユーザ視点」で見ることができるというのは自然だな。EUCでやってもらえれば言うこと無し。これなら最終出力ワークシートの複雑さを書き込み行数で計るか、セルの修飾具合で決めるか、とかいうガイドを作ってくれればファンクションポイント値を迷わず計算できる。ああすっきりした。残る心配は、データを別のファイルから読み込んだとき、つまりマクロで読み込ませたときと、別のファイルから使用者にコピー＆ペーストさせたとき、つまりマクロを使わないときと、使用者に個別入力させたときにファクションポイントがどう変わるかです。個別入力させるときはフォームを用意したときと、セルに直接入力させたときのファンクションポイントをどのくらい変えればよいかはIFPUGに悩んでもらうとして。多分「それは各ユーザーの問題です」と思って悩む必要も感じないんだろうな、悩ましいことだ。
万能パッケージソフト、実は生成文法から連想してます。だから「人は万能業務パッケージソフトにあこがれる」と言っているわけ。ビジネスロジックは数行にまとまると仮定して、プレゼンテーションは万能パッケージソフトに任せることが出来る限り（万能パッケージは極めて信頼性が高く停止することはないという前提で）、プログラム規模をファンクションポイント法で計って、そんなに違和感はない。でもビジネスロジックってもう少し複雑ですよ。例えばそのレコードに「残高」と付く項目、いくつありますか？で、休日がないという前提でマッチングをかけるのですか？どこかの項目が０だったときは？ヌル値の場合ってありますか？
オンラインだとユーザーから見て異例のデータとシステムから見て異例なデータが一致する確率が高い。またその場で分かる。バッチだとユーザーから見てあり得るデータだが、システムから見ると異常なデータが多くなる。その場で修正できない。というわけでオンラインとバッチは別の計測法が必要となるハズ。で、IFPUGが考えているのがオンライン。NESMAがバッチ処理、と見て良いかな。だからどちらかに統一しようとすると整合性がとれなくなる。