はじめに はじめにNTT西日本の長谷川です。 本記事では、セキュリティ業界の有志で運営している「MINI Hardening」というコミュニティのメンバーにより開発された、サイバー攻撃を想定したインシデント・レスポンスを体験するためのトレーニングツール「ZANSIN」の体験談と自身で環境を構築する際の手順と注意点をまとめています。 ※Hardening とは情報セキュリティ分野においてセキュリティ強化演習を指す用語です。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN セキュリティの勉強をすすめていると、よく攻撃手法やその脅威をテキストとして見ることはありますが、座学だけではその動きや脅威はあまり実感できません。 このZANSINはそれを体験できるツールですので、セキュリティのスキル強化やセキュリティ対策の重要性を理解し、スキルアップに役立てるべく紹介していきます。 トレーニング環境はローカル環境やプライベートゾーンなど外部から悪用されない安全な環境で構築してください。 許可なくインターネットサイトを攻撃することは法律（不正アクセス禁止法等）に抵触する行為となるため、絶対に行わないでください。 この「ZANSIN」を用いて以下の習得が期待できます。 実践的なセキュリティ強化スキル 脆弱性をついた攻撃とその対策方法 セキュリティ対策の重要性 本ツールは体験・トレーニングツールとして公開されているため、初級～中級を主なターゲットにしています。 対象読者 本記事が想定する対象読者は以下の通りです。 サーバーのセキュリティ対策に興味があり、そのスキルを伸ばしたい方 サイバーセキュリティ対策の腕試しをしたい方 サイバーセキュリティ対策の実践力を鍛えたい方 目次 はじめに 対象読者 目次 1.背景 2.ZANSIN利用の目的 2-1. 実践的なセキュリティ強化の習得 2-2. 脅威モデリングと対策検討 2-3.ZANSINのトレーニングシナリオ 2-4.ゲームサーバー（Trainingサーバー）の構成 2-5.トレーニング例 3.ZANSINを使ったトレーニングイベントに参加してみて 3-1.チームでのトレーニング 3-2.実際のトレーニング結果 3-3.トレーニングを受けて感じたこと 4.ZANSINの構築方法 4-1.要求スペック 4-2.構築場所 4-3.ローカル環境におけるOS構築手順（Controlサーバー、Trainingサーバーで共通） 4-4.クラウド環境におけるZANSIN事前設定（AWS＆Azureのみ実施) 4-5.ZANSIN構築手順（ローカル環境、クラウド環境共通） 4-6.ZANSINトレーニング開始 5.最後に 執筆者　 参考資料・出典 商標　 免責事項 1.背景 セキュリティの勉強を進めていくと、さまざまな攻撃や脆弱性について語られることがありますが机上では学べないものが多く、以下のように悩むことがあります。 実際に脆弱性をついた攻撃などを体験する機会がない。 脆弱性を確認するにも環境構築からが大変。 実践的なスキルを身につける環境が欲しい。 私自身も、頭では理解しているつもりでも「実際に何が起きるのか」が結び付かず、もどかしさを感じていました。 このような悩みを持つ方も多いのではないでしょうか？ こういった机上では学べないことを実際に体験してみましょう。 2.ZANSIN利用の目的 2-1. 実践的なセキュリティ強化の習得 ZANSIN は Ubuntu®で構築されたControlサーバーとTrainingサーバーの2台で構成され、Trainingサーバーには「MINI QUEST」というWeb ゲームが稼働しています。 ControlサーバーはTrainingサーバーに対してサイバー攻撃を行います。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN 利用者はTrainingサーバーに潜む脆弱性を特定し、対策を施していくことでサイバー攻撃や不正行為に対して迅速かつ効果的な対応スキルを体験的に学ぶことができます。 実行される攻撃例 不正ログイン バックドア設置 ゲームサービス妨害 ゲームのチート行為 これらの攻撃に対する対策を通してセキュリティ対策スキルを養っていきます。 トレーニングの性質上どういった攻撃が実行されるかは明示しませんが、よく耳にする攻撃からの対策方法を学ぶことができます。 （あくまで防御について学ぶトレーニングツールであり、攻撃手法が学べるものではありません） ZANSINはあえて複数の脆弱性を含んだシステムを用意し、攻撃を受けながら守り方を学ぶという設計思想となっています。 実運用では本来避けるべき構成や設定も含まれていますが、それらを「なぜ危険か」「どう検知し、どう是正するか」を体験的に理解することを目的としています。 ※ZANSINは教育目的専用のツールです。実際の本番システムへの攻撃に応用することは法律で禁止されています（不正アクセス禁止法等） 2-2. 脅威モデリングと対策検討 事前資料から潜在的な脆弱性の洗い出し、攻撃シナリオの想定を行うことでセキュリティ設計の基本も体験できます。 ぶっつけ本番でおこなって体験するのもいいですが、効果的なトレーニングにするためにはしっかり事前準備するとより効果が得られます。 2-3.ZANSINのトレーニングシナリオ ZANSINは以下の指示に従ったトレーニングを行います。 Ubuntuで構築されたゲームサーバー（Trainingサーバー）が公開されましたが、脆弱性を含んでいるようです。 ゲームサーバー（Trainingサーバー）にはMINI QUESTと呼ばれるブラウザゲームが稼働しています。 ゲームサーバー（Trainingサーバー）がサイバー攻撃にさらされています。サイバー攻撃に対応しシステムを保護してください。 稼働しているMINI QUESTをチート行為から守ってください。 トレーニング時間（240min）の間に多様な攻撃が行われます。どの程度脆弱性が修正されたかで評価します。 2-4.ゲームサーバー（Trainingサーバー）の構成 ゲームサーバーにはUbuntu上に構築されたNGINX®、MySQL®、Redis®、Docker®で動作しており、構成は概略として以下となっています。 出典：ZANSIN（GitHub） https://github.com/ZANSIN-sec/ZANSIN このゲームサーバには多くの脆弱性が潜んでいます。 トレーニングを受けるユーザーはこの構成図と配布されるGAME API設計書から脆弱性の予測と洗い出しを行い、トレーニングに挑みます。 2-5.トレーニング例 トレーニングに影響が出るといけないので、多くは書けませんが、 実際にどのような攻撃が行われるか一つの例をあげてみます。 Trainingサーバーにはいくつかの脆弱性があります。 その中の一つに脆弱なパスワードを使っているユーザーがいます。 それを放置しているとパスワードを推測されて不正ログインされた結果、管理者権限を奪われ、バックドアとなる不正ユーザーが作成されます。（不正ユーザーが作成される経路は複数用意されています） ログなどから不審なユーザーが登録されていることを見つけることができれば、その後バックドア経由での攻撃を防げるかもしれません。 他にもセキュリティを勉強しているとよく目にするいろいろな攻撃が仕掛けられます。 ログや配布資料をもとに攻撃を特定し対策をしていきます。 3.ZANSINを使ったトレーニングイベントに参加してみて 実際に私もZANSINを使ったトレーニングイベントに参加してみました。 3-1.チームでのトレーニング トレーニングイベントでは参加者は4～5人のチームに割り振られました。 チームごとに提供された事前情報をもとにサーバーを防御するというものでした。 このときはZANSINというものは知っていたので、実際に体験するいい機会でした。 イベントでは初対面同士でチームが構成されてトレーニングに臨みました。 写真：社内で実施したトレーニングイベントの様子 トレーニング実施前の準備時間に、与えられた情報から簡単に以下の役割を決めました。 全体管理 ログ等からの分析 実際の改修、修復 3-2.実際のトレーニング結果 実際にトレーニングを行った結果はボロボロでした。 （普段から専門的にセキュリティ対策に携わっていないと初見ではかなりやられると思います） ですが、今まで机上でしか知ることがなかった攻撃が目の前で実行されます。 それをログなどから追いかけ対策を講じていくというのは非常に多くの学びがありました。 紹介していたようにWeb ゲームが動いていますが、どうしようもなく破壊されたときには頭を抱えるほどでした。 3-3.トレーニングを受けて感じたこと 実践的な経験を通じたトレーニングの有効性を改めて実感しました。 私は即席のチームでイベントに臨みましたが、いろいろな対応が必要になるためチームビルディングの重要性を感じました。 トレーニングに挑む際には以下にあげたような役割を決めて挑むほうが、慌てず対処できると思います。 全体管理 ログ分析（攻撃監視） 対策（スクリプト・設定修正） ZANSINは公開されているので、自身で環境構築をすればこのトレーニングを通してスキルの向上に役立てられそうです。 実際、1回ですべて対策できるとはとても思えないくらい多様な攻撃が行われます。 繰り返しトレーニングしてスキルを高めていきたいと思わせるツールです。 4.ZANSINの構築方法 自身でトレーニングをするためのZANSINを構築していきます。 ZANSINはUbuntu Serverで動作しますが、ControlサーバーとTrainingサーバーの2台が必要になります。 ZANSINの要求スペックは低いのでローカル環境でも十分構築できると思います。 Ubuntu Serverは20.04以上が必要とされており、22.04までは正常にインストールできることが確認されています。 24.xではインストールスクリプトを修正すればインストールが可能とコミュニティへの報告もありますが、22.04で構築することをお勧めします。 4-1.要求スペック それぞれのサーバーに必要とされる最低スペックは以下のとおりとなっています。 コア数 メモリ 記憶域 Controlサーバー 1 2GB 30GB Trainingサーバー 1 2GB 30GB 記憶域は30GBとなっていますが、実際は10GB程度しか使っていないことを私の環境（Ubuntu 22.04, 2026年3月時点）で確認しているため、節約したい場合は20GB程度でも動作します。 メモリは2GBとなっていますが、1GB以上のSWAPがあればメモリは1GBでも動作します。 4-2.構築場所 ZANSINが要求するスペックは高くありません。 古いPCを2台用意する方法もありますが、仮想環境を用意して構築するほうが現実的かもしれません。 AWS®やAzure®といったクラウド環境であれば手軽に構築を始められるかわりにローカル環境の構築より手順が多くなっています。 クラウド環境構築に必要な追加手順や外部から悪用されないセキュリティ設定などに不安があるのであれば、ローカル環境でHyper-V®やVirtualBox®などを用いるほうが手軽に構築できます。 （ローカル環境構築の場合も外部ネットワークに公開しないなどのセキュリティを考慮した設定は行ってください。） ※クラウド環境の場合いくつかの追加モジュールが初期インストールされていないため、手動追加する必要があります。 （”4-4.クラウド環境（AWSやAzure）におけるZANSIN事前設定”や”4-5.ZANSIN構築手順”の手順5～6が必要） 4-3.ローカル環境におけるOS構築手順（Controlサーバー、Trainingサーバーで共通） ※クラウド環境は、Ubuntuの22.x系を選択し、4-4項を実施。 以下にインストール時のパラメータを示す。 Controlサーバー、Trainingサーバー用に2台用意し、同じ設定で構築する。 インストール手順については公式ドキュメント等を参照してください。 項目 値 備考 OS Ubuntu Server 22.x インストールメディア・iso等 インストールタイプ Ubuntu Server（minimized） 両サーバー共通 Profile:Your name zansin 両サーバー共通 Profile:Your servers name 例：ControlServer、TrainingServer 運用上わかりやすい名前を任意で設定 Profile:Pick username zansin 両サーバー共通 Profile:Choose a password 任意のパスワード 両サーバー共通 SSH設定 チェック 利用できるようチェックする ローカル環境で構築する場合、トレーニング受講者のみがアクセスできる安全なプライベートネットワークにControlサーバー、Trainingサーバーを構築してください。 4-4.クラウド環境におけるZANSIN事前設定（ AWS＆Azureのみ実施 ) AWSやAzureを利用した場合の追加となる事前設定。 （Hyper-VやVirtualBox等ローカル環境で構築の場合は不要） この設定を行わないとAWSやAzureではインストールスクリプトが正常に終了しなかったり、トレーニングが正常に行えないため、必ず実施する。 自分でOSからインストールする場合は不要。 1.ネットワークセキュリティ設定（ トレーニング用途限定 ） トレーニングに必要な以下のネットワーク通信を許可する。 プロトコル ポート TCP 5555 TCP 3000 TCP 22 TCP 6379 TCP 80 TCP 3306 TCP 443 TCP 2375 ICMP (推奨) これらのポートへの接続ができなければ、正常なトレーニングが行えないため、トレーニング環境に限定して通信を許可すること。 ※これらのポートはトレーニング用途で解放するもので、そのままでは脆弱性につながるものがあります。 ※本番環境では解放するポートについては用途を確認し十分注意して解放すること。 ※特にTCP:2375の解放は本番環境では注意すること。 勘の鋭い人はここからどんな攻撃が行われるか予測できるかもしれませんね。 クラウド環境の場合、外部からの不正アクセスに対する設定を行ってください。 以下が一例ですが、このような設定を推奨します。 ・ トレーニング受講者のみがアクセスできるようなIPによるアクセス制限の追加。 ・ 以下のようなSSHのみ許可した踏み台サーバを用意し、踏み台サーバからポートフォワード機能を利用してトレーニング環境へアクセスする。 （踏み台サーバの構築、ポートフォワード機能については本記事では取り上げておりません） 2.zansinユーザーの作成 アカウント：zansinを作成する。 コマンド例 $ sudo useradd zansin $ sudo passwd zansin パスワードは任意で登録。 ただしControlサーバーとTrainingサーバーでパスワードは共通にしておくこと 3.ZANSIN展開用ホームフォルダの作成 以下の例を参考にホームフォルダを作成する コマンド例 $ sudo mkdir /home/zansin $ sudo chown zansin:zansin /home/zansin 4.sudoersの追加 以下コマンド例を参考にアカウント:zansinでsudoが使えるようにする。 コマンド例 $ sudo usermod -aG sudo zansin 5.apache2の停止 クラウド環境ではapahe2がインストール済みで自動起動している場合がある。（AWSでは確認済み） ZANSINの構築時には競合するため、停止させておく。 コマンド例 $ sudo systemctl stop apache2 $ sudo systemctl disable apache2 6.SWAP作成（推奨） ※必須ではないものの、やっておいた方が安定性とレスポンスが向上する コマンド例 $ sudo mkdir /swap $ sudo dd if=/dev/zero of=/swap/swapfile bs=1M count=2048 $ sudo chmod 600 /swap/swapfile $ sudo mkswap /swap/swapfile $ sudo swapon /swap/swapfile $ sudo echo ‘/swap/swapfile none swap sw 0 0 ‘ | sudo tee -a /etc/fstab 4-5.ZANSIN構築手順（ローカル環境、クラウド環境共通） ZANSINをインストールして環境を構築します。 一番の山場で時間がかかります。 ここは手順通りに進めていても不安になりやすい箇所なので、焦らず進めることが大切です。 ※AWS、Azureで構築した場合はインストーラがモジュール不足でエラーを出し、正常にインストールできません。5及び6の修正作業が必要 1.sshdの設定変更（Controlサーバー、Trainingサーバー両方で実施）　 ※本番環境では非推奨 ControlサーバーはパスワードログインのSSHを通してTrainingサーバーを制御しています。 そのため両サーバーでSSHのパスワードログインを有効にします。 パスワードログインの有効化 /etc/ssh/sshd.confの修正 以下コメントアウト　もしくは追記 PasswordAuthentication yes ※SSHのパスワードログインはセキュリティリスクにつながる可能性があります。 本番環境では特別な理由がない限りは推奨されません。 2.ZANSINセットアッスクリプトのダウンロード（Controlサーバーで実施） ZANSINをインストールするためのスクリプトを入手します。 以下は ZANSIN のインストールスクリプトを取得するコマンドです。 このスクリプトは GitHubで公開されています。 https://github.com/ZANSIN-sec/ZANSIN コマンド例 $ cd /home/zansin $ wget https://raw.githubusercontent.com/ZANSIN-sec/ZANSIN/main/zansin.sh ※このコマンドで指定しているのはGitHubの公開リポジトリへの直接リンクである。そのため将来リポジトリ構成が変更された場合にリンク切れとなる可能性がある。その場合はGitHubから変更されたリンクを確認すること。 3.インストールスクリプト実行（Controlサーバーで実施） インストール作業はカレントディレクトリを/home/zansinに変更して実施。 コマンド例 $ cd /home/zansin $ chmod +x zansin.sh $ ./zansin.sh 4.インストールスクリプト（Controlサーバーで実施） スクリプトを実行するとインストーラが走ります。 インストールに必要な情報として以下を入力するよう求められます。 sudoパスワード（設定したzansinパスワード） ControlサーバーとなるマシンのIPアドレス （プライベートIPv4アドレス） TrainingサーバーとなるマシンのIPアドレス （プライベートIPv4アドレス） zansinパスワード：zansinのパスワード（設定したパスワード） 必要な情報を入力してインストールが開始されます。 マシンスペックにもよりますが、データ転送に時間がかかります。 要求最低減のスペックの場合、30分以上かかる場合もあります。 特にコンテンツデータの転送は時間がかかり止まってるように見えますが、気長に待ちましょう。 ※クラウド環境で実行した場合モジュール不足でエラーが表示されます。（インストールは最後まで走る） ※クラウド環境で構築する場合、以下を追加で実行する必要があります。（AWS、Azure以外では不要） 5.Controlサーバーでのモジュール追加（ AWS、Azure環境のみ実行 ） ※AWS、Azureで構築した場合はインストーラがPython®のモジュール不足でエラーを出し、正常にインストールできないためこの作業でモジュールを手動追加します。 エラーが出る不足モジュールを追加します。 $ source /home/zansin/red-controller/red_controller_venv/bin/activate $ pip3 install python-nmap $ pip3 install bs4 $ pip3 install paramiko $ pip3 install requests $ pip3 install docopt $ pip3 install aiohttp 6.インストールスクリプト再実行（ AWS、Azure環境のみ実行 　Controlサーバーで実施） 以下コマンドでインストールを再実行します。 $ ./zansin.sh 4-6.ZANSINトレーニング開始 構築作業お疲れさまでした。 以上でZANSINの構築は完了しました。 ここからは、ZANSINを実際に動かしてみましょう。 最初はすべての攻撃に対応できなくても問題ありません。 私も初回は思うように対処できず、かなり戸惑いました。 特にこういったインシデントに初めて触れる人は以下を目標とするくらい気楽にやる方がいいかもしれません。 ログやWeb画面で攻撃を目の当たりにする （何が起きているかを追えるようになるとさらにGood） なにか一つ対処できた （こうすれば対処できたといった振り返りができただけでも十分） ZANSINでトレーニングを開始する場合は以下を参考にコマンドを実行します。 SSHでControlサーバーに接続しトレーニング実行のコマンド以下を実行します。 通常モードでトレーニング開始 ~$ source /home/zansin/red-controller/red_controller_venv/bin/activate ~$ cd /home/zansin/ red-controller/ ~$ python3 red_controller.py -n ***** -t ***.***.***.*** -c ***.***.***.*** -a 1 python3 red_controller.py　オプションパラメータ補足 -n　Trainingユーザー名指定（自由に指定可能） -t　TrainingマシンのIP指定（AWSではプライベートIPV4アドレス） -c　ControlマシンのIP指定（AWSではプライベートIPV4アドレス） -a　攻撃シナリオ（上記例は1） 標準で登録されている攻撃シナリオは以下のとおり　0：デバッグシナリオ、1：標準シナリオ、2：簡易シナリオ（動作チェック等でなければ1を選択すること） コマンド例： Trainingユーザー名：test01 TrainingマシンのIP：10.10.10.1 ControlマシンのIP：10.10.10.2 攻撃シナリオ：１ $ python3 red_controller.py -n test01 -t 10.10.10.1 -c 10.10.10.2 -a 1 5.最後に 環境を用意する手間はありますが、仮想化技術を活用することで、トレーニング環境は容易に構築できます。 こういったトレーニング環境を活用することで、セキュリティインシデントを他者に影響与えることなく体験することができます。 セキュリティに興味のある方は、力試しやスキルアップの機会として活用を検討してみてください。 きっとセキュリティ設計やトラブルシュートに役立つ学びがあると思います。 執筆者　 長谷川 喬一（NTTビジネスソリューションズ（株） エンタープライズビジネス営業部 ネットワーク＆ソリューション推進担当） サーバーやクラウド、セキュリティの案件支援及びエリアのPMOに携わっています。 参考資料・出典 GitHub - ZANSIN-sec/ZANSIN · GitHub 商標　 「Ubuntu®」は、Canonical Ltd. の登録商標です。 「Hyper‑V®」および「Azure®」は、Microsoft Corporation の登録商標です。 「VirtualBox®」および「MySQL®」は、Oracle America, Inc. またはその関連会社の登録商標です。 「AWS®」は、Amazon Technologies, Inc. またはその関連会社の登録商標です。 「NGINX®」は、F5 Networks, Inc. の登録商標です。 「Redis®」は、Redis Ltd. の登録商標です。 「Docker®」は、Docker, Inc. の登録商標です。 「Python®」は、Python Software Foundation の登録商標です。 免責事項 本記事の情報を利用した結果として生じた損害・トラブルについて、当社および執筆者は一切の責任を負いかねます。

