AIが思考を代行する時代に人間が「知識を繋ぐ」固有の価値とは何なのか？

AIが知識ネットワークの構築すら代行する時代、人間が自ら思考する意義はあるのか。
AI時代の思考と知識ネットワークとは何なのか？
Obsidianによる暗黙知の可視化とAI連携の現在地を踏まえ、概念同士を自らの手で繋ぎ、世界観を深めていく「人間固有の思考行為」の本質と価値に迫る。

【参考】
Obsidian - Sharpen your thinking

AI世界で価値を持つ知識｜クロメル

【1】Obsidianは単なるmarkdownエディタ、アウトラインプロセッサと思っていたが、他人のObsidianを見ると、自分の思考の中身を見える化するツールだと思う。
Obsidianのネットワーク図は、自分の頭にある概念モデルを見える化したものだと思う。

Obsidianのネットワーク図とは自分の思考行為そのものだ。
たくさんの言葉、概念がバラバラにあったとしても、それを理解するために、自分の頭の中でそれらを関係づけることで理解を促進する。
概念そのものよりも、概念同士をつなぐ関連線、概念同士の関係が重要だ。
ネットワーク化が思考そのものだ。

僕は概念同士を関連付けるネットワーク化は、ビジュアル化、図示化と思う。
きちんと絵や図にできないが、空想できるもの。
目に見える形にしようとすると、雲のように消えてしまうが、それでも図示できるもの。

Obsidianのネットワーク図は、氷山モデルのうち海面下の隠れた暗黙知に相当すると考える。
氷山モデルのうち、目に見える氷山は、バラバラの概念。
それらの概念は関連付けられていないので、単なる石ころに過ぎない。
しかし、海面下では、それら概念は関連付けられて、思考の本棚に概念が整理されて片付けられて、いつでも取り出せるような形になっている。

Obsidianのネットワーク図は、SECIモデルでは、暗黙知から形式知へ変換するプロセスに相当すると考える。
バラバラの概念、暗黙的に隠された概念は、ネットワーク構造から、別の概念を想起させる。
それこそが、蒸留された知識、概念。
一つの概念で、全ての現象、事象を説明できる。
一つの概念から、芋づる式にすべての知識にアクセスできる。
そんなイメージを持つ。

たとえば、製造業における技能継承ならば、ベテラン技術者が持つ暗黙知に相当するだろう。
この工程では実は、温度は何度くらい、どんな明るさや色なのか、どんな感覚なのか、どんな音なのか、をベテランは直感的に知っている。
しかしそれらは言葉にされず、彼の経験の奥底に隠されている。
その暗黙知を具体化して言葉に出し、その言葉を関連付けることで、一つの概念を形式知に変換させる。

【2】では、AI時代ではObsidianはどのように使われているのか？
ある人の使い方が参考になった。
彼は、Obsidian上でメモやログをmarkdownでとにかく書いて保存する。
そのmarkdownファイルには、Open Knowrageフォーマットというタグを付ける。
このタグ付けにAIを使い、AIでタグ付けを自動化する。
すると、このタグに基づいて、Obsidianが概念を紐づけてネットワーク図を作り出す。

つまり、AI時代では、ObsidianとAIはとても相性がいい。
学習データを人間が作り出し、それを元にAIがタグ付けして、Obsidianというツールが概念同士の関係をネットワーク構造に自動化する。
それにより、概念の多次元ベクトル空間が自動生成される。

これこそが、オントロジーに相当するものだろう。
ドメイン駆動設計なら、ドメインモデルそのものになるだろう。

従来はオントロジーやドメインモデルは人力で作るしかなかった。
よって、そのモデルは陳腐化しやすかった。
しかし、AI時代では、AIが自動更新してくれるので、とても重要な資産になる。

【3】AIがObsidianのネットワーク図を自動生成するようになれば、人間の思考行為そのものもAIが代用するだろう。
AIは計算資源が豊富であれば、人間の思考よりもはるかに高速で強力だ。
人間の思考なんてあっという間にAIが追い越すだろう。

では、AI時代では、人間が思考する行為そのものに意味はあるのか？
全てAIで思考行為そのものも代行できるなら、人間の思考に存在意義はないのではないか？

この意見に反対する立場として、クロメルさんの記事が参考になる。

AI世界で価値を持つ知識｜クロメル

（引用開始）
大学で学ぶ目的って、この知識ネットワークを自分の中に作る事が一つあると思うんです。
知識を売る仕事は、いえ少なくとも僕のnoteの活動は、ここにまだ価値を生める余地があると思っています。
何か異なる分野や概念を探って「価値の高い」橋を見つけ架けるのです。

点と点を線で結ぶ価値は、AIに対して点自体の価値より比較的残るだろうと言う主張です。
（引用終了）

AIの方が概念の多次元ベクトル空間を作り出す能力がいくら高くても、人間が人力でネットワーク構造を作り出す行為そのものは意義がある、という主張だ。
僕も直感的に賛成する。

概念のネットワーク図を自分の頭の中に作り出す行為は、自分の世界観を深く、広くさせるもの。
その行為そのものは忘れたくない。

Redmine AI HelperプラグインはRedmineをAI駆動プロジェクト管理に変える可能性を秘めている #Redmine

Redmine AI Helperプラグインの講演資料を読んで改めてアーキテクチャ構造がよく考えられているなと思った。
Redmine AI Helperプラグインを知っている前提で、理解したことをラフなメモ書き。

