ホームページ作成がライフワークといえるほど、この20年以上、自分のホームページを作り直し続けてきました。フルリニューアルだけでも数十回はやってる気がします。

先日「Raspberry Pi上で動く書籍PDF検索エンジンを作ってDiscordボットとn8nと連携させてみた」に書いた通り、Raspberry Piで書籍PDFの全文検索を作りました。その際、ローカルマシン上にためこんだファイルに対してAI技術を用いることの可能性を感じました。その後「メモ管理は Obsidian in Cursor が最強｜松濤Vimmer」という記事を見て、やっぱり自分の知的生産に用いるためのデータはローカルにファイルとして持っておくほうがAIの支援を受けやすくて便利だという気持ちが強くなってきました。ローカルでいろんなAIモデルを動かしやすくもなってきましたしね。

Obsidianはこれまで何度か試してみたのですが、日頃メモというものを全然取らないので常用するにいたりませんでした。しかし、そんな自分にも毎日書いているものがあります。それは日記です。日記をどこでどのように書くかというのは、ホームページ作りと同じく長年の課題であり続けてきました。この問題が解決できるならObsidianをちゃんと使っていけそうです。

そこで、ObsidianをヘッドレスCMSとして使うことで、コンテンツはObsidianで管理し、Webサイトとしての表示部分は静的サイトとして実装すればよいのではないかと思いつきました。公開前提の日記や、この記事もそうであるようなブログを書きつつ、プライベートなメモもObsidianのみで管理できたら便利そうです。

このホームページでできること

• トップページ: プロフィールページの情報をAIエージェントにそれっぽくまとめてもらいました。
• 日記: 日記を時系列で表示したり、過去の同じ日の日記を振り返ったりできます。
• ブログ: ストックしたいまとまった考えなどを書きます。
• アウトプット: note、YouTube、zennなど、様々なプラットフォームでの活動をまとめて表示しています。
• 個別ページ: いまのところプロフィールページがあります。その後増えるかも。
• 全文検索: サイト内のコンテンツをキーワードで検索できます。

Webサイトとしては特に変わったことができるわけではないのですが、コンテンツ管理をObsidianで一括してできること、静的サイトでありつつもわりと高速に動く全文検索がついていることあたりが、個人的には気に入っています。

ソースコードはkentaro/kentaro.github.ioに公開しています。Vibe Codingなコードで、これ自体を見てもあまり意味がなさそうですし（そういうコードを書くこと自体はどんどん簡単になっているし）、伝えたいのはアイディアについてなので、以下にポイントを書いていきます。

ObsidianをヘッドレスCMSとして使う

やったこと：

• ObsidianのデータをGitHubで管理（Gitプラグインを利用）
• Obsidianのディレクトリ構成を公開用とプライベートなものとに分類
• 静的サイトビルダーをNext.jsで実装し、上記のリポジトリをsubmoduleとして登録
• 公開用のディレクトリのみをホームページのコンテンツソースとして利用

Obsidianのディレクトリ構成は、以下のようにしました。特定のフォルダ（ここでは"public"にしてます）に置いたMarkdownファイルが、自動的にホームページのコンテンツになるようにしました。

public/
  journal/YYYY/MM/DD/YYYY年M月D日.md
  blog/YYYY/MM/DD/タイトル.md
  profile.md

...

（publicディレクトリ以外はプライベートなメモ）

Obsidianのようなふだんから使うツール（僕は最近ちゃんと使い始めたのですが）がそのままCMSになるのは便利ですね。

Wasm化されたRDBMSを用いてローカル全文検索する

やったこと：

• ビルド時にコンテンツから検索用に用いるデータを生成
• ブラウザ上で動くRDBMSにSQLクエリを実行し、全文検索を実現

これは主に自分自身にとって便利な機能です。たとえばこんなことがありました。ここ数日で花粉症がひどくなってきたので日記を検索したところ、昨年も同じぐらいの頃に同様のことが起こっていたようでした。また、そうなると気分が沈みがちなので、これまでの事例に基づいて、気の持ちようをコントロールすることができます。

ところで、ブラウザ上で完全にローカルで全文検索を実現するというのは、20年前から行われていたことではあります。ここでは、最近の技術を用いて車輪の再発明をしてみました。すなわち、PGliteというPostgreSQLをWebAssembly化したものを使って、ブラウザ上で動く全文検索機能を実装しました。

PGliteのWasmバイナリが2.8MB、記事データが5.8MBほどあるようです。初回のページロード時にデータベースの初期化が走るのですが、いまどきならそんなに問題になるほどでもないかもしれません（検索しようとしたときだけにするような工夫はしたいところです）。

コンテンツ更新をトリガに自動デプロイする

やったこと：

• コンテンツとコードを別々のGitHubリポジトリで管理
• コンテンツのリポジトリの更新をトリガーに、ホームページリポジトリのビルドを実行

コンテンツとウェブサイトのコードは、別々のGitHubリポジトリで管理しています。そして、コンテンツを更新したら、自動的にウェブサイトが作り直されて公開されるように、GitHub Actionsを設定しました。どちらも単一のリポジトリで管理することも可能なのですが、Obsidianアプリを開いたときにコードが含まれるのはコンテンツ管理上煩雑なので、分けることにしました。

ホームページのリポジトリは更新があったらGitHub Actionsで自動デプロイするようにしています。さらには、Obsidianで管理しているコンテンツのリポジトリに変更をプッシュすると、GitHub Actionsでホームページのリポジトリのワークフローをトリガするようにしました。そのことで、コンテンツ更新時にホームページのリポジトリ側でもGitHub Actionsが動いて、ビルドとコンテンツ更新ができるようにしました。

コンテンツのリポジトリのワークフローを参考に掲載しておきます（といっても、公開用ディレクトリで更新があったらホームページのワークフローをトリガしてるだけですが）。

name: Trigger Main Repo Workflow

on:
  push:
    branches: [ main ]
    paths:
      - 'public/**'
  workflow_dispatch:

jobs:
  trigger-main-workflow:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Main Repository Workflow
        run: |
          curl -X POST \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer ${{ secrets.HOMEPAGE_REPO_PAT }}" \
            https://api.github.com/repos/kentaro/kentaro.github.io/actions/workflows/deploy.yml/dispatches \
            -d '{"ref":"main"}'

いろんな場所のアウトプットをまとめて表示

やったこと：

• 複数のプラットフォーム（note、YouTube、zennなど）のRSSフィードを取得
• ビルド時にフィードを解析し、データを統合
• 統合したデータを時系列順に並べた静的ページを生成

僕はnoteやYouTube、zennなど、いろんな場所でコンテンツを出しています。以前のホームページでもやっていたのですが、これらを一箇所にまとめて見られるように作ったのがアウトプットページです。自分の活動をふりかえるのに便利です。

やってること自体に特筆すべきことはありません。各サービスのRSSフィードを取得して、時系列順に並べて表示しています。これも、ホームページをビルドするときに自動でデータを取得して、静的なページとして生成しています。

「n年日記」機能で過去のふりかえり

やったこと：

• 日記コンテンツを日付でインデックス化
• 同じ日付の過去の日記を並べて表示する「n年日記」ビューを実装

日記を続けていると、「去年の今日は何してたっけ？」と振り返りたくなること、ありますよね。そこで、普通の日記表示に加えて、いわゆる「n年日記」という機能を実装しました。ある日付の日記を年をまたいで見られる機能です。hnsやtDiaryのような、Web日記の創世記からあるCMSが実現していた面白い機能です（「長年日記」をmain trunkにマージ - tDiary.org）。

「あー、去年も同じことで悩んでたな」とか「この頃から考え方が変わってきたんだな」とか、自分の変化を客観的に見ることができて面白いです。Scrapboxで日記を書いていたときは日付のタグを付与することで実現していたのですが、このシステムでは自動的にできるようになりました。

おわりに: 知的生産のベースとしてのホームページへ

このホームページは、Webサイトとしては特にたいしたことをやっているわけではないのですが、AIエージェントの力を借りることによって短期間でこれまで紹介してきたことを実現できました。

そもそもAI前提だとローカルにファイルがある方が取り回しがいいよねということで始めたわけですが、そのあたりはまだまだ全然着手できていません。また、Obsidianでのメモ書きもあまりできていないので、そもそも機能をあまり使えていません。キーワードリンク的な機能なども使っていくと、その辺を記事としてどう扱うかとか、ナレッジベース自体も公開対象にするとか、そういうこともやりたくなりそうです。

Obsidian自体をもっと使いこなせるようになったら、自分の知的生産のベースにしていけるはずなので、今度はそのあたりに取り組んで行きたいですね。

本記事は「🎅GMOペパボエンジニア Advent Calendar 2022」の10日目の記事です。9日目の昨日は「Slack→GAS→NotionでTODOリスト化を少し便利にする - にっしーのシンギュラリティ計画」でした。

今年のアウトプット

対外的なアウトプットについて、自己紹介ページに記録するようにしています。今年のアウトプットの内訳は、以下の通りです。

• 研究
  • 査読付論文：1本
  • 学位論文：1本
  • 表彰：1件
• 執筆：2件
• 登壇：16件
• ポッドキャスト：3件
• 取材：2件
• 技術ブログ：13本

以下、それぞれについてふりかえっていきます。

研究

今年は年初に修士論文を完成させ、修士（情報科学）の学位を取ることができました。目標は博士号ですが、もしだめでも修士号は取っておきたいというのが最低限のラインでしたので、ひとまずクリア。まずは一安心ではありました。おまけに、優秀修了表彰もいただきました。

4月から博士後期課程に進学しました。そして、修論を元にブラッシュアップしたものを情報処理学会論文誌に投稿しました。条件付採録を経て、先日無事に採録通知をいただきました（出版は来年3月です）。ジャーナルに通すことは、まずは研究者の卵としての第一歩としての大きなマイルストーンなので、こちらも大変喜ばしいことでした。

しかし、研究テーマの流れの中で、2本目となるべき研究に着手できず、今後の頑張りが必要な状況です。

受賞・表彰

• 優秀修了, 北陸先端科学技術大学院大学博士前期課程（先端科学技術専攻）, 2022年3月.

学位論文

• 栗林健太郎, 修士論文：IoTシステムの双方向データフローにおける設計と実装の複雑さを解消する手法の提案, 修士（情報科学, 北陸先端科学技術大学院大学）, 2022年3月. [発表資料]

ジャーナル論文

• 栗林健太郎, 三宅悠介, 力武健次, 篠田陽一, Pratipad: IoTシステムを単一のプログラミング言語で統合的に構築できるデータフロー基盤の提案, 情報処理学会論文誌. (to appear)

執筆

今年は、WEB+DB PRESSの特集記事を2本書きました。1つ目は、Elixirコミュニティの皆さんとのElixirに関するもの。2つ目は、会社の同僚らとのWeb3に関するものでした。どちらもオーバービュー的な1章を書いたのですが、それぞれにけっこう苦労があったりもしました。

執筆に関しては、今もまさに進めている企画があります。なかなか筆が進んでいない状況なのですが、早く出せるよう取り組んでいきたいと思います。また、技術雑誌はもとより、技術書展に出したり、はたまた全然違うジャンル（文化的な内容など）の執筆活動もしてみたいと思っています。

• 栗林健太郎・高瀬英希・大聖寺谷一樹・山内修・隆藤唯章・齋藤和也, 「Elixirによる高速なWeb開発！作って学ぶPhoenix」, WEB+DB PRESS, Vol.127, 技術評論社, 2022年2月24日, ISBN 978-4-297-12705-3
• 栗林健太郎・吉本康貴・高岡佑輔・池田昭仁・黒瀧悠太・大和田純, 「作って学ぶWeb3 ブロックチェーン，スマートコントラクト，NFT」, WEB+DB PRESS, Vol.130, 技術評論社, 2022年8月24日, ISBN 978-4-297-13000-8

