flowchart LR
    subgraph Mobile["📱 スマホ"]
        T[Terminus]
        TP[TablePlus]
    end

    subgraph Server["🖥️ サーバー"]
        SSH[SSH接続]
        LOG[ログ確認]
        DB[(データベース)]
    end

    subgraph Actions["✅ できること"]
        A1[確認する]
        A2[読む]
        A3[考える]
    end

    T --> SSH
    T --> LOG
    TP --> DB
    SSH --> A1
    LOG --> A2
    DB --> A3

    style Mobile fill:#e3f2fd
    style Server fill:#f3e5f5
    style Actions fill:#e8f5e9
  

通勤時間、なんかもったいなくない?

片道45分。往復で1時間半。週5日で7時間半。

電車の中でスマホを眺めながら、ぼんやり思っていた。この時間、なんとかならないかな、と。

SNSを見る。ニュースを読む。ゲームをする。それはそれで悪くない。でも「今日やらなきゃいけないタスク」が頭の片隅にあると、なんとなく落ち着かない。

かといって、満員電車でノートPCを開くわけにもいかない。立っていることも多い。両手が使えるとは限らない。

「スマホで開発できたらいいのに」

そう思って、試しにいくつかアプリを入れてみた。結論から言うと、フル開発はできない。でも「開発の一部」はできるようになった。

今回は、TerminusとTablePlusという2つのアプリを使って、通勤時間を「開発時間の一部」に変えた話をする。


なぜスマホ開発を試したのか

きっかけは単純だ。PCを開けない時間が、思った以上に多かったから。

私の1日を振り返ってみた。

  • 通勤電車:往復1時間半
  • 昼休み:会社のPCは触りたくない
  • 病院の待ち時間:たまに発生
  • 子どもの習い事の送迎待ち:週1回

合計すると、週に10時間以上「PCはないけど、スマホはある」時間があった。

この時間のうち、1割でも有効に使えたら? 週に1時間。月に4時間。年間で50時間近くになる。

もちろん、全部を「生産的な時間」にする必要はない。休息も大事だ。でも「ちょっと確認したいな」というときに、確認できる環境があるのは便利だろうと思った。

通勤時間の変化:Before / After

    flowchart TB
    subgraph Before["❌ 導入前"]
        B1["📱 通勤時間<br/>━━━━━━<br/>・SNSを見る<br/>・ニュースを読む<br/>・ゲームをする"]
        B2["💭 気になること<br/>━━━━━━<br/>・ログは大丈夫かな?<br/>・あの設定どうだっけ?<br/>・データ確認したいな"]
        B3["😰 モヤモヤ<br/>━━━━━━<br/>・確認できない<br/>・出社まで待つ<br/>・忘れてしまう"]

        B1 --> B2
        B2 --> B3
    end

    subgraph After["✅ 導入後"]
        A1["📱 通勤時間<br/>━━━━━━<br/>・選択肢が増えた<br/>・確認できる<br/>・考えられる"]
        A2["🔍 できること<br/>━━━━━━<br/>・ログ確認<br/>・DB確認<br/>・設定確認<br/>・コード確認"]
        A3["✨ メリット<br/>━━━━━━<br/>・モヤモヤ解消<br/>・事前に当たり付け<br/>・PC作業に集中"]

        A1 --> A2
        A2 --> A3
    end

    Before -.->|Terminus<br/>TablePlus導入| After

    style Before fill:#ffebee
    style After fill:#e8f5e9
    style B3 fill:#ffcdd2
    style A3 fill:#c8e6c9
  

Terminus でできること

最初に入れたのは Terminus というSSHクライアントアプリだ。iOSでもAndroidでも使える。

SSH接続ができる

当たり前だが、これが一番大きい。

自分の開発サーバーや、VPSに接続できる。鍵認証も使える。接続情報を保存しておけば、ワンタップで繋がる。