【参考】
Redmine AI Helperとそのしくみ

第29回redmine.tokyo勉強会

2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集

Building Multi-Agent Systems with LangGraph and Ollama: Architectures, Concepts, and Code | by Diwakar Kumar | Medium

【1】Redmine AI Helperプラグインのマルチエージェントモデルは優れていると思った。

Redmine AI Helperプラグインのマルチエージェントモデルでは、Issueエージェント、Wikiエージェント、Userエージェントなどの機能に特化したエージェント群と、GitHubエージェント、Slackエージェント、メールエージェントのようなMCPエージェント群が協調して、互いに会話しながら動作する。

その時に、マルチエージェントモデルのアーキテクチャとして、@haru_iidaさんは、Networkではなく、Supervisorを選んだ。

第29回redmine.tokyo勉強会

2025年の年始に読み直したいAIエージェントの設計原則とか実装パターン集

Building Multi-Agent Systems with LangGraph and Ollama: Architectures, Concepts, and Code | by Diwakar Kumar | Medium

なぜ、Supervisorを選んだのか？
redmine.tokyo勉強会の講演で聞いたときは、NetworkよりもSupervisorの方がエージェント同士のレスポンスがいいと話していた。

理由は色々推測できる。
おそらく、複数のエージェント同士で処理を実行するために会話させたならば、誰かが全体の処理を監視してコントロールしなければ、変な方向に行ってしまう場合が多いのだろう。
エージェント同士のコミュニケーションパスが多くなるほど、統制が効かなくなるはずだ。
つまり、人間集団や組織と同様に、コミュニケーションパスを減らし、1人の管理者がコントロールできる範囲に収めるようにしなければ、本来実施して欲しい処理の品質が悪くなるのだろう。

では、Supervisor型のエージェントモデルでは、どんなコミュニケーション構造を取っているのか？
@haru_iidaさんの設計では、仮想チャットルームを作り、Supervisorが必要なエージェントのみをチャットルームに召喚して処理を実行させている。
仮想チャットルームは、まるで人間のSlackみたいな感じだ。

第29回redmine.tokyo勉強会

つまり、Slack上でエージェント同士が、チケットを更新する処理のために、Supervisorがまずエージェント達にゴールを共有した後、SupervisorがUserエージェントやIssueUpdateエージェントと会話してるイメージ。
エージェントは仮想プログラムに過ぎないのに、人間のように振る舞う点がすごく面白いと思った。

実際の仕組みは想像になるが、Supervisorやエージェント同士が会話するログのテキストファイルがあって、そのログテキストにあるプロンプトからファンクションコールされてエージェントがキックされるのだろうと思う。
つまり、会話ログというテキストファイルが仮想チャットルーム、すなわち、Slackみたいなイメージになるのだろう。

そのSlackにプロンプトが書かれると、処理すべき機能に対応するエージェントがファンクションコールで呼び出されてキックされて、プロンプト通りにエージェントが実行するわけだ。

そんな仕組みを考えると、処理を実行するプロンプトの背景、ゴールを明確に定義する必要があるだろう。
つまり、AIでよく言われるコンテキストが重要になってくるだろう。
なぜならば、背景や前提条件、制約条件というコンテキストが明確でなければ、期待した結果が出てこないからだ。
実際、ChatGPTでも前提条件を細かく書かないと、欲しい結果がなかなか出てこない。

こういうエージェントモデルでは、各エージェントのフォルダにコンテキストを事前設定するプロンプトを配置して、エージェントを制御する仕組みがあるらしいので、おそらく@haru_iidaさんは事前プロンプトにかなりのノウハウを組み込んでいるのではないかと想像する。

【2】Redmine AI Helperプラグインのアーキテクチャ構造も優れていると思った。

内部構造では、ユーザ要求処理、ビジネスロジック、外部サービスの3層構造に綺麗にレイヤ化されている。
具体的には、Webアプリ層、Agent層、MCPサーバやLLMの層の3層構造に綺麗に設計されている。
これはすごく綺麗だ。
アーキテクチャをちゃんと理解できる人しか組めないような綺麗なアーキテクチャだ。

第29回redmine.tokyo勉強会

わざわざ、マルチエージェントモデルを3層構造で分けたメリットは何なのか？
オブジェクト指向設計に慣れている人ならば効果はすぐに理解できるはずだ。

ユーザがMCP Agentや各機能に特化したドメインのAgentへ処理を実行させたい時、その処理は中身は違っても操作としては共通のインターフェイスを持つはずだ。
つまり、ユーザ要求処理とビジネスロジックの間に、Agent抽象化レイヤーを入れて、Agentへ指示する操作をインターフェイスで抽象化すれば、ポリモルフィズムを使って制御すればいい。

同様に、MCP AgentがGitHubやSlackに連携させたい時、MCP抽象化レイヤで操作をインターフェイスで抽象化しておけばいい。
あるいは、IssueAgentがOpenAIやAnthropicのLLMを使いたい時、LLM抽象化レイヤで操作をインターフェイスで抽象化すればいい。
そうすれば、LLMのバージョンが上がって追加したくなる場合、ビジネスロジック層のプログラムを変えることなく、簡単に追加したLLMを利用できるようになる。
つまり、抽象化レイヤがあるおかげで機能追加や機能修正のプログラミングが非常に楽になる。