登壇

技術トーク、講演、パネルディスカッションでお話しする機会がありました。

技術トーク

今年は、6本でした。ミートアップでのLTで話したのがほとんどで、大きな舞台での技術的に込み入った内容の話はできませんでした。昨年のように、海外の技術カンファレンスで話すみたいなことに、またチャレンジしないとなあ。でも、技術トークは国際会議での研究発表の方でもっと頑張りたいというのもありますね。

• 栗林健太郎, Elixirで構成された3層構造からなるIoTシステムにおける分散機械学習・推論実行基盤へ向けて, K-Ruby#28 LT&もくもく会, 2022年1月.
• 栗林健太郎, WEB+DB PRESSで特集記事を書く方法, WEB+DB PRESS vol127 Phoenix特集こたつで座談会, 2022年3月.
• 栗林健太郎, 最近のElixir活動＠2022年3月, K-Ruby#29 LT&もくもく会, 2022年3月.
• 栗林健太郎, asdfでRubyを使う, K-Ruby#30 記念大会, 2022年5月.
• 栗林健太郎, 最近の技術活動@2022年7月, K-Ruby#31 LT&もくもく会, 2022年7月.
• 栗林健太郎, Cookpad Code Puzzle for RubyKaigi 2022をやってみた！, K-Ruby#32 LT&雑談会, 2022年9月.

講演

今年は、講演を2本しました。ここでいう講演とは、主に依頼されて技術的な内容でないことについて話すというぐらいの意味です。聴いてくださる方がいるのはもちろんありがたいですし、自分の考えをまとめるいい機会になったという意味でも、ありがたいことです。ただもうキャリアの話はいいやという感じですが……。

• 栗林健太郎, キャリアを時間・空間軸で考える, type エンジニア転職フェア ONLINE, 2022年9月.
• 栗林健太郎, 先行きの見えなさを楽しさに変える ーVUCA時代のキャリア論と絶対他力主義ー, 技育祭2022【秋】, 2022年10月.

パネルディスカッション

今年はパネルディスカッションへのお声がけが多い年でした。8本ありました。自分一人で話すのと違って、話題が多岐にわたって楽しいことが多いです。一方で、モデレータをつとめることもありますが、もっと楽しい話を引き出せたはずだと、反省することしきりです。

• 栗林健太郎, 小賀昌法, 藤本真樹, 広木大地, パネルディスカッション / 日本CTO協会理事が質問に回答, オープンなCTO協会を目指して。協会活動と今後について大公開, 2022年5月.
• 栗林健太郎, 嶺井政人, 古田哲晴, 小泉泰郎, パネルディスカッション / CTOに知っててもらえると嬉しいファイナンス講座, 日本CTO協会コミュニティイベント, 2022年6月.
• 落合渉悟, 栗林健太郎, 黒瀧 悠太, パネルディスカッション / もうちょっと知りたいWeb3 〜うねりの最前から見えるトレンド〜, FGN Future Talks #2, 2022年7月.
• 安田壮平, 米丸まきこ, 福留大士, 栗林健太郎, 中垣雄, 勝眞一郎, パネルディスカッション / 奄美をデジタルのチカラでパワーアップ・かせぐ地域づくりに向けて, 招待制イベント, 2022年8月.
• 伊藤穰一, 栗林健太郎, 紫竹佑騎, BBB, パネルディスカッション / web3の未来とクリプトが果たす役割, CryptoBar P2Pポップアップストア in 博多オープン記念イベント, 2022年10月.
• 国分崇志, 植山類, 栗林健太郎, パネルディスカッション / 海外エンジニアに訊く海外でのキャリアパスの描き方, SAKURAJIMA HOUSE 2022, 2022年10月.
• 三谷隆, 栗林健太郎, 安藤健一郎, 稲守貴久, パネルディスカッション / CTO対談 ～技術責任者会議～, GMO Developers Day 2022, 2022年12月.
• 栗林健太郎, 堀江正信, 北川雅士, パネルディスカッション, エンジニアが社会人大学院で学ぶ意義 〜社会人との両立と卒業後の展望〜, 2022年12月.

ポッドキャスト

10月頃に「ポッドキャストに出たい！」とTwitterに書いたら、ありがたいことにお声がけいただき、出させていただきました（研究者・エンジニアとしてのものにカウントしていいのかどうかはともかく）。

うまく話せるかどうか心配でしたが、話してみると楽しくて、あっという間に時間が過ぎていきました。また、自分の話し方の癖にも気付かされたので、そのあたりは今後改善していきたいです。

• 富所亮, 栗林健太郎, ep 79 @kentaroと社会人大学院、Elixir について, Yokohama North AM, 2022年10月.
• 栗栖義臣, 長山武史, 栗林健太郎, 213. 歌舞伎の魅力 (ゲスト:あんちぽさん), Ossan.fm, 2022年11月.
• 栗栖義臣, 長山武史, 栗林健太郎, 214. 男性性とアンラーニング (ゲスト:あんちぽさん) | Ossan.fm, Ossan.fm, 2022年11月.

取材

今年は2本でした。少ない！「話を聞きたい」と思われるような活動をしていかないとなあ。

この2つは、六本木のawabarで飲んでいたら取材を受けることになったことがきっかけでできた内容です。特に後者は、文面にはあまり表れてはいないのですが、自分自身にとって人生のふりかえりとして機能するような体験で、とてもありがたい取材でした。

• 【人生グラフ】#5 六本木編 | IT業界がなかったら死んでいてもおかしくなかった - YouTube, 2022年9月.
• 「奄美でひとり、ブログを書いてたら」 東京でCTOになった元・地方公務員の物語 | ビズリーチ, 2022年11月.

技術ブログ

技術ブログはZennで書くようにしています。今年は13本。もっとコンスタントに書いていくようにしたい。書くべきネタはたくさんあったはずなのですが。

• evision事始め - ElixirでOpenCVを使って画像処理をする
• 通信経路が片方向の場合のElixirのノード間通信の挙動を確認する
• ElixirでTCP接続したクライアントからの入力を他の全クライアントにブロードキャストするサーバを作成する
• BanditとPlugによるElixir製のシンプルなWebアプリケーションをfly.ioにデプロイする
• OpenAPI GeneratorでMoralis APIへのElixirによるクライアントを作る
• asdfでRubyを使う
• Nervesが動作するホスト上でファイル操作をする
• Nerves on Raspberry Pi 4でカメラモジュールを使う
• Mix.install/2を用いてElixirライブラリの使い方を多数掲載しているmix_install_examplesが面白い
• Livebookの新機能Smart Cellsを使ってシェルコマンドを実行できるセルを作った
• CopilotとDeepLを使って（ほぼ）何も考えずにElixirでAtCoderの問題を解いてみた
• TinyEMU（RISC-Vエミュレータ）を用いてLinuxを動かす
• ChatGPTにスライドビューアアプリを作ってもらう

おわりに

こうしてふりかえってみると、それなりのボリュームがあるように思えました。しかし、それぞれのカテゴリについて、もっとやれたよなあという思いもあったりします。おしゃべり的な内容も続けてはいきたいのですが、今後はもっと研究・技術の面でのアウトプットを増やしていきたいものです。

『事業をエンジニアリングする技術者たち ― フルサイクル開発者がつくるCARTAの現場』（版元のWebページ）をいただきました。ありがとうございます。本記事では、副題となっている「フルサイクル」という言葉に着目して、本書について簡単に紹介します。

本書の位置付け

本書は、2020年に刊行された『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』の「改題改訂版」として刊行されたものです。

まず「改訂」の方から。前著の刊行から2年が経過し、「事業」運営母体も大きく変わりました。それを受けて、各章の最後にこの2年のアップデートが付記され、さらには新規事業と経営基盤システムの統合を扱う2章分が追加されました。

「改題」の方はというと、サブタイトルが新たに追加されています。前述の運営母体の変更による内容とともに、「フルサイクル開発者」という言葉が明記されていることに、一瞥して気づかれることでしょう。

フルサイクル開発者とは何か？

「フルサイクル開発者」という言葉は、前著においても幾度も言及されていました。今回の「改題改訂版」では副題にまで取り上げられていることもあり、本書のコンセプトをひとことで示す重要な概念としての位置付けに格上げされたようです。

そのフルサイクル開発者について、本書では以下のように解説されています。

「ビジネスアイディアからお客さんに届くまで」を1つのサイクルとみて、それを全て一人の技術者でもやれるようにしよう、というのがフルサイクル開発者のイメージです。

（中略）

ビジネスの一番最初から運用して観測するというフィードバックサイクルを回せるのが「フルサイクル」のイメージ（後略）。

本書p.61

元々はNetflixのブログから取り入れた概念であったそうです。「Netflixにおけるフルサイクル開発者―開発したものが運用する - CARTA TECH BLOG」として訳出されています。この記事では、フルサイクル開発者とは「ソフトウェア開発ライフサイクル」を通じた職務を持つエンジニアであり、以下の役割が期待されています。

フルサイクル開発者はエンジニアリングの原則をライフサイクルのあらゆる分野に応用する。開発者の視点で問題を評価し、「このシステムを動かすために必要なものをどう自動化できるか？」「どのようなセルフサービスツールがあればパートナーが開発者の手を借りずに自分の疑問に答えることができるだろうか」と問う。人間中心よりもシステム中心に考え、手動で行われていたものを自動化することによって、チームはスケールする。

Netflixにおけるフルサイクル開発者―開発したものが運用する - CARTA TECH BLOG

ここでいわれるような「ライフサイクルのあらゆる分野」にエンジニアリングを適用し、問題解決できる人々のことを「フルサイクル開発者」と呼ぶのでしょう。

ソフトウェアエンジニアリングの対象

ところで、本書が主題とするソフトウェアエンジニアリングについて、『Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス』では、以下のように述べてます。

本書が共有する重要な見識に、ソフトウェアエンジニアリングとは「時間で積分したプログラミング」とみなせる、というものがある。自分たちのコードを、着想し、導入し、保守し、廃止するまでのライフサイクルを通じて持続可能（sustainable）なものとするためにコードに導入できるのは、どんなプラクティスだろうか。

本書では、コードを設計し、コードのアーキテクチャーを定め、コードを書いていく際に、ソフトウェア組織が留意すべきと我々が感じる 3 つの根本的原則に重点が置かれている。

時間と変化

コードがその存続期間にわたりどのように適応していかなければならないか

スケールと発展

進化するにつれて組織がどのように適応していかなければならないか

トレードオフとコスト

「時間と変化」、「スケールと発展」から得られる教訓に基づき、組織がどのように決定を行うべきか

『Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス』p.x

ここでは「サイクル」という言葉の含意がより広く捉えられているように思われます。すなわち、「自分たちのコードを、着想し、導入し、保守し、廃止するまでのライフサイクル」とはつまり、開発サイクルを超えた「事業ライフサイクル」というべきより広い概念ですし、サイクルに応じた組織のスケールについても言及されています。

「フルサイクル開発者」という言葉の可能性をより広げるためには、その「サイクル」の円周をさらに広げて、「事業ライフサイクル」として捉えると良いのではないでしょうか。事実、本書における「サイクル」とは、最近ローンチされた新規事業から、長いものでは20年に及ぶ事業まで様々な来歴を持つプロダクトという時間的スケールにおいて語られているのであり、それは日々の活動としての開発サイクルを包含した、よりスケールの大きな営みの連鎖の謂なのですから。

このようにソフトウェアエンジニアリングの定義とその対象を捉え直した時、本書が広告配信、EC関連サービス、メディア、人材採用等の、一見すると取り止めもなく思えるほどの幅広いサービスにわたり、それぞれの事業を支えてきたエンジニアたちの奮闘ぶりを余すところなく伝えてくれることの、本当のありがたみがわかるというものでしょう。

