この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の1日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。この記事はプログラミングをするパンダが全て執筆しています。

私をシニアエンジニアにしてくれたアジャイル開発を振り返る

本アドベントカレンダーの内容は、今から2年前の2022年には書き上がっていました。熱心に下書きを執筆したところまでは良かったものの、推敲と掲載の労力を考えるとどうにも腰が重くなりどこにも発表していませんでした。当時のマネージャーに見せたところ「もはや論文ですね」と言われるほど量が膨大だったのです。

まとめる気力を起こそうとカンファレンスのプロポーザルとして提出したことがあります。2度プロポーザルを書き、2度とも落ちました。「スクラム, XP,DevOpsを一気に全部やったら真のアジャイルチームになれた」というような内容だったのですが、運営の方は発表内容がぼやけると考えたのでしょう。実際、60分のトークであっても語り尽くせないほどの内容です。

それでもアドベントカレンダーという形式を借りて発表しようと思ったのには理由があります。2022年の「真に顧客志向に、真にアジャイルになれた開発体験」が現在の自分のキャリアやチームに対する向き合い方のターニングポイントになったことをひしひしと感じるからです。

スクラム,XP,DevOpsをチームで一度に実践するという取り組みとプロジェクトの成功をマネージャーから評価された結果、自分はシニアエンジニアという役職を貰いました。また、当時のプロダクトオーナーも今ではPdMのマネージャーに昇進しています。他にも当時のPJメンバーは現在も社内で人並みならぬ活躍をしていることからも、このチームでみんなが得た経験の大きさを感じています。

今でも私自身はどんなチームであれ、あの時チームに存在した好循環を産むことを目標にチーム作りをしています。その結果、当時とは異なるマネージャーと働いている今も「あなたに任せると安心感がある」と言ってもらえるチーム運営が出来ています。このため良いチーム作りは誰でも再現することは可能です。

個人的に何より嬉しいことはLeanとDevOpsの科学を読んでから、チームメンバーの誰も絶対にバーンアウト（燃え尽き）させたくないと強く思い続けています。実際、シニアエンジニアになってから自分と同じチームだった人で退職した人はいないというのはとても幸運なことです（業務委託の方は除く）。これが何より燃え尽きていない証拠だと言えるでしょう。

プロジェクト自体は3ヶ月という短い間でした。しかし、アジャイル開発の大切なエッセンスが詰まった実りの多い3ヶ月間でした。

このアドベントカレンダーを読み終えた頃には、あなたも真のアジャイルとは何か心で理解して貰えるでしょう。それでは少し長いですが、お付き合いください。プログラミングをするパンダによる「私をシニアエンジニアにしてくれた『真のアジャイル開発』体験記」です。

エリートチームを目指して

スクラムとXPとDevOpsを同時に実践したといえども全てが同列に置かれるわけではありません。「LeanとDevOpsの科学」を読んでFour Keysのエリートを目指すためには24のケイパビリティを発揮する必要があると学びました。

24のケイパビリティではリーダーシップやリーンな製品開発とマネジメント、技術への向き合い方が説かれています。全く新しい発見があるというよりは、良い会社の良いチームならできていることが書かれています。

私はこの本からムーンショットを打てというのではなく「基本を徹底するだけで他者と差別化できる」というメッセージを読み取りました。DevOpsといえば現代では知ってる人は多いものの、これらのケイパビリティを高いレベルで実践できてるチームは多くないのではないでしょうか。基本を徹底することでパフォーマンスは大幅に向上する。この本はそれらの基本を科学的な分析により導き出したのです。

DevOpsのFour Keys: 高パフォーマンスを目指して

Four Keysとは、デプロイ頻度、リードタイム、変更失敗率、復旧時間で構成される指標です。自分たちが担当するプロジェクトは新規の機能開発なので運用より開発が中心であるため、特にデプロイ頻度とリードタイムを向上させることにしました。

なぜデプロイ頻度が高いとハイパフォーマーと言えるのか、その理由は最初わかりませんでした。しかし、まずは「品質を高く保ちつつ高頻度でデプロイする」ことを目的にしました。その結果、デプロイ頻度が重要な理由が明らかになりました。

その効果を一つを紹介しましょう。デプロイ頻度を上げると、仕掛かり中の作業と完成した作業がはっきり分かれます。TODO, 仕掛かり中、完了した作業をチームにわかりやすく共有するためにスクラムのスプリントバックログをカンバン形式で作りたくなります。

カンバンを作るにあたり、チームは自分たちが一番効率的に使えるツールを自由に選定をします。このチームでは最初Miroを使っていましたが、後にFigJamとAsanaに、最後はFigJamのみを使うようになりました。スプリントバックログはスクラムイベントであるデイリースクラムやスプリントプランニングやバックログアイテムのリファインメント、レトロスペクティブなどでチーム全員が触れることになります。

カンバンはXPの言う「情報満載のワークスペース」になったためチーム間のコミュニケーション漏れがなくなりました。コミュニケーションはXPが示す価値の一つでもあります。リモートワーク全盛期の時代でもスムーズな開発に十分適応できました。デプロイ頻度を上げるとチーム内のコミュニケーションが盛んになったのです。

DevOpsのケイパビリティを発揮するためにスクラムとXPを実践する

他にも「LeanとDevOpsの科学」で書かれているプラクティスを実現するためにスクラムとXPを組み合わせた例を簡単に紹介します。

1.毎日デプロイすることを目指した結果、ベロシティが安定した

