kitano

## プロジェクト概要 ### 目的、背景 Flutter で楽譜を描画するパッケージを開発し、pub.dev へ公開した個人開発OSS。前職（工事用機器メーカーの商品開発）から Web・モバイル開発へ職種転換するにあたり、「キャッチアップできる」と言うだけではなく**公開された検証可能な実績を残す**ことを目的に、「楽譜をソフトウェアで扱う」というテーマを描画・認識・アルゴリズムの3方向から実装して検証した。本プロジェクトはその中核。 ### 規模感、チーム構成、担当した役割 - **公開**: 2024年3月。以降現在まで**計14バージョンを継続リリース**（転職後もメンテナンス継続中） - **チーム**: 単独開発。企画・要件定義・設計・実装・テスト・運用保守の全工程 - **実績（2026年9月時点の実測値）**: pub.dev **likes 20** / **pub points 150（160点満点）** / **月間ダウンロード 554** / GitHub **Star 21** / MITライセンス - **対応プラットフォーム**: iOS / Android / Web / macOS / Windows / Linux の**全6プラットフォーム** ### 使用技術や開発環境 Dart / Flutter（CustomPainter による Canvas 描画）/ Git / GitHub / GitHub Actions（CI）/ pub.dev ## 取り組んだ課題 ### どんな課題だったのか - **前例がない**: Flutter 向けの楽譜描画ライブラリに参考実装がなく、設計の準拠先がない - **記譜法のドメインルールが複雑**: 音符の連結、臨時記号、小節幅の決定など、例外の多いルールをコードに落とす必要があった - **命令的APIの使いづらさ**: 既存の楽譜描画アプローチは命令的で、呼び出し順序の間違いが実行時にしか分からない - **6プラットフォームでの描画差分**: フォントメトリクスの扱いが環境によって異なる ### 技術的なアプローチや工夫した点 - **宣言的API設計**: Flutter の Widget ツリーと同じ感覚で楽譜を組み立てられる形にし、**不正な楽譜構造をそもそも表現できない型設計**にすることで、実行時エラーをコンパイル時に寄せた - **描画とレイアウトの分離**: 「何を描くか」と「どこに置くか」を分け、記譜ルールの追加が描画コードに波及しない構造にした - **デザインパターンの適用**: Builder / Strategy / Factory を用い、新しい楽譜要素の追加を既存コードの変更なしで行えるようにした - **CIによる回帰検知**: GitHub Actions で自動テストを回し、計14バージョンのリリースを破壊変更なしで続けられる状態を保っている - **Issue対応**: 利用者からの Issue ・要望を受けて機能追加・修正を継続 ## 関連して取り組んだ検証（同テーマ・別アプローチ） - **楽譜認識（OMR）**: 紙の楽譜を機械可読な形式へ変換することを目的に、物体検出モデル（SSD）を学習させ、実際の楽譜上での音符・記号の検出を確認 - **運指決定アルゴリズム**: 入力された音名列に対し、バイオリンの最適な運指を**動的計画法（DP）**で算出するロジックを実装（TypeScript） ## 取り組みの成果 - 前例のない領域で、企画から運用までを単独で完結させ、**公開後2年半にわたってメンテナンスを続けている**（計14バージョン） - pub.dev **pub points 150/160**、**月間ダウンロード 554**、GitHub **Star 21**という外部から検証可能な指標を獲得 - 複雑なドメインルールを型とアーキテクチャで押さえる設計ノウハウ - このパッケージで身につけた Flutter の設計力が、入社3ヶ月で約30画面規模のアプリのテックリードを任される土台になった ## まとめ 職種転換の「本気度」を言葉ではなく公開された数字で示すために始めたプロジェクトです。楽譜という例外の多いドメインを、宣言的APIと型設計で「間違った使い方ができない」形に落とし込む作業を通じて、ライブラリ設計の考え方を身につけました。転職後もメンテナンスを続けており、「公開して終わり」にしていない点も見ていただければと思います。