ソフトウェアエンジニアリングの3軸

本書における語り手たちが勤務するCARTA HOLDINGSと前身であるVOYAGE GROUPは、長きにわたって「技術力評価会」を運営してきたことで有名です。それがどのようなものであったかは、同社をCTOとして率いてきた元CTOの小賀さんによる「5分でわかる技術力評価会」をご覧ください。

ところで、筆者が取締役CTOとして勤めているGMOペパボ株式会社においても、長い間エンジニア評価制度というものを運用してきました。元々はエンジニアのための制度だったのですが、数年前から同じ枠組みを全職種に展開するに至り、全社的な制度として運用しています。そこでは、「能力」（エンジニアであれば技術力といわれるようなこと）を、以下の3軸によって定義しています。

「GMOペパボ会社紹介資料」p.28より

「フルスタックエンジニア」という言葉が広く用いられるようになって久しいようです。「フルスタック」という時の水準に対する認識次第では、もちろん望ましいエンジニア像です。一方で、スタックの深さというのは、それ自体ではこれまで述べてきたソフトウェアエンジニアリングという観点からは、複数ある軸のひとつであるという位置付けになるでしょう。すなわち、いかに時間の経過（ライフサイクル！）をその対象とし得るのかという問題です。また、上図では「影響を広げる力」として、他者に対するインパクトもまた重視しています。

フルサイクルエンジニアリングの担い手たちへ

本書のいう「フルサイクル開発者」とはすなわち、ここでいう「作り上げる力」のみならず、「先を見通す力」によって「時間で積分した」（前掲書）価値を実現し、「影響を広げる力」によって事業全体を通じて影響力を行使するような気概を持つエンジニアのことをいうのではないでしょうか。そして、実際に本書に登場するのは、きれいごとばかりではない事業運営の中で、時には「つらい」と落ち込んだり、かと思えば「アンガー駆動」で勢いづいたりする、等身大のエンジニアたちです。その奮闘ぶりは、読者を心底から勇気づけてくれるでしょう。

また、前述のNetflixによる記事（の翻訳）にあるように「フルサイクル開発者はエンジニアリングの原則をライフサイクルのあらゆる分野に応用する」のであり、また、ソフトウェアエンジニアリングの対象が、「時間と変化」「スケールと発展」という必然に向き合うべき組織もライフサイクルにおける重要なファクターなのであれば、マネジメントという営みもまた、フルサイクルエンジニアリングの射程に入ってくるでしょう。そのあたりについては『エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング』がいまや古典の風格をもって語るところです。

また、そのような意味で捉えたとき、エンジニアリングとは何も職種としてのエンジニアのみが担うべきことではもはやありません。本書の帯に再録された@tokorotenさんのツイートにある通り「アフターDXの働き方がここにある。非エンジニア必見（中略）企業のDX担当者には必携の一冊」であり、いまや誰もがフルサイクルエンジニアリングの担い手である自覚を持ってことにあたるべきであるということになるのではないでしょうか。

そのような人々に向けて、本書は改題改訂版としてあらためて我々の前に再登場してきたのでしょう。フルサイクルエンジニアリングを担うすべての人々に、ご一読されることをおすすめします。

本書の位置付け

Web3を特集した「WIRED（ワイアード）VOL.44」において、「国のためのDAO」（p.192。以下、ページ番号のみ記載する場合は、すべて本書への参照を示す）であるDAO for Nation（DAO4N）について語っていた落合氏は、本書では打って変わって 「マイクロパブリックを生み出すシステム」（p.193）としてのAlgaについての「取説」（p.41）として本書を上梓した。なぜ国が対象ではないのか。

理由は明白だ。使ってみてもいないものを国が採用するはずはない。使ってみて、その利便性の高さを腹落ちしてこそ、人はその価値を知るし他の人々にもその価値を伝え、共有しようとするものだ。

p.195

自明にも思えるが、しかし極めて現実的な見解であろう。著者のいう「マイクロパブリック」とは、以下のごとき存在である。

マイクロパブリックとは何か。

読んで字のごとし、「小さな公共空間」だ。公共空間といえば、誰でも公平に使える空間のことをいうが、マイクロパブリックとは、個人の目的を行使することができる公共の空間といったところか。そこには、自治会があり、マンションの管理組合があり、PTAがあり、生徒会がある。他にも自分の目的が叶うはずの公的な場所はいろいろ考えられる。

p.192

本書で著者がプレゼンテーションするAlgaとは、そのような「マイクロパブリックを生み出すシステム」（p.193）である。国ではなくマイクロパブリックを探求と実践の緒として選択した著者の意気込みはこうである。

誤解されてもたかだか町内会のアプリだよね、というところから地ならしをしていく。公共にリーダーがいないというのはどういうことなのかを、頭と体で理解している層を増やしていくことが、外堀を埋めていくというか（中略）。

p.125

著者は、この本ではあえて天下国家についての語りをできるだけ差し控え、我々ひとりひとりにとってイメージすることが容易で、それぞれの立場においてすぐにでも実践に移せそうなスコープから、事を語り始めるのである。

そのための道具としてのAlgaは、本書においてはあたかも既に使えるものであるかのように述べられているが、実はそうではない。

開発ロードマップとしましては一年以上前の段階で各モジュールのプロトタイピングが終わっており、実現可能性については目処が立っています。今年（引用者註：2022年）の後半にかけてコミュニティ主体で開発していければと考えています。

【取材】ブロックチェーンで民主主義の改善を目指す、DAOアプリ「Alga」発表（落合渉悟 インタビュー） | あたらしい経済

差し当たっては、この「取説」を熟読すること。自らの意見・感想をフィードバックすること。そして、可能であれば開発に参加してみること。もちろん、Algaがリリースされた暁には、ユーザとして使ってみること。まずはマイクロパブリック目線において、著者が描く世界の展望への参加を呼びかけるというのが、本書の目的とするところであろう。

「いじらしい存在」としての国

そもそも本書のタイトルにも含まれる「メタ国家」とは何か。本書は「国家を支える3つの要素」としてを（1）民族自決権、（2）犯罪人引き渡しの拒絶、（3）人権保護が可能な唯一の主体であること、の3つを挙げる（p.17）。その上で「メタ国家」を以下の通り定義する。

メタ国家は上記の、国家を支える3つのうち、そのいずれかの要素を持ち、かつ国家にしかできないことができるならそれは国家なのだ。

（中略）

僕の作ったメタ国家を生み出す仕組みの名は「Alga（アルガ）」。Algaはスマホ一つでメタ国家を作れるプラットフォームであり、動的な人権保護機構である。

p.18

ここで定義されている「国家を支える3つの要素」というのが、3つで全てなのか、例示なのかは判然としない。「メタ国家」を定義する引用箇所は、果たしてそれは「国家」であるのかないのか、それもまた判然としないように思われる。そのため、この定義には言葉足らずの印象を覚える。

この文をチャリタブルに読むならば、こうも考えられるように思う。すなわち、「公共性のある限定された次元を担うにすぎず、そのすべてを包含するわけではない」と齋藤純一『公共性』が位置付ける（同書p.7）ような意味において、国家をまずは相対化しようというのが「メタ国家」の「メタ」たる所以なのだろう。また、「3つのうち、そのいずれかの要素を持」てば十分とされる「メタ国家」とは、国家に対する私たちの「assumption（前提）」（pp.245-255）を切り詰めるための概念操作であるとも読める。どういうことか。

御厨貴他編『舞台をまわす、舞台がまわる - 山崎正和オーラルヒストリー』で、山崎正和は再三にわたって「国家」は「いじらしい」存在であると感じていた者たちの話をする。

私は象徴的に森鴎外までを第一世代と呼んでいます。それはどういう人たちかというと、自分よりも国家のほうが小さいと思っている。国家をいじらしい存在だと感じている人たちです。（中略）

これが永井荷風になると、もう政治は全くの埒外になってしまう。（中略）メンタリティの点で、このあたりが第二世代の始まりです。第二世代の大きな特徴は、まず国家が自分より大きくなっているという意識です。国家を偉大と見るか、抑圧的と見るかのどちらかですね。

御厨貴他編『舞台をまわす、舞台がまわる - 山崎正和オーラルヒストリー』（p.332）

明治維新以後の「第一世代」を象徴する森鴎外にとって、国家は「いじらしい存在」であった。別の箇所では「鴎外の段階では、国は可愛がってやらなければならない、庇護してやらなければならない存在だった」（同書p.192）。それは、明治維新以降の近代化を支えるエリートとしての強烈な公共心の表れであっただろう。

1934年生まれの山崎正和は、「第二世代」どころか昭和生まれであってなお、国について鴎外＝第一世代的イメージを持っていたという。

生意気をいわせていただければ、日本国家が非常に小さく見えた。日本はのたうって苦難を味わっていた。左翼の人たちにとっては、日本は憎むべき巨大な権力だったかもしれない。しかし私から見ると、波間に漂う笹舟のようなもので、一つ間違えると本当にひっくり返るという状況に見えていました。明治国家に対する鴎外たちのような力を、昭和国家に対して私たちが持っていたとはとても思えません。でも貧者の一灯というか、何かを寄与したいという気分は似ていました。

同書pp.170-171

30代にして有力な若手知識人として、佐藤栄作をはじめとする歴代の首相のブレーンを務めたほどの大人物ならではの感慨というべきか。ともあれ、いまの私たちにとっては（当時においてだってそうだっただろうけれども）、遠く離れた認識であるかのように思える。

なるほど、国というものをただ私たちがいま想念しているようものとして捉えればそうだろう。しかし、本書のいう「メタ国家」とは、国という存在に対する私たちのassumptionを切り詰めることで、いま一度、国というものを「いじらしい存在」へと変える概念操作なのではなかろうか。すなわち、ただただ「偉大」あるいは「抑圧的」と思えるだけの国家を、マイクロパブリックとしての、あるいはそれらの群れとしての「メタ国家」へと開いていくことで、「いじらしい存在」へと認識を変えていくということである。

「自立共生的な道具」としてのDAO

国という存在へのassumptionを切り詰めることによって、何が可能になるのだろうか。そのことについて考えるための切り口として、本書の導入する「道具」という概念について検討する。

国に対する「第二世代」以降的なassumption（つまり私たちにとってのそれである）は、国について「偉大」であれ「抑圧的」であれ、肯定的であれ否定的であれ、いずれにせよ自らとは遠く隔たるものと観念することによって、むしろ望ましくない結果に加担することになっていたのだというのが、本書の見立てであろう。そのようなassumptionを支えるのが「道具」である。

国家とはマクロ的現象であり宗教的現象なのだろう。領土的野心と民族というアイデアが、制空権やエネルギーや統治システムという道具から想起され、結果的に社会的実態として結実するにすぎない。道具のアイデアに支えられたか細い存在。

p.29

第一世代＝森鴎外的な「いじらしさ」の感覚とは遠く離れた、私たちが抱く国に対するよそよそしい観念こそが、国という本来的には私たちがより良く生きるための「道具」でしかない存在を「制空権やエネルギーや統治システム」に必然的に結びつけて止まない。そのことが、本書が再三にわたって指弾する人権侵害を惹起しているばかりか、それに対する反省をすら、ややもすると「しかたがない」こととみなす無力感によって無化してしまったのだろう（一方で著者は国について「か細い存在」と、山崎的な感慨をいみじくも述べている。著者の大人物たる所以である）。

あるいは、天下国家はともかくとして、私たちの日常生活においてもまた同様の事象は観察可能であるかもしれない。たとえば、本書にはこんな「余談」が記されている。

余談として付記するが、Googleは果たして道具といっても良いだろうか？使い手の意に反して政治的に突然挙動が変わるモノに僕たちは手に馴染んだ道具としての信頼関係を築けるだろうか？

