Bram Moolenaar と Vim：エディタ文化が開発者の習慣を作った方法

テキストエディタを超えて Vim が重要な理由

Bram Moolenaar は Vim を、古典的な vi エディタを改善したかたちで作りましたが、Vim が数十年にわたって残った理由は単に技術的なものだけではありません。Vim は共有された作業様式になり、チームやチュートリアル、オープンソースのプロジェクトを通じて広がりました。Bram の逝去を受けた多くの追悼はこの点を強調しています：Vim は単に人々が使うソフトウェアではなく、人々が学び日常の仕事に持ち込む何かでした。

「エディタ文化」が意味するもの

開発者が「エディタ文化」と言うとき、それは単なる好み以上のものを指します。ツールの周りにできる習慣や規範の集合です：

• みんなが知っていることを期待する共通のショートカット
• 設定の慣習（vimrc を共有するなど）
• ワークフローを語る語彙（「どうやって移動する？」「どうやって素早くリファクタする？」）
• メンタリングの儀式：誰かの編集を見てテクニックを吸収する

この文化は行動を形作ります。同じファイルを同じエディタで開いても、練習された習慣の差で動きがまったく違うことがあります。それは才能の差ではなく、習慣の差です。

この記事で得られること

これはコマンド事典ではありません。代わりに、Vim が普及させたワークフローパターン、つまり繰り返し可能な編集ルーチンの作り方、小さな変更の摩擦を減らす方法、大きなファイルで方角（位置）を見失わないコツを学びます。

「Vim 人間」である必要はなく、技術的な背景がなくてもついていけます。専門用語は控えめにし、やさしい言葉でアイデアを説明し、習慣がなぜ重要かに焦点を当てます—たとえ今別のエディタを使っていても役立つ考え方です。

Bram Moolenaar の物語と Vim の長い歩み

Bram Moolenaar（1961–2023）は Vim のアイデンティティと切り離せません。Vim が一人プロジェクトだったからではなく、ボランティア主体のツールを数十年にわたり一貫性あるまま維持する安定した舵取りを行ったからです。

短いタイムライン：クローンからクロスプラットフォームの常連へ

Vim のルーツは vi エディタの伝統にあります。Bram は 1980 年代後半、Commodore Amiga 上で既存の vi 風エディタを改良する形でプロジェクトを始めました。そこから Vim は出自を越えて急速に成長しました：1990 年代初頭のリリースで機能や移植性が広がり、Unix、Windows、後には macOS や Linux といった開発環境が一般的になるにつれて、ほぼどこでも Vim が使えるようになりました。

このクロスプラットフォーム性は大きな意味を持ちます。家庭のマシン、大学のラボ、職場のサーバで同じように動作するツールは信頼を得ます。その信頼が Vim を専門家にも趣味者にも長く受け入れられるデフォルトにしました。

メンテナとして、コミュニティの支柱としての Bram

オープンソースプロジェクトは、調整がコーディングより難しくなったときに静かに失敗することがよくあります。Bram の重要な貢献は「メンテナンスを技術として行う」ことでした：パッチのレビュー、リリースの指導、ドキュメントと挙動の一貫性の維持、人々が協力するための規範の形成です。多くの貢献者が Vim を改良しましたが、誰かが全体を整えてくれていたからこそエディタの「感触」は保たれました。

チャリティウェアの精神

Vim は「チャリティウェア」としても知られていました。大まかな考え方は単純です：Vim が有用なら、Bram が推奨する慈善活動に寄付を検討してほしい。使用のための支払いではなく、ただ優しく「還元してください」と促すものでした—ソフトウェア文化が効率だけでなく寛容さを含めうることの早期の示唆でした。

Vim の長い歩みは結局「継続性」の話です：流行を追うのではなく、慎重に進化しつつコミュニティと価値観を保ち続けたエディタの物語です。

モーダル編集：行動を変える核となる考え方

Vim の最も特徴的な考えは「モード」です。同じキーが意図によって別の仕事をします。これは奇妙に聞こえますが、実は既に行っている作業を反映しています—時には変更について考えている、時には文字を打ち込んでいるのです。