僕は、この内部構造のアーキテクチャを見て、AIエージェントの仕組みを理解できた。
さらに、最近、AIの機能を入れました～とあらゆるWebサービスやパッケージ製品で広告を見かけるが、おそらくそれらシステムも@haru_iidaさんのようなアーキテクチャ構造に似た構造になっているに違いないと思った。
そうでなければ、大量の人員とお金を投資した案件なので、今後のシステム保守を考えれば元が取れないはずだ。

【3】Redmine AI Helperプラグインの根本テーマに「プロジェクト管理にもAIを」がある点がすごくいい。
AIが当たり前の現代では、ソフトウェア開発であれ、ホワイトカラーの仕事であれ、経営戦略をねったり、プロジェクト管理することも全てAI駆動になる。
AIを使うだけでなく、AIでいかに価値を出すか？

Redmine AI Helperプラグインによって、RedmineをAI駆動プロジェクト管理に変える可能性を秘めている。
従来は、Excelによるプロジェクト管理からの脱却がメインテーマだったが、現代では、AI駆動のプロジェクト管理により、プロジェクトリーダーやプロジェクトマネージャは本来の意思決定に専念できるようになる。
そんな機能が沢山盛り込まれているし、今後の機能追加により、さらに発展するだろう。

Redmine AI Helperプラグインは、そういう機能追加がやりやすいエージェントモデル、アーキテクチャ構造になっているので、今後の開発にすごく期待できる。
今後もウォッチしていきたいと思う。

「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT

第27回redmine.tokyo勉強会で講演された「RedmineのUbuntu+Docker構築への移行」は内容が参考になったと思う。
ラフなメモ書き。

【参考】
第27回勉強会 - redmine.tokyo

発表 #1609: 第27回 講演: ＜RedmineのUbuntu+Docker構築への移行＞ - redmine.tokyo

【1】今回の講演の背景としては、問題意識として、RedmineをCentOSで利用している場合、どのOSへ移行したら安全なのか、容易に移行できるのか、がある。
おそらく、Redmineはフリーで現場で使っているので、OSやサーバも自前で構築する時にCentOSを利用しているケースは非常に多い。
そこで、CentOSはサポート切れになってしまった状況では、セキュリティリスクがあるために、どこかのOSに移行せざるを得ない。
OSSのLinuxOSは数多くあるが、どれが最適であるのか？

さらに、どのOSが最適なのか、そして移行作業としてどれだけの工数や難易度が発生するのか、という問題も発生する。
RedmineというWebアプリ程度なら簡単だろうと思っていると、RubyやOSのバージョン、プラグインとの相性など色んな点で地雷を踏んでしまうリスクがある。

そういう背景を踏まえて、本資料を読み直すと価値があると考える。
本資料では2つの観点で整理できると思う。

【2】1つ目は、本資料では、CentOSからの移行先OSとして、Ubuntsを選択している。
移行要件詳細①を読むと、Ubuntsを選択している理由は明確だ。
s
Ubuntsを選択した理由を品質特性の観点で整理すると下記になる。

リリースの歴史が長く突然停止の可能性が低いこと
　→OSとして成熟しており、信頼性が高いと想定。

LTSの定期的な提供、2年単位の最新版提供により最新の機能が使える
　→最新の機能が使えるので、機能適合性が高いと想定。

Webクライアントとしてのシェアが高くナレッジ豊富
　→障害が発生しても障害解決の知見が豊富なため、信頼性(耐障害性)が高いと想定。
　→Ubunts上では、他のソフトウェアと共存し使用できる知見が多数あるため、互換性が高いと想定。

x86やARM等アーキテクチャを問わず稼働し、汎用性に優れる
　→x86やARM等アーキテクチャなど幅広く移植できるため、移植性が高い。

CentOS互換系のOS特有の機能を使わないのでCLIでよい
　→CLIでメンテナンス用プログラムを作成できるため、保守性が高いと想定。

CLIに慣れる事でLinuxに対する耐性や知見を上げる
　→CLIに慣れれば、UbuntsOSはCLIで操作しやすいため、使用性が高いと想定。

すなわち、信頼性、機能適合性、信頼性、互換性、移植性、保守性、使用性などでUbuntsの品質は高いと分析されている。
品質特性のかなりの数の観点が網羅されており、実際にRedmine移行で成功されたことを考慮すれば、Ubuntsを選択した理由には妥当性があると考える。

もちろん、RockyLinuxなど他のOSも候補に入るだろうが、普及されているUbuntsは移行先の有力候補になるだろうと思う。

【3】2つ目は、本資料では、Redmineの移行を今後も考慮するためにDockerを採用されていることだ。

vSphereの期限切れという事情もあるだろうが、Hyper-VとDockerのような仮想基盤の上にアプリ層を乗せる方が、今後の移行作業もコピーするだけでよく、作業しやすくなる。
「Redmineの移行」ページにソフトウェア構成図が記載されていて、Redmineが乗る基盤が層別に整理されていてイメージしやすい。

また、Dockerイメージを複製することで、移行後の動作検証やプラグイン検証、性能検証なども並行作業で実施しやすくなる。
本資料で注目すべき点の一つは、Redmine本体のDockerイメージ(sameersbn / redmine)とプラグイン込みのRedmineのDockerイメージを区別して準備されている点だろう。