p.25

Googleに対する、Web3と呼ばれもする昨今の潮流と同期するこうした評価については、賛否両論あるだろう。ここでは、ことの成否について論じようとは思わない。そうではなく、私たちがどのような「道具」を用いるかが決定的に重要なことであるのだという意図を汲み取ろう。「いじらしい存在」としての国家へと切り詰められた私たちのassumptionが、よりよい社会の実現へと動機づけられるためには、「手に馴染んだ道具」を見つけなければならない。

本書のいうマイクロパブリックにおける、人々のあるべきあり方について、イヴァン・イリイチは「自立共生的（コンヴィヴィアル）」という言葉をあてた。

すぐれて現代的でしかも産業に支配されていない未来社会についての理論を定式化するには、自然な規模と限界を認識することが必要だ。（中略）いったんこういう限界が認識されると、人々と道具と新しい共同性との間の三者間関係をはっきりさせることが可能になる。現代の科学技術が管理する人々にではなく、政治的に相互に結びついた個人に仕えるような社会、それを私は“自立共生的（コンヴィヴィアル）”と呼びたい。

イヴァン・イリイチ著、渡辺京二他訳『コンヴィヴィアリティのための道具』（p.18）

そして、そのような社会は、彼が「自立共生的な道具」と呼ぶ道具によってこそ成立するのである。彼にとっての道具とは、ハードウェア的なものばかりでなく、制度や法のような「社会的工夫」のようなものも包含する。その上で、望ましい「道具」のありさまを以下のように説明する。

自立共生的な社会は、他者から操作されることの最も少ない道具によって、全ての成員に最大限に自立的な行動を許すように構想されるべきだ。（中略）自立共生的な道具とは、それを用いる各人に、己の想像力の結果として環境を豊かなものにする最大の機械を与える道具のことである。

同書pp.58-59

そのような「道具」とは、たとえばどのようなものなのだろうか。具体的に見てみよう。本書では、星暁雄氏との対談においてコンピュータの歴史が参照される。そこからの連想により、補助線を導入する。1996年に刊行された古瀬幸広、広瀬克哉『インターネットが変える世界』は、初期のポータブルコンピュータであるOsborne 1を設計したリー・フェルゼンシュタインについてこう述べられている。

イワン・イリイチの『コンヴィヴィアリティのための道具』を読んで感銘し、それを実現するためにパーソナルコンピュータをつくった

古瀬幸広、広瀬克哉『インターネットが変える世界』p.6

そして、そうしたハッカーたちの共通の動機についてこう述べる。

革命（引用者註：パーソナルコンピュータ革命）に参加したハッカーたちの目標は、コンピュータの能力を大衆に解放し、それを使って知識と情報を共有することであった。すなわち、コンヴィヴィアルな道具としてのコンピュータシステムづくりに邁進したのである。

同書p.9

こうして見ると、前述のイリイチによる「コンヴィヴィアリティのための道具」とは、ここでの私たちの文脈においては、まさにDAOの設計指針について述べられたものであると読むべきだろう（というか、もはやそうとしか読めない）。そうしてみれば、パソコンやインターネットの歴史が営々と生み出してきた「道具」たちの末裔こそが、DAOなのであった（もちろん、Algaを利用する上で唯一必要となる道具である「スマホ」もまた）。実のところAlgaとは、そのような「道具」を生み出すための「道具」の謂いである

連帯への「感情教育」

以上の通り私たちは、適切な規模に切り詰められたassumptionによって、マイクロパブリックにおいて自立共生的に生きていくための道具としてのDAOを手にすることになった。一方で、やはりことが最終的には社会の変革を目指すのであってみれば、そうしたボトムアップな戦術論のみならず、トップダウンのビジョンもまた必要とされるだろう。

そこで持ち出されるのが「世界人権宣言」である（本書には谷川俊太郎訳の世界人権宣言が収録されている）。Algaとは「「人権」という僕らが本来、持っているべきはずの権利を権力から取り戻すことができる時代が訪れる。それを実現する」（p.58）ためのものなのである。

国家へのassumptionを身の丈にあったマイクロパブリックに切り詰めることは、同時に、誰がその身内なのかを狭く捉えることにもつながり得る。それは、フォーカスすべき対象を適切な「限界」（イリイチ）に押しとどめることであると同時に、社会がバラバラになってしまうことにもつながりかねない。であるからこそ、普遍的な原理原則としての、また、国家に対するカウンターとしての「人権」概念が持ち出されるわけだ。逆にいうと、人権という価値を前景化するためにこそ、そうし切り詰めと道具の精錬が必要とされたということでもあろう。

リチャード・ローティは、ともすれば狭まってしまいがちな私たちのassumptionを拡大する営みを「感情教育」と呼ぶ。彼は、道徳を次のような事態として捉えている。

ローティが『偶然性・アイロニー・連帯』において主張したのは、「残酷さこそが私たちのなしうる最悪の事柄である」と言うシュクラーの考えに同意し、「正しい道徳」が実在するのではなく、「残酷さ」と「苦痛」に対する感受性を磨くことによって向上するような道徳性が存在する、ということである。

大賀祐樹『リチャード・ローティ―1931-2007 リベラル・アイロニストの思想』p.180

そして、そうした道徳を拡大していくために必要なのが「感情教育」であるというのだ。

ローティによると、そのような道徳が拡がりを持つには、「われわれ」という意識を拡げる以外にない。そしてそれは、「感情教育（sentimental education）」によって、より遠くの人々の残酷さや苦痛に対する「共感」を持つことを通じて可能になるのである。（中略）つまり、そうした「感情教育」は、残酷さと苦痛を表現する「物語」によって成し遂げられる。

同書pp.292-293

すなわち、本書の文脈でいうとこういうことだろう。私たちが自立共生的な道具としてのDAOによって運営されるマイクロパブリックからまず始めるという選択を行うのは、公共圏を「いじらしい」「波間に漂う笹舟のようなもので、一つ間違えると本当にひっくり返る」範囲にあえて引きとどめることで、ある種の道徳（本書におけるそれは「人権」である）を涵養する余裕を作り出すためなのであると。そのことで、人権概念の持つ普遍性の返す刀で、私たちのマイクロパブリックをじょじょに社会全体の連帯へと広げていく。DAOとは、私たちの感情教育ためののインキュベータでもあったのだ。

とだけいって済ませると、ローティが黙ってはいないだろう。なぜならば、ある種の金科玉条のような考えを基礎づけとして、客観的に正しい何事かが存在するなどということに一貫して反対し続けてきたのが彼だからである。

ある人格の、あるいはある文化の終極の語彙の正しさを証すものが何ら存在しないのとまったく同様に、何らかの葛藤が生じた時にその語彙をいかに再編するかを指令するような何かが、そうした終極の語彙の中に含まれているわけではない。私たちがなしうるのはただ、私たちが手にしている終極の語彙を持ってーーそれがいかに拡張されたり、修正されうるかについてのヒントに注意深く耳を傾けつづけながらーーやってゆくことである。

リチャード・ローティ著、斎藤純一他訳『偶然性・アイロニー・連帯: リベラル・ユートピアの可能性』p.409

本書の持ち出す「人権」という概念を、決定的に正しい「終極の語彙」として、すなわち議論のしようのない道徳のようなものとして理解・利用することには、私としては賛同することはできない。「何らかの葛藤が生じた時にその語彙をいかに再編するかを指令するような何かが、そうした終極の語彙の中に含まれているわけではない」のだから。

そうではなく、いまのところ私たち人類が手にしている、それこそ道具としての「人権」という概念を、テンポラリな「終極の語彙」として常に磨き続け、「われわれ」の範囲を広げていくための感情教育を自らに対して施していくこと。いかようにも変わり得る偶然性への認識＝アイロニーとは、つまりそうした教育の効果による自己の変革への動因であり、それこそが連帯を拡大していく。そのための道具としてのDAOこそが、本書が差し出してくれた大事な宝物であろう。

人ならざる存在のためのDAO

2018年1月に東京藝術大学で行われたニコラ・ブリオーによる公開講義は、ある印象的な挿話から始まった。

ブリオーは、ニュージーランドの「ファンガヌイ（Whanganui）」と呼ばれる川の紹介から講義をはじめた。この川は、マオリの人々とニュージーランド政府との闘いの結果、2017年に「生きた」存在として政府に認められるに至った。つまり、川は人間ではないにもかかわらず、自らの立場においてさまざまな主張をなしうる、一個の人格と権利をもった主体として認められることになったのである。（中略）いまや、狭義の「人間」そのものの再定義が図られなければならないということである、とブリオーは述べる。

Special Lecture Report | 沢山遼 「人新世におけるアート」は可能か？：ニコラ・ブリオー、あるいはグレアム・ハーマンの「無関係性の美学」

この挿話を枕にしてブリオーは、人間からなる文化と非人間による自然とを分ける考え方を乗り越えるアートの取り組みについて紹介するレクチャーを行ったのであった。それは、人間のみならず非人間的な存在に対してもエージェンシーを認めるアクターネットワーク理論に影響を受けつつ、従来的な考え方の枠組みを再度問い直すことである。

ところで川が「「生きた」存在として政府に認められるに至った」とは、どういう事態だったのだろうか。「先住民マオリ崇拝の川に「法的人格」認める、ニュージーランド　写真1枚　国際ニュース：AFPBB News」ではこう説明されている。

ニュージーランドの議会は15日、先住民マオリ（Maori）が崇拝する川に「法律上の人格」を認める法案を可決した。河川を法人と認める判断は世界初とみられる。

欧米諸国の判例とマオリの神秘主義を兼ね備えた法律は、ワンガヌイ川（Whanganui River）を「生きている実在物」だと正式に宣言した。クリストファー・フィンレイソン（Christopher Finlayson）司法長官は、「（ワンガヌイ川は）法的な人格と、それに付随するあらゆる権利、義務、法人としての法的責任を有することになる」と述べた。

先住民マオリ崇拝の川に「法的人格」認める、ニュージーランド　写真1枚　国際ニュース：AFPBB News

The New Zealand river that became a legal person - BBC Travelによると、「世界初」ではないということのようであるが、ともあれ自然を「法人」とみなすというのは驚くべき事態である。そのような取り扱いによっていったい何が起こるのか、非常に興味を引かれるところである。そしてそれは、具体的にこう述べられている。

法律に基づき、実際面ではマオリ側と政府側をそれぞれ代表する弁護士2人が代理人として法的手続きを行い、ワンガヌイ川の利益を守っていくこととなる。

また、ワンガヌイ・イウィには政府から、長期に及んだ裁判の損害賠償として8000万ニュージーランド（NZ）ドル（約63億円）と、川の環境改善費用として3000万NZドル（約24億円）が支払われた。

同記事

もちろんこのような任を担うのであるから、善良な人々なのであろう。環境保護にはお金もかかる。現に、少なからぬお金が環境改善費用として支払われたということではないか。ではその使い道をどうやって公共に資する形で決定するのか。それをどのように透明なプロセスにおいて実施するのか。そして、必ず訪れる「腐敗」に対してあらかじめ対処する術はあるのか。本書が述べる通り、このような事態こそ、まさにDAOが登場するにふさわしい。

私たちの「メタ国家」への旅路は、こうして人ならざる存在をも包含する「人権」意識へと、自らを「感情教育」しおおせた。「パブリックチェーンや「世界との契約」もデジタルネイチャーの一種であると認識している」（p.229）と述べる著者ならば、ネイチャーそのものを「法的な人格」へと練り上げていくようなデジタルテクノロジとしてのDAOの利用もまた、デジタルネイチャーの一つのあり方だと認めることだろう。

私はかつてこんなことを書いた。

