Mac/iOSのアウトライナーアプリ『Kosshi Outliner』をリリースしました。

Kosshi - macOS/iOS Outliner

A simple, local-first outliner for Mac and iOS.

経緯

2022年にアウトライナーを作り始めていたのですが、 仕事が忙しくなったり他のことを始めてしまったりで、プロジェクトが頓挫していました。

その後、久々にアウトライナーに熱中する時期が来て、プロジェクトが復活しました。 そこからはわりと集中して開発できて、最終的にKosshiとしてリリースすることができました。

どんなアプリか

階層構造を持つ箇条書きで文章を書いていくことができる、いわゆるアウトライナーのアプリです。 アウトライナーは、通常のメモアプリに比べて、まとまった文章を作る必要がなく、行単位で構造を変えやすいので、ガシガシと文章を書いていくのに向いています。

アウトライナーは、記事など文章を書く用途で使うほか、普段の仕事でもタスクの整理や設計をまとめる際などにもよく使っています。 既存のアウトライナーも十分便利ではあるのですが、自分のユースケースに完全に合ったアウトライナーは世の中に存在しておらず、 自分で理想のアウトライナーを作ることにしました。

Kosshiは、MacとiOS専用のアウトライナーアプリです。 ネイティブアプリとして実装しているので、操作感が良いのが特徴です。 MacとiOSでコードベースを共有しているので、両方のプラットフォームで同じように使うことができます。

また、もう一つの特徴は、Markdownで文章の装飾を書けることです。 ソフトウェアエンジニアだと、基本Markdownで文章を書いていくことが多いので、Markdownをそのまま貼り付けて管理できるのは便利です。 一方、現状はMarkdownで書ける前提のUIになっているので、Markdownを知らない人には少し敷居が高いかもしれません。

他には、MacとiOSの同期にiCloud (CloudKit) を使っているのも特徴です。 CloudKitを使うと、AppleのアカウントでユーザーのiCloudスペースでデータを管理できるので、 ユーザーは運営者が管理するサーバーにデータを預ける必要がなくなります（データはAppleのiCloudサーバーに保存されますが、アプリの運営者はアクセスできません）。

メモアプリには運営者のサーバーにデータを預けるタイプのものがありますが、プライバシーやセキュリティの面で気になることが出てきます。 運営者がデータを読み取れないようにするには、E2E暗号化などの対策が必要になってきますが、実際にはそこまで対応されているサービスは多くないと思います。 私個人としても、プライベートなメモやノートは、万が一の漏洩などが起こるとかなり悲惨なことになるので、 データを置くのに運営者のサーバーを介さない方が安心できると思っています。

またCloudKitを使うと、ユーザーはログインや会員登録をする必要がなく、 Apple純正のNotes.appと同じように、Appleアカウントでデータが同期できます。 これは使う側にとっても楽だと思います。

技術的な話

技術選定

最初はMac/iOS専用で作っていて、途中からやっぱりクロスプラットフォームで行こうかなとTauriで作ってみたりして、色々と試行錯誤していました。 が、結局、ある程度作ったもの同士で比較してみるとネイティブで作った時の操作感が明らかに良かったので、今の形に落ち着きました。

アウトラインエディタ

CoreTextでアウトラインのエディター部分を自作しました。

カーソル、選択、Markdown装飾、折りたたみ、ドラッグ＆ドロップなど、 だいたい全部自前で実装したので、エディター部分だけで25000行くらいあります。 ここは一番こだわったところです。

コア部分はMacとiOSで共有していて、パフォーマンスも意識して作りました。

同期機構の実装

同期の実装は、 ローカルのSQLiteデータベースとCloudKitのレコードをCKSyncEngineで同期しています。

最初の頃はMacとiOSで同期ミスが結構発生してしまっていて、自分のメモも何度も吹っ飛んでしまいました。