最初に設定するときだけちょっと面倒だが、一度やってしまえば後は楽だ。

ログ確認ができる

私がスマホでよくやるのは、ログの確認だ。

    tail -f /var/log/app/error.log
  

本番でエラーが出ていないか、バッチ処理が正常に終わったか。電車の中でサッと確認できる。

問題がなければ安心して出社できる。問題があれば、出社前に頭の中で対応を考えておける。

軽い修正・確認ができる

正直、スマホでコードを書くのはしんどい。キーボードが小さすぎる。括弧を打つのに何タップも必要だったりする。

でも、読むのはできる。

    cat config/settings.py | grep DATABASE
  

「あれ、この設定どうなってたっけ?」という疑問を、その場で解決できる。

たまに、本当に1行だけの修正をすることもある。コメントアウトするとか、フラグを変えるとか。でも基本は「確認」がメインだ。

失敗談:うっかり本番で rm -rf

これは笑えない話なのだが、一度だけ、電車の揺れで誤タップして危ない目に遭いかけた。

幸い、Tab補完の途中で止まっていたので実害はなかった。でもそれ以来、スマホからは本番サーバーに直接触らないというルールを自分に課した。

確認用の踏み台サーバーを経由するか、読み取り専用のアカウントを使う。スマホでの操作は「見る」に徹する。これ大事。

安全なSSH接続構成

    flowchart TB
    subgraph Dangerous["❌ 危険な構成"]
        D1["📱 スマホ<br/>(Terminus)"]
        D2["🖥️ 本番サーバー<br/>━━━━━━<br/>・読み書き可能<br/>・全権限"]
        D3["⚠️ リスク<br/>━━━━━━<br/>・誤操作で本番破壊<br/>・電車の揺れで誤タップ<br/>・rm -rf の危険"]

        D1 -->|直接接続| D2
        D2 --> D3
    end

    subgraph Safe["✅ 安全な構成"]
        S1["📱 スマホ<br/>(Terminus)"]
        S2["🛡️ 踏み台サーバー<br/>━━━━━━<br/>・読み取り専用ユーザー<br/>・限定された権限"]
        S3["🖥️ 本番サーバー<br/>━━━━━━<br/>・踏み台経由のみ<br/>・SELECT のみ許可"]
        S4["✅ 安全対策<br/>━━━━━━<br/>・直接接続不可<br/>・読み取り専用<br/>・誤操作防止"]

        S1 -->|Step 1| S2
        S2 -->|Step 2| S3
        S3 --> S4
    end

    Dangerous -.->|改善| Safe

    style Dangerous fill:#ffebee
    style Safe fill:#e8f5e9
    style D3 fill:#ffcdd2
    style S4 fill:#c8e6c9
  

TablePlus を入れて変わったこと

もう1つ入れたのが TablePlus だ。iOSアプリがある。データベースクライアントだ。

DBの状態が見える

MySQL、PostgreSQL、SQLiteなど、主要なDBに接続できる。

私は開発環境のDBに接続して、テーブルの中身を確認するのに使っている。

    SELECT * FROM orders WHERE status = 'pending' LIMIT 10;
  

このくらいのクエリなら、スマホでも十分打てる。

データの違和感に気づける

これが意外と大きかった。

テーブルをざっと眺めていると、「あれ、このカラムNULLばっかりだな」とか「この日付、おかしくない?」とか、データの違和感に気づくことがある。

PCで作業しているときは、コードを書くことに集中している。データをじっくり眺める時間は意外と少ない。

電車の中で、ぼんやりデータを眺める。これが意外とバグの発見につながる。

クエリの下書きができる

「あとでこのクエリを実行しよう」と思ったとき、スマホでクエリを書いておく。

PCを開いたときに、コピペして実行。考える時間と実行する時間を分離できる。


実際に捗った作業

具体的に、スマホで何が捗ったかを挙げてみる。

1. クエリの確認・調整

「このJOIN、合ってるかな?」