放っておくと疲れてしまう、愛らしい「物」たちの声を耳を澄ますこと。物自体に内在する力という仮想的な認識を通して、我々の認識は社会へと開かれていく。それは、よりよいシステムを作り続けることにつながるかもしれないし、物を大事に扱うということにつながるのかもしれない。ひいては、大きくいえば社会をよくするということだ。そうした物を通しての社会への開かれを、エコロジーと呼んでみたい。目の前の物たちが「疲れてしまう」ことを真剣に受け取ることから、それは始まる。

アリストテレスを真剣に受け取る：「物」を通じて社会へ開かれるエコロジー｜栗林健太郎

いまならばこれを、DAOという道具に基づいて語り得るだろう。すなわち、DAOを通じて社会をより良く見通せるようになった私たちは、私たちの「人格」の外縁が、侵されるべきでない「人権」を有する人間としての他者のみならず、非人間たる「物」たちへも拡がっていくということだ。DAOは、そうした「他者」の声をよりよく聞くための道具でもある。

引用文献

1. 落合渉悟『僕たちはメタ国家で暮らすことに決めた』
2. 「WIRED（ワイアード）VOL.44」
3. 【取材】ブロックチェーンで民主主義の改善を目指す、DAOアプリ「Alga」発表（落合渉悟 インタビュー） | あたらしい経済
4. 齋藤純一『公共性』
5. 御厨貴他・編『舞台をまわす、舞台がまわる - 山崎正和オーラルヒストリー』
6. イヴァン・イリイチ著、渡辺京二他訳『コンヴィヴィアリティのための道具』
7. 古瀬幸広、広瀬克哉『インターネットが変える世界』
8. 大賀祐樹『リチャード・ローティ―1931-2007 リベラル・アイロニストの思想』
9. リチャード・ローティ著、斎藤純一他訳『偶然性・アイロニー・連帯: リベラル・ユートピアの可能性』
10. Special Lecture Report | 沢山遼 「人新世におけるアート」は可能か？：ニコラ・ブリオー、あるいはグレアム・ハーマンの「無関係性の美学」
11. 先住民マオリ崇拝の川に「法的人格」認める、ニュージーランド　写真1枚　国際ニュース：AFPBB News
12. The New Zealand river that became a legal person - BBC Travel
13. アリストテレスを真剣に受け取る：「物」を通じて社会へ開かれるエコロジー｜栗林健太郎

13日目はわたくしの「mix upload.hotswap (kentaro/mix_tasks_upload_hotswap)の裏側」でした。2日連続の登場です。

『プログラミングElixir 第2版』をご恵贈いただきました。ありがとうございます。ちょうどElixirについて学び始めたタイミングでの刊行で個人的にとてもタイムリーなこの本について、本記事で簡単に紹介します。結論だけ先にいうと、プログラミング言語についての本としても読み物としてもとても面白いので、ぜひ広く読まれたいと思います。

Dave Thomas・著、笹田 耕一＋鳥井 雪・訳『プログラミングElixir 第2版』

Elixirとわたくし

前述の通り、この記事は#NervesJP Advent Calendar 2020向けに書かれるものです。Elixir本の紹介記事なのでNervesのカレンダーに書くのはカテゴリエラーのようですが、自分自身にとってはElixirとNervesとは切っても切り離せないものなので、こちらに書いています。

Elixirの存在自体は（わたくしはRubyistでもあるので）2012年のリリースの頃から知ってはいたものの、それ以上深入りすることなく2020年秋まできてしまいました。2020年11月13日に行われた「第7回WebSystemArchitecture研究会」でNervesというものについて語られており、それはわたくしの関心に近いものである旨を、参加した研究所の同僚から教えてもらいました。それを見た瞬間「求めていたのはこれじゃん！」とピンときて、その週末は連日明け方まで調べたりコードを書いたりデバイスをいじったりしました。公開されたその時のお話のスライド（@zacky1972先生による「Nerves on Cloud (Japanese edition) 」と、@kikuzokikuzoさんによる「Elixir/NervesHubによるエッジコンピューティング環境実現に関する検討」）も素晴らしく、それからはすっかりElixir漬けの毎日で、急速に夢中になりました。何がそこまでわたくしを夢中にさせたのでしょうか？

Elixirとこれからの世界

インターネットサービスのエンジニアをやってきた中で、わたくしが関心を持ってきたことのひとつに、いかにシステムを更新し続ければいいのかということがあります。特にOSSに強く依存する昨今のシステム開発においては、エコシステムと歩調を合わせていくことが求められます。さらには、IoTのようにシステムが現実世界にはみ出していくようになると、エコシステムとの共存にはまた別の難しさが現れてくるでしょう（そもそもアップデート自体が大変だし、一様なサーバ群とは異なる多様なデバイスが存在することになるから等の理由）。4月から通っている大学院では、そのあたりを研究したいと思っているところです。

そういう関心からしても、ElixirやNervesには興味深いことがたくさんあります。NervesHubという仕組みによるOTA（Over The Air）アップデートを可能にする仕組みがあります。また、Elixir（とErlang）という言語のあり方そのものに対して、温故知新的に（？）まさにいま求められているものじゃないかという気づきを得たりもしました。すなわち、@takasehideki先生による以下の図の通りです。

!

「ElixirでIoT！？ナウでヤングでcoolなNervesフレームワーク」p.21

昨今は、microservicesだとかなんとかで、ひとつのホストという制約を超えたコンピューティングが、これまでとはまた別のあり方で発展しつつあるように思われます。上図などはまさにそういうことを表しているのでしょうし、自分の関心的にも取り組んでいきたい領域です。そういう関連もあって「mix upload.hotswap (kentaro/mix_tasks_upload_hotswap)の裏側」という記事にも書いた通り、デバイスの開発効率向上という観点からのHot Code Swappingの応用についてもやってみたりしているところです。

そんなわけで、自らの関心に基づくやりたいことに対しての助けになりそうなNervesからElixirに入ったのですが、Elixir（とErlang）そのものにももちろん強い関心を持っています。それで各種ドキュメントを読んでいたところ、本書がちょうど刊行され、しかもいただけるという光栄に浴すことになったわけです。みなさま、本当にありがとうございます。ご縁ですね。

著者について

著者のデイブ・トーマスさんはThe Pragmatic Programmers, LLC.（PragProg）の共同創業者。これまで刊行された著名の書籍をあげるだけでも、綺羅星のような名著ぞろいというすごい人です。多くのプログラマが「この1冊」に挙げる『達人プログラマー』、原著第1版は1999年に刊行された浩瀚な『プログラミングRuby』、いまも版を重ねるAgile Web Development with Rails（邦訳はもはや追いついてないので原著へのリンク）といった書籍や、アジャイルソフトウェア開発宣言への署名者としてアジャイル開発プロセスの推進者としての活動を通じて、この20年以上の我々の業界でいまや当たり前になったプラクティスを作ってきたひとりです。その彼が2014年に刊行したのが本書の第1版で、それを著者が2018年にアップデートしたのが本書の原著です。

そういうひとが書いた本ですので、一筋縄ではいきません。著者も「はじめに」で書いている通り、あの巨大な『プログラミングRuby』とは明確に異なるアプローチで、Elixirという言語の良さが、時には著者の個人的な好みも色濃く織り交ぜながら書かれています。そんなわけで、本書はプログラミングそのものが初めてのひとよりは、なんらかの言語による経験がそれなりにあるひとの方が楽しめるだろうと思います。そういうひとにとっては、達意のプログラマによる目を開かされるような創見が豊富な本書のような本を、他の言語との比較において楽しめるだろうからです。

赤いカプセルをとれ

「純粋で正確」な関数型言語を検討はしたものの魅力を感じなかったという著者は、Elixirに「不完全な世界」を容れる包容力がありながら純粋な関数型言語とは異なる「実用的なクオリティ」を見出し（本書386〜387ページ）、この本をのっけからこんな感じで始めます。

赤いカプセルをとれ

本書1ページ

これは、もちろん映画「マトリックス」を踏まえたフレーズです。つまり、Elixirを学ぶというのは「世界に対する見かた」を根本的に変えるということなのです。オブジェクトの持つ状態を更新することが眼目となるオブジェクト指向言語の前提とする世界に対して以下のように宣言します。

でも、これは現実の世界ではない。現実の世界では、抽象的な階層構造をモデル化したいわけではない（なぜなら、実際には、真の階層構造なんてそう多くはないからだ）。私たちは仕事を済ませてしまいたいのであって、状態を維持したいわけではない。

（中略）

あなたの世界へのまなざしも、オブジェクト指向におけるクラスの責任について考えるのをやめて、仕事を終らせる、という観点で考え始めるように、変化していくだろう。そして、たいていみんな、それは面白いって認めてくれるはずだ。

本書1ページ、3ページ

こうしてレッドピルを選び取った我々は、「ネオ」のように世界の実相（？）をデイブ・トーマス御大の語り口に導かれて、次々に見ていくことになります。

本書の特色

本書の文法事項の説明を開始する第2章は、こんな文章でまとめられます。

ErlangのクリエータであるJoe Armstrongは、Erlangでの等号記号を、代数での等号記号の使われ方にたとえる。

（中略）

彼のいいたいことはこうだ。はじめに手続き型プログラミング言語の代入と出会ったとき、代数的な = の意味を忘れなければならなかった。今はそれをさらに忘れるときだ。

本書20ページ

よくあるプログラミング言語が文法解説が変数や代入文のような基本的な事柄から始まるのに対して、本書はパターンマッチから始まります。Elixirの=はその見かけに反して代入文ではなく、関数型言語では広く見られるパターンマッチを意味します。それは、x = 1みたいなよくある代入に見えるようなパターンマッチにもなりますし、タプルやリストのようなより複雑な構造をマッチさせたり、さらには関数の引数をパターンマッチさせることで、引数に応じた同名の関数宣言を複数書くことだってできます。

ただまあ、そこまでだとオブエジェクト指向言語ではなく関数型言語がいいよという話に過ぎないようにも思えます。そういう話ならもう聞き飽きたというひともおおいでしょう（とはいえ、それはそれで面白い話題がたくさんあるのですが）。やっぱりElixirが面白いのは、そういう話はもとより、Erlang由来のプロセスやOTPだろうと思います。というわけで、文法事項の説明は400ページほどあるこの本の半分で早々にまとめられ、その後はErlang VMのパワーを存分に活用するためのあれこれに話題が移ります。

Elixir（もちろんErlangでも）では、とにかくいろんなことにプロセスが使われます。本書では、フィボナッチ数列を計算するプログラムだって、プロセスを使って実装します。この、「プロセスで考える」ということこそが、本書がわたくしたちの世界への見かたに対して大きく変更を迫る本質的なポイントであるように思えます。

ほとんどのまともなElixirプログラムは、本当にたくさんのプロセスを使う。そして、だいたいにおいて、プロセスの生成と管理を、オブジェクト指向プログラミングでオブジェクトを生成・管理するのと同じ具あり気楽に行う。でも、この考え方を学ぶには、もうしばらくかかるだろう。粘り強く行こう。

本書216〜217ページ

このように幅広く、気軽に使われる大量のプロセスを用いて、いかにして現実の要求を満たす堅牢なシステムを構成していくのかという話題について、しばらく話が進みます。すなわち、GenServerによるOTPサーバ、スーパーバイザ、OTPアプリケーションなどです。それらが何なのかについてはここでは説明しないので、ぜひ本書を買って読んでみてください。これらこそが、先に書いた通り、これからのインターネットのシステムアーキテクチャにとって「これじゃん！」となっていくポイントなんじゃないかと思います（そこではNervesが大きな役割を果たすことになるでしょう）。Erlangって1986年に作られた言語なんですよね。そんな歴史のある言語が、いまこそ未来を指し示しているように見えて、ドキドキします。