流石に仕事のメモが吹っ飛び続けるのはまずいので、オートバックアップの機能なども入れました。 今は安定していますが、同期周りは一番苦労したところかもしれません。

テスト基盤

今回のプロジェクトでは、かなりテストに力を入れました。

テストは4種類用意しています。 ユニットテスト、スナップショットテスト、パフォーマンステスト、E2Eテストで、 全体で約2,000件くらいのテストケースがあります。ユニットテストが95%くらいです。

パフォーマンステストでは、大量行の操作で遅くなっていないかをチェックしています。 ベースラインを決めておいて、それを超えたら警告、さらに超えたら失敗するようにしました。

パフォーマンスに関しては、まだ改善できそうではあるので、このテスト基盤を使って引き続き改善していきたいと思っています。

最後に

App Storeからダウンロードできます。1週間の無料トライアル付きです。

現在、$25で提供していますが、日本の方にはドル換算だと高くなってしまうので、1ドル＝100円換算の2,500円で提供しています。サブスクではなく買い切りなので、一度購入すればずっと使えます。

iOSアプリ『もふもふサイコロ』をリリースしました。

かわいい動物たちがサイコロを投げてくれる、ちょっとほっこりするサイコロアプリです。

もふもふサイコロ

かわいい動物たちがサイコロを投げてくれる癒し系サイコロアプリ

どんなアプリか

黒うさぎ、黒ねこ、プードルの3人のかわいい動物キャラクターから、 お気に入りを選んでサイコロを投げてもらえます。

サイコロの操作は2つのモードがあります。

• ボタンタップ: ボタンで気軽にサイコロを振れます
• スワイプ操作: 自分で投げる感覚を楽しめます

物理エンジンで再現された本格的なサイコロの動きで、リアルな転がり方を楽しめます。

ゾロ目の祝い

ゾロ目や連続で同じ目が出たら、動物たちも一緒に喜んでくれます。 これが地味に嬉しいです。

履歴と確率

過去の出目を最大9999回分記録して、確率もグラフで確認できます。

技術的な話

Swift + SwiftUI で開発しました。

サイコロのリアルな動きは SceneKit の物理エンジンで実現しています。 スワイプの方向に応じて力を加えつつ、ランダム要素も混ぜることで、 予測できない自然な転がり方になるようにしました。

サイコロが床にぶつかったときは触覚フィードバックも入れていて、 実際に転がしている感覚が出るようになっています。

使い道

ボードゲームや順番決め、運試しなど、いろいろな場面で使えます。 お子さんとの遊びにも良いかもしれません。

インストール

App Storeから無料でダウンロードできます。

開発時に Mac でローカルサーバーを立ち上げて、モバイルデバイスで動作確認したい場合がある。

サーバーを 0.0.0.0 で立ち上げると、同一 LAN 内であればプライベート IP アドレス（192.168.0.0/16）を使用してサーバーにアクセスできるけれど、 セキュリティ設定などで、localhost のみが許可されていて、プライベート IP アドレスを使うことができない場合がある。

このような場合、iOS デバイスと Mac 間で SSH ポートフォワーディングを確立することで、 iOS デバイスから直接 localhost のアドレスを使って Mac のローカル環境にアクセスできるようになる。

接続手順

1. Mac の共有設定から「リモートログイン」をオンに変更

システム設定から共有設定を開き、「リモートログイン」をオンに変更する。 これにより、Mac に SSH を通じて接続できる。

2. iOS デバイスに WebSSH (SSH クライアント) をインストール

App Store から WebSSH をインストールする。 このアプリを使うと、VPN-Over-SSH 機能により、 Chrome や Safari などの他のアプリで、ポートフォワーディングの設定を継続して利用できる。

3. ポートフォワーディングの設定

WebSSH を起動し、以下の手順でポートフォワーディングを設定する。

1. Mac の共有設定で確認した以下の情報を入力
   • ホスト名
   • ユーザー名
   • パスワード
   • プライベート IP アドレス
