私が手掛けている研究開発は、①PostgreSQL as a Service、②PostgreSQLの性能向上・機能改善、③PostgreSQLにおけるグローバルトランザクションの実現です。PostgreSQLはオープンソースソフトウェア（OSS）のDBMS（DataBase Management Sys­tem）です。
PostgreSQL as a Service は、NTTデータのクラウド基盤上などでPostgreSQLのマネージドサービスを構築し、PaaS（Platform as a Service）として提供することです（図1）。オンプレミス（ローカルなサーバ）での構築ですとお客さまごとにPostgreSQLのインストールやバックアップなどを一から検討して構築する必要がありますが、これをクラウド基盤上にPaaSとして構築することで、お客さまは簡単にPostgreSQLを利用できるようになり、バックアップも自動的に定期取得され、監視も行われます。
現在、世界的なトレンドとして商用DBMSからの移行というかたちでPostgreSQLの導入が進んでおり、従来はOSSの利用が少なかった、社会インフラとしての基幹系システムにおいてもPostgreSQLの採用が進んでいます。社会インフラシステムの場合は特に、万が一のトラブル時には迅速に解析・対応できるように整えておく必要があり、性能情報の収集機能が重要になります。そこで、PostgreSQLの性能向上・機能改善として、メモリの使用状況を確認するための機能やトランザクションログに関する情報などの性能情報収集機能を開発して、Postgre­SQLに機能追加しています。
PostgreSQLにおけるグローバルトランザクションの実現については、グローバルトランザクションに必要な、複数のデータベースインスタンス（メモリ構造とプロセス群で構成される仕組み）をまたがるトランザクションの実行結果に一貫性を持たせるAtomic Commit、および複数のインスタンスをまたがるトランザクション実行の観測結果に一貫性を持たせるAtomic VisibilityをPostgre­SQL上で実現することで、OSS開発コミュニティへ提案し、採用されることをめざしています（図2）。グローバルトランザクションとは、ユーザがDBMSを操作する際に使用する複数のインスタンスの中で、複数操作を1つのトランザクションとして実現するメカニズムです。PostgreSQLにおけるトランザクション処理能力を増大させるために、複数のインスタンスを連動させることがありますが、インスタンスをまたがるトランザクション処理の一貫性が必要になり、それを実現するための手段がこのテーマです。

PostgreSQL as a Serviceは、コンテナ仮想化ソフトウェアを管理・自動化するためのOSSのKubernetes上に構築することを検討しています。Kubernetes上でのPostgreSQL as a Serviceの実現には、従来のオンプレミス上のPostgreSQL環境では使われてなかったさまざまなオープン製品の組合せが必要になり、最適な組合せの検証を行っています。これらのオープン製品について、知見をためて使いこなせるようにならなければならない点が課題の1つです。さらに、Kubernetes関連は技術の進歩が早いので、その継続的なキャッチアップも重要な課題です。
グローバルトランザクションについては、Postgre­SQLコミュニティ内で機能追加の合意をまだ得られておらず、今後どう開発・展開していくのかを再検討する必要があります。

これは個人的なモットーとも重なりますが、研究開発において「おもちゃ」はつくりたくないと思っています。「おもちゃ」とは、お客さまに使っていただいたけれど、1年後には製品として存在しないものとなりサポートもない状態で、お客さまからすれば梯子を外されたような状況を生み出してしまうことです。
こうした思いから、自らの研究開発成果については、長期的なサポートやメンテナンスのエコシステムが確立されたPostgreSQLなどのOSSに可能な限り取り込み、自分たちだけではなくコミュニティとも連携しながら、お客さまに安心して最後まで使ってもらえるように考えています。そして、成果を世に送り出して終わりではなく、お客さまにお使いいただいてフィードバックを受け、継続的により良いものにしていきたいと考えています。その意味では、お客さまにご利用いただいてからが本番だと思っています。
また、研究開発成果について、途中で投げ出さない、何が起きても最終的に自分たちが責任を持ってトラブル対応するなどの“覚悟”を持つことも必要です。その“覚悟”を決める判断基準の1つは、成果についてソースコードレベルで裏側まで理解していることです。システム（ソフトウェア）にブラックボックスの部分があると、トラブル発生時にその部分について責任を持った対応ができないことがあります。もちろん、どの研究開発も裏の裏まで熟知する必要はありませんし、ブラックボックスを組み合わせて新しいものをつくり出すこともあると思います。ただ、データベースのような基盤レイヤにおいては裏の裏まで熟知していることが重要なポイントで、データベースの研究開発者としてはこの責任感は持っていたいと思います。
私たちはデータベースでトラブル発生時の最後の番人的な立場ともいえます。番人の姿勢については同僚とも話していますし、新人や若手にも番人として「中身まで分かる人」になってほしいと伝えています。また、若手にはPostgreSQLのパッチやプログラムを書いてコミュニティに投稿してもらっています。このタスクを続けていくと自動的に中身を知ることになりますから、彼らの「中身まで分かる」番人としての実力も養われていると思います。