毎日デプロイを目指すにあたって、トランクベース開発を取り入れました。その結果、小さいPRでも良いからどんどんマージしていこうという雰囲気がチームで醸成され、プルリクエスト1つ当たりの変更行数が少なくなりました。すると、大きいタスクを次のスプリントに持ち越すということが大幅に減り、スプリントのベロシティが安定しました。

2.バッチ単位の作業を心がけた結果、情報の透明性が高くなった

毎日デプロイを目指してから、プルリクエストの変更行数を減らすためにタスクを小さく細分化することがチーム内で当たり前になりました。タスクの見積もりをするときに「5ポイントでも大きすぎるのでは？」という感覚をチームメンバー全員が持ち始め、リファインメントでは出来るだけ1,2,3ポイントになるまでタスクを分解することを心がけていました。

すると、プランニング時にみんなが想定していなかった新しい作業が出てきたらデイリースクラムできちんと共有する動きが生まれました。もしあるタスクに大きい5ポイントを当てていたら「少し作業が増えてもポイントの範囲内だ」としてあえてチームに共有されなかったかもしれません。結果的にチーム内の情報の透明性が上がりました。

3.情報セキュリティのシフトレフトにトライしたら、インシデントの予行演習を実施できた

情報セキュリティのシフトレフトは自分たちのチームにとって重要な要素でした。なぜなら、自分たちが開発するのは個人情報を扱う機能だったからです。法務とセキュリティチームに会議で開発する機能の懸念点について、プロダクトオーナーを中心に質問して守りを固めました。

のみならず、スプリントレビューに加わって貰うことで会議ではわからなかった考慮漏れに事前に気づけて対策を打てました。機能のリリース前には、個人情報に関するセキュリティインシデントが万が一発生した場合の予行演習を社内の各チームと一体になって行えたました。このことは今でも情報セキュリティのシフトレフトの極地だったと誇りに思います。

4.変更を小さくした結果、受け入れテストのスプレッドシート管理が廃止された

開発初期の1ヶ月間はプロダクトオーナーが各タスクの受け入れテストの項目をスプレッドシートで作成・管理していました。しかし、タスクが完了したらプロダクトオーナーにチェックしてもらっていたこと、また変更内容が小さいため差分がわかりやすかったことからスプレッドシートでの管理はなくなりました。デグレのチェックはスプリントレビューの前日に特に入念にやっていました。しかし、ほぼ毎日触ってるので何かおかしいことがあれば誰かが気づく体制になっていました。

アジャイルであり続けるために

ここまで良いことばかりを書いてきました。しかし、重要なのはDo Agile（Agileをする）ではなくBe Agile（Agileになる）です。一度ゴールに到達したとしても、その後もBe Agileであり続けることは難しいです。気を抜くとすぐに元に戻るからです。

例えばチームは成功体験を積んだ後も以下のようなことを経験しています。

• プルリクエストが肥大化してデプロイ頻度下がってしまうこと
• 燃え尽きないようにコンスタントに仕事をする方法を採用しているのに「見積もりが増えても私がなんとかハードワークをして解消します」という宣言をしてしまうこと（タスクはチームで分担しましょう）
• プロダクトバックログではタスクの着手順を決めているのに、その人の興味関心から優先順位が下の技術調査を進めること
• デイリースクラムで決めるべき事項が決められないまま、あわや「今日のデイリーは終わりですね」と解散しそうになること
• リファクタリングを継続しなくなる etc.

このような異変に気づいて「ちょっと待ってください」と軌道修正する人はチームに必要です。「真のアジャイルチームであり続ける」ことは一筋縄ではいかないのです。

DevOps、スクラム、XP - 基本の徹底がもたらす変化

DevOpsやXP、スクラムは表面的な取り組みだけでは効果が出ません。良いチームを作り上げ、チームをアジャイルにし続けるためには基本を徹底することが必要なのです。このアドベントカレンダーでは、真のアジャイルチームの一つのあり方を微に入り細を穿つような書き方で紹介していきます。読者の方が所属しているチームでも必ず真のアジャイルチームになる方法を再現できると信じているからです。

XP本に「夜遅くまで働いて疲弊しているチームよりも、うまくいっているチームが解雇される」と書かれています。うまくいくチームはトラブルが少ない上に仕事を早く終えているため、周りから楽をしているように思われるからです。自分たちのチームはプロジェクトが終わると解散させられるどころか、別のチームが合流してきてより大きな機能を作ることになりました。が、それはまたどこかで語るような別の話です。

次回は「私たちのアジャイル開発が始まる：プロジェクトとチームの紹介」です。

現実、ソフトウェア、モデリングの関係

この記事は、現実とソフトウェアとモデリングの関係を哲学の観点から整理する試論です。この記事を通して、読者の方のモデリングという行為に対する理解が深まれば幸いです。

なお、哲学といっても特定の哲学者の思想には触れないので前提知識は不要なので気楽に読み進めてください。

ソフトウェアが絶えざる変更に晒されるのは、現実と乖離するためである

ソフトウェアがいつも変更に晒されているということはソフトウェア開発者にとって常識です。では、なぜソフトウェアは変更に晒されているのでしょうか。立ち止まって考えてみましょう。

ソフトウェアが対象にしている現実が絶えず変化しているため、対象の変化に応じてソフトウェアも変化する必要があると言えるでしょう。これを仮の結論とします。

しかし、ソフトウェアは本当にそのもの現実を対象としているのでしょうか。そうではないように思えます。

例えば、配送管理システムを考えてみましょう。あなたは荷物を会社宛に配送し、2日後に担当者から荷物を受け取った旨の連絡が来ました。しかし、ネットで確認できる追跡情報上では何らかの手違いで荷物がまだ会社には未着だと表示されています。担当者のところに荷物が届いたことは現実であるのに、ソフトウェア上では荷物が届かないままです。