2. Port Forwarding の設定
   • 例：Mac 側で localhost:3000 を使用している場合は 3000:localhost:3000 と入力
3. VPN-Over-SSH を有効化
   • この設定により、他のアプリ使用時も SSH トンネルが維持されます

4. ポートフォワーディングの確認

ポートフォワーディングの設定が完了したら、iOS デバイスで WebSSH を開き、 ポートフォワーディングの設定が反映されているか確認。

最近、個人サイトを毎日少しずつ整えていってるのだけど、 だんだん改善してきてよくなってきたなと思う。 ここでは、個人サイトを持つことについて、 個人的に思っていることをまとめてみる。

個人サイトの良い点

まず、自分でサイトの発信内容やデザインを完全にコントロールできるのが良い。

noteでも記事を更新しているのだけど、 noteだと画面の折り返しの横幅が狭すぎて、なかなかコードが読みにくい。

あるいは、技術系の記事ならQiitaやZennでも投稿できるし、 たぶんその方が見てもらえるのだけど、技術記事以外を置くことができない。

個人的には、技術系の記事もそれ以外の記事もまとめて置きたい気持ちがある。 個人サイトは、なんとなく人となりがわかるような、そういう場所にしたいと思っている。

どうやって個人サイトを作るか

個人サイトを作るにはいくつかの選択肢がある。 まず、WordPressや Wix、 STUDIO などの、ノーコードのサイト制作ツールを使う方法がある。 これらは手軽で多くの人にとって便利な選択肢だと思う。

だけど、自分でWEBサイトを手作りすることも選択肢の一つとして提示したい。 静的サイトジェネレーターを使うと結構簡単に作ることができる。

静的サイトジェネレータ

静的サイトジェネレイターで有名なものには、 Astro、 Hugo、 Jekyllなどがある。

このサイトは、Next.jsの静的サイトジェネレート機能で作っている。

デザインのテンプレートを使えば、最初からそれなりのデザインのサイトを作れるし、 カスタマイズしたい場合は、ソースコードレベルで自由にカスタマイズできる。

あと、静的サイトは、コスパがよい。 このサイトは、Cloudflare Pagesにデプロイしていて、 ドメイン代（約1000円/年)を除けば運営コストがかかっていない。

ただし、敷居が高いのは間違いない。 また、WordPressなどでプラグインですぐに作れる機能も いちいち開発が必要になってくる。

ただ、そういう作る過程を楽しみたい人には、おすすめと言える。

「ゆっくり急げ」という言葉がある。 これは、2000年以上前に初代ローマ皇帝アウグストゥスが好んで使った言葉らしい。

この言葉が、現代まで残っているのは、 人類はいつの時代も、たいてい急ぎすぎて失敗することが多いということなのだと思う。

日本においても、「急がば回れ」とか、「急いては事を仕損じる」のようなことわざがあるけれど、 「ゆっくり急げ」という言葉は、急ぐことも重要と言っているのが違いだ。

単にゆっくりやれば良いというわけではないという部分が、 絶妙な表現で個人的に結構好きな言葉だ。

「ゆっくり急げ」は、開発現場でも役に立つかもしれない。 プログラミングは、急ぎすぎても、ゆっくりすぎても失敗する。

プログラミングでは「ゆっくり」は以下を意味するかもしれない。

• 読みやすいコードを書く
• ユニットテストを書く
• リファクタリングを行う
• ドキュメントを整備する
• CI/CDを導入する

その意味では、「急げ」は次のように解釈できそうだ。

• 早めにリリースする
• 早めにユーザーのフィードバックをもらう
• 必要最小限な機能を実装する
• 無駄な抽象化を行わない

コードの品質もリリース速度もどちらも大事というのが 「ゆっくり急げ」ということになる。

僕はある程度プレッシャーがなければ、「ゆっくり」作業する方に偏りがちだけれど、 ただ、時間的なプレッシャーがかかると、品質どころじゃなくなって、急ぎすぎてしまうこともある。