本書の記述はさらに続いていくわけですが、個人的に特によかったのはプロトコルや型仕様についての説明です。ドキュメントを一読しただけだと全然理解できなかったのが、スッと入ってきました。また、付録Dの日本語版の特典「Elixir 1.6以降の状況と開発運用の実際」も素晴らしいです。本書はElixirがバージョン1.6の時の本なのですが、そこからキャッチアップできる情報が簡潔にまとめられています。とはいえ、かといって本文の方が古いかというとまったくそんなことはないので、ご心配なく。

翻訳もとても練られており、考え尽くされた様子が目に見えるようで、非常に素晴らしいです。第25章の原題はMore Cool Stuffというのですが、それが「かっこいい機能いろいろ」とそれこそCoolに端的に訳されていることに象徴される通り、読みやすさと理解しやすさに繊細に気を配っていることが察せられます。よい翻訳者を得た幸せな本ですね。

おわりに

最初に書いた通り、最近はとにかくElixirにハマりきっているのであれこれと書きたいことはあるのですが、既にこの記事もだいぶ長くなってしまっているので、このへんで終わりにしようと思います。

デイブ・トーマスさんについて「この20年以上の我々の業界でいまや当たり前になったプラクティスを作ってきたひとりです」と紹介しましたが、ことElixirについては、まだそこまでの事態になっているようには思われません。いずれそういうときも来るのでしょうか。みなさんもこの機会にElixirを始め、「赤いカプセル」を選択して、世界の真相を探す旅にでましょう。

Dave Thomas・著、笹田 耕一＋鳥井 雪・訳『プログラミングElixir 第2版』

#NervesJP Advent Calendar 2020の15日目は、@torifukukaiouさんの「グラフうねうね (動かし方 編) (Elixir/Phoenix) 」です。続けてお楽しみください。

技術そのものの話については、今年は#NervesJP Advent Calendar 2020あたりに書いていっていますので、そちらをご覧ください。Elixir/Nervesめちゃ面白い！！

それはそれとして、エンジニアとしての自分自身にとって今年一番大きなインパクトがあったできごとはなんといっても大学院に通い始めたということだったので、その話をします。

これまでの大学院での活動

「北陸先端科学技術大学院大学先端科学技術研究科博士前期課程に入学しました」というポストに書いた通り、2020年4月から北陸先端科学技術大学院大学（以下、JAIST）の東京サテライトで、社会人学生をやっています。東京サテライトの所属ではあるものの、品川にあるキャンパスには2回しかいってないので、授業もゼミもほとんどオンラインという状況です。新型コロナウィルス感染拡大の第3波がきている（？）現状ですので、おそらくは2021年3月まで、1学年まるまるオンラインになりそうな気がしています。

4月に入学してからこれまでは、講義を受講して単位を取得することが主な目的となる活動をしていました。必修込みで20数単位ぐらい（はっきりとは認識していない）を取る必要があります。また、情報科学の学位を取るには、当たり前ですが情報系の単位を多く取る必要があります（知識科学系というもう一方のコースの単位も、ある程度まで認定されます）。そのあたりの話は、JAIST東京サテライトの名人物である白山さんが「働きながら修士課程1年目を終えて - 怠惰を求めて勤勉に行き着く」というポストにいろいろと詳しく書いていらっしゃるので、そちらをご覧になるとよいかと思います。

その他に、指導教員によってやり方が違うとは思いますが、わたくしの配属された研究室では、毎月1回のゼミがあります（また、研究室のSlackワークスペースもあり、そちらでも交流しています）。はじめの頃は特に話せることもなく、先輩方の進捗報告を聞いたりするぐらいでしたが、最近はM1のわたくしたちも、少しずつ何か話す感じになっている状況です。2020年3月には、修士論文の研究計画を出す必要があるため、先生や先輩方にあれこれと相談をしていきたいと思っているところです。

2020年の社会人学生生活

来年以降入学する方々には参考にはならないかもしれないですが、1年を通してオンラインで講義を受講できたのは、単位取得という観点からいうと、例年よりだいぶ楽なのではないかと思います。まず、そもそも通学しなくていいのが楽ですね。また、情報系の授業だと期末試験を失敗したらそれ一発で単位を落とすということも多かったようですが、試験の代わりに宿題やレポートを課されることも多く、一発勝負よりはだいぶ楽になりました（宿題やレポートは、それはそれで分量的には大変ではありますが）。

社会人学生ということで、仕事と学業との兼ね合いをどうするかが課題になるのは間違いありません。とはいえ、できることはほとんどありません。仕事は仕事で普通にやってますし、それに加えて学業分の時間が必要になるので、可処分時間はだいぶ減りました。特に、1年次はとにかく単位を取れるだけ取るという方針でやっているので、毎週土日は朝から夕方までまるまる授業という日々が続きます。また、前述の通り宿題やレポートも多く、それらにはかなり時間を使っていると思います（平日夜の時間に、週に5〜8時間ぐらいということもある）。まあ、がんばるしかないですね。

とはいえ、前述の通り授業がオンラインなので、やはり例年よりはだいぶ楽してるんじゃないかと思います。品川まで通うとなると、わたくしの場合、出かける準備なども含めれば往復で2時間以上はかかります。授業は朝9時20分からですので、毎週土日は8時前には起きなければならなかったでしょう。朝に弱いわたくしにとっては、かなりの苦行だったろうと思います。個人的にはやはりこの点が一番ポイントで、その意味では思いのほか楽だなという感想を持っています。いまと同じぐらい宿題とレポートがあってさらに通学も必要だったとしたら、かなりきつかったんじゃないかなあ。

本当に大変なのは「研究」

M1ということもあり単位取得にいっぱいいっぱいなので、これまでは「勉強」の話ばかり書いてきましたが、わたくしが大学院に入ったのは「研究」をするためです。とはいえ「絶対にこれがやりたい！」「この研究で世界を変えるんだ！」みたいな明確な研究テーマやモチベーションを持っていたわけではありませんでした。自分の力でやりたいテーマを見出し、それを研究としての一定の水準における成果として完成させる方法論と実績を作りたい、そのことで自分を次のレベルに成長させたいという目的を持っています。

そういう観点からすると、上述の「勉強」がいかに大変かといっても、「研究」に比べるとそんなにたいした問題ではありません。「勉強」はゴールが明確ですし、時間をかけさえすれば終わりますし、かかる時間もある程度は予測可能です（といいつつ、このポストを書く直前にも宿題をやっていましたし、期限に追われていますが……）。一方で「研究」は、そもそも何をやればいいのかというところからしてわかりません。また、どのレベルの内容であれば研究たり得るのかというのも難しいところです。単にやりたいことをやればいいというわけでもないですし（そういうやつが修士課程に行くのはどうかと思われるかも知れませんが、その批判は甘受しましょう）。

わたくしの場合は、会社でCTOと研究所の所長をやっていることもあって、会社や研究所全体としてこういうことをやっていきたいというコンセプトメイキングはやってきましたし、作りたい世界観もあったりはします。ただ、それを修士課程の研究とするには、限られた時間で実現可能な、適切な範囲にフォーカスする必要があります。また、いろいろな考えがありセキュリティ（に近い内容）についてやりたいというのもあって、会社の研究所のコンセプトと修士での研究とセキュリティ関連という特定の分野との間で、どういうことができるかを決める必要もあるという事情がありました。

そんな中で、それでもあれこれと修士課程を終了するにふさわしいと思われる研究テーマを、アイディアをあれこれと出したりしながら考えていました。それで、ある日のゼミの際にひとつアイディアを持っていって簡単に紹介したところ、「もっと問題を掘り下げるべき」だという助言を先生からいただきました。その後、ゼミの初めての懇親会があり「研究というのは世界観を持っているべきだ」という話もいただきました。そういう観点からいうと、自分の持っていったアイディアは、たしかに単にできることをやろうとしているだけで、世界観、つまりこうありたい、こうあるべきだという自分のアイディアや思想の表現にはまったくなっていませんでした。

それからまた、研究テーマについて思いあぐねる日々が続きました。そんな中で、現状がこんな感じというのを、以下のツイートのスレッドで書いたりもしています。これはこれで、後に「あの時は大変だったけど乗り越えたなあ」と振り返られることを願って、記録として書いておいたものです。

https://twitter.com/kentaro/status/1331556327638802432

そんなことを書いているいまも、なんとなくやりたいことが見えてきたとはいえ、それが果たして修論としての研究にふさわしい「世界観」を持っているのか、そしてそれ以前に、そもそも自分にとって実現可能なのかどうかすらもわからない状況です。そのようなもやもやした考えを、浮かべては消すことを数ヶ月繰り返しているのは、かなりストレスフルな状況であるとは思います。「他の人々はどのようにして研究テーマを決めているのだろうか？」ということもよく思います。しかし、研究所の皆さんを見ていると、それぞれに研究テーマをこれと決めるまでには、かなり苦労をしています。そういうものなのでしょう。

なんだか、やたらネガティブな感じに読めるかもしれませんが、これがわたくしが大学院に求めていたことなのです。自分が本当にやりたいことを見つめ、しかし単に自分の興味関心だけでなく、アカデミズムにおける基準に従って自己の成果を判定し、さらには社会にとって役立つような新しい何かを生み出すこと。わたくしは、自らが何か成し遂げたいという強いモチベーションみたいなものを持っていません。それでも生きる上での課題の解決はできますし、ひとの役に立つこともたまにはあるでしょう。しかし、この先にもう一歩踏み込んで進むためには、そのような自分を変えていかなければならない。そう思って取り組んでいるところです。

おわりに

今年の4月に入ったJAISTでの社会人学生としての生活と、その中で感じたこと、いままさに大きな課題になっていることについて述べてみました。そして、この課題を乗り越えたあとに、さらに研究そのもののプロセスにおいてまた壁にぶち当たることが目に見えています。それもまた自分が望んだこと。楽しんでやっていきたいと思います。

4日目はminneのEngineering LeadでAndroidエンジニアのまたくによる「minne Android アプリ開発基盤における改善」です。続けてお楽しみください。

まず前提として、学ぶ対象の「新しいこと」とは何かについて述べておく。ここでいう新しいこととは、研究やイノベーションに関することではない。そういうのは、ググっても出てこないレベルの新しさなので、このエントリで述べる対象ではない。ここでいっているのは、自分にとって新しい知識であり、かつ、既に一定の蓄積があるような内容のことである。

それをひとことでいうと、入門書があるような領域ということになる。たとえばプログラミング言語はメジャーなものはたいてい当てはまるし、DockerとかKubernetesのような技術要素も入門書があるし、もっと広く学問一般についても当てはまる定義である。

さて、さっそくどうやって学ぶかを順番に書いていく。

1. 新しく学びたい領域について、入門書を5冊〜10冊ほど買う（技術書なら1万〜2万ぐらいか）
2. ひとつひとつを精読するのではなく、ただ文字を追うぐらいの感じでわからないところは読み流しつつ、読み切る
3. 1冊1時間と時間を決めて、必ず時間を守る
4. 本を読んでいる時にコードを書いたりコマンドを実行したりなど、試したりすることはしない。ただ読むだけ
5. それを、買った冊数分（5冊〜10冊）くりかえす。そうすれば5時間〜10時間、すなわち1日で学習できる
6. 上記により、その領域の入門的な全体像は頭の中に入るので、あとは簡単なタスクについて手を動かしながら、公式ドキュメントなどを読みながら自分で進める

この方法のポイントがいくつかある。まずは上記しているように、とにかく何冊も読むということと。そして、読み流すということ。そのことで、まずは当該領域に関する入門レベルの全体像をつかむ。よくある失敗は、全体像をつかむことなく細部から入るから起こる。細部から入ると学習が遅いし、行き詰まって嫌になる。これが一番のポイント。

