Duolingoについて

自分は無料プランで英語学習のために利用している。今のところ278日継続しているようだ。3ヶ月で飽きる自分が続けられているのは、Duolingoの仕組みによるところが大きいと思う。

1. アイコンの変化 Duolingoを利用している人は見たことがあると思うが、このアプリはアイコンで訴えかけてくる。何をきっかけに変えているかは定かではないが、常に変顔をしてくるのだ。これがスマホを触ったときに目に入り、意識付けをしてくる。

2. 執拗なまでの通知 いつもアプリを起動する時間までにレッスンを終えていないと、メールとプッシュ通知で執拗なまでにリマインドを送ってくる。この通知をタップしてレッスンを開始することが多い。

3. 連続日数の表示 正直、自分にはそこまで刺さっていないが、連続記録日数（ストリーク）を表示してくれる。これによって「今日もやらねば」という意識が働いているところはある。

この三つの要素が主に継続率に影響していると思う。私の場合、3ヶ月で続かなくなる背景には、そもそも意識が向かなくなって徐々にフェードアウトしていく傾向があるので、このDuolingoのリマインドは非常に効果的に感じている。

習慣が人を作る

習慣の大切さは様々なコンテキストで語られている。私の好きな映画『キングスマン』には「マナーが人を作る（Manners maketh man）」というセリフがある。日々の礼節を大切にすることが人を作る、という意味だ。また『Atomic Habits（邦題: 複利で伸びる1つの習慣）』の著者であるジェームズ・クリアも「習慣が人を作る」と言っている。日々の習慣の積み重ねで、先の未来が大きく変わるということだ。その他にも様々な偉人や歴史が習慣の大切さを語っており、習慣が人を作るということは間違いないと思う。だからこそ、習慣を作るのに遅すぎることはないし、それを継続する意識は持ったほうが良いと思う。

習慣を作ってみる

私が読んできた様々な本では、「毎日継続できる小さなハードル」を設定することが重要だとよく書かれていた。それを信じてやってみたが、これがまた続かない。なぜなら意識の外にいってしまうからだ。そこでDuolingoを参考に、リマインドを送る仕組みを作ってみた。

仕組みは非常にシンプルで、NotionのDBにその日の活動記録を付け、ClaudeのRoutineで定期的にDBをチェックし、未達の場合はリマインドを送り、届いたリマインドから完了報告を行う、というものだ。これでDuolingoっぽい体験を再現できていると思う。

今のところ無理なく続いている。やっているのは運動、掃除、勉強の3つだ。早速少し良い効果が出ていて、運動をしながら気になっていたテック系のPodcastを聴いてみている。これが思ったより良くて、非常にクリアに耳に届いて頭に残る。『ドラゴン桜』でも、ただ勉強するより何かをしながら学んだほうが定着率が上がると言っていたが、まさにそういった効果を感じている（もしかしたら短期記憶なのかもしれないが）。

次のステップ

いまはとりあえず自分に足りていないことをやっているだけだが、将来的には長期目標を立てて、そこにアラインする形でやれると尚良いのだろうと思っている。しかし1年以上先の長期目標を立ててしっかり取り組むのがこれまた苦手なので、これは次の課題として考えていこうと思う。

エンジニアという職業に就いてから、土日の時間を使ってひっそりと何かを作ってリリースすることをやってきたが、これまでは勉強目的のものが多かった。今回はちゃんとリリースして運用していくことを目的にやってみている。というのもAIコーディングが発展して「この表現どうやって実装すればいいんだ！」みたいな壁も簡単に乗り越えられるようになり、サービスの出来栄えも自分としてはある程度満足できたからである。

何を作っているのか

toC向けで、作業効率を上げる系のサービスを作っている。人と他愛もない雑談をしている中で「この作業やりたくないなー」と感じたことを自動化して公開した。人の不便を解決することはやはり需要があるようで、ある程度の人に使ってもらえている。

リリース以来の累計で1.1万人、MAUでいうと約1,500人ほどが利用している。