余裕がないときこそ「ゆっくり」、余裕があるときは「急げ」の精神で、 普段から「ゆっくり急げ」を意識したいと思う。

昔から思っているのだけど、いいものを作れるかどうかに必要な要素として、作るのにかかる膨大な時間を受け入れているかどうかがあると思う。

もちろん知識やスキルの要素もあると思うのだけど、膨大な作業時間を本心で受け入れているかどうか、というメンタリティの要素が実は大きいのではないかと思う。

昔、僕は以下の動画を見てかなりのショックを受けた。この方は半年間迷路を書き続け、最後に燃やしてしまう。

この動画はほとんど精神力との戦いだけど、こういうことが実行できるかどうかの精神力が、ものづくりには必要なのだと思うようになった。

自分の場合で考えてみると、プログラミングを覚えたてのときは、バグでなかなか動かないみたいなことがあると、1日無駄にしてしまったように感じていた。最近はこの程度はもはや何も思わなくなったし、なんなら1日で終わればラッキーと思うかもしれない。経験を積んだ結果、作業そのものに対する苦痛に鈍感になってきたように思う。

そうなると、何かものを作るのに半年とか1年とかの期間がかかるのは普通という感覚になってくる。そういう感覚になって、はじめてそれなりに大きなものを作れるようになったきた。僕の場合は10年くらいやってきて、ようやくそう思えるようになったかもしれない。

だけど、たまにこの痛みに最初から鈍感な人がいて、そういう人は、いきなり超大作を作り上げてしまったりする。そういう人は色々な分野で、何を作ってもすごいものを作り上げてるイメージがある。

そういう作業量に対する先天的な苦痛への耐性が、ものづくりの才能なのかもなあと思う。

フリーランスとして働こうと決意したものの、 退職時点ではまだ具体的な案件が決まっていなかった。 なので、本当にやっていけるかどうか確かではなかったのだけど、 「なんとかなるだろう」と深く考えずに退職を決めてしまった。

その後、カンファレンスで知り合った方や、昔の同僚から仕事を紹介してもらい、 無事にフリーランスとしての仕事をスタートすることができた。

これまでやってきた仕事は、ほとんど知人経由か、仕事で知り合った人経由なので、 フリーランスとして活動するためには、どこかの会社に入って仕事のつながりを作っておくのは、結構重要なのかもしれない。

フリーランスになってからは、なんでもやります的なスタンスだったので、 色々な案件に関わることができた。

例えば、

• React Nativeでのモバイルアプリ開発
• Flutterのモバイルアプリ開発
• Railsバックエンドの開発
• PythonでのAPI開発
• GoでのバックエンドAPI開発
• Next.jsでのWebサイト開発
• TerraformでのAWSインフラ構築
• 機械学習・AI関連の機能開発

などがあった。

最初の方は調査とアドバイスがメインの技術支援の仕事もしたけれど、 やっぱ自分でコードを書く仕事の方が面白いし、貢献できるので最近はやっていない。

フリーランスの仕事は会社員の業務と違って、ほぼ全ての業務時間がプログラミングなので、 それが自分には合っているなと感じている。

フリーランスでの仕事は思った以上に順調な一方、 元々の目的の個人プロジェクトが後回しになりがちだった。

元々は週3日を業務、残りの週4日を自分の開発と考えていたのだけど、 いつの間にか週7日稼働しているみたいな状態になることもしばしばで、これがこの2年間の大きな反省点だった。

まず、僕の場合、単純に開発スケジュールが厳しくなってきたりすると、 ついサービス精神で稼働を増やしてしまいがちということ。

また、個人プロダクトの方は、収益が発生するかどうかもわからないし、発生するとしても未来の話なので、 現実的に収入が得られる仕事の方が優先度が高くなりがちだった。

