Smart Client

エストニアでも線路沿いにたんぽぽが咲き乱れるようやく春らしい気候になりました。ただまだ早朝夜間や、建物の影では肌寒いです。

つい先日エストニアの方々と雑談をしたときのことです。ちょうど初めてのデジタル署名を経験した後だったので、あれはすごく便利、日本のハンコは面倒で嫌だったんだということを伝えました。エストニアのDigital Signatureについては下記をご参照ください。

https://e-estonia.com/component/digital-signature/

すると、彼らからこういった趣旨のことを言われました。

「個人でももちろん便利なんだけど、企業でもかなりの事務の手間が省けてすごく助かる。エストニアは人口が少ない小さな国だから、そういう手間暇を人間がやっていたらあっという間に人手不足で経済が回らなくなってしまう。日本みたいに優秀な若い人材がたくさん国内で就職してくれるわけではないんだよ」

彼らがどういったニュースや情報から日本の印象をもったのかはさておき、さて果たしてこれを「そうなんだね」と安直に私は同意してよかったのでしょうか。確かに全人口131万ほどのエストニアは一般的に小さな国ですし、翻っていかに散々若者の就職率や海外離れが話題になったところで、そもそもビザや言語や生活レベルを考えれば若者がこぞって海外に就職してしまう…なんていう多言語国家かつEU加盟国のエストニアのような事態は日本では起こっていないし、これから起こる可能性も低いと思います。ただし若年人口もとい就労世代の人口は日本においても縮小に向かっているのは揺るがせない事実です。この「手間なことをやっていたら人手不足で経済が回らなくなってしまう」という感覚は、正直日本でも有効なのでは…。実際人材が豊富な大企業はともかく、中小企業では必要なポストに必要なリソースが避けず窮地に陥ることは日常茶飯事ではないでしょうか。

そこで出てくるのがいわゆる効率化や機械化、IT化といった部類だと思うのですが、なんとなく日本の中だと「無駄をなくす」＝「人件費削減」といった短絡的な文脈で捕らえられていることが多いように感じます。それも大抵マイナスの意味で語られているのではないでしょうか。現場を理解していない上層部の絵空事だ、みたいなイメージが私にもあります。

ここらで、決して目先の利益をかさ増しするためというだけの観点からではなく、これから人口が減っていく日本の将来や経済のため、いやせめて、いつかのIT化は避けられないので、なるべく少しでも良い結果にしてやろう、というくらいの共通認識は、彼らエストニア人のように広く一般的に日本人が持っていたほうがいいように思うのです。

というのも、日本人のプログラマーは足りていません。人口云々の前に人手不足です。その結果が文系新卒もIT会社に入ってプログラムを学ぶ、といった現象になるかと思うのですが、正直優秀なプログラマーになるには相応の努力とセンスが必要です。しかしプログラム言語を介して、世界中にリソースを求めることが可能です。これがオフショア開発です。

では世界中からプログラマーを確保できるので問題ないかと言えばそうではなく、ITに不慣れな日本人のクライアントと世界の開発チームの間を埋める仲介人を海の向こうに求めることはできません。相変わらず人手不足のままです。そしてこれは一朝一夕に育つものでもありません。

敏腕なマネージャーと機動力の高い開発チームにあたるのは、はっきりお金と時間と運次第です。これはもう、来たるIT化のために「良き」クライアントであることが、結局は1番得をすることになるでしょう。

経験とは尊いもので、百戦錬磨の第一線現場プレーヤーというのはとても頼りになります。こんなことがあった、あんなこともあった、そういうときはこうすると上手く行くもんだ。こうした経験から得られる知見や感覚というのは文字通りその経験分の人生と、それを乗り越え続けるタフネスを延々と必要とするもので、何にも代えがたいものだと思います。

この経験則がプログラム化しにくいというのは、どんなアナログなシニアのクライアントも大体は直感的に理解していただけます。ただそこから、その貴重で膨大な自分の経験を、類型化しパターン化し網羅しつつ、原則と例外に振り分けてどちらにも柔軟に対応できる「ルール」や「マニュアル」として規定（プログラム）できるか、それ以前にその作業が必要だということを理解してもらえるかというと、これは何故か別の話です。どころかそういうマニュアル化作業に嫌悪感を示す方もいます。

汗も涙も滲んだ思い出を、ちょっとばかり分類してエッセンスを抜き取って抽象化してシステムに載せたところで、その輝きがあせることはありません。

是非皆さんの中に、外部のシステム会社やコンサル会社、または新人さんでもいいです、

「この場合はどういう作業をしていますか？」

ということを聞かれた際に、

「Aの場合はこう、Bの場合はこう。ただしCの要素があったらここをこうして、後はDとか」

という過去の経験を網羅しただけの解答をする前に、一度自分で「原則（プリンシパル）」と「それを遂行するための基本ルール」と「考慮すべき場合わけ」と「自分の経験」にわけて考えてみてください。高校生の数学の教科書にだって定理と公式と例題と練習問題があります。三角関数の例題を並べただけで加法定理を理解させるというのは、それこそ相手が天才か多大な経験に裏打ちされた秀才でないと通用しません。イマイチ反応の鈍いシステム担当や笑顔だけがさわやかなコンサルタント、私もそうですがやる気にかけるゆとり世代にそんなこと期待するだけ無駄というものです。

自分の作業内容をマニュアル化してみてください。原理原則に即してなるべくシンプルに美しく系統立ててください。あまりに例外処理や個々人の裁量に依る部分が多いときは、抜本的に改革が必要なのか、いっそいざというときにIT化しないことも選択肢に入れるべきです。ミスが多い部分は、何か条件付けに不備やダブリがあるはずです。システム化すると、各人がギリギリうまく回避してくれていた部分がすぐにバグとなって表出します。

もちろん本来そうしたギャップを埋めるのはシステム会社の担当者であるべきですが、残念ながらそんなことを言っている場合ではないのです。開発部も、契約を結ぶ上層部も、常に忙しそうな現場の人間も基本的に同じ言語を話してはいないのです。それでいて最終的に1番割りを食うのは、中途半端な慣れないシステムで日々の業務を回さなければいけない現場です。既に種々の怨嗟をシステム会社にお持ちの方もいるとは思いますが、もはや自衛するより他なしでしょう。一応システム側の人間も、一生懸命やっているのです…。

未来の日本社会が少しでも良きシステムを持てますように！

【執筆者プロフィール】
楼　まりあ

神戸・東京・マニラのオフショア開発を繋ぐブリッジSEとして、そして東欧での新拠点をリサーチするため現在エストニア現地企業で外部契約社員として勤務。大学時代、マニラオフィスのオープンスタッフとして1年間マニラに滞在。NYでインターン経験有。
東京大学経済学部卒。