毎日使うようなサービスではなく、四半期に1回開くかなあという感じなのだが、サービス特性を考えるとまあまあの数字かなと思う。

開発環境やインフラなど

• 開発環境

  • 開発マシンWSL2
  • ツールなど
    • Claude Code（Max）
      • 開発、レビュー用途
    • Copilot
      • レビュー用途
    • Docker Compose
      • ローカルでの開発環境構築
  • CIマシンUbuntu Mini PC
    • GitHub Actions経由で、self-hosted RunnerをつかってPR作成時の自動Preview環境を作成
    • PreviewはCloudflare Accessをつかって公開

• アプリケーション

  • フロント
    • React, TypeScript
  • バックエンド
    • Golang, Gin

• 本番環境など

  • インフラ
    • Cloudflare, Cloudflare Pages, Cloudflare Workers
    • Supabase
    • Resend
  • モニタリング
    • Sentry, Discord, IFTTT（不具合のつぶやきなどみてる）
  • CI/CD
    • GitHub Actions
      • 自動Preview環境構築（前述のとおり）
      • 自動テスト
      • 本番デプロイ
      • Health Check（定期的にAPIの疎通確認して、失敗したらDiscordに通知）
      • コスト監視（定期的にCloudflare / GCPのコストを確認して、一定額を超えていたらDiscordに通知）

• 本番のセキュリティ周り

  • CloudflareのWAF
  • Cloudflareで日本以外からのアクセス全ブロック
  • GitHubのDependabotで脆弱性チェック
  • サプライチェーン対策
    • SHA Pinningの強制
    • Takumi Guardの導入
  • Cloudflareへの異常アクセスを能動的に監視
  • RBACをもとに、403アクセスが発生した際のDiscord通知（基本は起こらない）
  • シークレットの定期ローテーション
  • 利用ユーザのメール必須化
  • すべての重要機能にMFAの必須化
  • セルフで脆弱性テストを実施するイテレーションの仕組みを構築
  • etc...

ざっとこんな感じ。あまりお金をかけずにできることはやっているつもり。 PIIはSupabaseの管理テーブルにのみ保持しているが、CloudflareのProプランの導入検討や、利用ミドルウェアの脆弱性通知を収集する仕組みをつくるなど、セキュリティ周りはもう少し強化していきたい。

最初はK8sで作るか！とも思ったけど、サービス開発の時間が割けなくなるので、なるべく楽に運用できる構成にした。 この構成ではCloudflare Pagesにちょっと癖があってハマることがあったので、それは別の記事で書こうかなと思う。

今後やっていきたいこと

前述のセキュリティ強化はもちろんだが、サービスのDAU・MAUをKPIに据えて伸ばしていきたい。そのために今後も地道にユーザの声を聞きつつ、突き抜けた使いやすさを追求したいと思っている。世の中のWebサービスは機能が多すぎて複雑だなと感じるので、シンプルでわかりやすいUI/UXを追求していきたい。

これは盆栽である

このサービスはあくまで趣味でやっている盆栽のようなものである。そのため収益化の予定は今のところない。人のためになって誰かが喜んでくれたら、それで十分である。 個人開発は全部自分でやることになるから、サービス開発の脳トレになって勘所が磨かれるし、普段本業で触らない技術にも挑戦しやすいのが良い。 あと自分の財布から出費しているので、ちゃんとコスト管理しないと自分が辛くなる、という適度な緊張感があるのもいい。

利用ユーザがいるうちは責任をもって運用を続けていく。

自分のキャリアの中で中長期を見据えた取り組みを何度かしてきた。想定通りうまくいったものや、失敗したと感じる施策もあった。振り返るとそれぞれのなぜは言語化できるようにおもう。ただ昨今のAIのようなパラダイムシフトの中で本当に中長期の戦略を考えることに如何ほどの意味があるのかと疑問に思うことも増えてきた。これらのテーマについて自分の考えを発信することはまだ正解がみえてないので避けてきたが、GWでやや余裕があるので答えがわからないながらも思考を整理すべく書いてみることにした。