つまり、ソフトウェアはこの荷物の現在地そのものと連動しているわけではないのです。ここに現実とソフトウェアの管理するデータのズレがあります。

ソフトウェアは計算機上で動くデータ加工のロジック群である

ではソフトウェアの対象とは実際のところ何でしょうか。

そもそもソフトウェアとは、データを受け付け（入力）、データを加工し、加工したデータを出力するロジックであり、このロジックはコンピュータ上で動作するという特徴を備えています。

計算ロジックは現実そのものではありません。ソフトウェアは「配送先に届ける荷物のバーコードを配達員が読み取ったら、荷物の配送ステータスを『届け済み』にする」というロジックを実行しているだけです。

荷物を受け取ったタイミングで配達員が間違ってこの操作をしたら、荷物は即座に届け済みになってしまいます。これも現実に反します。このため、ソフトウェアの対象は現実そのものではないということができます。

ソフトウェアの対象は計算可能なもの、つまりデータです。そして、ソフトウェアを構成するものは計算ロジックです。何らかのデータがハードウェアを通してソフトウェアという計算ロジックに送られた結果、ソフトウェアはデータを計算（加工）してハードウェアに出力します。

つまり、ソフトウェアを単なる関数とみなすとf(input) = outputと書けます。

ソフトウェアエンジニアは、このソフトウェアという巨大な関数f(x)を構築し、書き換え続けています。ソフトウェアの計算ロジックをコンピュータ上で実行するためにソフトウェアエンジニアはプログラムを書いているのです。

改めて、ソフトウェアが対象しているものは何か

さて、ここからが本題です。先ほどソフトウェアは現実そのものを扱うわけではないと書きました。次にソフトウェアの役割を大きな視点から捉えました。すると次のことが自然と導かれます。

それは、ソフトウェアの対象とは現実の中の計算可能な側面であるということです。現実を計算可能なものとするためにはデータ化が必要です。

例えば、宅配便の荷物であればダンボールで包んで送るでしょう。ダンボールの大きさに焦点を当てると、立方体の縦横高さの数値が重要になります。極端に書くと縦横高さの3つの数値こそが荷物を表現しているのです。

ここでは、ダンボールの色や角がへこんでいることやガムテープがなぜか側面に貼られていることなどの現実は関心外でデータ化されません。このように不要な部分を扱わないことを捨象といいます。

ソフトウェアにおけるモデリングとは何か

現実から何らかの要素を抽出してソフトウェア上で計算可能なデータとして扱うこの行為こそが、ソフトウェア文脈におけるモデリングというものです。モデリングのプロセスとは、現実の物事を数値化（デジタル化）してデータを抽出するという現実の抽象化と呼ぶことができます。

例えば、人間というものを考えてみましょう。実のところ人間一般というものをソフトウェアで扱うことはありません。ソフトウェアには目的があるためです。そこで人間というものを特定のソフトウェアのためにモデリングすると一人の人間は「飛行機の搭乗者」「患者」「ライター」「家族の一員」などとされるわけです。

これらは全て私という一人の人間でもあります。飛行機で東京から北海道に行ったり、風邪を引いて病院で受診したり、今このように記事を書いていたり、家ではそれに当たるというようなある側面を切り取ったものです。

飛行機のチケット予約サービスであれば出発時刻や目的地、飛行機の便や座席の位置をデータ化します。電子カルテであれば受診歴や病歴、このサイトのブログシステムなら書いた文章や公開した時間、戸籍管理システムなら本籍地や家族関係をデータとして扱います。

深く多様な現実の中から、ある事物のある側面を抽出するのがモデリングという行為です。モデリングはまた、現実に存在する物事の豊穣なディテールを余分なものとして切り落とし（捨象）、本質というコアを探し出すためにある特定の視点から役に立つデータを画一的に抜き出すこと（抽象）でもあります。

端的に書くと、ソフトウェア文脈のモデリングとは、現実の物事をソフトウェアが計算できるように、ソフトウェアの目的に関する要素だけデータの塊として抽出することと言えるでしょう。

現実の物事をデータ化するだけでは何のことかわかりません。100, 70, 40というデータだけがあっても何を指しているかわかりません。これをそれぞれ縦横高さと名付けることで荷物として送るダンボールのサイズだとわかるのです。ただのデータを集めて、人間が意味ある情報として扱えるようにすることもまたモデリングの役割です。

ソフトウェアは計算ロジックの集まりであるが、なぜ現実とは連動しないのか

ソフトウェアは計算ロジックの集まりだと書きました。計算ロジックで大事なことは何でしょうか。それは、間違ったロジックを差し込まないことです。ソフトウェアのバグとはプログラマが間違ったロジックを仕込むことなのです。

ソフトウェアのバグとはレトリックであり、ソフトウェアは与えられた式通りに計算しているのですからソフトウェアにはバグはありません。プログラマが間違った計算ロジックを差し込むだけなのです。

では、そもそも計算ロジックにおける間違いとは何でしょうか。計算ロジックに間違いがなければ、ソフトウェアの計算結果は常に現実と一致するのでしょうか。

ここで哲学議論の考え方を借りてみましょう。以下は、How to Argue - Philosophical Reasoning: Crash Course Philosophy #2 というYouTubeの動画を参考にしています。

論理的に正しいことと現実的に正しいことを区別する

ここでは演繹的推論（deductive reasoning。または演繹的な論証 deductive argument）を取り上げます。演繹的推論とは、ある前提を元に論理的に結論を導き出す方法です。全ての前提が正しければ結論も正しいと考えます。有名なのはアリストテレスが定式化した三段論法です。