多くの人が最初に出会う三つのモード

Normal mode は編集アクションのためのモード：移動、削除、変更、検索。書き込みではなく指示を出すモードです。

Insert mode は文字を文書に入力するモード—ほとんどのエディタがデフォルトとする動作です。

Visual mode はテキストを選択して操作するためのモード（インデント、削除、変更、コピーなど）。

簡単な例：

• Normal mode で dd を押すと行全体を削除します。
• i を押して Insert mode に入り、新しい内容を入力します。
• Esc を押して Normal mode に戻ります。
• v を押して Visual mode を開始し、移動で選択してから d を押して選択を削除します。

「考える」ことと「打つ」ことの分離が摩擦を減らす

すべてが常に打ち込みモードだと、作曲と編集の二つの異なる作業が混ざってしまいます。モーダル編集はそれらを分けます。

Normal mode では手が無意識に文字を挿入してしまわないので、より意図的になれます：どんな変更をしたいか？ ここを削除、あれを変更、そこに移動、繰り返す。Insert mode は文字を追加するための集中した瞬間になります：今は書き込んでいる。

時間が経つと、エディタと格闘するのではなく、明確で小さな指示を与えているように感じられるようになります。

初心者の混乱とよりよいフレーミング

よくある初期のつまづき：

• 「テキストが消えたのはなぜ？」（Normal mode にいて x や dd のようなコマンドを押した）
• 「入力できないのはなぜ？」（まだ Normal mode にいる—i を押してください）
• 「Esc がそんなに重要なのはなぜ？」（モードをリセットして、挿入ではなく指示する側に戻るからです）

モードを意図の状態として再定義しましょう。Normal mode は「動かせない」状態ではなく、意図的に編集するモードです。これがモーダル編集が教える習慣です：まず意図的に変更し、次にタイプする。

合成可能性：小さなコマンドが組み合わさって力になる

Vim の「特権」は膨大なメニューではなく、小さなコマンドがパチッと組み合わさる点にあります。すべての場合ごとに別のショートカットを覚えるのではなく、いくつかの基礎ブロックを学んで組み合わせるのです。

動詞 + 対象（わかりやすく）

編集を 動詞を対象に適用すること と考えてください。

• 動詞 はやりたいこと：削除する、変更する、コピーする。
• 対象 はテキストの指し示し方：単語、行末まで、引用の内側。

Vim の用語では、動詞は オペレータ（d は delete、c は change など）、対象は モーション／テキストオブジェクト（w は単語、) は文、i" は引用内）です。

日常で実感できる例

いくつかの組み合わせで効果がわかります：