中長期を見据えたアーキテクチャ戦略の必要性

私の主張としては、目先の課題や目的に対するアーキテクチャ戦略自体は当たり前に必要だと考えている。

• 技術的負債を最小限に抑えるため
• AIが理解しやすいコードにする必要があるため
• チームの生産性を向上させるため
• etc...

などこれらは当たり前かもしれないが、事業を支える観点ですぐれたアーキテクチャはアウトプットに直接影響し、その先のアウトカムの創出にも寄与する。これは多くの人がそう思っていると思う。

では、"中長期を見据えた"アーキテクチャ戦略は必要なのか？という問いに対してはどうだろうか。ここでいう中長期のアーキテクチャ戦略というのは、例えば複数サービス展開をしていきたいという考えであれば、共通認証基盤が必要になるよね？という話だったり、組織が大きくなったらチームが細分化して担当領域が細かくなるはずだからマイクロサービスの戦略をとっていったほうがよいのではないか？ みたいな話である。将来のあるべき姿を想定して、そこに向けて今から準備をしていこうというスコープの検討、これが必要なのかを最近疑問に思っている。

なぜ疑問に思っているかというと

• 将来のあるべき姿を想定してそこに向けて準備をしていくことは、将来のあるべき姿の想定が違った場合にやっていることが無駄になってしまう
• 期待した未来がくるまではそのアーキテクチャは、直近の最適化されたアーキテクチャではない可能性がある。そのため本来期待した恩恵を受けるまでの期間はある意味、備えるだけのコストが重荷になる。
• いまのAI時代であれば常に目の前の課題の最適化を最速でやることが可能になってきている
• headless SaaSやMCPのようにプロダクトの価値提供の形自体がAIによって変わりつつあり、従来の延長線上で描いた将来像につながる確度が低くなっている

以上の背景から中長期を考える必要がないのではないか？という疑問も持つようになった。

疑問には思うけれども...

中長期を見据えておかないと辛い部分はやはりでてくると考えている。特に後から変更が効きにくい不可逆な判断にこそ中長期の視点が必要で、そこを短期最適だけで進めたときに後から払うコストが大きくなる。まあ単純に従来の運用開発と照らし合わせてAIで容易にできるならそんな考える必要なく、AIにできないことはちゃんと先をみて作ろうぜって話なのかもしれない。一例ですが

• AIで容易に変更できること
  • アプリケーションレイヤーの対応全般
• AIで容易に変更できないこと
  • データベースのスキーマ / データの分離対応（本来領域が違うテーブル同士をJOINしている場合など）
  • オブザーバビリティの整備など（全部自前で作るよりは、Otelにのっかってplugableな設計にしておくなど）
  • etc...

後者のようにドメイン的に許してはいけない越境をしてしまっていたり、データが蓄積される場所やその連携方法をとりあえず目先の目標のためにえいやで作ってしまうと、たぶん将来の誰かがとても苦しむことになると思う。

というか短期的な観点での最適化と中長期を観たときの最適化だと、前者のほうが手軽だしメリットがあるし最高みたいな空気になるとおもう。それは中長期的な観点での備えをやらないというトレードオフ（白黒というかグレーなグラデーション）なのではとおもうので、ちゃんとその判断をした結果やってるのであれば問題はないのだとおもう。

中長期施策を推進する難しさ

アーキテクチャは課題を解決するための手段でしかないので、何を選ぶにしてもトレードオフになりがちだし、どんなアーキテクチャがいいかは所属する組織の様々な状況に応じて変わる。なのでいいアーキテクチャは何かということは一旦置いておく。