前提1: すべての人は死ぬ（大前提）
前提2: ソクラテスは人である（小前提）
結論 : よって、ソクラテスは死ぬ

これは valid（有効な、妥当な）な議論です。人は死ぬという誰にでも起きる普遍的な事象をソクラテスという個人に当てはめることで、ソクラテスという人間が将来死んでしまうことを推測し、結論づけています。

次にこの議論はどうでしょうか。

前提1: すべての人は死ぬ
前提2: ソクラテスは人である
結論 : よって、ソクラテスはプラトンの師匠である

これは前提は正しいものの結論が間違っています。これは invalid （有効ではない、不当な）な議論です。二つの前提だけではこの結論は導き出せないからです。しかし、歴史に照らし合わせると確かにソクラテスはプラトンの師匠ではあります。

さらにもう一つの議論を検討します。

前提1: 全ての人間には尻尾がある
前提2: 私は人間である
結論 : よって、私には尻尾がある

この議論は直感的におかしいと思われるでしょう。ただし、論理の世界に閉じるとこれは valid な議論なのです。ロジックだけを見ると、普遍的な前提と個別の前提を元に正しい結論を導き出しているからです。

一方、現実的にこの議論は間違っています。人間に尻尾はありません。前提1の「全ての人間には尻尾がある」が間違っているのです。つまり、論理的に正しいということと、現実的に正しいということは異なるのです。そこで前者は valid と呼び、後者は true と呼び分けます。

この考え方を使うと、今までの議論の違和感を説明できます。例えば議論2の「よって、ソクラテスはプラトンの師匠である」という結論は、論理的に invalid であるが現実では true です。一方、「よって、私には尻尾がある」は論理的に valid だが、現実的には false でありそんな事実は現実にありません。

総合すると、健全な演繹的推論は「論理的に間違っていないこと（validity）と全ての前提が現実的に正しいこと（all true premises）」が必要なのです。

ソフトウェアは論理の計算式である

ソフトウェアの議論に戻りましょう。ソフトウェアは計算ロジックの集まりだと書きました。ここまでの議論を踏まえると、ソフトウェアは validity の化身と呼べます。計算自体は計算式に沿って順番に間違いなく（= valid に）処理されるからです。

「ソフトウェアは書いた通りに動くのだから、バグが出たらソフトウェアの不具合ではなく自分の書いたコードをまずは疑え」というデバッグにおける有名な格言もこのことを暗に示しています。ソフトウェアは書いた通りにしか動かず、「今日はハロウィンだからお菓子をくれないと計算結果にイタズラしちゃうぞ」などとは考えないわけです。

ただし、ソフトウェアは常に valid だといえども常に現実のモデルと一致しているわけではありません。ソフトウェアが true を保証することはないのです。

まさにこれが冒頭の荷物の配達の例です。荷物は会社に届いているのにバーコードが読み取られずシステム上は未配達であるケースです。このとき荷物は届いているか改めて確認してみましょう。荷物は担当者の手元にあるのでこの回答は true であり、かつバーコードが読み取られていないのでソフトウェア上では未配達であるということもまた valid なのです。

現実は様々な要因によって変わります。現実が変わるとソフトウェアで扱うモデルも変わります。荷物の配送にドローンという選択肢が加わることを想像してみてください。今までの荷物の配達経路の計算ロジックはドローン配送には適用できません。

現実が変わり、モデリングが変わればソフトウェアという計算ロジックも変わります。この true と valid のズレを揃えていくこと、変わりゆく現実に対してソフトウェアを追従させ続ける力学こそ、ソフトウェアが絶えざる変更に晒される理由なのです。

クラスとオブジェクトはプラトンのイデア論に似ている？

この記事の内容は何らかの結論に至るものではない。この問題について思考しきれておらず、結論めいたものすらない。こうかも知れないという洞察は得たものの、まだ資料による裏付けがない。つまり、アイデアは降ってきたが検討・検証しきれてない状態だ。それでもこれを書き留めておくことには意義があると思い、秋を感じさせる涼しく心地良い風が吹く夜の酔いに任せて筆を取ったものである。

オブジェクト指向というものを何か哲学的に考えられないものか。この問題意識は自分の中で長らく放置されていた。ソフトウェアエンジニアになってまだ１ヶ月か2ヶ月の頃、自分はまだクラスとオブジェクトの違いも分からなかった。

そんな折、指導係の先輩とランチに出かけた。場所は東日本橋、川沿いの雑居ビルに入っている中華料理屋だった。昼時だというのに客の入りは良くない。二人で窓際の席に座って話すうちに、クラスというのは型みたいなもので、オブジェクトというのはそれを元に作られたものだという説明をしてもらった。

それを聞いた自分は「まるでプラトンのイデア論みたいですね」と言っても先輩はピンときていないようだった。そこで洞窟の比喩を持ち出して説明したものの、やはり納得いっていないご様子。まあ、哲学とプログラミングは全く異なるものかと思い話題を変えることにした。

しかし、ここで話したことは今でも鮮明に覚えている。それは何かもっと抽象的な、根本的な視座から自分たちが生業としているプログラミングというものを捉えたいという気持ちを抱いたからだった。

時は流れて2024年、自分もソフトウェアエンジニアとして経験を積んで5年以上経った。上記のような思索は「どうせ手がかりがない」と諦めていた。しかし、今年に入ってプラトンの著作を何冊か読んだり哲学史の概説本を読んだりするうちに、最近になってまた一つ考えてみるかという気力が湧き起こった。

哲学の視点からオブジェクト指向を捉える

