#04 - 業界初のシステム開発への挑戦

業界で統一したシステム化として失敗事例しかない「商品」がありました。その失敗事例を参考にして更に検討し、なんとか業務システムとして成功させたプロジェクトに参画させてもらったことがあります。その後の自分自身の成長を大きく左右するプロジェクトでもありました。その時の経験を綴ります。

背景と必然

厚生年金は最近よくニュースでも話題になるので、みなさんご存知ですよね。では厚生年金基金はどうですか? 同じ様なものじゃないのと思われるかもしれませんが、本質的には違います。また、厚生年金基金の場合は、それを支援する金融商品もあるのです。ただ、今の時代は厚生年金基金は運用益を出すこと自体が困難になってきているため、だいぶ少なくなっており確定拠出年金への移行が加速しているようです。

厚生年金基金とは、
基本的には、会社が厚生年金基金を設立し、国（日本年金機構等）に代わって厚生年金保険料の一部を収受・記録、年金資産の管理・運用、年金額の裁定（記録に基づく決定）、支払いの業務を行うという仕組みになっています。
もともとは、老齢厚生年金の給付を基金が代行しつつ、さらに基金独自の給付を上乗せし、加入員の受け取れる年金額を増やすことで、充実した生活保障を達成することを目的としていました。
厚生年金基金が高い資産運用の利回りを実現できた時代には、この目的を達成することができていました。しかし、バブル景気が終わり、1990年代から景気が後退し始めると基金の運用利回りが低迷し、各基金の財政が悪化し始めました。その結果、確定給付企業年金に移行し、解散する基金が相次いだのです。

りそな銀行のページ 「確定拠出年金」と「厚生年金基金」の違いとは？ から引用

りそな銀行のページに簡単な説明が記載されていましたので、引用しました。少し補足すると、ここで言っている「資産運用の利回りを実現できた時代」というのが、私がこの仕事に携わった時代のことです。大きな会社は一社で小さな会社は連合で厚生年金基金を設立し、国の代行で集めた資金と退職金積立金を高い利率で運用し、合わせて社員への退職金としての還元することを実現していたのです。その際、運用の一部で金融商品や保険商品を購入して安定した利率での運用を実現する基金が多数存在しました。大手の電力会社、ガス会社、大手スーパーなどがこぞって厚生年金基金の運用のために金融商品や保険商品を取り入れていました。

一言で表現するとしたら、厚生年金と企業の退職金を統合して管理し、社員に還元する仕組みです。そのときの掛金の運用を支援するための商品の一つとして厚生年金基金保険というのがあったのです。

この時、厚生年金基金の運用を支援する商品は、信託銀行と保険会社でしか取り扱うことができませんでした。(のちに、銀行でも扱える様になりました)また、これらの商品の契約量は信託銀行が上位を占めており、保険会社のシェアはそんなに多くありませんでした。

そんな背景の中、ある保険会社が決断したのです。
厚生年金基金保険システムを開発してその良さを訴求しシェアを伸ばすために投資することを。

調査と学習

プロジェクトが立ち上がり、プロジェクトメンバーが選定されました。もちろん、我々は発注をいただく立場ですが、この時は、お客様と共に体制が組まれ一丸となって取り組むように席自体も近くに設けられました。今だと、偽装請負の疑いをかけられるような感じですね。当時としても、あまり見かけない形式でした。

その時に設計リーダーとして、3名が選抜され、そのうちの一人が私でした。3大業務領域に対し1名ずつのアサインでした。お客様もそれぞれの業務領域に専任の担当者がアサインされました。業務の専門家1名と情報システムの担当者2名でした。

3大業務領域
掛金 : 厚生年金代行部分と加算部分に対する拠出金を徴収したり管理する業務
裁定 : 給付対象の年齢に近づいた時に権利の確認をする業務
記録 : 対象となる方の掛金や給付、退職金に関するすべての記録管理業務

この時、私は「裁定業務」にアサインされました。当時、商品としての厚生年金基金の統一システム化が困難とされていた部分の業務でした。


プロジェクトは開始しました。

まず最初に実施されたのは、我々に対して、「厚生年金」と「厚生年金基金」の基礎業務知識を叩き込むという試みでした。なんと、3時間/日を6ヶ月間も実施していただきました。原則、午前中は教室でのレクチャーが3時間実施され、午後になると、仕事に戻りますが、最初の頃は失敗事例の研究、各社の退職金制度の理解に時間を当てて、夕方以降、業務理解がなくても設計できる共通部品の設計業務を実施し、設計が完了次第、お客様の立場でその時所属していた会社に開発を発注しました。当然、開発する側も専任のリーダー、開発者がアサインされて体制を作っていました。

データベースの壁