電車の中でTablePlusを開いて、クエリを実行。結果を見て「あ、ここの条件が漏れてる」と気づく。メモアプリに修正版を書いておく。

出社してPCを開いたら、すぐに本実装に入れる。

2. データ構造の把握

新しく関わるプロジェクトで、テーブル構造を理解したいとき。

通勤中にTablePlusでテーブル一覧を眺める。カラム名を見る。外部キーの関係を追う。

「なるほど、ordersとorder_itemsがあって、order_itemsにproduct_idがあるのか」

この「把握する時間」を通勤中に済ませておくと、PCの前では「手を動かす」ことに集中できる。

3. バグの当たり付け

「なんか動きがおかしい」という報告があったとき。

電車の中でログを見る。エラーは出ていない。じゃあロジックの問題か。DBを見る。データは入っている。値は正しそう。

「ということは、このへんの処理が怪しいな」

当たりを付けておくと、出社してからの調査が速い。

4. 「あれどうなってたっけ」の即解消

コードレビューのコメントを読んでいて、「このへんの実装、どうなってたっけ」と思うことがある。

スマホでTerminus開いて、サッとファイルを見る。「あー、こうなってたのか」で解決。

この小さな「引っかかり」が解消されると、レビューへの返信もスムーズに書ける。


向いている作業・向いていない作業

正直に言うと、スマホでできることは限られている。向き不向きがある。

向いている作業

  • 確認作業:ログを見る、データを見る、設定を確認する
  • 読む作業:コードを読む、ドキュメントを読む
  • 考える作業:クエリを考える、設計を考える、方針を考える
  • 下書き:クエリの下書き、コミットメッセージの下書き

向いていない作業

  • コーディング:まとまったコードを書くのは無理
  • デバッグ:ステップ実行とかは当然できない
  • ビルド・テスト実行:できなくはないが、出力を追うのがつらい
  • 複雑な操作:複数ファイルを行き来するような作業

要するに、「入力」より「確認」、**「作る」より「考える」**がスマホ向きだ。

スマホでやるべきか判断フロー

    flowchart TB
    Start["やりたい作業"] --> Q1{作業の種類は?}

    Q1 -->|確認・閲覧| Q2{データ量は?}
    Q2 -->|少ない| Good1["✅ スマホ向き<br/>━━━━━━<br/>・ログ確認<br/>・設定確認<br/>・コード確認<br/>・データ確認"]
    Q2 -->|大量| Bad1["❌ PCで<br/>━━━━━━<br/>・大量ログ解析<br/>・複数ファイル比較<br/>・画面が小さすぎる"]

    Q1 -->|思考・設計| Good2["✅ スマホ向き<br/>━━━━━━<br/>・クエリを考える<br/>・設計を考える<br/>・方針を決める<br/>・メモに下書き"]

    Q1 -->|入力・編集| Q3{入力量は?}
    Q3 -->|1〜2行| Maybe["△ 可能だが注意<br/>━━━━━━<br/>・フラグ変更<br/>・コメントアウト<br/>・誤操作に注意"]
    Q3 -->|多い| Bad2["❌ PCで<br/>━━━━━━<br/>・コーディング<br/>・リファクタリング<br/>・入力が非効率"]

    Q1 -->|実行・操作| Q4{複雑さは?}
    Q4 -->|シンプル| Maybe2["△ 可能だが注意<br/>━━━━━━<br/>・単発コマンド<br/>・安全確認必須"]
    Q4 -->|複雑| Bad3["❌ PCで<br/>━━━━━━<br/>・デバッグ<br/>・ビルド<br/>・テスト実行"]

    style Good1 fill:#e8f5e9
    style Good2 fill:#e8f5e9
    style Maybe fill:#fff3e0
    style Maybe2 fill:#fff3e0
    style Bad1 fill:#ffebee
    style Bad2 fill:#ffebee
    style Bad3 fill:#ffebee
  