こんにちは、ファインディでFindy Toolsの開発をしている本田です。 この記事は「 エンジニア達の人生を変えた一冊 」として、ファインディのエンジニアが人生を変えた本を紹介していくシリーズです。 Part7では、本田・加藤・山田の3名でお届けします。アジャイル開発との出会いになった本、iOSアーキテクチャ設計の答え合わせになった本、AI時代に再読して背筋が伸びた本。3冊それぞれ切り口は違いますが、いずれも自分の中の「開発の判断軸」を作り直してくれた一冊です。 それでは、さっそく紹介していきましょう。 RailsによるアジャイルWebアプリケーション開発 第4版 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ iOSアプリ設計パターン入門 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ 世界一流エンジニアの思考法 この本を読んだきっかけ 本の内容 この本から影響を受けた点/学んだ点 特に印象に残った部分 このような方におすすめ おわりに ■ 本田 / フルスタックエンジニア ■ ファインディでFindy Toolsの開発をしている本田です。 RailsによるアジャイルWebアプリケーション開発 第4版 RailsによるアジャイルWebアプリケーション開発 第4版 作者: Sam Ruby , Dave Thomas , David Heinemeier Hansson オーム社 Amazon 本書は、原著「Agile Web Development with Rails」をもとに、Rails 3.1に対応する形で翻訳された一冊です。著者には、アジャイルソフトウェア開発宣言の起草者の一人であるDave Thomasと、Railsの作者であるDavid Heinemeier Hanssonが名を連ねています。アジャイルの源流とRailsの源流が、ひとつの本のなかに揃っているというのは、今振り返ってみると改めてすごい組み合わせだと感じます。 ちなみに、そのDave Thomasが、2026年6月17日・18日にファインディが主催するオンラインカンファレンス 「エンジニアの役割の変化に向き合うConference 2026」 に登壇予定です。本書の著者本人の話を聞ける機会でもあるので、興味のある方はぜひチェックしてみてください。 この本を読んだきっかけ 業界4年目の頃、私はC#でウォーターフォールの開発をしていました。仕様を固めて設計書を書き、それに沿って実装し、最後にまとめてテストとリリース。それが「開発」というものだと思っていました。 そんなときに、Railsを使った新しいプロジェクトが立ち上がりました。チームメンバーは全員、Railsも本格的なアジャイル開発も未経験で、何から始めればいいのか分からない状態でした。そこで、みんなでこの本を教科書にして、毎日お昼に少しずつ読書会をしながら進めることにしました。各自一章ずつ読んできて集まり、分からないところを話し合い、サンプルを動かしてみる。それを繰り返して、RubyやRailsを少しずつ自分たちのものにしていきました。 本を中心にしたチームの学びの時間は、いまでも当時を思い出すたびに頭に浮かぶ景色になっています。 本の内容 構成のおもしろさは、Depot（デポ）というオンラインショップの架空のプロジェクトを、章を追って少しずつ作り上げていく形式になっているところです。最初は商品一覧の表示だけ、次にカートをつけて、注文できるようにして、メール送信を加えて……というふうに、本一冊を通じて一つのアプリケーションがインクリメンタルに育っていきます。 機能ごとの章タイトルが「タスクA」「タスクB」と続く構成で、まるで開発の現場でユーザーストーリーをこなしていくかのような体験になっています。Railsの機能を学べると同時に、 「動くものを少しずつ広げていく」開発スタイルそのものを擬似体験できる ように設計されていて、書名どおりまさに「Railsによるアジャイル」を体現した本だと感じました。 この本から影響を受けた点/学んだ点 この本を読んで一番大きかったのは、開発の進め方そのものに対する自分の考え方が変わったことです。 それまでの私にとって、「仕様を固める」「設計を作る」「実装する」「テストする」は、それぞれが大きな塊として順番に並んでいるものでした。ところがこの本でDepotを作っていく体験は、まったく違いました。小さく動くものをまず作って、そこに機能を足し、動かしてみて、足りなければ調整して、また次の機能を足していく。短いサイクルで「動くもの」を中心に開発が進んでいく感覚は、当時の自分には完全に新しいものでした。 同じくらい衝撃的だったのは、Rubyという言語とRailsというフレームワークの書き心地そのものです。それまで書いていたコードと比べると、コードの量が圧倒的に少なくて、それでいて表現したいことがすっと書ける。フレームワークが規約として用意してくれている部分にうまく乗ると、書くべきものに集中できる。これも「開発って、こんなに違うものになるのか」という気づきでした。 「Webアプリケーションをアジャイルに作る」というのは、ツールやフレームワークだけの話ではなく、考え方と書き心地と進め方が一体になって初めて成立するものなのだと、サンプルアプリケーションを作りながら肌で理解できた気がします。 特に印象に残った部分 特に印象に残っているのは、Depotを章ごとに育てていく構成そのものです。 本の最初のほうで作ったDepotは、商品一覧を表示するだけのとてもシンプルなものです。それが章を進めるごとに少しずつ機能が増えていき、最後にはちゃんと注文ができてメールが届く、ひとつのアプリケーションになっている。途中で「これで動くようになった」「ここはこういう改善ができるのか」と、小さな達成感が積み重なっていく感覚は、技術書を読みながら得られる体験としてとても新鮮でした。 そして、それをチームで読書会として体験したことも大きかったです。お昼に集まって、一章ずつ進めて、分からないところは議論して、サンプルを動かしてみる。今思えば、これ自体が「短いサイクルで動くものを増やしていく」という本書で学ぼうとしていたスタイルを、学び方そのもののなかで実践していたのだと思います。本を読むという行為が、ただ知識を得る時間ではなく、チームで開発のスタイルそのものを共有する時間になっていました。 このような方におすすめ 日本語版は更新が止まっているため、今からRailsを学び始める人に第一の選択肢として薦める本ではないかもしれません。ただ、原著は今もアップデートが続いていて、最新版ではRailsの新しいバージョンに対応した内容で読むことができます。 pragprog.com 私個人としては、 Railsとアジャイル開発の出会いをひとつの本でまるごと体験した原体験の本 として、今でも特別な位置に置いています。AIで開発の速度や進め方が変わっていく今だからこそ、「小さく動くものを作って、フィードバックを得ながら育てていく」という当時学んだスタイルが、自分のなかでの開発の考え方の土台になっていることをあらためて感じます。 続いては、Tools開発でファインディ初のモバイルアプリ「Findy Events」を担当している加藤さんです。Clean Architectureを採用したプロダクトをリリースした直後に出会った、設計選定の「答え合わせ」になった一冊について語ってもらいました。 ■ 加藤 / モバイルエンジニア ■ ファインディ株式会社でモバイルエンジニアをやっている加藤です。ファインディ初のモバイルアプリ「Findy Events」を開発しています。 iOSアプリ設計パターン入門 peaks.cc ※現在はPEAKSの公式サイトで電子版のみ購入可能です。 私が紹介する「iOSアプリ設計パターン入門」は、iOSアプリのアーキテクチャを網羅的にまとめた書籍です。 この本を読んだきっかけ 当時の私はMVCのみの開発経験しかない中で、業務でClean Architectureに挑むことになりました。 手探りで設計を進め、なんとかリリースまで漕ぎ着けたものの、本当にこれで良かったのか、正しい形は何だったのかという確信は最後まで持てませんでした。 チーム内でClean Architectureに対する共通認識を取り切ることができず、QCDのDを優先して走り切った経緯もありました。そもそもClean Architectureを採用すべきだったのか、別のアーキテクチャの方が適していたのではないかという迷いも残っていました。 そんなタイミングで本書が発売され、自分の中の答え合わせをしたいという気持ちで手に取った一冊です。 本の内容 本書は冒頭で、一般的なアーキテクチャの歴史と構造を整理するところから始まります。 GUIアーキテクチャとシステムアーキテクチャの両面から解説されており、それぞれの位置づけがクリアになる構成です。 その上で、各アーキテクチャをiOSアプリにどう適用するかが具体例とともに示されています。 アーキテクチャの選定に関する考え方にも一定のページが割かれており、サンプルコードがGitHubで配布されているため、手を動かしながら理解を深められるのもありがたいポイントでした。 この本から影響を受けた点/学んだ点 一番大きかったのは、GUIアーキテクチャとシステムアーキテクチャは組み合わせて使うものだという視点を得られたことです。 それ以前の私は、この二つを同じレイヤーのものとして捉えており、MVCとClean Architectureを並べて比較するような考え方をしていました。 本書を読んでから、例えば、「MVPでGUIを構築しつつClean Architectureでシステム全体を整理する」といった組み合わせの発想ができるようになりました。 実際にその後の業務で「MVP + Clean Architecture」という形に取り組み、本書で得た視点を現場に持ち込めたのは大きな収穫でした。 特に印象に残った部分 第2部のまとめ「アーキテクチャの選定基準」に書かれていた次のような問いかけが、強く印象に残っています。 なんとしてでもClean Architectureを採用すべきでしょうか。 どんなアーキテクチャパターンを採用するとしても、そのパターンの経験があったり、パターンに精通していることが望ましいです。 アーキテクチャパターンが目的になっていないか これらは、当時の私の悩みに正面から答えてくれる内容でした。 Clean Architectureを採用したプロダクトをリリースした直後に本書を読んだこともあり、チームでパターンへの精通が揃わないまま走り切ってしまったことを、ページをめくるごとに痛感させられました。 本来であれば設計を選ぶ前に向き合うべきだった問いを、後追いで突きつけられている感覚です。 iOSに限らず、アーキテクチャ選定の場面では常に心に置いておくべき視点だと感じています。 長期的な開発・保守・運用まで見据えて選ぶことの大切さを、自身の反省と重ねて受け取った章でした。 このような方におすすめ これから、あるいは今まさにiOSアプリのアーキテクチャ設計に取り組むエンジニアにおすすめの一冊です。 iOSアプリのアーキテクチャを体系的にまとめた書籍は今でもそう多くないため、最初に手に取る一冊として機能すると思います。 また、iOSに限らずアーキテクチャの歴史や系譜に興味がある方にも価値のある内容です。 発売から7年近くが経つためTCAは扱われていませんが、TCAにつながるFluxの解説があり、現在のiOS開発の文脈でも参考になる部分は多く残っていると感じています。 最後は、事業推進でカンファレンスサービスを開発している山田さんです。山田さんが選んだのは、世界トップクラスのエンジニアの思考プロセスを言語化した一冊。AIコーディングエージェントが日常になった今だからこそ、再読の意味が増した本について語ってもらいました。 ■ 山田 / フルスタックエンジニア ■ ファインディ株式会社でフルスタックエンジニアをやっている山田です。ファインディのカンファレンスサービスを開発しています。 世界一流エンジニアの思考法 世界一流エンジニアの思考法 作者: 牛尾 剛 文藝春秋 Amazon 私が紹介する「世界一流エンジニアの思考法」は、Microsoft Azure Functions開発チームに身を置く著者が、世界トップクラスのエンジニアたちの思考プロセスと働き方を観察して言語化した一冊です。生産性の本質を「基礎理解の深さ」と「試行錯誤の前に思考する姿勢」に求めており、AI時代に再読する価値がむしろ増した本だと感じています。 この本を読んだきっかけ 最初に手に取ったのは、自身やチームの生産性向上を目的に、社内で技術的に優れたアウトプットを圧倒的な量で出し続ける同僚を意識した時期でした。実装スピードも設計の練度もPRの打数も桁が違う。その差分を言語化したくて、世界一流の現場で同種の人々に囲まれて働く著者の本を読みました。 最近になってAIコーディングエージェントが日常の道具となった時期に、自分の中の「思考順序」がAIを挟んで再び崩れ始めている自覚が芽生え、改めて初心に返り本書を再読することになりました。 本の内容 本書は7章構成で、第1章「世界一流エンジニアは何が違うのだろう？」から始まり、マインドセット、情報整理・記憶術、コミュニケーション、チームビルディング、生活習慣を経て、第7章「AI時代をどう生き残るか？」で締められます。 主軸は「生産性は時間ではなく思考の質で決まる」という立場で、具体的には次のような原則が繰り返し強調されます。 Be Lazy: 作業量を減らし、インパクトのある対象に集中する 理解の三要素: 説明可能／いつでも使える／応用可能、を満たして初めて「理解した」と言える 仮説駆動: 試行錯誤を悪とし、事実→仮説→検証の順序を守る シングルタスク／タイムボックス: マルチタスクは生産性が最低なのでやらない AI時代の生存戦略: 自分が学んだものとAIをどう掛け算するか この本から影響を受けた点/学んだ点 初読で強く影響を受けたのは次の二点でした。 基礎理解には時間をかけること。シニアが平気で数日を「読むだけ」に費やす描写から、表面的に動かす速度よりその後の実装と判断の速度を取りに行く姿勢を学びました。 試行錯誤の前に思考すること。手を動かす前に「事実を掴む → 仮説を立てる → 検証する」の順序を必ず通す習慣です。 再読で痛烈に蘇ったのは、AI時代において自分が崩していた順序の自覚でした。具体的には次の3つの兆候です。 AIのアウトプットの質を上げるために、プロンプトを試行錯誤で叩く回数が、自分の思考時間より長くなっていた AIを並列で走らせる並列業務に流され、シングルタスク原則が崩れていた AIが最初に出した "good code" を正にしてしまい、「bestなコードは何か／そこに至る道筋」を自分の頭で検討する工程が薄くなっていた ここから得た結論は、AIの登場は基礎の重要性を消したのではなく、見えにくくしただけということ。基礎力の向上は今も昔も時間がかかり、長い時間、同じ対象に向き合って初めて芽が出ます。AIを係数として効かせるための「自分側の係数」を、地道に上げ続ける意志が問われていると改めて認識しました。 特に印象に残った部分 第3章で示される「理解の三要素：説明可能／いつでも使える／応用可能」は、初読時から自分の判断基準として一番手元に残った概念です。再読時には、この三要素をそのままAI出力のレビュー基準として転用し、「生成されたコードを自分で説明できるか／別文脈で使えるか／応用が効くか」を改めて意識するようになりました。 もう一箇所は、第1章の「マルチタスクは生産性が最低なのでやらない」という言葉です。AIが並列処理を肩代わりしてくれる時代だからこそ、人間側がマルチタスクで思考の解像度を落とすのは本末転倒で、今手をつけている仕事を1つに限定することがAIを使いこなす前提条件だという文脈は再読で初めて腹に落ちたところがありました。 このような方におすすめ 周囲に桁違いのアウトプットを出すエンジニアがいて、その差分を言語化したい方 AIコーディングエージェントを使い始めてから、プロンプトの試行錯誤に時間を溶かしている自覚がある方 AIが出してきた "動くコード" をつい best として採用してしまっていることに違和感を持ち始めた方 並列タスクで日々が埋まり、1つの対象に深く向き合う時間が減っている方 「AI時代に技術力は不要になるのでは」という風潮に、戒めとしての軸を持ち直したい方 おわりに アジャイルを支える開発スタイル、iOSアーキテクチャを選ぶ視点、そしてAI時代に通用する思考法。今回紹介した3冊は扱うテーマこそバラバラですが、いずれも「自分の中の判断軸」を作り直す体験を与えてくれた本でした。 私はRailsとの出会いを通じて「小さく動くものを育てる」スタイルを、加藤さんはアーキテクチャ選定の問いを、山田さんは基礎理解と思考順序の重要性を、それぞれ本から受け取っています。年次を重ねるほど一冊の影響は薄まるのかと思いきや、振り返ってみるとむしろ「あのとき出会えた」一冊が、いまの判断や設計、思考のクセを支え続けている。エンジニアという仕事ならではの面白さだなと感じます。 皆さんにも、そんな一冊との出会いが一つでも増えるきっかけになれば嬉しいです。 ファインディでは一緒に働くメンバーを募集しています。少しでも興味を持っていただけた方は、ぜひこちらをご覧ください。