既に準備されているRedmine本体のDockerイメージを利用する理由は、Webサーバやバックアップなどの基本機能が既にあり、プラグイン無しの標準機能がそのまま使えることだろう。
つまり、プラグインを使わずRedmine本体の標準機能だけで使うならば、公開されているDockerイメージをそのまま流用するほうが品質も担保されているし、検証や移行などの作業工数も無駄に使わなくていい。

一方、プラグイン込みのRedmineのDockerイメージはカスタムイメージで独自作成されている。
Lychee RedmineやFull Text Search等のプラグインを使われているそうなので、それらの動作検証を入念に行われたと記載されている。
確かに、プラグインの動作はRedmineのバージョンやプラグイン同士の相性、OSの相性にも依存するため、Dockerのカスタムイメージを作成した方が、プラグインを1つずつ入れて検証OKのDockerイメージを作りやすく、事前検証の先祖返りのリスクもないだろう。

本資料を読むと、View Customizeで改良した部分が動作しなかったり、Lychee Redmineのガントチャートの日本語表示はOSの日本語フォント配置で解決したり、応答速度低下のクレームにはインスタンスのスケールアップやMariageDBのチューニングで改善されたりしている。
やはり移行後には予期しないクレームも発生するので、色々対応せざるを得ない。
そんなケースでもHyper-VとDockerを使っているなら、インスタンスの性能チューニングも簡単だし、Dockerで移植し直すこともできる。

分かってしまえば簡単な内容かもしれないが、やはり実際に移行してみないと分からない時も多い。
そういう試行錯誤された事例として非常に価値ある内容と思う。

入門Redmine第6版 [ 石原佑季子 ] 価格：3,080円（税込、送料無料) (2024/11/24時点) 楽天で購入

Javaのモジュールシステムの考え方をまとめてみた

Javaのモジュールシステムの理解が深まったのでメモ。
Java初心者のラフなメモ書き。

【1】モジュールシステムはなぜJavaで必要なのか？

異なるJarであっても、同一パッケージ名が衝突する問題があった。
モジュールは、パッケージを区別するための仕組み。
パッケージはクラスを包み込み、モジュールはパッケージを包み込む。

Javaはオブジェクト指向言語なので、機能追加したい場合、開放閉鎖原則に従って、既存クラスは修正せず新規クラスを追加する。
Rubyのオープンクラスみたいなもの。
すると、クラスがどんどん増えるので、パッケージでクラスを分類しようとする。
そして、パッケージをまとめたJarを配布して、開発者に利用してもらうようにする。

しかし、Jarファイルもどんどん増えてしまって、異なるJarなのに同一パッケージで衝突する場合がある。
Mavenでこういう依存ライブラリのJarを管理するけれど、名前衝突が多くなるのだろう。

【2】なぜ、無名モジュール、自動モジュールは必要なのか？

Java9以後はモジュールシステムを使う必要があるが、以前のJara8のJarファイルはモジュールに対応していない。
Java8のJarファイルを利用できるような環境としてモジュールが導入された。

基本は、Classpathにある無名モジュールが一般的だが、modulepathにないので、名前付きモジュールから無名モジュールを読み込めない。
そこで、modulepathにJarファイルを置いて、自動モジュールに変更して、名前付きモジュールから自動モジュールを読み込めるようにした。

実際の現場を見ると、Java8までで止まっているWebシステムは割と多いように感じる。
たぶん、Java9以後のモジュールシステムに対応するように、移植するのは難しい場面があるからだろう。

【3】無名モジュール、自動モジュールとは何か？

無名モジュールはJava9以前のJarで、Classpathにある。
以前のコマンドみたいに、java -cp **.jarみたいに使う。

なお、無名モジュールのJarはclasspathにあるので、名前付きモジュールから読み込めない。

自動モジュールはJava9以前のJarで、ModulePathにある。
java --module-path **.jar とか、java -p **.jarみたいに使う。

名前付きモジュール--> 自動モジュール、自動モジュール --> 名前付きモジュールの両方で読み込める。
なぜならば、modulepathに名前付きモジュールも自動モジュールも両方配置されているから。

なお、無名モジュールも自動モジュールも、パッケージのクラスは全て公開されているから、モジュールシステムのように公開の制限はできない。

無名モジュールはJDK9以前のライブラリ。
module-info.javaもMETA-INF/MANIFEST.MFもない。
ClasspathにJarを配置していると、java --module-path **.jarが使えない。

自動モジュールは、META-INF/MANIFEST.MFにAutomatic-Module-Name属性が指定されている or jarファイル。
JDK9以後は、java -p **.jarで実行する。

自動モジュールはできるだけMETA-INF/MANIFEST.MFにAutomatic-Module-Name属性を指定する。
なぜならば、Jarファイル名は書き換えられやすいので間違いやすい。
META-INF/MANIFEST.MFに記述すれば、Jarファイル名が書き換えられても呼び出されるJarは同じになるので安全。

【4】jlinkはなぜ必要なのか？

専用のランタイム用アプリを作りたい。
JDK9以後は、JREがないから。

さらに、クラウドのサーバーレス環境でアプリを実行する時、コンパイルしたアプリのサイズを小さくできる。
クラウドのリソースを抑えられるし、アプリの起動時間（ロード時間）も短くできるメリットが出てくる。
つまり、AWS lambdaみたいに、イベント駆動で多数のプロセスを並行起動するような場面では、アプリサイズが小さいほど性能も良くなるし、デプロイもやりやすい。