環境構築のポイント

スマホ開発を始めるにあたって、いくつかポイントがある。

1. 踏み台サーバーを用意する

本番に直接触らない。開発用のサーバーを用意して、そこからしか本番データにアクセスできないようにする。

スマホは誤操作のリスクが高い。安全策を講じておく。

2. 読み取り専用ユーザーを作る

DBに接続するユーザーは、読み取り専用にしておく。SELECT はできるが、UPDATE や DELETE はできない。

うっかり事故を防げる。

3. 接続情報は安全に管理する

Terminusも TablePlusも、接続情報を保存できる。便利だが、スマホを落としたときのリスクがある。

端末のロック、アプリのパスワード保護、必要なら二要素認証。セキュリティはちゃんとやる。

4. 無理しない

満員電車でスマホを操作するのは、正直しんどい。座れたときだけ、余裕があるときだけでいい。

「通勤時間を全部開発に使う」ではなく、「使えるときに使える環境を用意しておく」くらいのスタンスで。

セキュリティ設定のチェックリスト

    flowchart TB
    Start["🔧 環境構築開始"] --> Step1["1️⃣ サーバー側設定"]

    Step1 --> S1{"踏み台サーバー<br/>用意した?"}
    S1 -->|No| S1A["⚠️ 本番直接接続は危険<br/>━━━━━━<br/>・開発用サーバー準備<br/>・踏み台サーバー設置"]
    S1A --> S2
    S1 -->|Yes| S2

    S2{"読み取り専用<br/>ユーザー作成した?"}
    S2 -->|No| S2A["⚠️ 全権限は危険<br/>━━━━━━<br/><code style='color: white'>GRANT SELECT ON *.* TO 'readonly'@'%';</code><br/>・UPDATE/DELETE禁止<br/>・SELECT のみ許可"]
    S2A --> Step2
    S2 -->|Yes| Step2

    Step2["2️⃣ 端末側設定"] --> S3{"端末ロック<br/>設定済み?"}
    S3 -->|No| S3A["⚠️ 紛失時のリスク<br/>━━━━━━<br/>・PIN/パスワード設定<br/>・生体認証有効化"]
    S3A --> S4
    S3 -->|Yes| S4

    S4{"アプリに<br/>パスワード保護?"}
    S4 -->|No| S4A["⚠️ 他人が見れる<br/>━━━━━━<br/>・Terminus: パスコード設定<br/>・TablePlus: 接続時パスワード"]
    S4A --> S5
    S4 -->|Yes| S5

    S5{"秘密鍵は<br/>安全に管理?"}
    S5 -->|No| S5A["⚠️ 鍵漏洩のリスク<br/>━━━━━━<br/>・パスフレーズ付き鍵<br/>・定期的な鍵ローテーション"]
    S5A --> Step3
    S5 -->|Yes| Step3

    Step3["3️⃣ 運用ルール"] --> S6{"本番操作は<br/>禁止した?"}
    S6 -->|No| S6A["⚠️ 誤操作で本番破壊<br/>━━━━━━<br/>・スマホは「見る」だけ<br/>・更新はPC から"]
    S6A --> Done
    S6 -->|Yes| Done

    Done["✅ 設定完了<br/>━━━━━━<br/>安全にスマホ開発できます"]

    style S1A fill:#fff3e0
    style S2A fill:#fff3e0
    style S3A fill:#fff3e0
    style S4A fill:#fff3e0
    style S5A fill:#fff3e0
    style S6A fill:#fff3e0
    style Done fill:#e8f5e9
  

まとめ:通勤時間を「開発の一部」にする

スマホで開発できるか? と聞かれたら、「フル開発は無理」と答える。

でも、開発は「コードを書く」だけではない

  • 現状を確認する
  • データを理解する
  • 問題の当たりを付ける
  • 設計を考える
  • 方針を決める

これらは「開発の一部」だ。そしてスマホでもできる。