PostgreSQLの性能向上・機能改善については、実際にPostgreSQLを使ってくださっているお客さまやプロジェクトからニーズをしっかりと伺うことを大切にしています。ただ、お話を伺うだけではなかなか見つけられない課題があるので、私は実際に技術支援等で現場に入り、当事者として課題やニーズを確認し、新しいテーマも見つけられたらいいという心構えで活動しています。
現在は、技術支援の割合が少し減ってしまいましたが、少し前まではおおむね3分の1から半分程度の時間は現場に赴いて技術支援をしながら、残りの時間を使って研究開発をしていました。現場で課題を見つけては研究開発でそれを解決し、その解決した成果を現場へフィードバックし、さらに技術支援先からフィードバックをいただいて研究開発につなげるという、とても良いループができました。
また、現場に赴くとキャッチできる情報量が違います。思いもしなかった使われ方をしていることもあれば、技術者目線で当たり前の動作も、実際にお使いになっているお客さまの運用方法の観点からみると理解できないこともあり、お客さまの本当の「お困りごと」が具体的に分かることがあります。現場では異なる観点でさまざまなフィードバックをいただけますから現場に赴くことは大切です。ただ、私1人でできることには限界がありますから、メンバや部下に現場へ入ってもらいニーズを吸い上げています。それでも人手が足りていませんから、サイクルを回せる人材を増やしていきたいと思います。

入社18年目を迎えて、すでに古株という感覚があります。そんな私が若いころと比較して、お客さまが求めていることをより広い視野でとらえられるようになった、お客さまの立場で技術を眺めることができるようになった、そして引き出しが増えたことを通して、自らの成長を実感しています。
また、自信を持てるようになった大きなターニングポイントはPostgreSQLの本体の中に、データベースの更新内容を複製する、レプリケーションという機能を入れたことでした。当時、レプリケーション機能はPostgreSQLにはありませんでしたが、コミュニティに働きかけて入れることができました。PostgreSQL本体に機能を取り込めるように、プログラムを一からつくっては捨てることを2年ほど繰り返して、やっとの思いで入れることができました。そして、全世界の人に使っていただき、さまざま人から感謝されるまでに至りました。コミュニティでは技術的な正しさがすべてであり、それにより物事が進んでいくからこそ、基準も明瞭で議論にも納得感があるため、この過程を通して、技術者として成長できたと思います。途中で、紆余曲折があっても技術的な正しさはいつでもモノサシなので、この点において海外の技術者からも、さまざまな視点に気付かせてもらえ、どんな議論も納得できることが多く、自らの糧となりました。
これらの経験を通して、私はつくっているものに対する美学やこだわりを持つことが大切だと思っています。美学やこだわりによって成果が変わることもあり、深いレベルで能力を発揮することにつながると思って臨んでいます。私の一番の美学・こだわりはロジック・コードのシンプルさです。他の研究開発者がつくったコードもしっかりと読んで、トラブルの可能性を予見してプログラミング・コーディングをします。複雑すぎて自分しか知らないようなコードでは、サポートできる技術者が自分だけといった状況になってしまい、逆にお客さまに迷惑をかけることになりますから、多くの技術者がサポートできるようにするという意味でもシンプルさは大切です。

オープンソースのコミュニティや社外のミートアップ等、さまざまな場へ積極的に出て行って、成果へのフィードバックをもらうと良いです。さまざまなバックグラウンドの技術者やユーザから意見をいただくことで見識が広がります。今の若い研究開発者の皆さんの中には、すでにコミュニティでの開発や社外での講演に臨んでいる方もいて、また海外技術者との英語でのやり取りも臆していない様子が見受けられ、すごいなと感心しています。
どうしても外に出て行く最初の一歩が踏み出せない人は、思い切って一度やってみましょう。実はそこまで気を張ることでもなかったと分かるものです。最初の一歩はそのことに慣れている経験者と一緒に踏み出すことをお勧めします。もし、PostgreSQLであれば、私に直接聞いていただいてもかまいません。実際にTwitterで「改造したいけれどどうしたらいいか」等と直接連絡をいただくこともありますから、皆さんも遠慮せずに連絡してください。
研究開発者には新しい技術やトレンドに対するアンテナの高さは大切です。私が入社した当時と比較して、研究開発のスピードはどんどん速くなっています。最先端の技術を追って、そこに対して自分なりの付加価値を付けることで、さらなる新しい最新技術として成果を出すことができます。そして何よりも、研究開発において一番大切なのは「面白い」ことです。PostgreSQLのコミュニティでは50歳代後半の技術者がいらっしゃるのですが、その方はトップの開発者で、技術力の高さは世界的にも知られています。かつて日本では技術者の定年は35歳だといわれていた時期もありましたが、そんな世界はもう終わりました。永遠に技術者としてコードを書いて仕事をできるのが今の時代ですから、私もその中心に身を置いていきたいと思います。