• 単語を変更：cw — “change” + “word”。先に選択する必要はありません。
• 引用内を削除：di" — “delete” + “inside quotes”。引用符は残して中身だけ削除します。
• ブロックを選択：v してから i{ のように操作すると、{ ... } の中身をつかめます。

ポイントはトリックを集めることではなく、コマンドが予測可能なメンタルモデルを作ることです。

自信は速度より先に伸びる

合成可能性は正確さと一貫性に報います。同じ動詞が多くの対象で機能すると、編集の「当て推量」が減り、Undo が少なくなり、落ち着いて未知のファイルに取り組めます。速度は後からついてくることが多いです—速さを目標にするのではなく、信頼できる思考法を繰り返すことで自然に速くなります。

繰り返し可能性：ドット、マクロ、検索をワークフローの基礎にする

Vim の実用的な考え方の一つは、編集は一発芸ではないということです。一度編集を記述できれば、その編集を次の行や次の段落、次のファイルでも再現できるべきだ、という考え方です。ここで「速さ」は打鍵数の多さではなく意思決定疲労を減らすことになります。

ドットコマンド：最後の変更を繰り返す

ドット（.）は直前の変更を再現します。小さい機能に聞こえますが、編集をきれいで繰り返し可能な塊にすることを奨励します。

例：ある行で foo を foo() に変更したら、次の出現箇所ではカーソルを合わせて . を押すだけで同じ編集を繰り返せます。習慣はこうです：一つの編集を丁寧にやって、それを繰り返す。

マクロ：短い編集の“レシピ”を記録する

マクロはキー入力の一連を記録して再生します。概念的には「このパターンを見たら、この手順を実行する」と言っているのと同じです。安全でシンプルな使い方はリストの整形など：

• 複数行の先頭に - を追加する
• 複数行の末尾にカンマを付ける

テキストが一貫していない場合は過剰な自動化を避けてください。各行に異なる判断が必要なときにマクロを使うと、見つけにくいミスを高速で生み出してしまいます。

検索と置換：明確な意図を拡大する

検索は既にナビゲーションツールです。置換は検索にアクションを付けたものです。平易に考えてください：「この文字列を見つけて、あれに置き換える」。たとえば temp を draft に変えるときです。変更が関係のない箇所にも当たる可能性があるなら、無条件で全置換するのではなく一つずつ確認しましょう。

大きな教訓は、よく使う編集のために繰り返しできるレシピを作ることです。時間が経つと、ワークフローはアドホックな修正の連続ではなく、小さく信頼できる動きのライブラリになります。

キーボード優先の習慣とフローを保つ方法

Vim のキーボード中心のスタイルは純粋主義のテストではなく、マウスやトラックパッドに手を伸ばすたびに小さな注意のループが切れてしまう点に意味があります—手がホームポジションを離れ、目がカーソルを探し、脳が「何をするか」から「どこを操作するか」へと切り替わるのです。こうした中断を減らすことで、取り組んでいる問題への集中を保ちやすくなります。

ナビゲーションをテクニックではなく習慣にする

Vim はテキストをあなたが考える単位で移動するよう促します：

• 単語や文で（w、b、e、)）――文章や識別子を整形するときに便利。
• 行やカラムで（0、^、$、gg、G）――構造を意識するときに。
• 記号やパターンで（/、?、n、N）――意図を探すときに。
• ファイルや位置で（バッファ、:e、:b、タグや LSP ジャンプ）――変更がコードベースにまたがるときに。

時間が経つと「対象へ移動する」は毎回のミニ判断ではなく反射になります。

マイクロ最適化が筋肉記憶に変わる

本当の利得はミリ秒を削ることではなく、ためらいを取り除くことです。「引用内を変更する」「次のコンマまで削除する」といった小さな繰り返し動作が筋肉記憶になります。それらのパターンが定着すると、エディタの操作に使う心のエネルギーが減り、どの変更を選ぶかにより多くを割けるようになります。

アクセシビリティと人間工学：人による

キーボード中心のワークフローは手首の移動を減らす人もいれば、指への負担を増やす人もいます。人、キーボード配列、コマンドの選び方によって効果は変わります。Vim のカスタマイズ文化はここで役立ちます：押しにくいキーはリマップし、使うペースを守り、イデオロギーより快適さを優先してください。目標は持続可能な集中であって、耐久力を競うことではありません。

設定文化：vimrc、プラグイン、個人のデフォルト

Vim は所有を奨励します。エディタを封印された製品と扱うのではなく、作業台として調整して自分の考え方に合わせるものだとみなします。

vimrc とは（なぜ人々が気にするのか）

vimrc は Vim の設定ファイルです。ここでデフォルトを決めます：タブの振る舞い、行の折り返し、ステータスラインに何を表示するか、など。多くの開発者はこれらの設定をバージョン管理して dotfiles として持ち運び、どのマシンでも馴染みのあるエディタにします。

これは単なる個人化ではありません。小さなデフォルトの積み重ねが摩擦を減らし、驚きを減らすからです。Vim が「なぜこう動くの？」という瞬間を減らすことが文化的な理由です。

設定を整理する現実的な方法

プラグインを十個入れてから問題を理解しようとすると、汚いセットアップになりがちです。健全なアプローチ：

• 小さく始める：日々の不満だけを直す。
• 選択を文書化する：なぜその設定があるかコメントする。
• 肥大化を避ける：週に一度使わないものは疑う。