その上でここは個人的な振り返り。これまで中長期的な取り組みでうまくいかなかったなーと思うものを振り返ってみると、大体は中長期のプロジェクトに最後までかかわれなかった / 引継ぎ先がなかったというケースが多かった。中長期的な取り組みとして立案・導入をしたが、リソースの問題で担当外になってしまったパターンや、それが何でどう必要なのか関係者に伝えきれないために期待していない方向に進んでしまったなど、いわば注力できなかったのでやりきれなかった。中長期の施策を考えるときは将来的な組織状況などを考慮した上で立案・導入するのだから、リソース状況的に別PJにアサインしたいといわれても、そこでもっとぶつかるべきだったのかもしれない。もしぶつかった結果それでも外れるのであればアーキテクチャの廃止か継続可能なコミットメントし続けられる体制を模索するべきだったのだとおもう。そこの思考を放棄していたことについては他責になってしまっていたと反省している。

おわりに

先日昔の職場の上長とお会いして、この記事のような内容の話をさせてもらった際に「まこたすが偉くなったらいいんだよ」と言われたのがとても印象的だった。たしかに自分がやろうとしていることは中長期的にこうあるべきという意思をもって描いているし、それが組織の生産性をあげると信じてやっている。その実現性をあげるために偉くなることは一つの手段としてとても重要なので、そういうキャリアも考えてもよいかもと思った。

以前から4人以上のMTGなどにおいては、やや発言のしにくさを感じる場面があった。相手の話に対して意見を言う時よりも、「いいね」みたいな相槌や同意のリアクションが得意ではない。これは「いいね」と発言することで、相手に続きがあることを期待させてしまい、話の流れをさえぎってしまうのではないかという懸念からきている。 　 自分がメインの話し手になっている場合を考えてみよう。淡々と話を進めているが相手からリアクションが得られてないと感じる時がある。これは本当に何も響いてなくてリアクションがないパターンもあると思うが、先述の私のようなリアクションが苦手な人もいるのではないかと考えるようになった。話し手としては、相槌・頷き、意見の提言などがあると建設的な議論をしやすくてうれしいなと（少なくとも）私は感じる。

アイデア

そこでこんなものをAIに作らせてみた。

「オレの意見」https://www.maco.life/oreno-iken/

いたってシンプルで、同意、異議あり の二つのボタンがあり押すとそれぞれの音声が再生される。これをMTG参加者がスマホに出して表示しておき、感じたことを感じたタイミングで押すという使い方だ。同意は、昔あったトリビアの泉というTV番組の「へぇ～」みたいな使い方をし、異議ありは意見がある場合に押して発言する という想定。異議ありって言葉が強いけど、某裁判ゲームっぽい雰囲気が頭に浮かんだのでその文言にした。それ以上の意味はない。

おわりに

とまあ仕事の昼休憩にこんなものを作ってみました。今回作ったものはまだMTGで利用してないのですが、今度チームオフサイトがあるのでそこで利用しようかなと考えております。

Expoでの環境変数の扱い

公式のドキュメントはこちらを参照してほしい。

基本的にExpoでは、

• .envファイルを使って環境変数を管理
• expo.jsonで読み込み

以上の方法で管理でき、どちらも自動読み込みされる。.envに関しては読み込みされるパターンと優先順位が定められている。what-other-env-files-can-i-useを参照。

よくあるパターンで、EXPO_PUBLIC_で始まる環境変数はクライアントサイドでアクセス可能になる。またドキュメントにもある通りこれは平文で保存されるため秘匿情報を絶対にいれてはいけない。EXPO_PUBLIC_に関しては秘匿情報を絶対にいれてはいけない（大事なことなので二回）。

EXPO_PUBLIC_で定義してる時点で丸見えではあるが開発時に平文で持っておきたくない情報は、EAS（Expo Application Services）に可視性（Plan, Sensitive, Secrets）を設定することでビルド時に注入できる。具体的には、こちらの公式ドキュメントを参照。

秘匿情報を使いたいんです...

とはいっても秘匿情報を扱いたいケースはある。これに関してはBackend API側で秘匿情報を扱いそこで利用するしかない。 例外としてクライアントだとGoogleMapのAPIキーを扱いたいというケースもあるが、それはEXPO_PUBLIC_に設定した上でAPI Keyに実行できるアプリの制限をかけることで利用可能になる。

ローカルでの開発