たぶん、クラウドの開発に特化するようにJavaも進化してきているのだろう。

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

【5】jdeps --jdkinternal はなぜ必要なのか？

JDKの内部APIでクラスレベルの依存関係を検索するためのコマンド。
古いJava8のJarファイルがどんなJDKライブラリを使っているか調べるために使う。
Java9以後は公開されていないJDKライブラリは排除していくべきという考え方。

Java9のモジュールへ移行する時や、jlinkコマンドで小さい専用ランタイムアプリを作りたい時に利用できるだろう。

【6】なぜServiceLoaderは必要なのか？

ServiceLoaderは、Java9以前で依存性注入（DI）を実現する方法に過ぎない。
たとえば、Sampleインターフェイスだけ公開して、SampleImpl実装クラスは呼び出さないように実装したい。
META-INF/servicesに、実装クラスを記載したテキストファイルを作って、ServiceLoaderが読み込んで動的に切り替える仕組みにしただけ。

Java9のモジュールシステムでは、ServiceLoaderを利用する場合、module-info.javaにprovides～with～でIFを書いて公開する。

「公開IFの提供」をmodule-info.javaで宣言する => provides 公開IF with 実装クラス(SPIを実装)
「公開IFの利用」をmodule-info.javaで宣言する => uses 公開IF名(SPIとして使う)

ServiceLoaderはJDBCドライバの実装にも使われているので、わりと一般的。

【7】Javaのモジュールシステムは、Javaの進化でどのような意義を持つのか？

モジュールシステムは、Javaをクラウド開発に適用したり、デプロイしたモジュールやライブラリの移植性を高めるために必要なのだろう。
しかし、Javaは過去の遺産が多すぎるために、どんどん仕様が複雑になってきていると思う。

実際、Jarの依存性のエラーメッセージの種類が多くなっているために、問題解決するのは大変だろうと想像する。

Javaのモジュールシステムは複雑性をより増している: プログラマの思索

一方、Javaはオブジェクト指向言語だけでなく、関数型言語の一面も持つ。
実際、OptionalやStreamなどのモナドのAPIはまさに関数型言語そのものだ。

Javaが関数型言語の特徴を持つようになった理由の背後には、クラウド上で多数のプロセスを並行で動かす時に、MapReduceの仕組みがあれば、負荷分散をより活用できるメリットを活かしたいからだろう。

Javaはオブジェクト指向言語ではなく関数型言語だった～「[増補改訂]関数プログラミング実践入門」はお勧めの本だ: プログラマの思索

Javaはなぜ関数型言語になろうとしているのか: プログラマの思索

JavaSilverの感想～Javaはオブジェクト指向と関数型言語の2つの性格を持つ: プログラマの思索

そんなことを考えると、20年前にUMLやJavaを使って、オブジェクト指向設計に熱狂していた時代はもう古くなっている。
そういう価値観はもはや終わったように思える。
そして、時代は更に進化しているわけだ。

一方、その進化はどんどんソフトウェアの複雑性を増やす。
ソフトウェアの本質は複雑性にあるが、その複雑性をどのように手懐けてコントロールすべきなのか？
今も昔もソフトウェア開発はこの問題から逃れられない。

Javaのenum型はシングルトンクラスみたいだ

Javaの最新版に触れてみたら、enum型にコンストラクタやメソッドを持たせることができると分かった。
ちょっとびっくりした。

(2) よしけーさんはTwitterを使っています: 「enum にメソッド持たせるのは effective Java あたりを読まないと気がつけない気がする。。 #ドメインモデルパターンに挑戦する苦労ばなし」 / Twitter

(2) akipiiさんはTwitterを使っています: 「Effective Javaにenumのパターンが確かに書いてあった。enumでメソッドを定義する発想がなかった。後で読む」 / Twitter

あなたの知らないJava enumの使い方 - SEチャンネル

Effective Java 第３版 第６章enumとアノテーション - Qiita

Effective Java 3rd [Chapter 6] - enum とアノテーション - Little by little and bit by bit - マイペースにこつこつと

【Effective Java】項目３０：int 定数の代わりに enum を使用する - The King's Museum

Effective Java 第３版 「ほぼ全章」を「読みやすい日本語」で説明してみました。 - Qiita

ドメイン駆動設計に関する勉強会で、Javaのenumにメソッドを持たせられるというツイートを見た。
「Effective Java 第3版 | Joshua Bloch, 柴田 芳樹」を読んでみたら、たしかにenumに1章を割いて、詳しく説明されていた。

個人的印象としては、JavaのEnum型はシングルトンクラスみたいだ。
グローバル変数の出し入れに使える感じ。
使い道としては、業務システムのシステムコントロール定数を持たせたい時だろうか。

Effective Java 第３版 第６章enumとアノテーション - Qiitaでは、int型をEnu型で書くべき、というプラクティスは理解できる。
しかし、「拡張可能なenumをインタフェースで模倣する」プラクティスのように、通貨クラスに「＋」「-」のようなメソッドを独自で実装するという発想はなかった。
こういう考え方がドメイン駆動設計の値オブジェクトの実装に役立つのだろう。