そこでまず先人はいないかと調べてみると、あるWebページに以下のような記述を見つけた。

巷の技術者向け書籍を読んで何か物足りない、薄っぺらな感じがするものが多い。哲学が感じ取れない。（中略）名著には技術以前に哲学があり、思想がある。我々が学びとるのは単に実践的なテクニックのみで良いのだろうか？（略） 工学には科学の裏付けがあり、科学には哲学の裏付けがある。本来そうあるべきであろう。 連載　オブジェクト指向と哲学 第1回

これこそまさに自分がプログラミング（というよりコーディングに矮小化したほうがいいかも知れない）という営みに感じていたことだった。この文章を読んだときは先達に向かって僭越ながら我が意を得たりという心持ちだった。「コードを書いてユーザーに価値を届ける」という言い回しは聞き心地のいい甘言ではある。しかし、目の前で我々が書いているこのコードとは一体何かという問いには答えていないように感じていたのだ。

「オブジェクト指向と哲学」というエッセイをいくつか読むと、プラトンの哲学であるイデア論を引いてオブジェクト指向を説明したり、『プロタゴラス』という徳とは何かについてソクラテスが議論する対話篇で説明される徳についてUMLを用いてモデリングをしたり、アリストテレスの形相（エイドス。form）と質料（ヒュレー。material）を用いてまたオブジェクト指向を説明しようとしている。ただし、その試みが成功しているか否かについては読者の判断に任せるしかない。

なお、一言断っておかなければならないのは、私がここでいうオブジェクト指向というものはアラン・ケイが考えている本来ものではない。メッセージパッシングとは無縁な、クラスとオブジェクト、プロパティとメソッドのような矮小化されたものである。それでも自分はこれについて一通り考えを述べてみたいのだ。

クラスとは何か

そもそもクラスとは何か。プログラミングの概説書ではオブジェクト指向におけるクラスとは、型のようなものだと説明される。クラスをインスタンス化するとオブジェクトが生成される。クラスはオブジェクトの型のようなものなのだと。実際、プログラミング言語はクラスそのものを操作するのではなく、メモリに乗せたオブジェクトを操作している。

ここで一つ疑問が生まれる。クラスとは果たして実体と言えるのか。プログラミングの世界にはEntityという用語があって、これを直訳すると実体という意味である。しかし、クラスという実体はこの世界を見渡してもどこにも存在しない。コードというテキスト上に表現されたものであり、これが何かコンピュータの外の物体や概念を指すことはない。

例えば、Bookクラスがあるとする。書籍にはタイトルがあり、著者がいて、値段がある。

Class Book {
  title: Title
  author: Author
  price: Price

  // …
}

この時、このBookクラスは何を指示しているのだろうか。私は何も指していないと考えている。なぜなら、「書籍にはタイトルがあり、著者がいて、価格が設定されている」などということは一般論でしかないからだ。

タイトルがない書籍もあるだろうし、価格が設定されていない書籍もあるだろう。何を持って書籍とするのか、書籍を書籍たらしめているものは何か。タイトル、著者、価格が設定されていれば書籍と言えるのか。そのような疑問にぶつかる。

デカルトは座学の限界を知り「街という大きな書物を読む」ためにオランダなどの諸国遍歴の旅に出た。比喩表現だと分かった上でだが、この本にはタイトルがあって著者がいて値段がついているだろうか。そんなことはないだろう。

唯名論を手がかりにクラスを考える

この問題を考えるにあたり、何か手掛かりになることはないかと考えてみる。そこで思い出されるのはトマス・アクィナスの唯名論だ。「普遍的なものは名前（名詞）の上にしか存在しない」という有名な考え方である。彼は神学者なのでここでいう普遍（universe）はすなわち神だ。ただ、ここでは神ではなく書籍について考えている。そこでこの思想を援用すると「書籍というものはこの名詞にしかない」と言われれば、なるほどその通りだと思える。

我々は書籍というものを生まれながらの知識として持ってはいない。感覚を通して得た経験から、何かを「書籍である」「書籍ではない」と判断し呼び分けているだけだ。目の前にある個別具体的な書籍をあなたは必ず見たことがあるだろう。何冊も持っていて、書棚を埋め尽くしているかも知れない。お気に入りの一冊もきっとあるはずだ。

しかし、一般的で抽象的な書籍というものはこの世には存在しない。それは概念として人間の頭の中にあるだけだ。この抽象的な書籍を手に取ってみることはできないし、ましてや読むことなんてできない。

プログラミングにおいて、クラスとして表現されるものはただの一般名詞なのである。それゆえに、いいエンジニアはクラスや変数の名前にこだわる。ドメイン駆動開発で「命名は業務で普段使われている言葉を反映すると良い」（ユビキタス言語）と言われているのはこれが理由の一つでもあるだろう（これを推し進めるとウィトゲンシュタインの言語ゲームの視点から考察したほうが説明しやすいのだがここでは触れない）。

クラスを具体的なコンテキストに置いてみる

Bookというクラスはあまりに一般的すぎる。そうではなくて、これを何らかのドメイン、何らかのコンテキストに置くことで見えてくる一側面を取り出す必要がある。

本と一口に言っても「本屋で売られている商品としての本」「夏休みの課題図書」「映画の特典として無料で貰える書籍」「自宅の書斎の本棚に並んでいるもの（蔵書）」「積読本」「すでに読んだ本」と様々である。

例えば商品としての本は以下のようにモデリングできるだろう。

Class SalableBook {
  title: Title
  author: Author
  price: Price
  stock: Quantity
  
  public function isOutOfStock() {
    // …
  }
  // …
}

