👍

Software DesignでNix連載しました

2025/12/19に公開

 はじめにこの記事は Nix Advent Calendar 2025 の18日目です。 昨日はComamocaさんによる NixでGleam(Erlang)をシングルバイナリにする でした。
幸運なことにSoftware Designにて連載を執筆する機会に恵まれました。 本記事では、同誌への寄稿を目指す方に向け、執筆の進め方や編集部とのやり取り、実際に経験して分かった執筆のポイントを紹介します。

 出版物2025年9月〜2026年1月まで全5回分書きました。
Software Design 2025年9月号 - 技術評論社
Software Design 2025年10月号 - 技術評論社
Software Design 2025年11月号 - 技術評論社
Software Design 2025年12月号 - 技術評論社
Software Design 2026年01月号 - 技術評論社
初回の2025年9月号では表紙に載りました。
この記事の投稿日である2025年12月17日に連載最終回が発売されるので是非皆さん書店で手に取ってみてください。

 連載のきっかけSoftware Design 2025年3月号にEmacsについて書きました にも書いたとおり、2025年1月に @tadsan と一緒に特集記事を書きました。
特集が終わった後、編集者の方に「Nixで連載か単著かできないですかねー」と雑に相談していました。
期間が空いた2025年3月頃に「2025年9月号から連載しませんか? 目次案を出して全何回になるのか出してほしい」と誘われたのでふたつ返事で受けました。

 目次想定読者を「ITエンジニア歴5年目くらいでざっくり業務をひととおり経験した」と設定し、途中から読んでも面白くなるように配慮しながら書きました。
また、NixはSoftware Design読者で知ってる人がほぼいないマイナー技術なので、技術的な説明を詳しくするというよりは読み物として面白くなるように設計しました。

 第1章Nixの歴史からざっくりどんなことができるものなのか、Nixの"つかみ"部分を簡単に説明しました。


章
タイトル


1.1
Hello Nix

1.2
Nixの歴史

1.3
Nixの仕組み

1.4
Nix使うと何が嬉しいの？

1.5
どんな時に使える？ 実際のユースケース

1.6
終わりに


 第2章Nixは重厚なものだと思われがちなので、まずは手元でちいさく簡単に動かせる方法を書いて気軽に導入できることを紹介しました。


章
タイトル


2.1
はじめに：なぜ「ちいさく」はじめるのか

2.2
Nixのインストール手順

2.3
Hello, Nix！まずは試してみる

2.4
ちいさく学ぶNix言語

2.5
開発環境の"ちいさな"構築術

2.6
終わりに


 第3章第2章で構築したものを応用してflake.nixで実際に自分のツールをbuildできるようになる所まで紹介しました。


章
タイトル


3.1
はじめに：Flakesによる再現性の厳密な保証

3.2
flake.nixの構造：inputsとoutputsからなる自己完結した定義

3.3
nix develop入門：モダンな開発環境への移行

3.4
nix buildの実践：自作ツールをNixパッケージにする

3.5
Nixの再現性を支える仕組み：Derivationと/nix/store

3.6
おわりに：ビルドの再現から、高度な開発環境構築へ


 第4章「プロジェクトで必要なpackage管理」「手元マシンのpackage管理」「OSの設定」という3軸でNixならどう管理するかというのを紹介しました。


章
タイトル


4.1
はじめに：環境管理の3つのスコープ

4.2
プロジェクト環境の管理:devenvによる高度な開発環境構築

4.3
個人ツールの管理：nix profileを使いこなす

4.4
個人設定の宣言的管理：home-managerの世界

4.5
macOSシステム設定の宣言的管理:nix-darwinの世界

4.6
終わりに：自分のマシンを宣言的に管理する


 第5章本番サーバでNixOSを運用する時の管理方法について紹介しました。


章
タイトル


5.1
はじめに：再現性をインフラへ

5.2
NixOSの始め方: 環境構築

5.3
単一サーバの宣言的管理

5.4
Flakesによる複数サーバ管理

5.5
NixOS運用の実践

5.6
おわりに：Nixとの旅を振り返って


 毎月のスケジュール次のようなスケジュールを計5回繰り返しました。 これはあくまで目安であり、スケジュールにはかなり融通を効かせてもらいました。（ご迷惑をおかけしました）
誌面PDFは実際に雑誌に掲載する形に組版されたものです。 誌面PDFになる前はGitHub上で管理をしており、誌面PDF後はPDFのコメント機能でやりとりをしていました。


日付
アクション


10日頃まで
初稿提出

20日頃まで
レビュー、校正、ファクトチェックなど

月末まで
誌面PDFにしてもらう、他編集者からのフィードバック調整

月末ぐらい
印刷所に入稿