Javaから離れていたので、最新版のAPIや文法がかなり変わっているのに気づいた。
Javaはオブジェクト指向言語だというぐらいのイメージしかなかったが、RubyやPython、JavaScriptなどの良い面をJavaも取り入れようとしている印象を受ける。
Javaにラムダ式ぐらいを取り入れるのはまだよいが、ストリームAPIは何かやりすぎな感じもした。
気づいたことはまた書く。

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること、というツイートを見つけたのでメモ。
自分は理解できていないので、疑問点も一緒に自分用のメモ。
以下は自分の直感を適当に書いたので、論理的ではない。

【参考】
akipiiさんはTwitterを使っています 「中島聡さんのメルマガでテスラの凄さをよく解説されてるがピンとこなかったが、このスレッドで意味がすこし分かる気がした」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「テスラ・イーロン真理教の人も、トヨタ・日本車信仰の人もまあみんな落ち着いて。相手を知らず自分の信じたい情報だけ見てても何の進歩もありませんよ。まず日本の自動車メーカーの何がすごいか理解しましょう。テスラの話はその後です。日本メーカーの強さは簡単に言うと、」 / Twitter

テスラが従来の自動車メーカーと異なるところ - Togetter

【0】中島聡さんのメルマガも合わせて考えると、テスラが自動車製造にソフトウェアを持ち込んだメリットは3つあると思う。

週刊 Life is Beautiful ２０２２年２月８日号：自社製チップと粗利益率 - まぐまぐ！

【1】1つ目は、メーカーにも関わらず、売上高粗利益率が圧倒的に大きいので、どんどん新設備に投資できる財務基盤があること。
普通の自動車メーカーの粗利益率は10％台であり、トヨタですら16％くらい。
一方、アップルは40％、テスラは30％の粗利益率を持つ。
ソフトウェア専業のマイクロソフトは80％の粗利益率らしい。

売上原価には、1台の自動車を作る部品、原材料、人件費、設備の減価償却も含む。
もちろん、外注した部品代金、外注した車載半導体、外注した車載プログラムの開発費用も含まれる。
ソフトウェアの売上原価は、所詮、電気代とサーバーの減価償却と人件費くらいなので、製造業に比べれば圧倒的に低い。

中島聡さんのメルマガによれば、テスラやアップルはハートメーカーでありながら、自社で製品設計して、その製品を圧倒的に安く作るために韓国や台湾の製造専業メーカーに製造委託する。
だから、圧倒的に安く作れるので、売上原価は小さい。
一方、自社では、M1チップ、あるいは、自動運転の学習エンジン専用の半導体まで製造する。

そこで、アップルなら自社のOSやiTuneプラットフォーム、テスラなら自動運転のソフトウェアをオプションで付けて、安いハードに付加価値を付けて高く売りつける。
ユーザは、その利便性を求めるし、顧客満足度を高めることにより、ブランド価値を高めて、ロイヤルティを持たせる。
だから、メーカーでありながら粗利益率が圧倒的に高い。

でも、財務基盤の仕組みが分かっていたとしても、ソフトウェアの技術力が高くなければ、そう簡単に真似できないだろう。
ソフトウェア開発は、優秀な人材に依存するものであって、マネーの資本を注ぎ込んでも規模の経済は働かないから。

【2】2つ目は、工場の生産ラインそのものもソフトウェアでバージョンアップしやすくすることで、生産性が圧倒的に高いことだと思う。

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「イーロンは車両設計より工場の設計の方が100倍難しいと話すほどで、伝統OEMの常識から外れ、1-2年で主要設備を入れ替えたり、プラットフォームの大幅改善を行ったりします。発売時には既に数年古い技術の車となるOEMとは異なり、テスラからは常に最新の車が出てきます。参考: https://t.co/wA7liu1n1B」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「彼らのソフトの力がこうした離れ業を可能にしており、伝統OEMは全く理解できていません。VWも隣町にGiga Berlinが現れて初めて自社の生産性が完全にテスラに劣ると気づいたのですhttps://t.co/Rmbra4XoZN テスラは21年、トヨタを抜いて北米で最も生産性の高い工場になりましたhttps://t.co/QPx0tuLxa3」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「何年も同じラインのままの伝統OEMと1-2年毎にラインが進化するテスラ。既に上海工場はフリーモント工場より高い生産性を実現しており、車両の質までも上がってきています。そして来たるベルリン、テキサス工場…競争力のない工場をいくつも抱える伝統OEMと比べいかにテスラが筋肉質かわかります。」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「製造が進化する為、車両の質も日々上がり続けます。Model3の航続距離が突然伸びたり、価格が下がったりするのはこのためです。更に彼らはOTAを通じて購入後も常に車両性能を更新します。購入時既に古く、どんどん古くなる車と、買った時常に最新でその後も最新を維持するテスラ。どちらを選びますか。」 / Twitter

この辺りは僕は詳しくないのでよく分かっていない。
OEM生産といえば、スーパーがよくやるプライベートブランド商品を外部メーカーに委託する生産のイメージ。

テスラの生産ラインは1～2年でどんどん進化するらしいが、トヨタのような自動車メーカーの生産ラインは4～5年おきのように古いままなのだろうか？
今、スマート工場や工場のDXが叫ばれているが、日本の工場は古い製造ラインを数年も放置したまま製造しているのだろうか？
そんなに日本の工場はアナログなのだろうか？