ソフトウェアの個人開発プロジェクトは、途中で頓挫したり、あんまり良いアイデアが思いつかなかったのだけれど、 最近は、ハードウェア制作を重点を置いていて、ミニロボットの制作を目標として、こちらで活動している。

Shirokuma Make

プログラミング、電子工作、3Dプリンターなどを用いて、オリジナルのプロダクトを作っています。

また、去年から関わっているミーアのプロジェクトに関わっていて、 こちらもハードウェアプロダクトの開発を行っている。

ミーア / Mia

おしゃべりAIペットロボット「ミーア」は、100以上の種類の豊かな表情で、全国47の方言（大阪弁・博多弁・京都弁・沖縄弁など）を話します。毎日の中に、ちょっとした幸せと便利を。誕生日や記念日のプレゼントにピッタリです

今後はハードウェア開発もできるソフトウェアエンジニアとして、活動していこうと思っている。

僕は元々プログラミング自体が目的みたいなタイプだったので、 実際のアプリ開発、サービス開発にあまり興味がなかったのだけれど、 社内ハッカソンに参加したことがきっかけで興味を持つようになった。

ヤフーでは毎年Internal Hack Dayという社内ハッカソンがあり、 社内だけの人間で、2日間かけて自由に新しいプロダクトを作って発表するイベントがある。 僕は退職するまで毎年このイベントに参加していた。 当時、ヤフーでの最大の業務はハッカソンに参加することですとチームミーティングで冗談で言っていた気がする。

僕の中では、プログラミングは一人でやるか、もしくは大人数で取り組むことが多かったのだけど、 ハッカソンでは、小さいチームを作って、自分たちのアイデアを実現するものなので、 普段やっていることとは違う楽しさがあった。

3回目の挑戦では、良い仲間に恵まれ、類似画像検索のサービス「ウユニ塩湖に行きたいんやが」を作り、 入賞することができた。 これは海外の観光スポットの画像に似た近場の観光地を提案してくれるサービスで、 予想以上に高性能なサービスが完成し、ヤフーのテックブログでその取り組みが紹介されたりもした。

ヤフーの社内ハッカソン「Internal Hack Day」を紹介します

12年の歴史をもつヤフーのクリエイター文化を語るには欠かせない社内ハッカソン「Internal Hack Day」について紹介します。

ハッカソンが終了した後も、同じチームでさらに何か新しいものを作りたいという話になり、 ソフトバンクグループのソフトバンクイノベンチャーという新規事業立ち上げのためのプログラムに応募し、 そこに出向して新規事業に挑戦することになった。

ソフトバンクイノベンチャーでは、「BAKOON!」というエクササイズサービスを作っていた。

これは、アプリ上にライブ配信の機能を実装して、アイドルと一緒にエクササイズをするサービスで、 モーションキャプチャ機能などを使って運動量を可視化したり、スタンプでコミュニケーションを行うサービスだった。

BAKOON!はReact NativeとFirebaseを活用したサービスで、技術的な取り組みは以下の書籍で詳しく紹介されている。

React Nativeに支えられる企業：React Native Japan

2017 年 10 月に 「 React Native as a Service 」 という本を技術書典では出させていただきました。その第二弾となります！！ 本書は、実際に使われている企業様にインタビューを行い、React Nativeがどのようにつかわれているのか？ なぜ選んだのか？　どのようなライブリを使っているか？ などを書き上げた、実践的な事例集となっています。そのため、綺麗な話だけではなく、現実に即した知見を得ることができるため、React Nativeを使ったサービスを作ろうとしている、あるいはすでに運用をしている方のお役に立てるかと思います。是非とも我々がお役に立つことができ、ともにReact Nativeを盛り上げていけることを願っています。

このサービス以前では、これまで本格的なモバイルアプリ開発の経験がなかったので、 モバイルアプリ開発、WEBフロント開発も初めての経験だったのだけれど、 基礎から学びつつ、なんとかリリースまでこぎつけることができた。