混乱を招かないために、基本的にはesa.jsonだけで管理するのが良さそうにおもう。。どうしても.envファイルを使いたい場合は、.env.localなどでローカル専用の環境変数を定義し、gitignoreに追加する方針でやるべし。

小話

react-native-map というreact-nativeでGoogleMapを扱うライブラリがある。このライブラリの扱いについて、expoの公式ドキュメントに記載がある。

公式ドキュメントによると

   "android": {
      "config": {
        "googleMaps": {
          "apiKey": "process.env.GOOGLE_MAPS_API_KEY",
        },
      },
    }

以上のようなフォーマットで埋め込むことでexpoがprebuildでmanifestのmetaタグにGoogle Map API Keyを埋め込んでくれそうな記述があり、それにそって設定を進めてビルドしていたが全然うまくいかなかった。色々試行錯誤してもAIに聞いてもうまい回答が返ってこなく、react-native-mapのgithubの公式ドキュメントをみたらv1.22以降からplugin方式に代わっていた。 expo

{
  "expo": {
    "plugins": [
      [
        "react-native-maps",
        {
          "iosGoogleMapsApiKey": "YOUR_KEY_HERE",
          "androidGoogleMapsApiKey": "YOUR_KEY_HERE"
        }
      ]
    ]
  }
}

利用しているバージョンをちゃんと見て、公式のリポジトリを見たりソースコードを読んだら気づけることだったが地味にハマった。

最後に

こういうところをAIに頼って曖昧なまま進めると事故ってしまうので、面倒だけど備忘録を通して徐々に学習していきたい。

※もし内容に間違いがあればご指摘いただけると嬉しいです。

この一年はAIが進化して様々な場面で活用された一年でした。エンジニアの自分としても、Claude Code, Codex, GitHub Copilot, Devin, CodeRabbit, Cursor など... 利用してきたAI開発ツールの数をあげたらたくさんありました。またそれらのAIツールは日進月歩で進化しており、

「今日は〇〇の機能追加があった」

「こっちのAI Agentのほうがいけてるらしいぞ」

「並列開発できるようになって生産性N倍だ！！！」

...

キャッチアップ、AIが書いたコードのレビュー・AIの嘘を嘘と見抜くことに追われる毎日。

気づいたら心身ともに疲弊していました。そして自分を見直すことが必要なのでは？と思い坐禅をすることになりました。

なぜ坐禅

前段の話は半分冗談半分本気ではあるのですが、現在所属している会社のチームビルディングの一環で坐禅体験をしようという流れになり坐禅に挑戦しました。坐禅の案を出したのは私なのですが、「年を越す前に一旦自分を見つめなおす必要があるのでは？」という思いではありました。

また坐禅体験ってすぐできるものなのか？という疑問もありましたが、世田谷にある龍雲寺にて体験できることを知り、申し込みをしました。

• 妙心寺 東京禅センター 坐禅会
• 龍雲寺

今回は団体だったので電話での予約になりました。電話では「個人で参加する方もいらっしゃるので騒いだりせず、個の気持ちでお越し下さい」と伝えられました。一緒に行くメンバーにその旨を伝えたところ「チームビルディングとは一体...？」という深遠な禅問答をいただき、出発前から既に意識が高まっているのを感じました。

体験当日

私は今回が初めての坐禅体験でした。現地のお寺はとても厳かな雰囲気でやや緊張しましたが、他にも団体の方がいらっしゃったり受付で丁寧に案内いただき本堂までスムーズにはいることができました。

坐禅体験会は今回はほぼ満席（30名ほど）で、老若男女様々な方がいらっしゃいました。最初に僧侶の方から坐禅の基本についてお話いただきました。お話の中で「無心」とはどういうことかという話が印象的でした。お話いただいた僧侶の方の解釈では、「心を空っぽにするというよりは、今ここで坐禅をしているということに意識を向けて向き合うこと」と説いていただきました。そうすることで坐禅で整えるべき、姿勢 / 呼吸 / 心が整うとのこと。この他にも坐禅とはそもそもなにかということや、今月は成道の日がある月なので、各地で坐禅が執り行われていることなど体験会に参加しなければ知りえなかった様々なお話をしていただきました。