多くの企業と契約して成り立つ保険商品ですが、他の保険と異なる部分がありました。通常の保険は、一定の掛金を運用し、保険部分の費用を差し引いて、その結果をお客様に還元するすることになりますが、厚生年金基金の場合は、お客様の会社ごとに異なる退職金制度に基づいた掛金(退職積立金)があり、勤続年数や給与、職位事の手当て、獲得したポイントなどを考慮した退職金の算出がベースとなった給付金の算出が必要だったということです。本来なら、一社一社異なるシステムが必要になるくらいの内容です。

契約は、各会社単位で実施するので、その際に退職金規定を提供してもらいます。もちろん機密情報扱いですが、これを読み解くのが大変な作業でした。その目的はというと、それまでに実現できなった、標準化して統一された一つのマスターデータベースを構築するということでした。会社単位のデータベースは実現できるのですが、それでは契約のたびにデータベースが必要になり、プログラムも必要になります。どんな企業と契約しても、同一プログラムで業務できるようなマスターデータベースにする必要がありました。

退職金規定を読めば読むほど全く異なる内容だということに気付かされ、その中から共通点と特異な点を整理しながら、どうすればマスターとして設定できるか、大きくなり過ぎればパフォーマンスに影響するし、共通化のためにコード化しすぎると保守が複雑になるということも意識する必要がありました。

何しろ意識しなければならないことが多過ぎたのですが、原点に帰り、その退職金制度はその企業に合うように作られているはずなので、企業の特徴なども理解する様に努めました。例えば、小売業などはパートの従業員の人が多いのですが、その人達にも退職金が行き渡るように制度設計されていたり、営業職が多い企業は、営業の成果をポイント制という制度があり、積み立てたポイント量が退職金に影響したりするということがわかってきたのです。多少の差はあるものの業種や職種で共通化できる項目が浮かび上がった訳です。

その後は、共通部分のデータ項目を整理し、どうしても企業ユニークな項目は企業コードをキーとしたレイアウトにすることで構築していきました。最終的には、なんとか保守や制度変更にも耐えられるデータベースになったと思っています。

帳票の設計の壁

やっとデータベースがなんとかなったと思い、次のことを考えることになりました。その時、お客様システム担当者から諦めの連絡が入りました。

「この帳票は1枚で表現するのは無理だから、2-3枚にしよう !」
「数日、時間をもらえますか? 考えてみます。」
「いいけど、無駄だと思うよ。」

こんなやりとりをして、その後検討開始です。
私は、この手の課題解決が好きでした。
何しろ、達成感が感じられるので。

問題となった帳票は、今でいえば「ねんきん定期便」みたいなものです。最も、若い人は受け取ったことはないと思うのでイメージが湧かないかもしれませんのでサンプルをつけておきます。60歳になったら、この程度の年金がもらえる様になるはずですよというお知らせです。ただ、この例では、なぜその金額になるのかというのはちょっと分かりませんよね。

当時、お客様がさじを投げたのは、算出根拠となった期間や給与、ポイントなどを表示しつつ、その計算式を表示して予定金額も表示するということです。更に言えば、60歳近くになった人が見る帳票なので、小さなフォントは避けなければなりません。現在のねんきん定期便も数枚に別れて表示されています。できればもう少し大きな字がいいかもしれません。

課題としては、一枚で、その人の退職金資格が表現され、年金または一時金の支給金額を計算式と共に一枚で表示するということです。しかも、大きな文字で。

当時の帳票は、異なる各社の制度上考えられる最大の表示域を固定で設計されていました。そして、その固定域の中に必要なデータを表示するというものです。設計としては簡単ですね。ただし、これでは表示されるべき内容が何もない欄が多くなるということもありました。それを発想を変えて、表示する項目は罫線を含めて、必要なものだけを表示することができれば一枚に入れることができるのではと思いました。つまり、全体を可変して出力するという方法です。ただ、当時は今と違い、印刷するときに罫線などを制御するのは結構大変だったのです。

結果として採用したのは、表示域は紙面のサイズ上で設定できる最大で固定し、表示する内容に関しては可変で制御するということでした。つまり枠は固定、その中に何を表示するかはプログラムで制御するということです。この方法が実現できれば、少なくとも当時の契約の中で全ての枠を使い果たす契約はありませんでしたから、一枚に収めることが理論的に可能だったわけです。ちょっと文字だけだとわかりにくいかもしれませんが、皆さんの想像力に頼ります。

最後の難関は、計算式の表現でした。
計算式解析のアルゴリズムは、よく紹介されています。つまり計算式の優先順を考慮して解析するということですね。

例で考えてみましょう。
A + (B * C + D) = Y の場合は、BにCを乗じて、その結果にDを足し、更にその結果Aを足すという計算です。
であれば、B * C + D + A = Y と書き直して左から順に計算しても同じ結果になりますね。
この時、A、B、C、Dが給付額を計算するための項目名で定義しておけば、データベース上の項目名と同一にしておけば、計算式を解析しながら、実際の数値を当てはめて表示し結果を算出することができるはずですね。
マスター上は、理解しやすいように、A + (B * C + D) = Yで定義しておき、出力する際に、B * C + D + A = Yと変換して処理するということです。表示されるのも変換後の形式になります。