vimrc を雑多な引き出しではなく、作業日誌のように扱ってください。

マッピングとプラグインを平易に説明すると

マッピング はショートカットです：一つのキー操作で長いコマンド列を実行します。良いマッピングは繰り返しを減らし、悪いマッピングは Vim を一貫性のないものにします。

プラグイン は機能を追加します：ファイルピッカー、Git ヘルパー、言語サポートの強化など。プラグインは便利ですが、起動時間や新しい振る舞いを学ぶコストも増やします。

「最小限の Vim」ベースライン

余計なものを入れる前に、いくつかの基本を身につけましょう：

• 妥当なインデント（スペースかタブか）
• 検索の振る舞い（ハイライト、大小文字ルール）
• 行番号の表示（絶対／相対）
• 読みやすい簡素なカラースキーム

そのベースラインが自然に感じられるようになってから、プラグインは学習の代わりではなく意図的な拡張になります。

学習とコミュニティ：ヘルプ、メンタリング、規範

Vim の文化はプラグインやホットキーから始まるのではなく、学習から始まります。Bram Moolenaar はドキュメントを製品の一部として扱い、その態度が Vim の教え方を形作りました：Vim は秘密のセットではなく、着実に育てられるスキルとして教えられます。

ヘルプシステムはセルフサービスの学習ツール

Vim の :help は手間のかかる付属物ではなく地図です。トピック、相互参照、例が用意されていて、探究心に報います。

いくつかの小さな習慣で「詰まった」を「見つけられる」に変えられます：

• :help {topic}（または :h）で :h motion や :h visual-mode のように特定概念に飛ぶ。
• ヘルプ内のリンクに CTRL-] で飛び、CTRL-T で戻る。
• 用語がわからないときは :helpgrep {word} でドキュメント全体を検索する。

このモデルは拡張可能です：エディタに質問する方法を学べば、覚えるべき一覧に頼る必要が減ります。

メンタリングとコミュニティの規範

Vim のメンタリングは小さく、敬意を持った介入に見えます：一つのマッピング、一つのモーション、一つのワークフローチップを共有する。暗黙のルールは「相手の今いる場所で受け入れること」です。よくある習慣として、「既にあなたのエディタでうまくいっているならそれでいい」と付け加えることも普通です。

他の実用的な規範：

• 再現可能なアドバイスを共有する（正確なコマンドや最小限の設定を含める）
• 設定の違いを尊重する（ターミナル版か GUI 版か、ミニマル Vim か重めの Neovim か）
• 概念を教えること（純粋性のテストはしない）

規範がどう伝播するか

Vim の知識はチートシート、ライトニングトーク、dotfile テンプレート、小さな「スターター」リポジトリといった軽量のアーティファクトを通じて広がります。良い資料は「何を打つか」だけでなく「なぜその習慣が役立つか」を説明します。

深さは人それぞれで良い

ある人は SSH での短い編集にしか Vim を使わないかもしれませんし、別の人は日常環境を Vim に組み込むかもしれません。Vim 文化が機能するのは、どちらの到達点も正当として扱い、そこへの道筋を照らし続けるときです。

実務での Vim：ちょっとした修正から日常の開発まで

Vim の評判は「パワー」に支えられていますが、本当の価値は日常の場面に現れます：明確にしたいコミットメッセージ、慎重に変更する必要のある本番の設定ファイル、ペアリング中に正確で説明しやすい編集がほしいときなどです。

実際に使う典型的なワークフロー

コミット編集： 多くの開発者は Git を Vim でコミットメッセージやインタラクティブリベースを開くように設定します。モーダル編集はここに合います。読む・並べ替える作業が多く、Normal mode がレビュー用のモードになります：文の間をジャンプし、行を入れ替え、小さな修正をマウスに頼らず行えます。

サーバでの迅速修正： SSH でマシンに入って設定をパッチする必要があるとき、Vim は既に利用可能であることが多いです。目標はカスタマイズではなく自信です：正しい stanza を検索し、意図したところだけを変え、保存してきれいに終了する。