開発作業の分解:PC vs スマホ

    flowchart LR
    subgraph Dev["開発作業全体"]
        direction TB
        Think["🤔 考える<br/>━━━━━━<br/>・設計を考える<br/>・方針を決める<br/>・クエリを考える<br/>・アーキテクチャ検討"]
        Confirm["🔍 確認する<br/>━━━━━━<br/>・ログ確認<br/>・データ確認<br/>・設定確認<br/>・コード確認"]
        Input["⌨️ 入力する<br/>━━━━━━<br/>・コーディング<br/>・リファクタリング<br/>・テスト作成<br/>・ドキュメント作成"]
        Execute["▶️ 実行する<br/>━━━━━━<br/>・ビルド<br/>・テスト実行<br/>・デバッグ<br/>・デプロイ"]
    end

    subgraph Mobile["📱 スマホで可能"]
        M1["✅ 思考作業"]
        M2["✅ 確認作業"]
    end

    subgraph PC["💻 PCが必要"]
        P1["⌨️ 入力作業"]
        P2["▶️ 実行作業"]
    end

    Think --> M1
    Confirm --> M2
    Input --> P1
    Execute --> P2

    M1 -.->|通勤時間に| Result1["事前に考えておく<br/>→ PCでは手を動かすだけ"]
    M2 -.->|通勤時間に| Result2["当たりを付けておく<br/>→ PC作業が効率化"]

    style Think fill:#e8f5e9
    style Confirm fill:#e8f5e9
    style Input fill:#e3f2fd
    style Execute fill:#e3f2fd
    style Mobile fill:#c8e6c9
    style PC fill:#bbdefb
    style Result1 fill:#fff3e0
    style Result2 fill:#fff3e0
  

TerminusとTablePlusを入れて、通勤時間が変わった。正確に言えば、通勤時間の「使い道」が増えた

毎日使うわけではない。ぼんやりSNSを見る日もある。それでいい。

ただ、「確認したいな」と思ったときに確認できる。「気になるな」と思ったときに調べられる。その選択肢があるだけで、頭の中のモヤモヤが1つ減る。

週に1時間でも、考える時間が増えれば、PCの前では「手を動かす」ことに集中できる。

開発は「PCを開いた瞬間」だけではない。


使っているアプリ

最後に、今回紹介したアプリをまとめておく。

  • Terminus:SSHクライアント。iOS / Android対応。無料でも使える。
  • TablePlus:データベースクライアント。iOS版あり。主要なDBに対応。

他にも似たアプリはあるので、自分に合うものを探してみてほしい。大事なのはツールではなく、「スマホでも確認できる環境を作っておく」という発想だ。

通勤時間、ちょっと試してみませんか。


設計判断の背景

「スマホでも開発できる」という選択肢を検討したとき、当然「モバイルIDEを入れてコーディングする」というアプローチもあった。でもスマホの入力環境を考えると、それは生産性を下げるだけだと判断した。代わりに「確認と思考」に特化する方針を選んだ。開発作業を「入力」と「確認・思考」に分解し、それぞれに適した環境を割り当てるという考え方だ。

現場での判断基準

誤操作で本番に影響を出しかけた経験から、スマホ操作は「見るだけ」に限定するルールを設けている。具体的には、読み取り専用ユーザーの作成と踏み台サーバー経由でのアクセスを必須にした。「便利さ」と「安全性」のトレードオフでは、特にモバイル環境では安全性を優先する。一度でも事故を起こせば、その後の信頼回復コストの方がはるかに大きい。

見るべきポイント

モバイル開発環境を導入するときは、まずセキュリティ設計から始めることを勧める。接続情報の管理、権限の最小化、端末紛失時の対策。これらを後回しにすると、便利になった分だけリスクも増える。また、「全部の時間を有効活用する」という目標は長続きしない。使えるときに使える環境を用意しておく、くらいの距離感が現実的だ。