このツイートが正しいならば、フォルクスワーゲンのようなドイツ企業、GMのようなアメリカ企業も同様に、彼らの工場の生産ラインは古くて生産性が低いのだろうか？

【3】3つ目は、EV製造に関わるソフトウェアは、いろんな事業とシナジー効果が大きいこと。
自動運転のソフトウェアの開発の為に、機械学習専用の半導体チップを製造したり、バッテリや充電施設を強化したり、果てはスペースXのような宇宙事業にまで、シナジー効果がある。

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「こうした強さを支える根幹がソフトウェアです。ソフトの重要性を理解しているテスラは、工場のデジタル化はもちろん、半導体チップから内製し、自社で自動運転トレーニング用のスパコン(Dojo)まで開発しています。ここまでやってる企業は他にいません。Dojoの計算能力は日本のスパコン京を凌駕します。」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「また、80台ほどしか販売してないホンダレジェンドや試験走行のWaymoやCruiseと異なり、テスラは数百万台の実車両からのリアルデータが収集・学習され、より堅牢な自動運転ソフトウェアの開発に寄与しています。今や取り返しのつかないほどの差になってきています。1点彼らの自動運転思想の特徴として、」 / Twitter

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「LiDARを廃しカメラのみで自動運転を実現しようとしている点があります。これについては賛否あり、私個人は難しいのではと感じています。いずれは低機能低価格のLiDARと組み合わせるなど妥協策が出てもおかしくありません。さて次はエネルギーです。手短にいきます（疲労）」 / Twitter

中島聡さんのメルマガでは、人間は2つの目というカメラで運転しているのだから、自動運転技術はカメラだけで十分であって、LiDARにまでコストを掛ける必要もない。
LiDARをつけたソフトウェア開発は余計に複雑になるから、と書かれていて、なるほど、と納得した。

ウミガメ@闘え日本の自動車メーカーさんはTwitterを使っています 「ソフトの強みは当然自動運転技術にも生きてきます。全部書くと長くなるので一例を紹介します。例えばラベリング。伝統OEMは未だに多額で外注したり、何ヶ月もかけて人の手で行なっていますが、テスラでは同じ規模のラベリングを自動で1週間ほどで実施してしまいます。悲しいほどの差です。」 / Twitter

このツイートもよく分かっていない。
OEM生産のラベリングとは、所詮、プライベートブランド商品に製造ラベルを貼り付けるだけだと思う。
自動車メーカーのラベリングは数ヶ月もかかるような手間がかかるものなのか？
ラベルを大量生産する仕組みを今まで作っていなかったのはなぜなのか？

【4】このツイートを読んで思うことは、ハードに対するソフトウェアのメリットは、プログラムの頻繁なバージョンアップによって機能強化できることにより、ユーザにとっては、古いハードであっても、いつでも新しい機能を使えて利便性が高まることだ。

つまり、ハードは一度リリースしたら変更できない。それは当たり前。
一方、ソフトは一度リリースしても、ファームウェアのアップデートやソフトウェアのバージョンアップによって、手持ちの製品がいつでも最新版の製品に生まれ変わることだ。
それにより、ユーザの生産性もどんどん上がる。

そういうソフトウェアの特徴を生かして、工場の生産ラインにも反映して、生産ラインを制御するソフトウェアをどんどん進化できるような仕組みを作っているのだろうと思う。
だから「工場も一つの受注製品」という主張が成り立つわけだ。

DevOpsやアジャイル開発では、コミュニケーションが大事とよく言われるが、僕はそんな所にイノベーションとか価値があるわけではないと思う。
むしろ、製造とリリース後の保守も含めて、全てをソフトウェアで一貫して制御することにより、1人のプログラマが全ての工程をコントロールできるようになったことが大事だと思う。

従来であれば、各工程の専門家による分業体制でしか製造できなかった製品が、たった1人あるいは数人のソフトウェア開発チームで製造できるようになったこと。
ビジネスモデルは、規模の経済からソフトウェアによる少人数のチーム開発へ変革された。
たぶんそこに、ソフトウェアが従来の製造業と異なる価値をもたらしているのだと思う。

「RubyやRailsは終わった」という記事のリンク

「RubyやRailsは終わった」という記事があったが本当なのか？
見つけた記事だけをリンクしておく。
自分が後で読むためのメモ書き。

【参考】
“Rubyは死んだ”のか？　まつもとゆきひろ氏が語る「プログラミング言語サバイバル」とRubyの未来 - Part1 - ログミーTech

Ruby2系はチームの幸福度を最大化できなかった - Qiita

「Railsは終わった」と言われる理由 - Qiita

Rubyは死んだというが。流行り廃りに拘らず、便利なものは活用すればいいのに - Qiita

Rubyは果たして死んだのか | 日経クロステック（xTECH）

Rubyは終わった？将来性と今後の展望をまとめてみた│エンジニアハック

将来性のないプログラミング言語5選として「Ruby」が挙がり話題に | スラド IT

個人的にはRubyは好きだ。
「メタプログラミングRuby 第2版」を読んで、色々動かして、やっとダックタイピングの意味が分かった。
やはりRubyはJavaとは違う。
Rubyは究極のオブジェクト指向言語なのかもしれない。

また、Rubyというコミュニティも素晴らしいと思う。

なぜソフトウエア後進国の日本でRubyは成功したのか？～ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある: プログラマの思索