ペアリング： Vim は意外に「ペア向き」です。操作が明示的だからです。「この段落を削除して」「引用内を変更して」と言えば、コマンドが明確で観察を通じて学べます。

エディタの周りにある小さなツールとの統合

Vim はチェーンの一部として使うと光ります。ripgrep/grep で検索し、結果を開いて対象を編集する――エディタそのものをフル IDE にするのではなく、得意分野で使うのです。

よくあるループの例：端末で検索を実行し、ファイルを該当箇所で開き編集し、テストを再実行する。端末が検索を担当し、Vim が編集を担当し、テストランナーが検証する。日常作業に「一芸を極める」を当てはめた形です。

日常のきれいなセットアップ（クイックチェックリスト）

• Git のエディタを設定：git config --global core.editor "vim"
• 基本をオンにする：行番号、妥当なインデント、検索ハイライト
• 毎時使ういくつかの移動／編集を覚える（検索、単語を変更、区切り内を変更）
• 使う改善は一度に一つずつ（ファイルファインダ、コメント機能など）
• 小さく読みやすい vimrc を保ち、どこでも再現できるようにする

これが Vim の拡張方法です：複雑さを増やすのではなく、共通編集を速く、可逆で、一貫したものにします。

トレードオフと誤解：バランスの取れた見方

Vim には明確な利点がありますが、神話も集めがちです。中には週末試してそれで語る人や、バッジのように扱う熱狂的なファンもいます。実用的に言えば：Vim は一連の操作思想（特にモーダル編集）であり、多くのワークフローに適合し得ますが、必ずしもすべての人やチームに自動的に最良というわけではありません。

よくある批判（と実際のところ）

「習得曲線が急だ」

最初は急に感じるのは当然です：モード、オペレータ＋モーション、動詞中心の編集といった基本が違うからです。小さなコアを学んで日常的に使えば曲線は緩やかになりますが、たまにしか開かないなら筋肉記憶は定着しません。

「発見性が低い」

部分的には本当です。Vim は機能を常に広告するインターフェースではありません。発見の場はヘルプ、組み込みチュートリアル、共有される小さなパターンの文化にあります。

「Vim は人それぞれ違う」

これも事実です。設定は人によって異なり、プラグインで振る舞いが変わり、環境ごとにデフォルトも違います。ペアリングやマシンをまたぐときのフラストレーションは現実です。多くのチームはすべてを標準化しようとする代わりに、最小限の共通規約（あるいは「バニラ Vim を使う」という合意）で対処します。

Vim が不向きな場合

チームの制約が特定の IDE ワークフローを要求する、オンボーディング時間が限られている、あるいはアクセシビリティの要求でキー中心の操作が困難な場合、Vim は適切でないことがあります。好みも重要です：視覚的な UI とリッチなリファクタリングを好む人はそこで最良の仕事ができるでしょう。

実用的には、実際にやっている作業を支えるツールを選ぶのが良いです：SSH での迅速な編集なのか、設定ファイルの編集なのか、コードを書く日常なのか、標準化された環境での共同作業なのか。

生産性の罠を避ける

やる気のある学習者を捕らえる罠が二つあります：

一つは終わりのない調整—プラグインをいじる時間が実際に使う時間を食ってしまうこと。二つ目はショートカット集め—コマンドを集めるだけで繰り返し可能な習慣を作らないこと。Vim によって速くなりたいなら、週に一度は繰り返すワークフローに集中し、名前を付けられるものだけ自動化してください。

健全なルール：ある変更が次の週に時間を節約したりミスを減らさないなら、それは保留にする。

バランスの取れた指針

Vim はフローを保ち、意図をもって編集し、繰り返し可能なパターンを作るのに役立つときに最も価値があります。別のエディタの方があなたやチームにとってより良ければ、罪悪感なくそちらを選んでください。目標は「Vim を使うこと」ではなく、摩擦を減らして良い成果を出すことです。