ここでは、販売されたかどうか、販売可能かどうかということに焦点が当たる。本屋の書籍は商品だからだ。「夏休みの課題図書」は例えば中学生向きか、高校生向きかという区分や、古典か最新の小説かなどというジャンルが重要になるだろう。蔵書などは横幅と高さを設定して本棚の一角に収まるのかや、重量に関心を持って重さで床が抜けないかという点に関心を持つかも知れない。

そしてこれら具体的なコンテキストに置かれたクラスは、明らかにそのシステムやサービスが対象とする現実の書籍という存在を対象としている。より正確には、現実にある複数の書籍の一側面を切り取ったもの（抽象化したもの。特徴を抽出したもの）だ。

複数という要素が重要で、この世に唯一ものもはクラス化しないのではないか。例えば、この記事を読んでいる「あなた」という存在はシステム上クラス化するのは適切ではないだろう。ある会社に勤める「従業員」としてのあなた（Employeeクラス）や、銀行口座を開くときの「顧客」としてのあなた（Customerクラス）であれば、システムはクラス化して管理できるだろう。

従業員という観点からは、あなたの健康状態や年齢、職歴、給与、住所などの一側面にしか興味がなく、銀行の顧客としてのあなたは上記に加えて、資産総額や家族構成に興味を持たれるだろう。このように、クラスというものは現実に存在する物事（対象）の一側面を抽出したものである。この辺りは、DCIアーキテクチャの考え方と一致するのかも知れない（が、それについては自分は詳しくないので何とも言えない）。

このように考えると、カントのカテゴリー論（認識論）もクラスとオブジェクトの考察に使えるような気もするが、今の私には荷が重い。そもそもここで語っているオブジェクト指向ですらクラスの話でしかなく、継承やインターフェース、ポリモーフィズムといった話題にも触れていない。それにどの考え方も聞き齧ったことをもとに書き散らしているだけだ。資料で確認しておらず正確性に欠けるしツッコミどころも少ない。酔いも覚めてきたのでここらで筆を置くこととする。

先月、大学からの友人と軽井沢プリンスホテルスキー場にスノーボードに行った。スノーボードをするのは人生で初めてだった。軽井沢を選んだのは何もハイソな場所がいいというわけではなく、単にスキー場が新幹線の駅から近くてアクセスがとても良かったからだ。

アクセスは便利だったものの、軽井沢のスキー場は子供から大人、日本人から海外の方まで様々な人でごった返していた。ゲレンデの人の多さに圧倒された初心者の自分は、スキルのなさに輪をかけて思うように滑れず、何度も人にぶつかりそうになった。

それでも初めてのスノーボードだったこと、山頂から冠雪した浅間山の雄大な姿がくっきり見えたこと、友人に滑り方を教えてもらって自分なりに滑ることができたので満足だった。

さて、友人とは行き帰りの新幹線でずっと話をしていた。その話題がどんな社会人にも当てはまるなと思ったので、ここに記しておく。

行きの新幹線の中では、近況報告も含めて心赴くままに気がねなく話していた。帰りの電車でも心は晴れやかだったものの、体の疲れのせいか話題は次第に会社の愚痴から仕事の相談に変わっていった。

友人の相談内容は以下のようなものだ。友人はソフトウェアエンジニアをしており、彼のチーム人数は2人。しかも基盤部分を担当しているので、様々なチームから質問や相談が舞い込んでくるそうだ。

同僚の中には仲のいい人もいるし、仕事面で尊敬する人もいることにはいる。しかし、同僚の中にはプライベートの話はせず仕事の話しかしない人がいるとのこと。

しかも仕事はリモートワーク中心である。話すと言ってもリモートワーク中心なのでパソコンの画面越しだ。その人と顔を突き合わせて話すわけではない。

そういった同僚たちのプライベートには興味が持てず、結果的に飲み会で同じ席になったとしても、途中で話題不足になってしまい気まずい思いをしてしまう。これが彼の悩みだった。

もちろん飲み会でも仕事の話はする。しかし、仕事の話はいつもしているので、しばらくすると話題はどうしても尽きてしまう。その後、お互いに話題を探すが見つからない。その沈黙に耐えられないというのだ。

これは自分も経験があるのでよく理解できる悩みだ。相手のことを全く知らないのであれば色々質問をして相手のことを知ろうとするだろう。しかし、相手のプライベートに興味がない、あるいはどこまで踏み込んでいい相手かわからないという場合もあるだろう。

その友人に「人に興味を持て」と言ったとしても、彼にとって何にもならない。自分を変える以上に、人を変えることは難しい。そのような命令は彼にとってアドバイスでも何でもないのである。

そこで、最近哲学という営みを面白がっている自分は、その立場から思いついたアイデアを彼に伝えてみた。これは友人に対するアドバイスであるが、一方で同様の悩みを持つことのある自分に対する助言でもある。

彼に伝えたのは、「答えの出ない問いについて話してみてはどうか」というものだ。例えば、「幸せとは何か」や「この世で一番価値のあることは何だろうか」とか「欲を満たせれば、その欲は消えると思いますか」などだ。

これらは哲学で扱うテーマではあるが、飲み会でも使えるテーマだと思う。誰もが何かしら自分の経験に基づいて話せるからだ。

直接的に問いかけると、相手は身構えてしまう。はっきり言ってこれらはハードな問いだからだ。そこでこれらの問いをシュガーコーティングし、自然な問いかけとしてスッと懐に差し入れるのだ。

幸せとは何か、ということものなら「最近何をやっても面白いとか熱狂するということがないんです。何をやってる時が幸せとか情熱を感じますか？」と変える。