あと、エンジニアも含めてプロダクトについて議論したり、 マーケティングやビジネス面のKPI部分の設計なども考えていたので、 単純にプログラミングだけでなく、プロダクト全体を考える経験ができた。 ビジネスやマーケティングは思ってた以上にデータ分析的で、自分の数学的知識とかを活かせるなと思った。

リリースして1年くらい運用し、いろいろ頑張ったのだけれど、結局サービスはクローズしてしまった。 ただ、0→1でサービスを作った経験によって、僕がプログラミングでどういうことをしたいのかという部分が変化したと思う。 プログラミングそのものの楽しさよりも、アイデアを自分で決め、それを実現するものづくりが楽しいと感じるようになった。

自分でプロダクトを作るという新たな目標が生まれ、 開発時間を捻出するために、フリーランスとして独立することになった。

新卒で入社したヤフーには大きなデータサイエンスの部門があり、 僕は入社時の面接時にはその手の話しかしていなかったので、てっきりデータサイエンス系の部署に配属されるものだと思っていたのだけど、 気づいたらヤフーショッピングというサービス部門の検索チームに配属されていた。 希望の配属先ではなかったのだけれど、振り返ってみるとここでサービス開発に関われたのは良かったと思う。

当時は、検索APIの機能追加や検索エンジン自体の運用が主な業務だった。 コードベースが大きくて歴史もあったため、まずはそのコードを読み、理解することから始めた。

それまでソフトウェアの設計本などで語られる内容について、イマイチピンときてない部分も多かったのだけど、 実際に大きなシステムを見ることで、なるほどこういう複雑なシステムに対処する話だったんだな、というのがわかった。

また、社内で使われていた技術の多くは、外部のOSSよりも性能が高くて驚いた。 たとえば、今はOSSになっている全文検索エンジンのVespaや NoSQLのmdbmなどは、かなり高性能だった。 OSSで人気のものが性能面でベストだと思っていたけれど、実際は内部のツールの方が優れていたことを知った。

あとは、チーム単位でAPI、サブシステムを管理していたので、 機能開発にはチーム同士の連携が必要だった。

最近は多くても2~3人のチームで、調整などの仕事はほとんど発生しないのだけど、 当時は、新機能開発時やAPIのクローズ時に他のチームお願いしに行くことがよくあった。 こうした組織的な開発は、プログラマとしての社会人経験として結構大事かもしれない。

また、当時、開発だけでなく運用も担当していたことは結構重要な経験だったように思う。

開発と運用が分離していると、それぞれの都合の押し付け合いみたいになってしまうし、 バランスを取るにはどちらも担当するのがベストだと思うようになった。

仕事で思い出に残ってるのは、年に1度のセールの日を迎える前に、 リクエスト数の予測、サーバー台数の調整、負荷試験の実施など、色々対策を行うのだけど、 こういう経験は、大規模なサービスならではだったなと思う。

最近は小規模なサービス開発が多いので、こういうことはあまりやってないけれど、 いつかこの経験が役に立ちそうに思う。

会社に入ってからはJetBrainsのIntelliJ IDEAを使うようになった。 大学時代はEmacsを使っていたが、大学の後半ではVimをメインで使っていた。 しかし、実務で対応すべき言語が増えるにつれ、だんだん状況が変わった。

業務では、PHP、Perl、Java、Go、Pythonなど、多くの言語を使う必要があり、 セットアップが不要で幅広い言語に対応できるIDEを好むようになった。

業務外の時間では、ハイパフォーマンスなシステムに興味があり、 C++や効率的なプログラミングに関する技術を学んでいた。 特に、将来的にC++を使うようなプロジェクトに関わりたいという思いがあったので、 当時は業務とは別に自作プログラミング言語やインタプリタを作ってみたりしていた。

結局当時仕事でC++を使うことはなかったのだけれど、 最近ではファームウェアの開発でC++をガッツリ使っているので、この学びが意外にも役に立っている。