1冊1時間と決めて読むのもポイント。だらだら時間かけてないこと。スプリントを区切って、とにかくたくさん読む。良い入門書1冊を繰り返して読めばいいのでは？と思うかも知れないが、1冊を繰り返すと飽きる。だから、何冊も読む。本を読むのが苦手でも、1冊1時間と時間を決めて単に目を通すだけなら、実行できる可能性が高まるはず。

また、入門書をたくさん読むと、同じようなことでも違う切り口で書いてあるので飽きないし、ある本ではわからなくても、他の本ではわかりやすい説明があったりして、挫折しにくい。

いまどきだとWebサイトや動画でいろんなことが学べるのだが、あえてネットのリソースは使わない。なぜか。上記したように、入門的な全体像を記したひとつの塊としての情報を時間を区切って読むことと、同じようなものを何度も読むことが重要だから。Webサイトや動画だと部分的なものが多いし、時間の区切りをつけにくい。だから書籍を読むことが必要なのである。

入門書として何を選べばいいのか？ 評判はあまり気にしないこと。ひとのお薦めに従うのはいいけど、1冊に決めないこと。なぜなら、入門者なんだから評判なんてわからないし、薦められた本が良いかどうかもわからない。だまって書店やサイトで検索して出てきた本を、端から買えばよい。ただ、学問的領域なら研究者が書いてる本がよいだろう

初学者にとっての敵は、学習に飽きること、わからないことにつまづくこと。なぜそうなるかというと、全体像がわかってないから。まずは、当該領域において入門レベルではこのあたりのことが語られているのだなあということを把握する。何冊も読んでいると、だんだんその領域についてきいたことがない話がでてこなくなる。10冊読めば、知らない話はまったく出てこなくなる。そうなったら独力で勉強できるようになったサイン。あとは、実際の課題に基づいて深く学んでいけばいい。

自分自身の経験でいうと、たとえば「実際に読んで選んだマネジャーのための100冊 - Kentaro Kuribayashi's blog」で書いたように、マネジメントを担うことになった時にこの方法を実践した（マネジメントといっても幅広いので、サブジャンルごとに何冊も読んだ）。最近では、機械学習や数学について同じことをしている。入門書を何冊も読んで入門レベルの全体像を得た後に、実際に手を動かして学習している。効率的に学べていると思う。

学習に対して投資したいなら、最初の時間に投資すべし。その時間を買うこと、なによりも飽きたりつまづいたりして学習が止まってしまうぐらいなら、1万〜2万など安いものだ。お金はそういうことに使いましょう。

JAISTは、本校は石川県の能美市にあるのですが、品川に東京サテライトがあり、わたくしはそこの所属ということになります。研究面では、篠田陽一先生に主研究の指導を仰ぐことになりました（といっても、まずは所定の単位を取得することが先決ではありますが）。

ただ、新型コロナウィルスのこともあり、授業もゼミもオンラインであるため、入学してからは一度もキャンパスに出向いておらず、誰ともお会いできていない状態です（追記: この記事を書いた翌日に、ゼミへの参加のために初めて品川の東京サテライトへ出向くことができました）。

なぜ社会人学生になったのか

わたくしのキャリアについてはホームページにあれこれ書いていますが、ひとことでいうと1999年に法学部政治学科を出た後にいろいろあってインターネットサービスのエンジニアになり、12年ぐらいこの業界でやってきました。そんなわけで、少なくとも部分的にはそれなりに勉強したとは思いますが、情報科学について専門的な訓練を受けたわけではありません。

そのままやっていくというのも可能ではあったのでしょうけれども、最近は研究所の所長などもやっていて、そのような立場として自分自身が学位を取る必要があると考えたのが、進学を決めた一番大きな要因です。研究所もメンバーが増えてこの先ますます専門化していく中で、研究所のディレクションや研究員との協働をより高いレベルで行っていくには、自分自身もその道でなにかしらの達成はしておくべきだろうということです。

わたくしの所属するペパボ研究所では「なめらかなシステム」というコンセプトを大枠に基づき、各自がそれぞれ研究活動を進めています。研究員の奮励努力により研究開発成果のレベルも年々上がっています。そんな中で、わたくしがアカデミックな達成やアウトプットがない状況では、大まかな方向性をディレクションすることはできても、もっと具体的なところで適切なレベルで協働することは難しいと感じてきました。

ざっくりそういうわけで、自分自身もチャレンジしてみることにしたわけです。

なぜJAISTで博士前期課程なのか

まず、先述の通り、わたくしは1999年に法学部政治学科を卒業した、文系学士です。その後いろいろ経験した後、大学院では勉強をしたいというよりは、自分の研究をひと通りやってみたいという気持ちがあります。なので出願資格を通して博士後期課程に行くという道もありえたわけですが、それは止して博士前期課程から行くことにしました。

そもそも、研究に関する実績が不足していること、博士後期課程で取り組むにふさわしい研究計画がまだ作り上げられてなかったこと、出願資格の日程的な問題でもし通ったとしても入学が1年遅れることになること等の理由がありました。また、博士後期課程は正直やりきれるかわからないので、まず博士前期課程を確実に終了して修士の学位を取るのが、なにかしら形に残る可能性が高いと判断したということもあります。

JAISTを選んだ理由ですが、まずは形式的な要件として、以下の条件を満たすことを前提としました。

1. 社会人学生としての入学なので、可能な限り土日に授業を受けられること
2. 情報科学に関する研究を、博士後期課程への進学を視野に入れた上で行いたい（修論指導できる体制と博士後期課程もあることが必要）
3. 通学場所は、時間的な関係でできるだけ東京都心に近い方が望ましい
4. できれば学費が相対的に安い国立・公立が望ましい

その前提で考えた時に、いろいろ調べた結果、実質的に東京においてはJAISTしか選択肢がないように思えました（私立だともうちょっと選択肢はあるのかもしれませんが）。その要件を満たす学校は他にもあるかもしれませんが、見つけられませんでした。

選んだ理由のうちの内容的な要件については、ホームページで先生方や研究テーマを眺めてみたところ、情報科学に関する様々な分野への取り組みや実績が豊富で、ここならだいじょうぶだろうと思えました。また、これが一番大きかったのですが、知人やインターネットで知っている人々にJAIST出身者が多くいたこともあります。特に@hirolovesbeerさんには研究室もご紹介いただいたり等、大変お世話になりました。

JAISTへの入学に至る経緯

ここ数年、先述の理由により、情報科学に関する学位取得へチャレンジしないとなあと思ってはいたのですが、いろいろ些事にかまけて取り組めずにいたところ、昨年（2019年）の11月頃になんとなく大学院について調べていたところ、興が乗ってきて「今度こそやろう！」という気持ちになり、その勢いで受験までいったというのが実のところです（ここ数年、秋頃になるとあれこれと大学院のことをおもむろに調べたりしていたということはありました）。

それで、JAISTの出願要項を調べて必要な書類をそろえ、簡単な研究計画のようなものを書いて、先述の@hirolovesbeerさんに相談してみました。そうしたところ、様々なアドバイスとともに研究室についてもご紹介いただき、ゼミにお邪魔する手はずまで整えていただきました。とりあえず出願だけは済ませておいて、ご紹介いただいた篠田先生にメールしたり、12月にゼミにうかがったりして、1月11日に試験を受けました。

受験は、出願時に提出した「本学入学後に取り組みたい研究課題について」という簡単な研究計画を述べた小論文について、3人の先生方の前で発表するというもので、以下のスライドを用いて行いました。

speakerdeck.com

（小論文とかあれこれの書いて提出したものを、自分としては公開してもいいのですが、出していいものかわからないのでスライドだけにとどめておきます）

このスライドで述べている内容も、だいぶぼんやりとしたものではあったので、あれこれと質問をいただいたのですが、あんまり研究内容そのものについての話にはならず、周辺的な内容が多かったように思います（「ほんとにこの研究をしたいと思っているのですか。何か他にやりたいことがあるのではないですか」とか「学部時代の得意科目として日本政治史があげられていますが、勉強したことについて短くまとめて答えてください」とか）。

（なぜそういう話になったかというと、エントリーシートのようなものに学部時代の得意科目を書く欄があったのですが、先述の通りわたくしは法学部政治学科卒なので、いま得意なことでいえば情報工学的な内容を書けますが、科目として受けたわけではないので学部時代のことを書くしかなかったわけです）

そんなわけで面接の手応えとしてはだいぶよくない感じで、だめだっただろうなあと思っていたのですが、2週間ほど後に合格通知をいただき、入学できることになったのでした。きちんと研究をして、「あのときのやつはちゃんとやってんだな」と思ってもらえるような成果を上げてご覧に入れたいと思っています。

研究テーマについて

上述のスライドの通り、入学を検討していた時期には、OSSによる生産性向上とセキュリティ担保の両立というテーマで研究をしようと思っていたのですが、入学後にあれこれ考えた後、ちょっと違うこともするかもしれないなあと思っています（もちろん、これはこれで強い関心があるので進めたいとは思っています）。

先述の通り、わたくしの所属するペパボ研究所では「なめらかなシステム」というコンセプトで研究を進めているわけですが、自分自身の大学院での研究も、もっと直接的にそのコンセプトに沿ったものにしたいなあと思い始めました。そこで、コンセプトを実現するに際しての研究所の具体的な主要テーマのひとつであるセキュリティ（具体的には昨年@monochromegane研究員や前述の@hirolovesbeerさんと共著した「なめらかなセキュリティ」に関すること）や、情報推薦あたりにも取り組みたいなあと考えているところです。

Webアプリケーションを取りまく、利用者、開発運用者、情報システムの間で行われるコミュニケーションをなめらかにするべく、自社のサービスで蓄積された行動ログによって分析・学習したモデルを用いて、サービスで課題となっているセキュリティ対策や情報推薦等に適用するみたいな内容にしようかなあとも考えたりしているところです（そもそもいろんな基礎知識が足りてないので、いま必死に勉強している状況です）。

JAISTへの入学を考えている人々へ

わたくしはつい数ヶ月前に入学したばかりなので、もしかしたらこれから挫折するかも知れないですし、そもそもまだ学校のこともよくわかっていないために、おすすめしたり助言したりするようなことはほとんどありません。しいていうなら、入試の面接は（少なくともわたくしの時は）ガッツリつっこまれたので、その心づもりで準備しておくほうがいいかもしれません。あとはまあ、JAISTは入るのは相対的に簡単なようですが、授業は普通に大変だし、（まだ取ってないのでわかりませんが）学位を取るのも大変なんだろうなあと思います。

それはともかくとして、冒頭に書いたとおり新型コロナウィルスの関係で、入学してからまだ一度も東京サテライトに出向いてないという状況で、授業もずっとオンラインです。そうなるといろいろとわからないことやイレギュラーなことがあったりするのですが、とはいえ周りに直接聞ける人もいません。しかし、有志によるSlackワークスペースが運営されており、そこでずいぶんといろんな人々に助けていただきました。オフラインの交流があっても、その有用性は減じないでしょう。これからはいる人々にとにかくいいたいのは、Slackワークスペースに必ず入りましょう！ということです。

おわりに

数ヶ月前に入学したばかりで、まだ研究テーマもはっきりとした輪郭ができたわけでもないので、いまはまだ前途多難な状況です。4学期制の1学期目が終わりそうな段階で、まだ1単位も確定していないので、勉学という意味でもどうなるかわかりません。そのため、この先どうなるかは全然わかりませんが、ともあれなんとか食らいついてまずは修士の学位取得を目指します。その後、心変わりしなければ博士後期課程にも進みたいと思っています。

43歳にもなって、いまはまだ何も達成していないわたくしです。そろそろ少しばかりでも何かしらを成したということを、ひとつぐらいはやってみたいと思って奮励努力するしかないという気持ちでいまはおります。

blog.kentarok.org blog.kentarok.org