みなさん、こんにちは☀️ プロダクト開発部の ねぎちゃん です🌱 スタメンは、先日開催された フロントエンドカンファレンス名古屋 2026 にプラチナスポンサーとして、出展・協賛させていただきました！ フロントエンドカンファレンス名古屋2026 日時：2026年5月9日(土) 場所：ウインクあいち(〒450-0002 愛知県名古屋市中村区名駅4丁目4-38 ) fec-nagoya-org.github.io プラチナスポンサーとしてブース出展いたしました💪 今回のカンファレンスには、専門領域がそれぞれ異なるスタメンのエンジニアたちが参加しました。 バックエンドメインのメンバーから、AI活用に注目するメンバーまで、多角的な視点でセッションを聴講した結果、「一見地味な罠」への対策から「5年におよぶ刷新劇」の舞台裏、さらには「AIインストールのリアルな地獄」まで、濃厚で痺れる知見がたくさん集まりました✨ このブログでは、参加メンバーが「いちばん印象に残った！」と語る、厳選セッションの感想レポートをそれぞれの視点でお届けします🔥 🔥 スタメンエンジニアが痺れたセッション5選 おしん 💭印象に残ったセッション： 「見た目は同じなのに検索でヒットしない」 ( @wabi_1318 ) wabiさんの「見た目は同じなのに検索でヒットしない」という発表が私にとって特に印象に残りました。 MacOS（NFD）からのアップロードと手入力（NFC）の差分でファイル名検索がヒットしなくなるというバグは、原因究明が難しそうで沼にハマりそうだと感じました。ブラウザやライブラリ側で自動解決されない問題を、Issueの議論などを交えてリアルに語ってくださり、面白かったです。 こうした「一見地味だけど踏むと痛い落とし穴」は中々表に出てこないと思うので、貴重な知見でした。 システムの入力境界でしっかり検証・正規化して、型を活用して素の文字列と区別するという設計思想の重要さを学べたので、今後のプロダクト開発に活かしていきたいと思います。 鈴木 雄一郎 💭印象に残ったセッション：「デザインとコードの境界を溶かす」( @kskwtnk ) 綿貫さんの基調講演「デザインとコードの境界を溶かす」という発表がとても印象に残りました。 私は、普段バックエンドメインで書いており、キャッチアップとしてTypeScript, Reactの学習はしているのですが、デザイン周りの語句もキャッチアップしておくべきという気づきを得ました。 また、デザインシステムを現場に導入したがチームが慣れておらず、うまくワークできなかったという話も、実体験をもとにした話で現場感がありました。こういう失敗談みたいなものはなかなか話しづらいと思うので、共有してくれてとてもありがたかったです。 「プロジェクトの初期はデザイントークンのグローバルトークンを導入するだけでもデザインの統一感が出て、コスパ良く導入できて良い」という話も明日から仕事で即使えそうなナレッジとして参考になりました。 ちぇる 💭印象に残ったセッション： 「いつか誰かが、と思っていた フロントエンド刷新5年間の実践知」 ( @kiichi_sugihara ) 長期的なリアーキテクチャに取り組みたいけど、目の前の改善業務に追われて時間が取れないという、現場でよくある課題への向き合い方が非常に面白かったです。 kiiさんの現場では、当初「業務時間の10%を自由に使えるシステム健全化枠」を設けていたそうですが、機能的な改善の方がチームや社内からも喜ばれやすく、「改善 → 喜ばれる → やめられない」というループに入り、枠を使い切ってしまっていたという失敗談には非常に共感しました。そこから学び、枠ではなく「丸1日システム改善しかやらない『システム健全化デー』」を設けることで集中の分断を防いだ点や、あえて残業時間を減らしてその余白を勉強に充てることが、長期的に組織やシステムへの良い投資になるというお話が印象的でした。 また、技術的負債という目に見えづらい課題を解決するためには、機能開発以上に周囲への説明と合意形成が必要となります。リアーキテクチャに伴うバックエンド側のAPI分離や、デザイントークン作成の必要性など、各ステークホルダーを巻き込む壁があった中で、「理想を描いて、事業プロジェクトのついでに段階的に仕込んでいく」という立ち回りは、どんな仕事においても通じる突破口だと感じました。 必要性の吟味に始まり、周囲の課題と自分の理想をマッチさせながら、最終的に覚悟を持ってプロジェクトを完遂させる姿勢は、まさに「Get things done」の体現だなと思いました。 伊賀本 衛 💭印象に残ったセッション： 「AIと乗り切った1500ページ超のヘルプサイト基盤刷新」 ( @mugi_uno ) 「AIと乗り切った1500ページ超のヘルプサイト基盤刷新」のセッションを聞いて、AIへの過信の危うさを改めて実感しました。 AIがあれば何でもできると思いがちですが、実際に掘り進めると「地獄への始まり」とも言える複雑さが待っています。コードを変えるだけでなく、プロダクトのフェーズに応じた判断が求められ、刷新前後の差分を完全に排除することの難しさも痛感しました。TDDの徹底やドキュメントの積み重ねによってナレッジを蓄積し、誰でも編集できる状態を作るというアプローチはとても参考になりました。 また、AIを使うことで自分の観測範囲に閉じた局所最適に陥りやすいという指摘も刺さりました。自社でも個人スキルの向上は進む一方、プロジェクト横断的なナレッジ共有の仕組みはまだ整備途上です。この課題に向き合い、チーム全体のスキルを底上げする仕組みを作ることが急務だと感じています。自社プロダクトをより多くの人に使いやすく届けるためにも、AIを活用しながらスピード感を持って動いていきたいと思います。 taro 💭印象に残ったセッション： 「いつか誰かが、と思っていた フロントエンド刷新5年間の実践知 」 ( @kiichi_sugihara ) 最も印象に残ったのはこちらのセッションです。 「いつか経験豊富なエンジニアが来て、一緒に刷新を進めてくれるだろう」と思いながら目の前の開発で精一杯だった、というところから始まる 5 年間の物語でした。 何より心を動かされたのは、登壇者の 仕事に対する熱量 です。5年かけて少しずつ信頼と専門性を積み上げ、最終的にフロントエンド刷新をやり切るまでの軌跡は、聞いている自分まで熱くなるものでした。 セッションを聞いて自分も取り入れたいと思ったのは、次の2つです。 1日の時間の使い方 責任者・関係者の巻き込み方 1日の時間の使い方についてです。毎日の業務を同じようにこなすのではなく、「もっと良いやり方があるのではないか」と問い続け、 時間の使い方そのものを設計する 。その積み重ねが複利のように効いてきて、未来を決めるのだという考え方は強く印象に残りました。 責任者・関係者の巻き込み方については、検証が進まない時期に、技術顧問との定例ミーティングを先に設定し、「 検証の進捗を共有する場を作る → 否応なく前進せざるを得ない構造」を作ってしまうという話が象徴的でした。また、1人だと曖昧になりやすい部分が、説明する過程で言語化されてクリアになる、という副次効果も語られていました。 さらに、刷新を「自分の余白」だけでやろうとせず、 事業ロードマップを見据えて事業 PJ に段階的に仕込む という発想にも痺れました。「場を作ってから埋める」アプローチを社内のあらゆる関係者に対して実践している姿勢は、今の自分にとても必要だと感じました。 このような規模のカンファレンスに参加するのは初めての経験でしたが、ブース運営もセッション聴講も、どちらもモチベーションを大きく引き上げてくれる時間でした。次回も機会があればぜひ参加したいですし、いつかは聴く側ではなく発表する側として登壇できるよう、日々の業務と学びを積み重ねていきたいと思います。 おわりに 以上、フロントエンドカンファレンス名古屋 2026の参加レポートでした！ 専門領域が異なるメンバーがそれぞれの視点でセッションを聴講したことで、技術的なナレッジはもちろん、チームビルディングやプロジェクト推進のヒントまで、本当に多くの刺激と学びを得ることができました🔥 スタメンでは、こうして得た最先端の知見や現場の実践知を日々のプロダクト開発に還元し、ユーザーの皆さまにより良い価値を届けていけるよう、これからもチーム一丸となって突き進んでいきます💨 改めまして、素晴らしいカンファレンスを企画・運営してくださったスタッフの皆様、そして当日ブースにお立ち寄りいただいた皆さま、本当にありがとうございました💐 それでは、次回のテックブログもお楽しみに🌷 herp.careers