翌月15日くらい
書店に並ぶ


 執筆について
 全体の流れ執筆だけにフォーカスして書くと、次の流れで対応していました。
7〜8割くらいのクオリティで書く
友人2人にレビューしてもらう
編集者にレビューしてもらう
ひととおり直して提出する

 執筆フロー最近自分は次のような執筆フローを踏むようにしています。
大見出し/小見出しをGeminiと対話して詰める
GeminiのDeep Researchを駆使して理解の浅い部分をひたすら潰して、関連リンクを読み漁る
小見出しに書く内容をひたすらに箇条書きする
文章の流れがおかしくないか等をClaude Codeと一緒に確認する
小見出しごとの分量を見積る
文章を一気に書く
Claude Codeにレビューしてもらいながら直す
画像やソースコードが入ると量は減るのですが、「1ページ 1200文字」「1回 8ページ」なので大体1万文字くらいを目安に書く必要があります。 本業のライターなら日に1万文字くらい書けるかもしれませんが、今年商業誌デビューした、素人に毛が生えた程度の文章力だと当然日数がかかります。 また、Nixについて知識が曖昧な部分や追加で調査しなくちゃいけない箇所は当然沢山あります。
連載なので5ヶ月の間、毎月一定量かつ高品質の文章を出力する必要がある訳です。 文章を書いてる人なら必ず「なかなか筆が乗らない」という状況はあると思います。
筆がどうやったら乗るのか考えた所、「筆が乗る日を1日に限定し、その1日のために1ヶ月かけて調査とメモを重ねる」ことで解決しました。 小見出しまでカチっと決めてから一気に書くことによって、起承転結や重複した文章の説明を気にせずに目の前の文章に集中でき、手戻りや混乱が大幅に減りました。
通勤中にスマホからGeminiに書こうと思っていることをひたすら対話して頭の中でイメージをつける
書こうと思っていることを雑に箇条書きでメモしておく、細かければ細かいほどよい
1日気合で筆を乗らせてレビューに耐えうる文章を書く
また、嬉々として調査したことを書いていると分量が爆発的に増えてしまいます。 できあがった文章から各章のバランスを意識して文字数を削るのは職人技です。 あらかじめ小見出しごとの分量を決めてから書くようにしたことで、各章の説明の過不足を減らし全体の分量をコントロールできたと思います。
書いた文章はClaude Codeに「この文章読んでて面白い?」「変なこと書いてない?」みたいなことを雑に相談して微修正してました。

 レビュー関連レビューは次の3人に実施してもらいました。
吉岡さん: プロの編集者目線
natsukium: nixpkgsメンテナ、nixに詳しい人目線
r-aizawa: nix初心者目線
レビューを受け入れるにあたって、基本的なスタンスは「要望は気軽に上げてほしい、受け入れるかは俺が決める」でした。
natsukiumとr-aizawaからはDMグループで五月雨式に気になった所を任意のタイミングで上げてもらい、編集者の吉岡さんからはIssueに纏めて上げてもらいました。 3者それぞれの目線からフィードバックしてもらったお陰でクオリティが一気に上がった実感があります。 レビューしてもらうなら、上級者目線、初級者目線、編集者目線の3軸用意することをオススメします。
指摘してもらった箇所は1commitずつ丁寧に修正して、各個人分ごとにPRを出してmergeしました。
余談ですが、natsukiumとr-aizawaはこの連載中に同僚になりました。

 Lint関連普段ブログを書く時に使ってる flake.nix をそのまま流用して使っています。 余談ですが、今回もMarkdownではなくOrgファイルで執筆し、Orgファイルのまま納品しています。
