オブジェクト指向のはなしとGREE Tech Conferenceのおしらせ
fujimotoみなさまこんにちは、グリー株式会社でCTOをやっておりますふじもと (@masaki_fujimoto) と申します。
今回は1週間後に控えたGREE Tech Conference 2022の宣伝も兼ねて、1年ぶりくらいにソフトウェアについてつらつらと書いてみます。というか、なにはなくとも10/25 (tue)、来週開催のGREE Tech Conference 2022にぜひぜひご参加ください。ひさびさにオフラインでも開催しますので！
あとついでに、1年くらい前からデジタル庁というところのCTOも兼ねさせていただいてまして、なんかやっぱりあれこれ質問いただくことも多いので、そのあたりどうよ、みたいなところもついでに少しだけ触れてみたいと思います (なんかGREE Engineers' Blog、というところで書くにはちょっとコンテキスト違うかなとも思うのであくまでおまけ、ってことで...)。
ぼくにとってオブジェクト指向とはなんだったのか
遡ること25-30年、BASICから始まりC言語や、たまにアセンブラでつらつらと、なんとかかんとかコードを書いていたぼくにとって「オブジェクト指向」はきらきらと眩しいもので、なんとしても習得したいものだなぁと必死にその概念やプラクティスを学ぶべく、あの手この手の本を読み漁ったりしたのでした、Turbo C++さん大変おせわになりました。しかしそれにしてもMFCは難しかった...というか今振り返っても結局あれはちゃんと理解できないまま、というか使いこなせないまま時が過ぎていった気がしますが、まぁ結局多分なんとかなってしまったのでMFCはぼくに「とりあえず分からないまま進んでもなんとかなることがある」という良いのか悪いのかわからないことを教えてくれた事例でした。
しょうもない思い出はさておき、オブジェクト指向といえば絶対出てきてぼくらも100万回くらい聞いている継承、カプセル化、多態性、そしてメッセージパッシングなどの概念とその実装によって、無駄のない、柔軟で堅牢なコードが書けるのだと信じてぼくは多くのコードを書いてきたのでした。正確に言えば、それらの概念を導入する「だけ」でソースコードはそれっぽくなり、結果良いソフトウェアができると思い込んでいたのでした。実際、継承と多態性によってある箇所についてはエレガントにコードが書けてるなー、という気持ちになって悦に入ったり、とても複雑な処理をシンプルなインターフェースで提供して、おぉカプセル化、とか思ったり、メッセージングによる連携に連携を重ねて疎結合だえらい、みたいな気持ちになっていたわけです (きっと思い当たる節があるかたはそれなりにいるんじゃないかと勝手に期待してます)。
しかしそれは結果として、継承に継承を重ねたことによる複雑な依存関係や、カプセル化はされているかもしれないが状態が複雑すぎて「だったらこっちからデータ渡させろよ」というクラスライブラリやらを量産することにつながり、「あれなんかおかしいぞ？」と思いつつ、こういうもんだよね、などと思って突き進んでいたりしたわけです、恥の多い歴史です、本当に申し訳ない。
念の為補足しておくと、オブジェクト指向云々以前にソフトウェアの品質を保つために守るべき、考えるべき要素は多くあり (たとえば凝集度とかね)、そういった大事な要素を忘れてオブジェクト指向だー、ということだけに捉われていた自分が問題なのであって、今にしてみてもオブジェクト指向そのものが良くないということではない、という点については言及しておきたいと思います。そもそもオブジェクト指向がオブジェクト指向たるべき本来の概念は、そのさまざまな解釈と実装により、やはりそこには多かれ少なかれズレが生じてくるのは避けられないことでもある、ということだとも思います。
そして、なんかそんな感じの懸念を抱えていたのはどうやらぼくだけではなかったようで、いやオブジェクト指向は人類には早すぎたのでは？という潮流が徐々に出てきたように感じています。有名なエントリだと2014年の
とかでしょうか、当時このエントリを読んで、まぁなんかわかるなー、でもどうしたもんかなー、などと思ったのをなんとなく覚えています。そして時は経ちこちらは去年のエントリで
というような話になるに至って、思えばこの10-15年くらいでゆっくりとひとは、上のエントリの言葉を借りれば、宣言的プログラミングの方向へ移行していったのだなぁ、としみじみする次第です。個人的にも、ブラウザアプリケーションとかで、もうなんかクラスにmutableなメンバ変数とかあるとなんかちょっとどきどきしちゃうようになってしまい、人の感情とはかくも身勝手なものなのだなぁ、などと思う次第です、散々そんなコードを書いてきたくせに…。
そして、純粋関数型言語に全てが向かうかどうかは別として、どの言語で記述する場合でも可能な限り宣言的に記述する、状態を持たない、冪等性を担保する、テストを書きやすくする、みたいなことに対する意識が高まり続けている昨今です (とりあえずぼくは)。
DDDとClean Architecture
宣言的なのはいいけど、全体の設計みたいなところはどうすんの？オブジェクト指向のいいところは、現実をオブジェクトとしてモデリングすることで云々、みたいなところも大きくあるよね？みたいな話も当然あるわけでして、それに対して鉄板で出てくる話がドメインモデルの話とClean Architectureの話かなーと思っています。正直のこのあたりは個人的にもまだ完全に理解したとも言えないレベルなので、あれこれ試行錯誤しながら、というところですが、なんか少しずつ大人になって、昔読んで「なんかもっと別な表現ないのか」と思っていた「ドメインの蒸留 (Distillation)」という意味が少しずつわかってきたかなぁ、という昨今です。DDDの本にも「蒸留して宣言的スタイルにする」って書いてありますしね。
てな形で整理されたドメインとその宣言的な実装で、ユースケースを記述していくとまぁこういう感じになるよね、っていう1つのプラクティスがClean Architectureかな、と思いつつ、なんか今日も社内でIoCに関してあれやこれや話がされていたり、細かいところでは多く議論がありはしますが、こうしたスタイルでコードを書いていく上ではやっぱり自然な選択肢ではあるなーと思うわけです。が、これについてはもうしばらくすると違うアプローチが出てきてもおかしくはない気はします。なんかもうこれはただの主観であり直観でしかないですが、Clean Architectureもまだ十分に成熟しているっていうところには辿り着いてない気がするのですよね (でも全然わからん)。
ので、ちょっともやもやしながらあーでもないこーでもないとか思っているのですが、まだ答えがありません。なんかこの辺読んどけよ、とかありましたらぜひ教えていただけるとうれしいです。
こっからどうなっていきそう？
未来のことはわからないのですが、個人的にはそれでもやっぱりオブジェクト指向の概念は、それはそれで忘れてはならないものだなぁとアラン・ケイさんに想いを馳せながら思っているところです。という以前に、多くの言語では、引き続きオブジェクトの概念はその根幹を成していたりしますし、ソフトウェアの振る舞いを考えるとき、特に抽象化をしていくときにオブジェクトという言葉は、やはり当たり前のように自分の中にあったりするので、きっと10年後くらいにはもう一段成熟した潮流が生まれているのではないかなーと勝手に思っています。
とはいえ目下のところで大事になってきそうなのはプログラミングパラダイムというよりも、エッジでの処理が徐々に(良いユーザ体験を提供する上で)重要になってきてますし、その実装のハードルが下がり続けていく一方で、それは計算機としての処理が、クライアントでもエッジでもサーバでも行われる、行われ得る、という複雑さと紙一重な気もするので、そのあたりを前提としたプログラミングモデルがどういう形になっていくかなーというのを個人的には注目してみています。
とりあえずプログラミングは楽しいけど難しいです。
国家公務員どう？
そしていきなり話は全然かわりますが、ついでに、といってはなんですが国家公務員どうよ？と最近個人的に割とよくいただくご質問にちょっとだけふれてみたいと思います。とはいえ、そんなあれこれ書くのも違うし、publicに書ける無難なことしか書きませんし書けませんけど (これは内容が無難、というよりも、公知の情報についてしか触れられません、って意味です、ので、まぁそりゃそうだよね、って話しかないです)。
で、行政府においてソフトウェアに関わるっていうことが、1企業においてのそれと何が違うかについて、しみじみと感じたことをいくつか書いてみたいと思います。
ユーザのありかた
一般に企業が提供するサービスであれば、ユーザはそれを利用しない、あるいは別のサービスを利用するという選択肢を採りやすいですが (もちろん会社で「これを使うこと」などなど制約があることも多いですがそれはそれとして)、行政のサービスは好むと好まざるとそれを使わざるをえないことがほとんどで、違うサービスが良ければ異なる自治体あるいは異なる国に行くしかありません。ということで、ユーザとしてサービスを選択するハードルが極めて高くなります。
そして同時に、行政としても「ユーザを選ぶ」という行為を行うことはできないしするべきでもないので、その前提でサービスを設計、実装していく必要があります。典型的にはアクセシビリティのところで、正直自分としてもまだまだなのですが、サービスを提供するユーザ層がとてもとても幅広い、ということを忘れずにいる必要があるなー、と自戒する昨今です。そしてその前提でサービス、システムを設計することは結構難しいです。
いずれにせよ、少なくとも相対的に「この国ソフトウェアは悪くない」と思っていただけるようにしていかないとなーと足掻く日々です、まだまだ全然これからですが。じゃないとただでさえ人口減ってるのに生産性上がらないし、違う国に行こう、ってなっちゃうのはやっぱり悲しいなー、と思いますので。
お金のありかた
これも当然なのですが、行政で使うお金は隅から隅まで税金によってまかなわれるものです、ので、その使い方には多くの制約が課せられます。もちろん企業というか株式会社においても投資が適切なものかどうか、という点については常に株主への説明を考えるわけですが、必然行政においてはそのハードルはかなり高いものになります。大事な税金なのでもちろん必要なのですが、その分機動的に動くことは難しくはなる、というのは正直あります。
典型的には、その費用の使途、価格は妥当かどうかについて常に説明可能であることを常に考え続ける、のと、(少なくとも一定額以上の費用については) 厳密なプロセスに従うことが課せられます。ので、「予算があるからあのひとに承認とってあの会社に発注しようー」ということは出来ないのが、難しさでもあり、でも大事なことでもあります。
実はこのあたりは普通に公開資料に記載されていて、まぁとてもとても長いのですが興味のあるかたは暇つぶしか、眠れない夜にでもご覧いただければと思います、きっとすぐ眠りにつくことができます。
このあたりの仕組みは、さまざまな歴史に基づいて成り立っているので、必要とはいえ悩ましいポイントもあったりするので (例えば一定額以上の調達になると、20日の意見招請、50日の公告期間が必要なのでなにをどんなにがんばっても3ヶ月弱のリードタイムが必要、とかとか)、より良い仕組みを考えていきたいものだなぁと思う次第です。
CTOできてる？
...ということで、とりあえず2つほど大きく違う点を挙げてみましたが、それはそれとしてCTOってどうなん？という点についても少しだけ。これはとても難しいところですが、正直に言えば「まだまだこれから」です。CTO、というからには本来は経営、国家で言えば政策意思決定とかにもうちょっとちゃんと関わらなければいけないし、そのレイヤにソフトウェア、技術的な要素をちゃんと反映させていくのが多分本来のお仕事であるべきかな、と思うのですが、ぼくの未熟さもあってまだまだこれから、というところです。
とはいえ、なにはなくとも行政府にCTO、というタイトルで職ができたのは多分良いことだなと個人的には思っていますし、まだまだ時間はかかりますが少しずつ信頼と実績を積み重ねて、このポジションが国家にとってプラスである、必要なものである、と認識される、ようにしていくのが今は重要かなと思っています。これは別にぼくがやる必要は当然なくって、次のCTO、またその次のCTO、と積み上げていければいいなと思いますし、きちんとバトンを渡せるようにまずはその道筋をつくるべく努力しているところ、です、たぶん。
改めてGREE Tech Conference 2022
ということで最後になりましたが改めまして、10/25 (tue) 開催のGREE Tech Conference 2022へのご参加お待ちしております。ぼくはたぶん最初のセッションで、このエントリとはまた全然関係のない、チームのサステナビリティについて少しだけお話しさせていただく予定です。昨今特に、先行き、未来が不透明な状況において、ぼくらはどんなことを考えていけばよいか、とかについてなんらかみなさまが考えを進めるきっかけになれるようにお話しができるように努力します...!
ではでは、来週会場かオンラインでお会いできるのを楽しみにしております。
Happy Hacking!