一方、RubyはPerlのシンタックスを受け継ぐ部分があるせいか、初心者には読みにくい記法がある。
慣れないと使いこなせない部分もある。

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

Ruby技術者認定試験の感想: プログラマの思索

Ruby初心者が間違いそうなこと: プログラマの思索

メタプログラミングRubyの感想: プログラマの思索

Rubyのブロック、Proc、lambdaのメモ: プログラマの思索

RedmineやRubyについては今後も追いかけていく。

実践した後に勉強するのがエンジニアの本来の道

実践した後に勉強するのがエンジニアの本来の道というツイートに共感したのでメモ。

はじめ??ソシャゲフリーランスエンジニアさんはTwitterを使っています 「中島聡さんが プログラミングの勉強は、アプリの開発を通してするもの と仰っていたけど完全同意です 恐らく100冊の技術書を読むより1アプリを作るほうが勉強になる そして1アプリを作った時の答え合わせのために技術書を読む 勉強→実践が普通の思考ですが 実践→勉強がエンジニアの本来の道です」 / Twitter

エンジニアは、仕事でシステムを開発して経験した後、技術書を読んで自分の経験を振り返る方が良い。

なぜなら、IT、プログラミングの技術書は抽象的で具体性がない。
具体性をいくら書いても、所詮プログラムなので、実際に動かさなければ、どこに落とし穴があるか分からない。
本の中身を丸暗記しても、実際にプログラミングがスムーズにできるとは限らないし、思ったようにプログラミングできない場合が多い。

一通りプログラムを書いて、アプリを動かして体験した後で、その体験内容を技術書で採点する感じ。
技術書に書いている内容に、ふむふむその通りと納得する時もあれば、こんな使い方があったのか、もっと速く知っておけばよかった、と思う時もある。
一方、こういう部分が泥臭くて難しくてハマる部分なのに、技術書に書いていなくて、消化不良だな、と思う時もある。

「大人の学びパターン・ランゲージ」の感想～知識と経験を行ったり来たりするタイミングを大切にする: プログラマの思索

DB Browser for SQLiteを使う

SQLiteを使う機会があった。
GUIツールとして、DB Browser for SQLiteが使いやすかったのでメモ。

【参考】
DB Browser for SQLiteの使い方

SQLite入門 | DBOnline

SQLite | ビューを作成する

SQLite | 日付と時刻を取得する(date関数, time関数, datetime関数, julianday関数, strftime関数)

CSVをインポートすれば、SQLが使えるのでAccessみたいに扱える。
割と便利。

Accessのクエリの代わりに、Viewを作っておけば、Viewを組み合わせて割と複雑なデータ集計もできる。

僕はやっぱりSQLは好き。
データがあれば、SQLを駆使すれば、いくらでも好きな集計データを作れるのがいい。

「入門xyzzy」は唯一のテキストエディタxyzzyの解説本だった

テキストエディタxyzzyを愛用しているのだが、入門xyzzyなる本を見つけて読んでる。
自分のためのリンクのメモ。

xyzzy - カスタマイズ可能で軽快な Windows 用テキストエディタ

「xyzzy」「Emacs」風の老舗テキストエディター - 窓の杜

強力な拡張機能を備えたテキスト・エディタ | 日経クロステック（xTECH）

入門xyzzy | Ohmsha

（引用開始）
無料で使える高機能なテキストエディタ「xyzzy」の解説書
xyzzyは、高機能なWindows用のテキストエディタである。Lispインタプリタを内蔵しており、Windows用の一般的なエディタとEmacsの両方の特徴を持ち、根強い人気がある。本書は、xyzzyについて、これから使い始める入門者から思い通りに使いこなしたい中級者までを対象に、インストール手順や操作方法、便利な設定や追加機能などを平易に解説。この一冊で、xyzzyを使いこなせるような構成となっている。
このような方におすすめ
xyzzyをこれから使ってみたいと考えているWindows（2000/XP）ユーザ
既に使っているがさらに使いこなしたいと考えているユーザ
（HTMLを手書きするような人およびプログラマも含む）
（引用終了）

Manual of xyzzy

xyzzyはEmacsやMeadowのWindows版もどきのMDIエディタ。
割とカスタマイズもできる。
Emacsライクなキーバインドは、WordやExcelと異なるので、Windows風に変更する。
英単語を英語辞書で辞書引きできる。ポップアップ表示もできる。
インクリメンタルサーチもできる。

気に入っている機能は、各プログラミング言語のコードハイライト、強力なGrep機能と検索置換、アウトラインエディタ。
基本は、markdownで書いてアウトラインエディタにしている。
EclipseやVSCode、Wordが重たいと感じる時があるので、サクサク使えるエディタが一番いい。

xyzzy 関連　outline-tree2

CommonLispで作られているので、Lispがそのまま使えるのもいい。
xyzzyでCommonLispでプログラミングする解説本「入門Common Lisp―関数型4つの特徴とλ(ラムダ)計算」も見つけた。
Lisp初心者向けの本だがこれくらいで丁度いい。
もっと早く知っていれば、Lispと仲良くなれたかなと思う。

xyzzyっはもう人気がなくなったのか、色んなプラグインのサイトが閉じられていて、肝心の本家のGithubの更新も滞っている。
GitHub - xyzzy-022/xyzzy: xyzzy 0.2.2 系列。有志により開発が継続中です。
けれど、今後も長続きして欲しいと思うソフトウェアの一つ。