体験会での坐禅中では、正しい姿勢で目の前の畳の縁をずーっと見つめている姿勢をしていました。その際最初は「あー、Slackで連絡が来ていたCI/CDの対応どうしよう」とか、Claude Codeのロゴが浮かんだりしていたのですが、体験会が進むにつれて徐々に無心になっていくのを感じました。最後のほうでは、警策（坐禅の時によく見る棒）をお願いして打ってもらう貴重な体験をさせていただきとてもありがたかったです。

体験会自体は先述の内容に加え、ありがたい法話をしていただくなどとても濃い時間をすごさせていただきあらためて良い時間を過ごせました。

一緒に行った同僚からも「普段無心になれることがないので良い体験だった」とフィードバックがありました。

まとめ

目まぐるしく技術が進化する業界に身を置き、常にアンテナをはって反応してしまうと疲れてしまったり、大事な何かを見失ってしまうこともあると思います。AIと全力で並走することで、我々のメモリが圧迫されSwapを使い切ってしまう前に、たまには坐禅を通して心のリブートをしてみるのも選択肢として良いのかなと思います。

コーヒーと私

私とコーヒーの付き合いは長く、小学校2年生に初めてコーヒーを飲んだことが始まりである。コーヒーを飲む前はコーラをたまに飲んでいたが、母にコーラは糖尿病になるからやめなさいと強く言われ、コーラの代わりに飲み始めたのがコーヒーだった。子供にとってコーヒーもそれなりに体に悪いとおもうのだが、なぜか両親に止められることはなくなんなら自分の分もよく買ってくれた記憶がある。そのままカフェイン中毒の道を歩み、毎日2~3杯はコーヒーを飲んでいる。

検定を受けたきっかけ

何か事情があったわけではない。これまでの人生でコーヒーはカフェインを摂取する嗜好品として嗜んできて、味の良し悪しとかはそこまで気にしてなかったが、一旦ちゃんと学んでみるのもありかなと思い資格などないか探したところ「コーヒーインストラクター検定」というものを見つけた。

検定の一番下の3級は、認定を得るためには1時間30分ほどのWeb講義を受けるのみとのことで手軽に取れるようだったので、申し込みをして受講した。申し込んだ後に知ったのだが、3級はコーヒーを好きになる/知ることを後押しするためにハードルをかなり下げているらしくまさしく自分みたいな人が対象者であった。

受けてみた感想

日常コーヒーに触れるうえで知っておいたほうが良い基本的な知識を丁寧に教えていただきとても良い体験だった。広く受講されてほしいので詳細は書かないが、印象に残った項目は以下のようなものがあった。

• コーヒー豆の種類と特性
• コーヒーの焙煎の歴史
• コーヒーの酸味とは何か
• 焙煎をすると何が起こるのか
• キリマンジャロやブルーマウンテンのようなコーヒーが高い理由
• どのようにコーヒーを入れると、どういう味わいになるのか（焙煎→抽出）
• 最近話題のスペシャリティコーヒーとは

あと講義の最初に「おいしいコーヒーは人それぞれである」と一言あり、多様性を意識した発言があったのが個人的に安心感があった。

最後に

受講を経て無事3級に認定していただけたので、今後コーヒーについて語るときは「自分コーヒーインストラクター検定3級だから分かるのですけれども」と枕詞を使っていこうと思います。

何を書くか

• 日常のあれこれ
• 思いついたアイディアとかメモ
• 勉強したことのメモ
• 読んだ本のこととか
• その他、残しておきたいこと

ガッツリ技術的な話は Zenn で書くとして、こっちは日常の記録とか、気楽に書ける場所にしたいとおもいます。

デザイン

白黒ベースでシンプルに。装飾は最低限。 静かにブログを書けることを意識しました。

これから

気が向いたときに、思ったことを書いていきます。

よろしくお願いします。