今年は公私ともにうまくいかなかった。仕事面では、年初の目標を全然達成できなかったし、私生活では旅行先でもらった感染症により入院した。2019年はいったんしゃがむことによって力をつけたのだというふうに考えたいところだ。

よいこともないことはなくて、5月に結婚したり、入院して8kgほど痩せたので維持のために3ヶ月お酒を断ったりなどということがあった。

良い習慣が限られた時間におけるパフォーマンスを高める

「人間は習慣の生き物である（Humans are creatures of habit）」とは、アメリカのプラグマティズム哲学者であるジョン・デューイの言葉だという。出典にあたって確かめたわけではないので、そのフレーズのいわれている文脈はわからないため誤解している可能性は否めないものの、習慣について語る文章では頻繁に引かれる言葉であるため、多くの人々の心を捉え続けていることは確かだろう。経験的にも、悪い習慣によってこれまで無駄にしてきた様々なことが思い浮かぶし、良い習慣を身につけることが高いパフォーマンスにつながることは普通にありそうなことだ。

また、時間は誰にとっても平等であるみたいなこともよくいわれる。長い目で見れば早死したり長生きしたりするわけなので、人生スパンで平等ということはあり得ないだろうが、数年スパンで考えるとそのように認識してもそう間違いではなかろう。とすると、平等に流れる時間においてこれまでよりもパフォーマンスを高めるためには、（1）時間の内訳を変えること、（2）能力を高めることで時間効率を高めること、のふたつしか選択肢がない。（1）の方策はつまり、他のことを犠牲にしてがんばるということになる。これは採り得ない選択肢であるため、（2）を選ぶしかない。

上記した人口に膾炙したフレーズを敷衍して述べると、すなわち、限られた時間においてパフォーマンスを高めるには、良い習慣を身につけることによって時間効率を高めることで、実質的な能力向上を実現する必要があるということになろう。では、どうしたらそのようなことが可能なのか？

Habitifyという習慣化支援アプリの簡単な紹介

Habitifyというアプリがある。ひとことでいうと、習慣を継続することを支援してくれるアプリである。プラットフォームとして、iPhone、Android、MacおよびWebをサポートしている。たいていの人はスマートフォンで利用するだろうから、使用する環境として問題はないだろう。習慣化を支援するアプリは類例が多数あるが、それらの話や比較に基づくレビューはここでは行わない。これまでいろんなものを使ってきたが、そのどれについても挫折を繰り返してきた。Habitifyのみが、いまこうして紹介を書くぐらいには、アプリの利用そのものが習慣化した初めての例であると述べるに留めておく。

わたくしは、このアプリを使い始めて初めて、習慣を継続するということができるようになってきていると感じている。なぜそういうことが起こったのか？確かに、Habitifyは非常によくできたアプリだと思う。UIはきれいだし、インタラクションは小気味よい。サポートは（英語ではあるものの）非常に親切で、エンゲージメントが明らかに上がったのを自分でも感じるし、課金体系としてサブスクリプション型を基本的にはとっているものの、4,800円払えばすべての機能を払い切りで使うことができるのもよいところだ。しかし、アプリの出来そのものについても、この記事ではこれ以上述べることをしない。Habitifyを使うのを勧めはするが、重要なのは習慣をみにつける考え方とツールの使い方にあるからだ。

多くの人々が習慣をどうしても継続できない理由

習慣とはなんだろうか？たとえば、英語を流暢に話せるようになりたいひとは、目標を達成するためにやるべきことを英会話のレッスンに通うだとか英語学習のプロセスを単語を憶えるだとかに分解し、それらを習慣化するべきタスクとして認識し、継続を試みるだろう。そのこと自体に、問題があるようには思えないし、習慣としたいタスクを計画している時は、いまよりもパフォーマンスの高まった自分を想像して希望に燃え、きっと今度こそは継続するという決意を高める。しかし、たいていの場合、それらのタスクが習慣として継続的にこなされることはない。いったいなぜなのだろうか？

ひとは常に選択の岐路に立っている。朝、起きなければならないという気持ちと、もう少し寝ていたいという気持ちが葛藤し、そのいずれかを選択する。そして、多くの場合、望ましくない選択肢、すなわち二度寝することを選んでしまう。習慣としたいタスクを実行しようという局面でも同じことが起こっている。「英単語を30個憶える」というタスクを目の前にして、なんかお腹が空いてきたからご飯を食べてからにしようとか、Twitterが気になってしまってスマフォを眺めて時間が経過してしまうとか、そういうことの果てに、タスクを実行できずに一日が終わるのだ。

選択肢があるということが問題の根源である。習慣にしたいタスクとそれ以外の行動という選択肢があり、無意識のうちにそれらを比較考量し、易きに流れてしまう。しかし、そのこと自体は人間の本性に基づく行動であり、容易に変えることはできない。にも関わらず、できもしないのにひとは怠惰な自分を変えなければならないと、誤った課題の解決に取り組んでしまう。繰り返すが、問題は選択肢の存在そのものであり、怠惰な方向に流される自分ではない。すなわち、選択肢の存在、発生そのものにアプローチしていかなければ、習慣が身につくことはない。

習慣化を阻害する「選択肢」をなくすための思考放棄

では、どうやって選択肢自体をなくせるのだろうか？たとえば最近流行りのコーチ付きトレーニングを行なうサービスも、選択肢をなくす方法のひとつである。すなわち、契約したトレーナーが毎日のように事細かに激詰めすることで、習慣の継続以外のことをする選択肢をできるだけ減らすというサービスを提供しているわけだ。しかし、えてしてそういうサービスには多くのお金が必要である。そのため、お金が尽きたらまた、元の木阿弥となることも多いと聞く。サステナブルな習慣継続のためにはどうしたらよいのだろうか？

落合陽一氏が、かつてこういう内容のことを書いていた。いわく、自分のGoogleカレンダーの予定は、周囲の人々に登録権限を明け渡しているため、自分でも知らない間にどんどん追加されていき、彼はただひたすらカレンダーの予定を上からこなしていくだけなのだと。これはつまり、この記事における文脈でいうと、どのような予定を立て、こなしていくべきかという選択肢をなくしていくということである。そして、登録されている予定をただ上からこなしていくためには、選択肢をなくし、かつ、思考放棄をする必要がある。行動の契機を、完全に外部に明け渡してしまうというわけだ。

我々もまた、彼の方法を取り入れ、考えることをやめよう。まず、やるべきことをリストアップしていくこと。そして、ただ上からひたすらにそれらのタスクをこなしていくこと。ポイントは、ツールの言いなりになるということである。下手の考え休むに似たり。ありもしない選択肢を幻視し、あたかもそれらを比較考量し主体的に考えているつもりで、ひとは誤った道を選んでいく。そして、いつまでたっても習慣は継続しないし、パフォーマンスは低空飛行だ。どうせ無駄なのだから、考えることをやめよう。

思考放棄を支援するツールとしてのHabitify

では、上記の考えに基づいて、具体的にHabitifyをどのように使っているのかを見ていくことにする。以下が、わたくしのHabitifyに登録しているタスクリストである（左から右へという順番で画像を配列している）。登録されている内容、および、順番に注意を払ってしばらく眺めていただきたい。

一見して気づくのは、「起床する」というタスクがあることだろう。似たようなものとして、「帰宅する」というのもある。このような、習慣化するまでもなく毎日行うに決まっている項目を入れるのはなぜか？これはいわゆる「アンカリング」の一種である。Habitifyでもなんでもこの手のツールは、そもそもツールを使うこと自体を習慣化する必要があるし、多くの人々は、英単語を憶えるとかいう以前に、ツールを使わなくなる。そのため、単に起きるだけでタスクを消化できるという状況にすることで、目覚めとともに「今日も一日、ツールのいいなりになって思考放棄して生きていくぞ」というマインドセットを行なうわけである。これは非常に重要なプラクティスである。

タスクの順番にも意味がある。思考を放棄するためには、ツールのいいなりになる必要があると述べた。そのためには、手にスマフォを持ち、Habitifyを見ながらただいいなりになって行動する必要がある。そのため、起きてから寝るまでの行動を順番にリスト化することで、上から順番にタスクをただこなしていくだけという状態を作る必要がある。そうしないと、またぞろ「選択肢」というやつが現れてくる。選択肢が出てきたが最後、我々は易きに流れてしまう。考える余地がないほどに、やるべきことで埋めていき、上から順番にこなすだけの一日を送ろう。そのためには順番が重要である。

その他に気づいたことはあるだろうか？Habitifyで習慣化しようといっているわりに、「〜日連続」という記載の「〜日」の日数が少ないことに気づいた方もおられるかもしれない。それもまた重要なポイントである。習慣の継続をさまたげるのは、完全主義である。習慣化を支援するアプリにはだいたいこの「〜日連続」という機能がついており、これを絶やさないために行動するという動機づけの仕組みが組み込まれている。さらには、Habitifyもそうだが、連続した日数がカレンダーなりグラフなりで一覧できるようになってすらいる。無視すべき機能である。どうせこんだけの量を詰め込んでいたら、全部こなすことなんて不可能である。完全主義の裏返しで、習慣の継続が完全でないといってやめてしまうぐらいなら、途切れたって無視すればよい。

タスクの表現にもひと工夫をこらしている。たとえば語学系タスクについて、「フランス語を聴く」、「英語を聴く」、「フランス語教材を読む」などがあるが、それらはどれも定量目標を記載していない。よくありがちなアンチパターンとして、「英単語を30個憶える」のように、定量目標を設定してしまうということがある。そして、誤った完全主義によって30個覚えなければだめだと自分を鼓舞するも、そんなことはできるはずもない自分を責め苛み、習慣の継続が終わる。ひとつもやらないぐらいなら、10個でも3個でも、なんなら辞書を一度引くだけでもマシである。そのため、タスクの達成目標をあえて定量化せずに書いている。これなら、「フランス語を聴く」はちょっとでも聴いたら達成である。なにもやらないより、ほんの少しでもやったらOKというハードルの低さが継続のポイントである。

このように、できるだけ多くのタスクを一日の時間的経過にそって順番にならべ、思考放棄してただひたすら上からこなしていくことで、習慣を継続していっているわけだ。しかし、完全主義は敵である。できなくたってかまわない。また明日があるし、習慣というにはほんの少しの実践であったって何もやらないよりはマシである。ハードルを下げよう。こっちは思考放棄しているのだ。高いハードルなんてこせるわけがない。考えることなくできるレベルにするべきである。また、リマインダー機能もついているのだが、使わない。なぜなら、上から順番にこなしていくだけなので、リマインドされる必要がないからである。リマインドされる必要があるということは、選択肢が存在しているということである。何度も行っているように、その時点で根本問題が解決されていない。

おわりに

本記事をまとめよう。

• 限られた時間でパフォーマンスを高めるためには、習慣化による時間効率の改善がもたらす能力向上が必要である
• 根本的な問題は、習慣を継続できない弱い自分ではなく、選択肢が存在することである
• 思考を放棄してツールのいいなりになることで、選択肢の存在・発生を根本的に排除する
• 習慣化したいタスクをツールにどんどん登録し、ただ上から考えることなくこなしていく状況を作る
• 習慣支援ツールの使用を習慣化するために、起きたらすぐタスクを消化できるよう「起床する」というタスクを入れる
• ただ上から順番にこなせばいい状態にするために、一日の流れを習慣化するべきタスクとして登録していく
• 「〜日連続」なんて気にしないで、できなかったらできなかったで次の日にやればいいと考える
• タスクの達成目標をあえて定量化しないことで、誤った完全主義の発動を抑制し、少しでも実行できるようにする
• リマインダーを必要とする時点で選択肢が存在しているということなので、リマインダーを使わない

他にも工夫しているポイントはいろいろあったりするのだが、それはまた次の機会に紹介することにしよう。