はじめに
Pythonを独学で学習している現役トラックドライバーです。
前回の記事では、VS Code版Codexを「他部署から来たベテラン点検員」のように活用し、開発中のFlaskアプリを静的レビューした記録を書きました。
Codexは短時間で多くの改善候補を見つけてくれました。
しかし、どの指摘を採用し、何を現在の仕様として残すのかを判断するのは、最終的には人間の役割です。
今回は、その次に始めた海外への技術発信について記録します。
私はこれまで、PythonやFlaskの学習記録をQiitaへ投稿してきました。
ある日、ふと次のことが気になりました。
世界には、Qiitaのように技術記事を投稿できるサービスがあるのだろうか？
そこでGeminiに調べてもらったところ、海外の開発者が多く利用している
DEV Community（DEV.to） というサービスを知りました。
英語で技術記事を投稿することには、もちろん不安がありました。
私は現在もDuolingoで英語を学習中で、自力だけで長い技術記事を書けるほど英語に自信があるわけではありません。
それでも、
何事も経験。何事も挑戦。
失敗しても大きなデメリットはないから、やるだけやってみよう。
と考え、DEV Communityでの発信を始めました。
主にChatGPTへ英訳、DEV向けの文章調整、アイキャッチ画像作成を手伝ってもらいながら投稿を続けたところ、思いがけない出来事が起きました。
海外の読者から記事を評価してもらっただけでなく、本番環境の運用やデータベース設計についての具体的な技術アドバイスや、仕事経験をプログラミングへ結びつけた部分への共感まで届いたのです。
この記事では、Python学習を始めて約2か月半の私が、Qiitaで積み上げてきた学習記録を海外へ届け、英語での技術交流につながるまでの過程をまとめます。
この記事は、英語が得意になった人の成功談ではありません。
英語もプログラミングも学習途中の状態で、AIの支援を借りながら発信へ挑戦した記録です。
技術発信の出発点はQiitaだった
私の技術発信の出発点は、DEV CommunityではなくQiitaです。
Python学習やFlaskアプリ開発の中で起きた出来事を整理し、まず日本語の記事としてまとめています。
記事を書く際は、次のような情報を確認しています。
- 実際に発生したエラー
- ターミナルや本番環境のログ
- 実行したコマンド
- 失敗した実装
- エラーの原因
- 修正後のコード
- 修正後の動作
- その時点で理解できたこと
- 今後改善したいこと
できるだけ、記憶や感想だけに頼らず、事実経過を確認しながら書くことを意識しています。
記事構成も、最初にQiita向けとして自分で考えています。
アプリを開発する
↓
エラーや課題が発生する
↓
原因を調査する
↓
修正して動作確認する
↓
事実経過を整理する
↓
Qiitaの記事としてまとめる
私にとってQiitaは、完成された知識を披露する場所というより、
その時点で何を作り、どこで失敗し、何を学んだのか
を記録する場所です。
Qiitaの記事を最も古いものから一つずつ英訳した
DEV Community向けに、新しい英語記事をゼロから作り始めたわけではありません。
これまでQiitaへ投稿してきた記事を、最も古い記事から順番に、一つずつ英訳して公開しました。
最初のQiita記事
↓
2本目の記事
↓
3本目の記事
↓
現在の記事へ近づいていく
一度に大量投稿したのではありません。
自分のPython学習記録を、時系列に沿って少しずつ海外へ届ける形にしました。
そのため、DEV側の記事を順番に読むと、
- 最初にどのようなアプリを作ったのか
- どのようなエラーに遭遇したのか
- どのように本番公開まで進んだのか
- どこで設計を変更したのか
- どのようにテストや運用を改善したのか
という成長過程が追えるようになっています。
DEV向けの記事を新しく作り直したのではなく、Qiitaへ蓄積してきた成長記録を、古い記事から順番に海外へ届けました。
ChatGPTに記事の中身を作ってもらったわけではない
完成したQiita記事をChatGPTへ渡し、DEV Communityの読者にとって自然な英語表現になるよう、英訳と文章調整を依頼しました。
ただし、出力された内容をそのまま投稿しているわけではありません。
英訳後の記事を自分でも確認し、必要に応じて次のような指示を出しました。
- 元記事と意味がずれている部分を直す
- 実際には行っていない内容を削除する
- 説明不足の部分を追記する
- 長すぎる部分を短くする
- コードやログを元記事へ合わせる
- 見出しの順番を調整する
- DEV独自の形式へ整える
- タイトルを英語圏向けに調整する
- タグを整理する
- アイキャッチ画像を作成する
全体の流れは次のとおりです。
Python学習・アプリ開発
↓
Qiitaの記事構成を自分で考える
↓
事実ベースで日本語記事を完成させる
↓
Qiitaへ公開する
↓
完成した記事をChatGPTへ渡す
↓
DEV向けに自然な英語へ調整する
↓
自分でも内容を確認する
↓
追記・削除・修正を指示する
↓
DEVへ公開する
役割を分けると、次のようになります。
開発経験を作る
→ 自分
失敗・調査・修正を記録する
→ 自分
Qiitaの記事構成を考える
→ 自分
事実を確認する
→ 自分
英語圏へ伝わる文章へ整える
→ ChatGPTと一緒に行う
最終確認と公開判断
→ 自分
AIに開発経験を作ってもらったわけではありません。
自分の経験を海外へ届けるために、ChatGPTを翻訳者・編集者・デザイナーのような支援役として使いました。
単純な機械翻訳ではなくDEV向けに調整した
Qiitaの記事を、そのまま英語へ置き換えれば完成するわけではありませんでした。
実際には、DEV Communityへ合わせて次のような調整を行いました。
- 英語圏で読みやすいタイトルへ調整
- DEV用のフロントマターを追加
- タグを4つに整理
- Qiita独自の記法を一般的なMarkdownへ変換
- 本文内の見出しをH2以下へ統一
- 英語向けのアイキャッチ画像を作成
- 長い日本語表現を英語で読みやすい文章へ変更
- Qiita原文へのリンクを設定
- 翻訳・再構成した記事であることを明記
現在は、DEV記事のフロントマターへQiita原文を示すcanonical_urlを設定しています。
canonical_url: https://qiita.com/tosane932/items/xxxxxxxxxxxxxxxxxxxx
本文にも、次の説明を入れています。
> This article was originally published in Japanese on Qiita and has been translated and adapted for DEV Community.
日本語では、次の意味です。
この記事は、もともとQiitaへ日本語で公開した記事を、DEV Community向けに英訳・調整したものです。
これにより、Qiitaが元記事であることを明確にしています。
見出し階層についても学んだ
DEV Communityへ投稿した際、アクセシビリティに関する注意が表示されたこともありました。
本文中で次のようにH1を使用していたためです。
# 1. Organizing Images and Videos by Purpose
DEVでは記事タイトルがすでにH1として表示されるため、本文中の主要見出しはH2から始める方がよいと案内されました。
修正後は次の形にしました。
## 1. Organizing Images and Videos by Purpose
### Update README Paths After Moving Files
これまで私は、Markdownの見出しを主に見た目として捉えていました。
しかし、見出しは文章構造やアクセシビリティにも関係します。
英訳して投稿したことで、英語表現だけではなく、技術記事の構造についても学ぶことができました。
DEVへの投稿を始めたときの不安
最初は、いくつかの心配がありました。
英語が不自然だと思われないだろうか
初学者の記事が海外で読まれるのだろうか
内容が簡単すぎると思われないだろうか
間違いを厳しく指摘されないだろうか
私は現役のエンジニアではありません。
Python学習を始めて、まだ約2か月半です。
それでも、自分の記事は単なる日記ではなく、
- 何を作ったか
- 何に失敗したか
- 何を確認したか
- どのように修正したか
- 何を学んだか
を記録した成長記録です。
日本で学んでいる初心者の失敗や気づきでも、世界のどこかに共感してくれる人がいるかもしれない。
そう考えながら投稿を続けました。
海外の読者からコメントが届いた
投稿を続けていると、海外の読者から英語でコメントが届きました。
最初にコメント通知を見たときは、
何か間違ったことを書いて、注意されたのだろうか？
と少し心配になりました。
しかし、実際の内容は否定や批判ではありませんでした。
記事の内容を評価したうえで、本番運用やデータベース設計に関する具体的なアドバイスや、仕事経験をプログラミングへ結びつけた部分への共感が書かれていました。
4つの記事に、それぞれ異なるコメントが届いた
DEV Communityへ投稿を続ける中で、4つの記事に対して、それぞれ1件ずつ、合計4件のコメントをいただきました。
届いたコメントは、すべて同じ種類のものではありません。
- DockerとPostgreSQLを扱った記事への、本番運用や復旧に関するアドバイス
- トラック運転の経験をプログラミングへ結びつけた記事への共感
- SQLiteからPostgreSQLへ移行した記事への、データベース接続やマイグレーションに関するアドバイス
- 論理削除を扱った記事への、販売履歴を守るためのデータ設計に関するアドバイス
初心者の記事なので、読まれても反応まではもらえないかもしれないと思っていました。
しかし実際には、コードやデータベース設計への技術的な助言だけでなく、自分の仕事経験をプログラミング学習へ結びつけた部分にも共感してもらえました。
4件のコメントを通して、
技術的に詳しい人から学べることもあれば、同じように学習中の人と経験を共有できることもある
と分かりました。
職業経験をプログラミングへ結びつけた記事にも共感が届いた
私は以前、トラック運転で安全な車間距離を保つ考え方と、ボタンの二重実行を防ぐisProcessingの仕組みを重ねた記事を投稿しました。
その記事に、モントリオールでレストランマネージャーとして働きながら、独学でプログラミングを学んでいるPawさんからコメントをいただきました。
Pawさんは、飲食店で行う「mise en place（事前準備）」と、プログラミングにも似た部分があると書いてくれました。
トラック運転とレストランの仕事では、業種も働く国も異なります。
それでも、
これまでの仕事で身につけた考え方を、プログラミング学習へ結びつける
という部分で共感してもらえたことが印象に残りました。
これは技術的な修正を提案するコメントとは少し違います。
同じように別の仕事をしながらプログラミングを学んでいる人と、これまでの経験を通してつながることができたコメントでした。
コードだけではなく、自分の経験や学び方にも反応してもらえたことで、成長記録を海外へ発信する意味を感じました。
Docker・PostgreSQLの記事でもらったアドバイス
DockerとPostgreSQLを使った複数コンテナ環境についての記事には、Mads Hansenさんからコメントをいただきました。
コメントでは、コンテナやボリュームを使ってデータを永続化することと、障害から復旧できるバックアップを用意することは、別の問題だと教えてもらいました。
たとえば、データベースのボリュームが残っていたとしても、
- 誤操作でデータを削除した
- データが破損した
- マイグレーションで問題が発生した
- ホスト側の障害でボリュームへアクセスできなくなった
といった場合には、永続化だけでは元の状態へ戻せない可能性があります。
そのため、単にデータが残ることを確認するだけでなく、
バックアップを作成する
↓
別の環境へ復元する
↓
アプリから正しく読み書きできるか確認する
という復旧テストも重要だと学びました。
また、次のような本番運用上の改善点も挙げられていました。
- PostgreSQLのヘルスチェックだけでなく、アプリ側でも接続可能になるまで再試行する
- 名前解決の成功と、PostgreSQLが接続を受け付けられる状態を区別する
- 構造化されたログを出力する
- ログへパスワードや接続情報を出さない
- 障害を想定した復旧手順を確認する
現在のDocker Composeでは、pg_isreadyとcondition: service_healthyを使ったヘルスチェックを設定しています。
しかし、名前解決やコンテナの起動を確認できても、PostgreSQLが接続を受け付けられることや、マイグレーションが完了していることまで保証されるわけではありません。
コメントを通して、アプリ側での再試行も含めて起動時の動作を考える必要があると学びました。
自分の記事では、Docker ComposeでアプリとPostgreSQLを起動し、データが保持されることを確認していました。
しかし、コメントを読んだことで、
データが消えないようにすることと、問題が起きた後に戻せることは別
だと気づきました。
アプリが正常に起動することだけではなく、失敗したときにどのように復旧するかまで考えることが、本番運用では必要になります。
Mads Hansenさんのプロフィールには詳しい職歴は書かれていませんでしたが、コメントや投稿内容から、データベースや本番運用に関する深い知識を持っている方だと感じました。
PostgreSQL移行記事でもらったアドバイス
SQLiteからRender PostgreSQLへ移行した記事では、次のような内容を教えてもらいました。
-
SQLiteImplは根本原因ではなく、原因を調べるための手がかり - 本番環境で
DATABASE_URLが存在しない場合は起動を失敗させる - 接続先の方言が本当にPostgreSQLか確認する
- デプロイ後に書き込みと読み込みのスモークテストを行う
- 複数インスタンスでは、起動時マイグレーションが競合する可能性がある
- 将来的にはマイグレーションを一度だけ実行するジョブへ分離する
- SQLiteだけでなくPostgreSQLでもテストする
自分の記事では、
SQLiteImplが表示された
↓
コードを確認した
↓
Gitの状態を確認した
↓
PostgreSQL自体を作成していなかったと判明した
という事実経過を書きました。
その内容を評価してもらいながら、さらに先の本番運用まで考えたアドバイスを受けることができました。
論理削除の記事でもらったアドバイス
商品を物理削除せず、is_active=Falseとする論理削除の記事にもコメントが届きました。
自分の実装では、商品IDを維持することで、売上履歴との外部キー関係を壊さないようにしました。
しかし、コメントでは次の視点を教えてもらいました。
product_idを残すだけでは、販売当時の情報が完全に守られるとは限らない。
たとえば、過去の売上が商品テーブルを参照している場合、商品名や価格を後から変更すると、過去のレポートにも現在の商品名や価格が表示される可能性があります。
そこで、売上レコード側に次の情報を保存する方法があると教えてもらいました。
販売時の商品名
販売時の単価
税
通貨
つまり、販売した時点の情報をスナップショットとして保存する考え方です。
また、単純なis_activeだけでなく、
discontinued_at
のように、販売終了日時を保存する方法も提案してもらいました。
さらに、今後のテスト候補として次のような内容も挙げられていました。
- 販売終了した商品の再販売
- 二重送信
- 同時編集
- 商品名変更前後の売上レポート
- 過去データの不変性
自分の修正を否定されたのではありません。
今回の対応は良い。さらに実務的な設計へ進むなら、この点も考えられる。
という内容でした。
自分だけでは気づかなかった次の課題が見えた
アプリは正常に動いていました。
外部キーエラーも解決し、過去の売上履歴も残せるようになりました。
しかし、コメントを読んだことで、
データが残っている
ことと、
販売当時の事実が変わらず残っている
ことは別だと気づきました。
これは、自分だけで開発を続けていたら、すぐには気づけなかった視点だと思います。
発信したことで、記事を読んだ人から次の課題を教えてもらうことができました。
アプリを作る
↓
記事を書く
↓
海外へ発信する
↓
経験者の視点が返ってくる
↓
次の設計課題が見つかる
発信は、成果を見せるためだけではありません。
自分の実装を外へ出し、別の視点を受け取る学習方法にもなると感じました。
英語力だけで技術交流が成立したわけではなかった
今回、海外の読者と英語で技術的なやり取りができたことに、自分自身が一番驚きました。
しかし、英語が完璧だったから会話が成立したわけではありません。
自分には、会話の材料となる実体験がありました。
- Flaskアプリを作った
- SQLiteからPostgreSQLへ移行した
- 外部キーエラーに遭遇した
- 論理削除を実装した
- Gemini APIの利用回数を削減した
- 本番環境へデプロイした
- エラーと修正内容を記事にした
英語は、それを相手へ届けるための手段でした。
会話の土台になったのは、
自分で作り、失敗し、調べ、直した経験
だったと思います。
英語が完璧になってから技術交流を始めたのではありません。
伝えたい実体験が先にあり、それを海外へ届ける手段としてAIと英語を使いました。
英語での返信にもChatGPTを活用した
海外から届いたコメントは、まず内容を確認しました。
技術的な意味を理解したうえで、ChatGPTへ英語での返信文作成を手伝ってもらいました。
ただし、返信についてもそのままコピーするのではなく、
- 相手の指摘を正しく理解しているか
- 自分が本当に考えている内容か
- すぐ実装すると約束しすぎていないか
- 感謝が自然に伝わるか
を確認しました。
たとえば、次のような内容で返信しました。
丁寧なフィードバックへの感謝
指摘内容を理解したこと
現在は単一インスタンス構成であること
将来的な改善候補として検討すること
コメントから学べたこと
英語の文章作成は支援してもらいましたが、何を伝えるかは自分で決めました。
「初心者」は言い訳ではなく現在地
私は現在も初心者です。
しかし、「初心者」という言葉を、間違いを正当化するために使うつもりはありません。
今の自分の現在地を示す肩書きだと考えています。
知らないことを指摘されるのは当然です。
指摘を受けたら、
内容を確認する
↓
自分の実装と比較する
↓
理解できない部分を調べる
↓
次の改善候補にする
という流れで学べばよいと思っています。
私は、先に多くの知識を覚えてから実践するよりも、
実践しながら必要なことを覚える
方が合っています。
これまでのPython学習も同じでした。
まずFlaskアプリを作る
↓
本番公開で問題が起きる
↓
DockerやPostgreSQLを調べる
↓
DB変更で問題が起きる
↓
Flask-Migrateや論理削除を学ぶ
↓
API制限にぶつかる
↓
実行方法やエラー表示を見直す
私にとって実践は、学習後に行う成果発表ではありません。
実践そのものが学習です。
「やるだけやってみる」が生んだもの
DEVへ投稿する前は、反応がない可能性も考えていました。
英語の間違いを指摘されるかもしれないとも思っていました。
それでも、
失敗しても大きなデメリットはない
と考えて始めました。
その結果、次の経験を得ることができました。
- 英語で技術記事を公開できた
- Qiitaの記事を世界へ届けられた
- 海外の読者から反応をもらえた
- 実務経験の深さを感じる技術アドバイスを受けた
- 本番運用について新しい視点を得た
- データベース設計の次の課題を知った
- 英語で返信できた
- 発信活動自体がポートフォリオになった
- 次に学ぶ内容が見つかった
投稿しなければ、間違いを指摘されることもなかったかもしれません。
しかし、今回得られた学びも生まれませんでした。
発信しない
→ 間違いを見られない
→ 新しい視点も返ってこない
発信する
→ 読んでもらえる
→ 指摘や評価を受ける
→ 次の学習へつながる
QiitaとDEVは競合ではなく役割が違う
今回、DEVでの発信を始めましたが、Qiitaでの発信をやめるつもりはありません。
自分の中では、次のように役割が分かれています。
Qiita
→ 日本語で事実経過を整理する
→ 学習記録の原文を作る
→ 日本の開発者へ共有する
DEV Community
→ 完成した記事を英語圏へ届ける
→ 海外の読者から別の視点を得る
→ 英語での技術交流を経験する
Qiitaで丁寧に記事を作っていたからこそ、DEVへ展開する元になる文章がありました。
DEVで海外から反応を得られたのも、元となるQiita記事に実際の開発経験が記録されていたからだと思います。
Qiitaで学習記録を積み上げる
↓
ChatGPTと一緒に海外向けへ調整する
↓
DEVへ投稿する
↓
海外から反応を受け取る
↓
次の学習へ戻す
この循環ができ始めています。
Duolingoでの英語学習も続ける
私は現在もDuolingoで英語を学んでいます。
英訳や返信はChatGPTの支援を受けていますが、自分自身でも少しずつ英語を理解できるようになりたいと考えています。
今回の経験で、英語学習の目的も少し具体的になりました。
以前は、
英語が分かるようになりたい
という漠然とした目標でした。
現在は、
海外の記事を少しずつ読めるようになりたい
コメントの意味を自分でも理解したい
自分の簡単な言葉で返信できるようになりたい
技術情報を英語でも調べられるようになりたい
という目標へ変わりました。
学習した英語を実際の技術交流で使う機会ができたことで、Duolingoを続ける理由も強くなりました。
今後やりたいこと
今後は、次のことを続けたいと考えています。
- Qiitaで事実ベースの学習記録を続ける
- 過去のQiita記事を古い順にDEVへ英訳する
- DEV向けの文章・見出し・タグを改善する
- Qiita原文への
canonical_urlを設定する - 海外から届いたコメントを次の開発へ生かす
- PostgreSQL環境でのテストを増やす
- 売上時点の商品名や価格を保存する設計を検討する
- APIやDB周辺のpytestを増やす
- Duolingoで英語学習を続ける
- 自分の言葉で短い英語返信ができるようになる
発信すること自体を目的にするのではなく、
作る
↓
記録する
↓
共有する
↓
反応を受け取る
↓
改善する
という学習サイクルを続けたいと思います。
まとめ
今回は、Qiitaへ投稿してきたPython学習記録を、最も古い記事から一つずつ英訳し、DEV Communityへ投稿した活動についてまとめました。
きっかけは、
世界にもQiitaのような技術コミュニティがあるのだろうか？
という小さな疑問でした。
Geminiで調べてDEV Communityを知り、実際の発信活動では主にChatGPTへ英訳、文章調整、アイキャッチ画像作成を手伝ってもらいました。
ただし、記事の元となる経験や構成をAIへ任せたわけではありません。
実際にアプリを作る
↓
問題へ遭遇する
↓
原因を調べる
↓
修正して確認する
↓
Qiitaへ日本語で記録する
↓
ChatGPTと一緒に海外向けへ整える
↓
DEVへ公開する
という順番です。
最初は、英語に自信がない状態で海外へ記事を出すことに不安がありました。
それでも、
何事も経験。何事も挑戦。
失敗しても大きなデメリットはない。
と思い、行動しました。
その結果、海外の読者から記事への評価だけでなく、本番運用やデータベース設計についての具体的なアドバイスや、仕事経験を通じた共感まで受け取ることができました。
自信がついたから挑戦したのではありません。
自信がないままでも、やってみることを選びました。
先に多くを覚えてから実践する方法もあります。
しかし私は、
実践の中で必要なことを覚える
方が合っています。
今回の経験を通して、発信もまた実践であり、学習の一部になると実感しました。
完璧になってから外へ出るのではなく、未完成のまま外へ出て、返ってきた反応を次の学びへ変える。
これからもQiitaとDEV Communityの両方で、学習と開発の記録を続けていきます。
関連リンク
GitHub
GitHubプロフィール
Qiita
DEV Community
前回の記事