10月のPHPの脆弱性騒動で見えたのは、古いバージョンを誰も更新しないまま動かし続けていたサイトの危うさでした。
企業型DCにも同じことが起きます。
導入時の担当者がいなくなり、加入していない社員には案内も届かない。
大企業でも、制度は放っておけば止まります。
導入して終わりにせず、制度を見守り続ける「保守役」。
そこに、これからのDCコンサルタントの価値があると私は考えています。
10月21日、レンタルサーバー各社が次々とサイトを止めました。
PHPという、世界中の多くのホームページを動かしているプログラムに、外部から勝手にプログラムを動かされるおそれのある重大な脆弱性が見つかったからです。
修正版が公開され、レンタルサーバー各社は夜通しで更新を進めました。
それでも騒ぎは収まっていません。
攻撃の試みは公開後に一気に増え、数日たっても一部のサービスを止めたままの企業があります。
10月23日には、3件目となる脆弱性も公表されました。
私がこのニュースで一番引っかかったのは、脆弱性そのものではありません。
「修正版が出ない古いバージョン」の話です。
作った人がいなくなったシステム
PHPには、開発元が面倒を見てくれる期間があります。
今回、正規の修正版が出たのは8.2以降でした。
8.1以前はすでにサポートが終わっています。
あまりに深刻な問題だったため、8.1・8.0・7.4には最小限の修正がソースコードで特別に公開されましたが、それより古いバージョンには何も出ていません。
IPA（情報処理推進機構）は注意喚起の中で、サポートが終了した古いPHPを使い続けているサイトやサービスが見られる、と指摘しています。
なぜ、古いまま動いているのか。
理由は想像がつきます。
作った人が、もういないのです。
制作会社との契約が終わった。
担当者が異動した。
動いているから、誰も触らない。
触り方を知っている人もいない。
そうやって、何年も前のバージョンのまま、静かに動き続ける。
何も起きなければ、誰も困りません。
困るのは、何かが起きたときです。
大企業でも、DCは「サポート切れ」になる
この話を読みながら、あるお客様のことを思い出しました。
その方は、誰もが名前を知っているような大企業にお勤めです。
勤務先には企業型DCがあります。
ところが、導入されたとき、その方はDCに加入していませんでした。
お話を伺う中で、私は加入を勧めました。
勧めるだけでなく、DCを始めるまでのサポートもしました。
そして、その方は最近、DCに加入されました。
驚いたのは、そのあとに聞いた話です。
周りの同僚は、ほとんど加入していないそうです。
そもそも、会社にDCがあること自体知らない人も多いそうです。
導入当時の人事担当者もすでに替わっていて、制度について社内で話題になることもないようです。
あくまで、その方から伺った話です。
会社全体の加入状況を、私が確かめたわけではありません。
それでも、私はこう感じました。
これは、サポートが切れたまま動いているPHPと同じだ、と。
制度はある。
掛金を出す仕組みも、運用商品も、規約も、ちゃんと動いている。
けれど、作った人はもういない。
社員に制度を届ける人もいない。
だから、誰も使わない。
大企業なら人事部もしっかりしているし、制度もきちんと回っているはず。
私も、どこかでそう思っていました。
でも、会社の大きさは関係ありませんでした。
むしろ、大きな会社だからこそ起きることなのかもしれません。
私も会社員時代、人事で採用の仕事をしていたことがあります。
大きな組織では、人事の仕事も細かく分かれていて、担当者が数年ごとに替わることも珍しくないと思います。
前任者が導入のときに込めた思いや、社員への届け方の工夫が、引き継ぎ資料に収まりきらないことは、十分にあり得ると思います。
担当者が替わっても、制度は止まりません。止まらないからこそ、誰も気づかないのです。
加入していない人には、何も届かない
なぜ、こういうことが起きるのか。
私なりに考えてみました。
企業型DCには、加入するかどうかを社員が選べる設計があります。
加入資格を「希望する者」とする方法や、選択制DCがそうです。
選べること自体は、悪いことではありません。
問題は、選ばなかった人のその後です。
企業型DCを実施する事業主には、加入者への継続投資教育が努力義務として課されています（確定拠出年金法第22条）。
けれど、裏を返せば、その教育が向かう先は「加入者」です。
導入のときに加入しなかった人には、制度の案内が二度と届かないことがあり得ます。
私のお客様も、導入のときには加入しませんでした。
それでも、私とあらためて制度の話をする中で、加入を選ばれました。
一度「入らない」を選んだ人でも、誰かがその人の状況に合わせてもう一度話をすれば、選択が変わることがあります。
逆に言えば、その一度がなければ、何年たっても変わらないということです。
導入から年月がたつほど、加入しなかった人は、制度があったことすら忘れていきます。
新しく入社した人は、入社時の書類の束の中に案内が埋もれて、それきりになるかもしれません。
そして、制度を知る担当者がいなくなれば、もう誰も思い出させてくれません。
PHPなら、サーバーが止まればすぐにわかります。
でもDCは、誰も使っていなくても止まりません。
掛金を出す人がいなくても、会社は困らない。
困るのは、何十年かたって、退職するときの社員です。
加入率は、制度の健康診断
ここで一つ、具体的な数字の話をさせてください。
企業型DCを入れている会社で、私が一番知りたい数字は**「加入率」**です。
加入できる社員のうち、実際に加入している人は何割いるのか。
導入したときは、説明会も開かれ、社内の関心も高かったはずです。
では今、その数字はどうなっているのか。
新しく入った社員はどのくらい加入しているのか。
導入時と比べて、上がっているのか、下がっているのか。
もし、誰もこの数字を知らないとしたら、それはPHPのバージョンを誰も知らないのと同じ状態です。
動いてはいる。
でも、健康なのかどうかは誰にもわからない。
加入率が低いこと自体が、悪いわけではありません。
加入しないという選択にも、その人なりの理由があります。
問題は、選ばなかったのではなく、知らなかった人がたくさんいることです。
知ったうえで選ばないのと、知らないまま入っていないのとでは、まったく意味が違います。
「保守役」は何をする人か
では、サポート切れを防ぐには、何が必要なのでしょうか。
私は、制度にも**「保守役」**が要ると考えています。
導入した人が去っても、制度を見守り続ける人です。
保守役がまずやるのは、制度の現状を見える化することです。
加入者は何人いるのか。
加入できるのに入っていない人は何人いるのか。
運用商品は、導入時のまま一度も見直していないのか。
規約は、最近の改正に合わせて更新されているのか。
担当者が替わるたびに、この確認がゼロからやり直しになっているなら、それ自体が問題です。
その上で、加入していない人に、もう一度制度を届けます。
導入時に「入らない」を選んだ人も、ライフステージが変われば考えが変わるかもしれません。
私のお客様がそうだったように、話を聞けば加入する人もいるはずです。
選び直す機会があることを、定期的に伝え続ける。
それだけでも、制度の使われ方は変わるのではないでしょうか。
たとえば、年に一度、次のことを確かめるだけでも違います。
加入率と、新入社員の加入状況。
運用商品の顔ぶれと、選ばれている商品の偏り。
規約が最新の制度に合っているか。
担当者の交代があったなら、何が引き継がれ、何が抜け落ちたか。
どれも、一日あれば確認できることばかりです。
ちなみに、12月1日からは企業型DCの拠出限度額が見直されます。
保守役がいる会社なら、こうした改正のたびに「うちの規約はどうする？」という話が自然に出ます。
保守役がいない会社では、改正は誰にも気づかれないまま通り過ぎていきます。
保守は、誰にも褒められない
正直に言うと、保守の仕事は地味です。
PHPを更新しても、サイトの見た目は何も変わりません。
何も起きなければ、誰にも褒められない。
むしろ「何もしていないのに費用がかかる」と思われることさえあります。
DCの保守も同じです。
加入者の数を確認する。
案内を出し直す。
規約の改正をチェックする。
どれも、目立つ成果にはなりにくい仕事です。
新しく制度を導入するときのような華やかさはありません。
古いPHPが放っておかれる理由には、「動いているものを触るのが怖い」という気持ちもあると思います。
更新したら、どこかが壊れるかもしれない。
だったら、このままでいい。
DCも似ています。
規約を変えるには、労使の話し合いが要り、運営管理機関とのやりとりも要ります。
手間がかかるうえに、変えたからといってすぐに目に見える成果が出るわけでもない。
だから、つい後回しになる。
そして後回しにしているうちに、担当者が替わり、そもそも何を後回しにしていたのかもわからなくなる。
保守役の仕事は、その「怖さ」と「面倒さ」を、会社の代わりに少しだけ引き受けることなのかもしれません。
それでも、今回のPHPの騒動を見て、私は確信しました。
本当に価値があるのは、何も起きていない日に、地味に更新を続けている人なのだと。
DCコンサルタントを目指す方へ
企業型DCの仕事というと、導入の提案や制度設計を思い浮かべる方が多いと思います。
もちろん、それも大切な仕事です。
でも、私がこれから一番必要とされると思っているのは、導入した後の制度を見守り続ける人です。
担当者が替わっても、制度の記憶をつなぐ人。
加入しなかった人にも、もう一度声をかける人。
改正があれば、規約を見直すきっかけをつくる人。
社内の人事担当者は、どうしても変わっていきます。
だからこそ、会社の外にいて、担当者が何人変わっても同じ制度を見続けられる人には、意味があります。
会社の外にいる人だからこそ、「この数字、最近どうなっていますか」と遠慮なく聞けることもあるでしょう。
それは、私があのお客様にしたことと、本質的には同じです。
制度があることを伝え、その人にとっての意味を一緒に考え、選び直すきっかけをつくる。
特別な技術は要りません。
必要なのは、作って終わりにしない姿勢です。
正直に書くと、あのお客様がDCに加入しても、始めるまでのサポートをしても、私には一円も入りません。
それでも、お客様にとってメリットがあるなら、勧めることが大切だと思います。
以前の記事「『ありがとう』だけで終わる相談に、意味はありますか？」で、アダム・グラントの『GIVE & TAKE』に出てくる「ギバー」の話を書きました。
自分の得になるかどうかより先に、相手のためになることを差し出す人です。
保守の仕事も、すぐにお金になるとは限らない仕事です。
だからこそ、ギバーのような姿勢を持つ人が、DCコンサルタントに向いていると私は思っています。
とはいえ、私自身もまだまだ若輩者です。
偉そうに言えるほど、できているわけではありません。
これからも精進していきたいと思っています。
おわりに
PHPの騒動は、この記事を書いている今も続いています。
修正版を当てた会社がある一方で、サポート切れの古いバージョンは、今もどこかで動いているはずです。
誰にも気づかれないまま。
企業型DCも同じです。
今この瞬間も、作った人がいなくなった制度が、誰にも使われないまま動いているかもしれません。
あなたの身近な会社の制度は、誰が保守しているでしょうか。
その問いに「誰もいない」と気づいたとき、そこがDCコンサルタントの仕事の始まりなのだと思います。