当時はこの解にたどり着くまでに結構時間がかかりましたが、なんとか解決することができました。ただし、コンピュータで計算するときは、小数点以下の桁数の問題として「精度」という課題が言語ごとに発生するので、それは要注意でした。

これでお客様が諦めていた帳票にも目処が立ってなんとなく光が見えてきました。

開発チームとの連携

開発チームは、同じ会社のSEチームだったので、連携は容易でした。多少の無理は通すことができるし、相談もしやすいので助かりました。
気をつけなければならなかったのは、開発のための仕様書を書くのは私の仕事だったので、そこが止まると開発者はアイドリング状態になりコストだけが発生してしまうということでした。つまりは私が、ボトルネックになって今う可能性があるということ。どれだけバックログを積み上げておくことができるかということがキーとなったわけです。

開発依頼の順番を考えました。

最初は、小さい共通部品をまとめて発注し、そのテストまでを依頼するということです。共通部品なので単機能であるため、テスト完了まで責任を持って実施してもらうことができます。次に発注したのは、難易度が高い仕様書です。一つ前の帳票での計算式の話もこれにあたります。難易度が高いと開発期間がかかりますので、その間で、その他の仕様書を量産するというのが私の計画でした。

本来は、全ての仕様書を書き上げてから依頼するのが普通の開発です。しかし、当時は学習していた期間を取り戻すために五月雨式の開発手法を採用しました。それができたのは、設計をお客様とともに考え、開発もよく知るメンバーに依頼することができたため、手戻りが発生しても何とか吸収できると踏んだからでした。

想定通り、手戻りは多く発生しました。次第にその傾向を学習した開発チームは、依頼を受けた順番ではなくて手戻りが発生しそうなものを選別して後回しにするということを実施してくれました。おそらく、私の記述する仕様書の曖昧な部分を察知してくれたのだと思います。これは助かりました。チームワークの成果でした。

やはり、プロジェクトチームには「阿吽の呼吸」というものも必要だなと感じるとともに、一人ではないと実感しました。大きな気づきでした。

プロジェクトを終えて

プロジェクトが終了し、しばらく経ったある日。お客様のプロジェクト責任者だったシステム課長から電話がかかってきました。オフィスでは広めの部屋の角に課長席があり、私の席は課長席から対角線上の反対の角でした。実は顔を上げれば見える距離です。

「リーダーの坂上だけど、今日は早く仕事終われそうですか?」
「はい。大丈夫です。」
「じゃあ、一杯だけ付き合ってくれるかな?　駅前の居酒屋で。」
「分かりました。定時で終わって現地に向かいます。」

というような会話 (名前は架空です) を交わして、居酒屋でお会いしました。二人で飲みに行くのは初めての経験でしたので緊張したのを覚えています。まだ20代の若造でしたから。しかも、お客様です。

「今回のプロジェクトでは、お疲れ様でした。今だから伝えられるけど、松浦さんにお願いした部分は失敗しても損はないと考えていたんだよ。どこも構築できていない業務だったからね。でも、その部分を作ってくれたおかげで、他社からシェアを奪い取ることができたんだよ、今回のシステムのおかげで。給付関係の処理が分かりやすいというのが、クチコミで回ったらしく、契約が急増したよ。本当にありがとう。今日は奢らせてもらうよ。」
「ありがとうございます。とても嬉しいです。役に立ったんですね。」

という様な会話で始まり、1時間余りの二人きりでの酒席を緊張しながらですが楽しみました。次の日に、開発チームにこのことを伝え、とても喜んでもらいました。今回のプロジェクトは、自分でも得るところが多く、終わってしまえば楽しく実施できたなと思いました。得られたことで最も大きかったことは、本当に利用する最終ユーザーのことを考えてシステムはデザインすべきだということとチームワークです。また、感謝の言葉をもらうとそれまでの苦労した時間は消え去っていくかのように感じました。

システムを使う人とは、お客様の先にいるユーザーさんだけではなく、今後保守を担当していく人で法改正や退職金制度の変更を管理する人、新たな契約が入った場合に退職金制度をデータベースに設定する担当者、そしてプログラム自体を修正保守する人も含まれます。それぞれの視点で今後も成長できるシステムとしてデザインするということの重要を学んだ、それまでで最高の経験でした。ともすれば、発注者の代表であるお客様システム担当者のことだけを考えがちですが、そうではないんだと感じた経験でした。

その後の仕事に対する姿勢の基礎ができたプシロジェクトだったと思っています。
そして、それを成功裡に導いたのは取りも直さず阿吽の呼吸で動いてくれたチームのおかげでした。
最高の経験はその後の人生を変える力を持っているものですね。