一番価値のあることは何かであれば、「自分は酒とかマンガとか収集が趣味なんですが、もっと価値のあることがある気がするんです。一番大切にしてるものって何ですか？」と具体例を提示してみる。

どれも自己開示から始めるのがコツである。自分が具体例を示すことで、答えの方向性がなんとなく相手に伝わり、相手が答えやすくなるからだ。

ただし、こういった高尚な問いに食いついてくれなさそうな人もいるだろう。そうであるならば、もっと世俗的な質問でも良い。「仕事ができる人ってどんな人だと思いますか」とか「仕事ができるようになるには、どんな習慣を身につければいいのか」といったものだ。

答えが出ないからこそ、誰もが話に参加することができる。しかも、答えがないから、見解の相違や意見の対立はあっても間違いだことはない。その場合、違いは違いとしてあるだけで、論破だなんだと勝ち負けはない。だからこそ気軽に話せるはずだ。

しかも、意外なことに質問者は、相手が答えてくれた内容を鮮明に覚えている。何度か会話をやりとりするうちに、相手の価値観を表す一言がパッと表れる時があるからだ。そのキーワードは自然に覚えられる。

口頭で会話しているのに、まるで相手の言葉を読んでおり、その部分だけ太文字になっているような感覚になるのだ。こういうのを共感覚というらしい。

おそらく、以前の記事で書いたように、自分が読書中に印をつけまくるようになってから、本を読んでいるのに著者と対話する感覚を得た

そして、この「微妙な距離の相手と気まずい沈黙が流れそうになった時に、答えのない問いを投げかける」というメソッドは、以前自分も試してみたことがある。具体的なエピソードはこのようなものだ。

それは、2024年の1月に入り、自分の所属する新しいチームが組成されたあとの初めて懇親ランチ会だった。

その場にはマネージャーを含めて5人いた。自己紹介を済まし、一通り今まで仕事でやってきたことなどを話した後、やはり沈黙が訪れた。各人が頭の中で話題を探しつつ、ぽつぽつと人が会話するだけの雰囲気になってしまった。

一度場が冷えてしまうと、また盛り上げるのは難しい。ランチ会なのでテーブルの上には酒もない。しかし、自分はそれをチャンスだと思った。「答えのない問いを問う」というメソッドを試してみる絶好のタイミングだと。

テーブルの向かい側には、むかし飲食店で働いていたと自己紹介で話していた20代半ばのエンジニアが座っている。その人は自分が持っている資格を活用して、ただのアルバイト以上の働きをしていたそうだ。正社員として同じ会社で働いている今でも副業で別の飲食店の手伝いをしているらしい。

その人にその場で思いついた疑問をぶつけてみた。それは「飲食店においてプロとアマチュアの違いって何だと思いますか」というものだ。

自分の内心としては「まあ、いきなりの質問だし、答えをはぐらかされたり、話題を変えられても仕方ないかな」と思っての問いかけだった。このメソッド自体初めて試みることだし、何か会話のきっかけになればいいと言うぐらいの気持ちだった。

しかし、意外なことに同僚はこの問いを受け止めてくれた。「うーん」と少し考えてから、「それは人から求められて作るか、自分が作りたいから作るか、ですかね」と答えてくれたのだ。

こうなるとしめたものである。もちろんこの問いに対する答えは自分も持っていない。なので、その回答に触発されて浮かんだ疑問をさらに聞いてみた。

「例えば EC サイトで食品を販売する人は、人から求められる前にまず作って販売している。その点で人から求められるよりも先に自分が純粋に作りたいという気持ちから作っていると言えるのではないでしょうか」と。

すると同僚は「確かに…」と言いつつ、他の人も交えて何度かやり取りをした。そして「お金をもらっているかどうかですかね」と答えてくれた。「人からも求められた上にお金を対価としてもらうのがプロなのだ」と。

この意見には他の人も賛同していた。自分にもそのように思われたし、頭の中で反例を考えつつ、ここから更に突っ込んでまた質問をしてしまうと、自分が嫌な人に思われてしまうかなと考えて、「面白いですね！確かにそうですね」と言うだけにした。

そして自分が「なんでこういう質問をしたかというと、最近哲学にハマっていて…」と経緯を話すとみんな納得してくれてさらに興味を持ってくれた。その後もこれをきっかけに別の人が「哲学とはちょっと違うんですが、思想という点だと高校時代に宗教に入信しそうになって…」など、他の面白い話題を続けてくれ、また場が温まったのだった。

もちろん、質問しているときは相手を否定しているわけではなく、純粋に気になるから聞いているのだという態度を取る必要がある。それは相手に対する敬意だ。

そして、「答えのない問い」つまりオープンクエスチョンを尋ねることのある効用もこの経験から学んだ。このようなオープンクエスチョンを聞くことで、相手の思考や価値観の核心に迫ることができるような感じがするのだ。それは表面的な雑談では決して到達しない深層部分である。

相手が何を大切にしていて、どのような視点を持っているかを知ることができる。相手が自分と違う視点を持っているほど面白い。会話をしていても、「つまりこういうことですね。ではこうも考えられませんか」と一度相手の主張を受け止めることで、相手も話をしっかり聞いてもらっているという感覚を得られるはずだ。

つまりこれは自己と他者違いというものを楽しむことができる対話なのだ。もちろん、その過程で自分の常識も覆されることもある。このような対話をして相手を深く理解すること。これこそが昨今お題目のように繰り返される「多様性」に対する取るべき態度なのではないだろうか。

自分の話したいことを話すだけ、相手が誰でもいいというような一方的な話には決してならない。このオープンクエスチョンについての対話は、1人1人顔を持つ相手と向き合っていくことができる。