実践的な学習経路：暗記ではなく習慣を作る

Vim はいくつかの信頼できる習慣を作ることで身につきます。目的は「速く」なることではなく、編集時に落ち着いて対処できることです。

2～4 週間のシンプルプラン（少しずつ毎日練習）

1 日 10–15 分を費やし、実際のタスクをひとつ Vim でこなしてください（小さなもので構いません）。どこがぎこちないか、どこが楽になったかをメモしましょう。

Week 1: 安心と安全

ファイルを開く、保存する、終了する、Undo を練習して詰まらないことに集中します。

Week 2: ナビゲーションと検索

より大きな跳躍で移動することと検索を頼りにしてどこへでも行けるようにします。

Weeks 3–4: 編集ワークフロー

小さな「編集＋繰り返し」パターンを追加します：change/delete/yank、. での繰り返し、頻繁に行うことのための基本的なマクロなど。

実際に使うスタータ習慣

• 安全に終了：:w、:q、:wq、:q!、および u（undo）と <C-r>（redo）
• 効率的に移動：w、b、e、0、$、gg、G、と少しの f{char}
• 自信を持って検索：/pattern、n / N、:%s/old/new/g（まずはフラグなしで試す）

実践的な練習案

README を編集して見出しを直し、箇条書きを並べ替え、段落を書き直してマウスを使わない。
小さなファイルをリファクタリング：検索＋置換で変数名を変え、数行を切り出して再インデントする。
日記を Vim で書く：毎日短いエントリを書く。繰り返しが慣れを早めます。

測るべき正しいこと

測るべきは 快適さ（パニックが減る）と 一貫性（コンテキストスイッチが減る）であって、生の速度ではありません。コマンドが何をするか予測でき、間違えたときに回復できれば、それが長続きする学びの兆しです。

レガシー：Vim がクラフトとコミュニティについて教えること

Bram Moolenaar の持続的な影響は、単に Vim を作ったことではなく、忍耐強い手入れがどのようなものかを示したことにあります。何十年も彼はパッチをレビューし、リリースを管理し、質問に答え、ツールの「感触」を効率的で一貫性があり、学べば寛容であるものとして保ちました。Vim のチャリティウェアの伝統も Bram の価値観を反映していました：ソフトウェアは公共財になり得る、そしてメンテナンスは丁寧に扱われるべき仕事だと。

クラフト：小さな習慣の積み重ね

Vim は小さく繰り返せる行動に注意を払うことに報います。大事なのは特定のコマンドではなく、摩擦を減らす習慣に投資するというマインドセットです。編集ごとに数秒を節約しても、それがデフォルトの考え方になると大きな違いになります。時間が経てばエディタは操作する道具から、作品を作るために通り抜ける媒体になります。

興味深いことに、この「意図優先」の考え方は新しいワークフローにもよく移ります。たとえば Koder.ai の vibe-coding のようなチャット型のインターフェースでソフトウェアを作る場合も同様です：変更を明確で繰り返せる指示として行い、小さく反復し、スナップショットやロールバックのような安全策に頼る—一度に大きく書き換えるのではなく。

コミュニティ：人が関わり続けるとツールは生き残る

Vim はまた社会的な技術も教えます：公開で学び、dotfile を思慮深く共有し、明確なバグ報告を書き、新人に対して忍耐強く接する。健全な規範は「難しい」ツールを近づきやすくします。深く学びたいなら、組み込みヘルプやコミュニティリソースは製品の一部であってオプションではないと理解してください。

この記事を閉じる前に、今週試すワークフローを一つ選んでください：よく手が伸びるキーをリマップする、繰り返し可能な編集パターンを一つ練習する、あるいは小さな個人的デフォルトを vimrc に書き留めるなど。

最後に一言：オープンソースのコミュニティはユーザーが支持者になることで生き続けます—寄付、ドキュメント、注意深い Issue、コードレビュー、あるいは単に「ありがとう」と言うことでも。Bram の遺産は、我々のツールを保守する人々がツール自体と同じくらい重要であることを思い出させてくれます。