理想はtextlintに頼らず筆者の魂を込めた文章を書くべきなんだろうなと思いながらも日和ってtextlintを使ってしまっているのが現状です。 文章力を高めたいですね。
{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs";
    nur-packages.url = "github:takeokunn/nur-packages";
  };

  outputs = { self, nixpkgs, nur-packages }:
    let
      systems = [
        "x86_64-linux"
        "aarch64-darwin"
      ];

      forAllSystems = f: nixpkgs.lib.genAttrs systems (system: f system);
    in
      {
        devShells = forAllSystems (
          system:
          let
            pkgs = nixpkgs.legacyPackages.${system};
            nur-pkgs = nur-packages.legacyPackages.${system};
            textlintrc = (pkgs.formats.json { }).generate "textlintrc" {
              plugins = {
                org = true;
              };
              rules = {
                preset-ja-technical-writing = {
                  ja-no-weak-phrase = false;
                  ja-no-mixed-period = false;
                  no-exclamation-question-mark = false;
                  sentence-length = false;
                  no-doubled-joshi = false;
                  max-kanji-continuous-len = false;
                };
                write-good = {
                  weasel = false;
                };
                preset-japanese = {
                  sentence-length = false;
                  no-doubled-joshi = false;
                };
                prh = {
                  rulePaths = [
                    "${pkgs.textlint-rule-prh}/lib/node_modules/textlint-rule-prh/node_modules/prh/prh-rules/media/techbooster.yml"
                  ];
                };
              };
            };
          in
            {
              default = pkgs.mkShell {
                packages = with pkgs; [
                  nodejs
                  (textlint.withPackages [
                    textlint-rule-preset-ja-technical-writing
                    textlint-rule-prh
                    textlint-rule-write-good
                    textlint-plugin-org
                    nur-pkgs.textlint-rule-preset-japanese
                  ])
                ];

                shellHook = ''
                  [ -f .textlintrc ] && unlink .textlintrc
                  ln -s ${textlintrc} .textlintrc
                '';
              };
            }
        );
      };
}

 良かったこともっとも良かったことは、「面白かったよー」っていうフィードバックを沢山いただけたことでした。 「Nixを知らない人でも読み物として面白くする」というのがテーマだったので目標とおりの結果になったことが非常によかったです。 雑誌を持ってきてくれて「サインしてくれ!!」 っていわれたり、ちょっとした有名人感を味わえて楽しかったです。 やはりこの辺の満足感は個人ブログがバズった時の比じゃないくらいに嬉しいものです。
チームとしても大成功しました。 振り返るとレビューのやりとりも日々のコミュニケーションもすごく円滑に行えたなと思いました。 進捗の有無にかかわらずこまめに報連相して状況を共有するのが重要ですね。 プロの編集者のレビューを受けられることは福利厚生ですね。

 大変だったこと入稿したら次、入稿したら次、と中距離走が5回続くのは体力が必要でした。 全国の本屋に置かれるので適当な文章を書く訳にはいかないなとプレッシャーがかなりありました。 終わった時の解放感や安堵感が強かったです。
今回かなり自分の中でノウハウ化できたので、もし強くてニューゲームできたら多分この半分くらいの労力で書けるだろうなーという感覚があります。 ちょうどよい負荷だったかもしれませんね。

 終わりに雑誌という形として書店に置かれてるのを見るとニヤニヤしちゃいますね。 無事完走できてよかったです。
レビューに関わってくれた吉岡さん、natsukium、r-aizawa本当にありがとうございました!! たけてぃ先生の次回作にご期待ください!!

章	タイトル
1.1	Hello Nix
1.2	Nixの歴史
1.3	Nixの仕組み
1.4	Nix使うと何が嬉しいの？
1.5	どんな時に使える？実際のユースケース
1.6	終わりに

章	タイトル
2.1	はじめに：なぜ「ちいさく」はじめるのか
2.2	Nixのインストール手順
2.3	Hello, Nix！まずは試してみる
2.4	ちいさく学ぶNix言語
2.5	開発環境の"ちいさな"構築術
2.6	終わりに

章	タイトル
3.1	はじめに：Flakesによる再現性の厳密な保証
3.2	flake.nixの構造：inputsとoutputsからなる自己完結した定義
3.3	nix develop入門：モダンな開発環境への移行
3.4	nix buildの実践：自作ツールをNixパッケージにする
3.5	Nixの再現性を支える仕組み：Derivationと/nix/store
3.6	おわりに：ビルドの再現から、高度な開発環境構築へ

章	タイトル
4.1	はじめに：環境管理の3つのスコープ
4.2	プロジェクト環境の管理:devenvによる高度な開発環境構築
4.3	個人ツールの管理：nix profileを使いこなす
4.4	個人設定の宣言的管理：home-managerの世界
4.5	macOSシステム設定の宣言的管理:nix-darwinの世界
4.6	終わりに：自分のマシンを宣言的に管理する

章	タイトル
5.1	はじめに：再現性をインフラへ
5.2	NixOSの始め方: 環境構築
5.3	単一サーバの宣言的管理
5.4	Flakesによる複数サーバ管理
5.5	NixOS運用の実践
5.6	おわりに：Nixとの旅を振り返って

日付	アクション
10日頃まで	初稿提出
20日頃まで	レビュー、校正、ファクトチェックなど
月末まで	誌面PDFにしてもらう、他編集者からのフィードバック調整
月末ぐらい	印刷所に入稿
翌月15日くらい	書店に並ぶ

GitHubで編集を提案

はじめに

出版物

連載のきっかけ

目次

第1章

第2章

第3章

第4章

第5章

毎月のスケジュール

執筆について

全体の流れ

執筆フロー

レビュー関連

Lint関連

良かったこと

大変だったこと

終わりに

Discussion