あるテーマについての問いを提示し、相手の答えを受け止め、さらに質問をして問いについて深く考えていく。すると、そのテーマについて深い洞察を得ることができる。その上、相手の価値観の核心に触れ、さらには自分の価値観が揺さぶられることもある。対話を終えた後、相手も自分もこの世界を新しい視点で見ることができる。これこそ、対話の効用である。

何がプロフェッショナルとアマチュアを分けるかという質問は飲食店に限定したものだったので、その同僚1人に対するものだった。しかし、例えばプロのエンジニアとアマチュアのエンジニアという区分にすれば、もう少し他の人も答えられてさらに盛り上がったかもしれない。

新幹線の中で、この懇親ランチの会話の概要を友人に話したところ、なるほどと納得していたようだった。友人も次の飲み会で試してみると話していたので、別の機会に実際どうだったか、このメソッドがうまく機能したかを聞いてみたい。

もちろん、このメソッドは万能ではない。場の空気や相手の性格も少し考慮して実施する必要がある。特に相手の話ばかり聞いて自分の考えを述べなかったり、相手の言うことを要約してワンクッション置かずに何度も質問することは、礼節に反している感じを相手に与えるのでよろしくないので注意が必要である。

このメソッドはプラトンが記した対話篇である『プロタゴラス』を読んで思いついたものだ。会話の沈黙を破るこの対話メソッドは、古代ギリシア時代から2000年以上経た現代でもソクラテスメソッドが古びていないことを私たちに教えてくれる（その後も私はこのメソッドの威力を体感し、その恩恵にあずかることになるが、それはまた別の話である）。

瓢鮎図の示す禅問答を解いてみたら、まだまだ無の境地には至っていなかった件（画像は wikipedia より引用）。

瓢鮎図とは禅のある公案を絵にしたものだ。この絵は京都の妙心寺が所蔵しており、この寺のご御朱印帳の表紙にもなっている。公案とはいわゆる禅問答であり、和尚（方丈）が僧侶（雲水）に出題する、答えのない問いだ。

僧侶は座禅をしたり、寺の掃除をしたり、修行の中で回答を考えて和尚に伝える。多くの場合は修行が足りないと突き返されるのだが、その答えが核心をついているのであれば晴れて悟りを得たと認められる。

代表的な公案の中には、「犬に仏性はあるか」（「狗子仏性」。『無門関』という公案集の最初の問い）というものや、「両手で一度拍手する。その時、パンッという音は右の手が発したものか、左の手が発したものか」（「隻手の音声」江戸時代の禅師、白隠が考えたもの）というものがある。

学校で出題されるテストとは異なり、どちらもれっきとした答えはない。

問いも多様ならその答え方も多様だ。例えば、「仏陀とは何か」という問いに、ある僧侶が「干からびたクソだ」と答えた。すると、その僧侶は悟りを開いたと認められたという中国の逸話がある。

解説には以下のようなものだ。仏教の根本思想は、執着を捨てることで苦しみから逃れられるというものだ

仏陀は何ものにも執着するなと説いた。しかし、その仏陀にすがることこそ究極の執着なのであり、その意味で仏陀の教えを後生大事にしている人は永遠に悟りを開くことはできない。

「仏陀の教えすらも捨てて、仏陀自信を何の価値のないクソに喩えることで、その僧侶は執着心を捨てた。僧侶はは無の境地に至ったのだ」ということだそうだ。

似たような句に「仏に会えば仏を殺し…父母に会えば父母を殺し…。初めて解脱を得る …」（逢仏殺仏）という物騒なものもある。これは三島由紀夫の『金閣寺』にも登場する句であり、初めて接した時は意味が分からずそのインパクトに圧倒された（金閣寺は禅寺である）。

一度悟りの境地に至ったら、その言葉は自由になり、何にも束縛されないということは何となく分かる気がするものの、やはりこれらの劇薬とも言えるフレーズが飛び出してくるのは禅宗ならではだろう。それは自分が禅宗を好む理由でもある。

さて、瓢鮎図である。この公案は、「瓢箪（ひょうたん）で鯰（ナマズ）を押さえることができるか」という問いだ。瓢箪は丸くてスベスベで、鯰はヌルヌルして捉えどころがない。果たして瓢箪を使ってナマズの動きを止めることはできるだろうか。

この公案を知ってから5年以上経って、やっとそれらしい自分なりの答えが浮かんだ。悟りとは程遠いかもしれないが、 試みに書いてみる。

それは、「ナマズが泳ぐ池を瓢箪の形にしよう。ナマズは池から出られず、その意味で抑え付けられたのも同然だ。」というものだ。公案に対する答えの精度は、悟りに至ったかどうかを測るバロメーターである。この答えは実際どうなのだろうか。解答例を参照しよう。

実は、瓢鮎図の上部には31名の過去の禅師の回答が漢詩で記されている。そのうち2つを紹介しよう。

「瓢箪でナマズを抑えて、ナマズの吸い物を作ればいい。だが飯がなければしょうがない。砂でもたいて飯でも作ろうか。」

08 | 退蔵院「禅と禅問答」より

「瓢箪に油を塗って、急流に泳ぐナマズを抑える。あっちから抑え、こっちから抑え、抑えきれぬと分かったところで、求める心はやむ」

同上

この答えを読むと、私にはナマズとは煩悩であり、それを捨てたり忘れたり気にしないようにせよと言っているように思われる。翻って、ナマズを捉えてしまう私の回答は、私自身が本能に捉われていることを示す。悟りの道は遠いようだ。さて、皆さんならどう答えるだろうか。