レナ改革 / 活動見直し

皆様、新年あけましておめでとうございます。¹

2026年睦月を迎え、凍晴の空が広がる時期となって参りました。昨年は Alice Project や maui-linux を初めとした多くのプロジェクトを通じて技術や運営の経験を積み、着実に成長することができたと感じております。今年も実りある1年にできるよう一層邁進して参ります。

さて、本題に入りましょう。本資料では、今までの活動をついて振り返り、課題点の発見とその対応策、改革方針について考え、その内容を記載しています。²

きっかけ

私は、2025年の約1年間、GitHub コントリビューション (後述) を参考として、ほぼ毎日欠かさずに開発を続けてきました。この期間の間はずっと、長期間継続的に行えていることに満足していました。

ただ、12月後半から旅行に行っていたため、継続が難しい状況になりました。以前は、Git の Commit を過去の日付を指定することで継続させていました³が、今回は1週間半程度とやや長期間空いてしまったので、その手は利用せず、ここで継続する習慣を一旦終了としました。

この継続する習慣が途絶えたことで、いくつかの良い点が見えてきました。そこで、この習慣を初めとした、組織思想から逸れた活動などに関して課題点が見えてきたので、それらを考え直し、改善に役立てたいと考え、この文章を作成しました。

課題点

形式化した開発

開発を継続する習慣の形骸化

私は、2023年以降のほとんどの開発プロジェクトにおいて GitHub を利用して開発しています。GitHub は非常に便利なサービスであり、これなしに開発はできません。

特に、2023年前期からは GitHub の Contributions (いわゆる GitHub の草) を開発量の参考として意識していました。

開発を継続することで、技術力が上昇して行くと考え、GitHub のコントリビューションを長期間継続したいと考えていました。結果として、以下のようなメリット、デメリットが見えてきました。

• メリット
  • 開発の継続による技術力の定着
  • 継続によりプロジェクトの大規模化
  • Ivy Cafeteria 内部向け資料の Git 化 (コミット数を稼ぐ目的だが、wiki として見やすくなったという点においてメリット)
• デメリット
  • 最低1日1コミット⁴が必要なので、1日で成果になるものしか取りかかれない (挑戦的なことができない)
    • 大規模改革、新機能・新プロジェクトが作りにくい体制
    • リファクタリングが主になる
  • 意味のないコミットが増える
  • 毎日開発を続けないといけないという義務感と心理的な負担
  • 忙しい時期にもこちらに気を使う必要がある労力的な負担

継続する習慣を初めた頃はメリットが目立っていましたが、活動を続けるうちに、デメリットの面がどんどんと見えてきました。最終的には新しい技術の確立ができず、メリットは殆どなくなり、いつの間にか古いプロジェクトに固執し続けてきました。

この習慣が終わってからは、毎日開発をしなければいけないという義務感がなくなり、気持ちが楽になりました。また実際に、Alice Project 管理の Alice Novel では大規模リファクタリングや放置され続けていたバグの修正を行えました。これは、たまたま時間を取ることができたというのもありますが、それ以上に「1日で作業が終了しなくても良い」という安心感の下開発できたから、という心理的安全性が高まったからと言えるでしょう。

過度な保守性

C# への固執と技術力の上限

LRA 及び傘下の組織は C# に強く固執しています。実際、C# 以外で利用している言語はほとんどなく、ウェブ系で利用している JavaScript / TypeScript 程度しか見られません。

元々、様々な言語を学習することによって、貴重な学習時間が分散して広く浅くの学習になるのを避けるために、万能言語である C# を選択し、集中学習していました。これは、技術力が低かった当時の選択として妥当性の高い選択と見ています。

しかし、現在はすでに C#の主要機能やプログラミング言語全般の一般常識についてはある程度理解できており、この方針を続ける必要性は低くなっていると考えます。

もちろん C# の内部処理や高度なプログラムの方法など、理解できていない部分も多いです。しかし、C# という単独の言語に固執するより、知識の汎用性が高いメモリ管理 (低層の開発では利用するはず) や速度向上のテクニック (アルゴリズムや非同期処理など)、その他言語に関係なく利用できる知識の習得のためにも、他の言語の学習を進めることにメリットを見出しています。(必須とまでは言えませんが)

過去の遺産に固執した開発体制

(先述した) 開発を継続する習慣にも記載した通り、新規プロジェクトの設置がほとんど行えませんでした。

(内容的には後述する、新規プロジェクト創設関係と重複する部分あり)

以下は2025年の月別のコミット数のランキングを示します。

• 斜体は影響が小さいもの
  • fluores: 実質プロジェクト停止 (依存更新のみ)
  • wiki: 内部資料
  • Aliénor Cast: 内部プロジェクトかつ停止
• 太字は影響が大きいもの
  • Akizuki Forest: Alice System を導入、大規模リファクタ
  • Common Novel: 新規プロジェクト
  • Novel IL: 新規プロジェクト
  • ReFlight: 新規プロジェクト (現在はほぼ終了)
  • mauigtk.net: 新規ウェブサイト (外部組織要請)
  • articles-qiita: 新規記事

ランキングを見てわかるように、全体として Alice Project 系の開発に偏っている。(CI/CD を用いた依存更新が多いのは強く影響しているが)

また、新規・成長プロジェクトについても Common Novel、Novel IL、Akizuki Forest⁵ に関しては Alice Project 関係なので、その偏重がわかるでしょう。

しかもその影響で、自主的かつ完全新規の開発プロジェクトは ReFlight のみとなっています。⁶

原因の考察については、後述の新規プロジェクトの欄を参照してください。

新しい視点の欠如

こちらも後述する新規プロジェクトの創出と類似する点を含みますが、旧来の方法にこだわり新しい仕組みや方法の導入がやや遅いと感じます。

原因についての考察は後述する、「新規プロジェクトの新鮮さ」にて記載します。

客観性の不足

Alice Project の目的意識の不明瞭さ

Alice Project についての目的について言及するには、設立当初から現在に至る歴史を振り返る必要があります。

2023年7-9月頃、当時は LEC NEO 部門の Himeno Next (Himeno Flex 開発計画) のもと活動を行っていました。Himeno Flex は当時としては期待の大きい計画で、このアプリケーションの完成によって、ただし、Himeno Flex は MAUI での開発に難航しており⁷、開発後半からは次期計画に期待がかけられていました。その次期計画として白羽の矢が立ったのがこちらの Alice Project (当時は Alice Novel 単独の計画) です。

そういった経緯で開発が始まった Alice Novel ですが、当初の目標は概ね以下のようなものでした:

• 技術力向上 (C#、GUI ネイティブ開発、MAUI)
• 言語ベースのノベルゲーム開発 (当時は初の試みだと考えていましたが、実際は多く存在しました)
• テキスト部分とコアエンジン部分の分離 (ゲームエンジンとしては珍しいですが、あまりメリットがないからでしょう)
• リアルタイム読み込み (ファイルロード時に一気に読み込むのではなく、逐次読み込む方式。こちらも珍しいですが、メリットが少ないからでしょう)
• Himeno Next に代わる計画の成功

これらは概ね達成され、追加で以下の目標外の技術向上も行えました:

• CI/CD の有効活用 (GitHub Actions / Azure DevOps)
• パッケージの発行 (Nuget)
• Alice Console などを含めた周辺エコシステムの導入
  • 言語開発 (Anov 構文)
  • 拡張言語開発 (Novel IL)
  • 資料整備 (Alice Docs)
• GitHub Organization 設立

すでに、当初のほとんどの目標は達成しています。「技術力向上」については、すでに達成しているとも、更に向上させるとも認識可能で、現在は後者の考えのもと開発を継続しています。ただ、近日はあまり新しい技術⁸の導入は減っており、既存の技術投入の活用が多くなっています。そうなると、後者についてももはやすることがないと考えられます。

(実用性を目標とするにしても、現在のシステムは一般ユーザーにとって非常にわかりにくく、それの簡略化のためにドキュメント作成や広報、システムの刷新などが必要となり、不可能ではありませんが非常に難しいと予想されます)

そこで、Alice Project の目標の再設定、または重要度の見直し⁹をそろそろ行うべきだと考えています。開発の継続を行うのなら、新しい技術の投入 (例えばデータベース) などについて考える必要があります。

新規プロジェクトの評価

新規プロジェクト創出の遅れ

新規プロジェクト創出が遅れた点については、先述した「開発の継続」による影響は確か大きいですが、それ以外の要因も考えられます。

• 開発の継続習慣による、新規プロジェクト創出の難しさ (先述)
• リアルの忙しさ
• 利益主義への転換 (詳しくは後述。面白いものの技術力向上などの利益が少ないものはほとんど進んでいない)
• 組織開発への注視 (個人開発が多かった2022-2024年と比較して、2025年には KDE や MauiGtk などの外部組織での活動を重視していました。その影響で内部組織に力があまり注力できなかった可能性があります)

リアルの忙しさについては仕方がありません。LRA も、リアルの私があっての組織ですから、リアルの活動を縮小するのはほとんど不可能です。

なので、本題は「利益主義」「組織開発への注視」にあります。前者に関しては後述しますので、後者について掘り下げていきましょう。

LRA (当時 LEC) 設立当初 (2022年) から2024年頃にかけては、ほとんど個人開発のみによって成り立っていました。これは技術力があまり高くなく、開発協力できるほどの技術力がなかったのと、組織とのつながりがなかったからでした。2022年後半ごろから日本 KDE での翻訳活動を開始し、2023年前半 (?) 頃から MauiGtk のコミュニティーとの協力体制を確立しつつありました。また、Electron.NET や、Errands などの微量な貢献を行いました。

そういった微量な開発を行っている中、紆余曲折あり、MauiGtk Community を GitHub Organization として正式に設立し、最初期メンバーとして加わりました。元々、個人開発では開発できるものの規模に限りがあり、大規模開発の協力または設立を行いたいと考えており、渡りに船といった状況でした。

そういった影響によって、大規模開発の進行に期待しましたが、Thomas 氏を中心として資金支援を待つタイミングとなり、すぐには進みませんでした。(そろそろ動き始めるはずです) そのため、表向きは外部組織でも内部組織でも両方とも開発があまり進んでいるように見えないという状況に陥ってしまいました。

また、外部組織での開発があるため、内部組織では小規模プロジェクトはともかく、中-大規模プロジェクトについて新規プロジェクトが出せなかったというのもあります。

実際、2025Q3 で「新企画に関してもいくつか思いついていますが、実行に移すかはまだ検討中です。(すでに、非公開の企画書を作成済みです)」「技術同人誌: 実際に作成するかどうか、実現性の検討を行いたいと思っています。」と言及しているように、新規プロジェクト案自体は存在しました。ただ、検討のみにとどまり、計画実行までは進めませんでした。

新鮮さに欠ける新規プロジェクト

先述の通り、新規プロジェクトの数がそもそも少なく、また計画された新規プロジェクトも新鮮さや面白さに欠けることからほとんど採用が見送られました。

これについては、2022年の「A-RPG 計画」の失敗や、旧 LEC 時代の構想である「3D 都市計画」、「生物学研究」(実態はウイルスの 3D モデルの作成) などが実用化されなかったこと、2024-2025年の「Lemon Festival」からの撤退が間接的な影響を与えていると考えています。

というのも、この旧 LEC 時代はまだ開発や製作の経験が浅く、基本的には「頑張れば個人開発でもフル 3D のゲームくらい作れる」くらいの認識だったので、大胆な計画や、理想的なプロジェクト案が多く生まれていました。(LEC KISS や LEC COI では「桜システム」(現存する Ivy Cafeteria のシナリオ) を越えるプロジェクトについて真剣に考えられており、多くのシナリオが考えられていました)

しかし、先述した「A-RPG 計画」はうまくゲーム化できず、3D モデリング系の計画は労力的にかなり厳しく、3D モデリングや音楽などを定期的に行うきっかけだった「Lemon Festivel」の終焉と共に「個人開発の限界」に直面することとなりました。

これ以降、現実的なラインとして既存の計画の延長線上か、小規模計画しか進めなくなってしまいました。(大規模計画が厳しいと思い、新しく挑戦しない姿勢) また、この考えによって、かつての大規模計画についても、後ろ向きの検討になってしまい、「新規プロジェクトの案はあるものの、実装に移ることがない」という状況に陥ってしまいました。

これは、個人開発であるため仕方ない部分も大きいです。事実、現在「3D 都市計画」のような大規模計画をやろうとしても、それは不可能でしょう。

そういった意味でも、「中小規模だけど面白いプロジェクト」を創設するしかない状況です。それが難しいのですが。

組織目的への逆進性

利益重視な開発体制

LRA の目標については、いくつかの資料にて触れられています。2023年には History of LEC にて、2024年からは About: Lemon’s Resting Area にて、2025年からは追加で About: Hisotry にて記載されています。

2023年の History of LEC は、当時の専門組織 (ブランド相当) への言及が多いですが、確かに「私がこの LEC という組織を設立した理由は、自分の好きなことをやりたいからでした。」と LEC という組織に対する思いを示しています。

続く、2024年の About: Lemon’s Resting Area では、組織目的について、「この組織の最大の目的は Lemon73 自身のやりたいことをやる場所です。」と、また「利益や目的が重視され、忙しい現代社会に疲れた私が、自由な発想と理論で活動できる場所 (Resting Area: 休息所) として設置したのが本組織です。」と役割について言及しています。

更に、2025年の About: History では、「2022年、現実の活動には関係のない、自由で楽しい活動をしたいということでこの Lemon73 という名義で活動を開始しました。同年5月に設立した LEC (Lemon Electronic Computer) も同様の思想を掲げ、グラフィック部門やプログラム部分での高度化などを目的として設立しました。」というように、2022年設立当時の意識について言及しています。

これらを見てわかるように、LRA の組織目的や意識は「好きなことをやる、楽しいことをやる」に一貫しており、資料上は非常に明確でした。しかし、2025年中期頃から現在に至るまで、その目的を無視し、達成から著しく逸れた「技術力向上」や「実務に役に立つ技術」などを優先した利益重視な開発体制が続いてしまっていました。

「役に立つ技術」というのも悪くありませんし、面白い部分もあります。ただ、近日はすでに知っている技術のもと開発する機会が多くなり、目新しさのある開発ができていなかったというのは事実だと思います。

そもそも開発に偏重している

かつての LEC には、ゲーム事業や Lemon Festival (LF) を中心として、3DCG や音楽部門などの多くの部門が存在しました。しかし、茶屋計画以降の現在は、プログラム以外の部門は縮小・消滅しており、ただのプログラミングの組織と化しています。LRA は総合組織と称していますが、名ばかりと言われても仕方がないくらいです。これは、私自身が技術系の人間なので仕方ない部分もありますが、それ以外の絵を描いたり、3DCG をモデリングしたり、という体験は非常に楽しかったはずです。なぜ、いつの間にか、部門は消えていたのでしょうか…。かつての、同人組織のような自由さやグラフィック系重視の体制をもう一度変えてみたい、と思っています。

(ウェブサイトをデザインではなくメンテナンス性重視にしてしまったのが最たる例です。確かにウェブサイトの更新にそれほど時間をかけたくないという思いがありましたが、理想形として考えていた「カフェテリア風のデザイン」はあまり色濃く反映されませんでした)

かつては 3DCG、音楽部門など、確かな「楽しさ」がありました。しかし現在、「OSS 化」や「技術力向上」などの社会的側面を重視しすぎて、かつての楽しいと思ってやっていた事柄は今やほとんど残っていません。これは、「義務感」でだと思い続け、ただの「惰性」で開発を続けているだけにすぎないのではないでしょうか。

組織が今後進むべき路線

開発の多様化

ゲーム開発の推進

上記の課題点では、Alice Project への批判が強く示しています。だが対照的に、Ivy Cafeteria については殆ど触れていません。これについては、本プロジェクトは今回の自己批判において比較的課題が少なく、概ね理想に近いからでしょう。

というのも、Ivy Cafeteria で現在開発が進んでいる「LynnePG」については、ゲーム開発としても、ドット絵のグラフィック制作についても新しい経験が多く、かつての「A-RPG」計画で達成できなかったような体験ができているというのが大きいです。特に、「A-RPG/A-Adventure 2D」では単純な横移動やジャンプすらイマイチでしたが、現在の「LynnePG」では、開発して早々にそういった単純動作を完成させることができました。それ以降の開発はあまり進んでいませんが、今月の開発では銃の基本実装ができ、テストプレイや成功した時だけでなく、予期せぬバグですら楽しいと感じています。ゲーム開発はやはり難易度が高く、グラフィックも制作する必要があるため大変であり、商業的利益はほとんど得られないと予測できますが、だからこそ、LRA にぴったりなプロジェクトだと感じています。

(「LynnePG」の進捗がイマイチなのは、Godot4 C# の日本語情報がほとんどなく、開発に時間がかかるためです。また、ゲーム開発に使えるような長時間をあまり確保できていないからです)

実験的プログラム/計算プログラム

今まで進めてきたプロジェクトは、

• ウェブサイト
  • Lemonium.net (ここ)
  • Alice Docs
  • Common Novel
  • Novel IL
  • MauiGtk.net (外部協力)
• アプリケーション/ツール
  • Alice Novel
  • Alice Console
  • Alice Aqua
  • Himeno Flex
• ライブラリ
  • Alice Console (+ AnovSyntax)
  • Common Novel
  • Novel IL

など、継続的に開発が必要な分野に偏っており、単発の実験的プロジェクトは非常に少ないです。

とはいえ、完全に実験的プロジェクトの事例がなかったというわけではなく、一応過去の事例として

• Jupyter-test
  • 円周率 - モンテカルロ法
  • 最大公約数 - ユーグリット法
  • パラドックス - モンティ・ホール問題
  • 距離空間 - ユーグリット距離 / シェビチェフ距離 / マンハッタン距離
  • シーザー暗号
• Medicolor (画像処理・色覚異常のシミュレーション)

などが挙げられます。これらの実用性はほとんどないですが、開発していて楽しかったものが多いです。

LRA としては、この「実用的ではない (けど、面白い)」というプロジェクトを大いに歓迎しています。

最小構成の 3D レンダリングエンジン、ただ立方体を回転させて AA (アスキーアート) として表示する、光の計算、F# で数学の計算…。何をしても面白いと思っています。

どうせ、秀才プログラマーや大規模 OSS 組織には勝つことはできませんから、コーディングで楽しめばいいでしょう。また、それができるのが、LRA という組織だと思っています。

データベース

今までの LRA では、データベースや動的サーバーを過度に避けてきました。これの理由としては、単純に「お金がかかる」や、「間違えて大規模な請求があったら困る」という資金的な面でした。(あとは、初めてやることなので時間がかかりそう、というのもあります)

現在でも LRA は資金難¹⁰であることに変わりはありません。しかし、Firebase や、Cloudflare の D1 のように、非常に安価 (使用量によっては無料) で扱えるサービスが多くあるのに、データベースや動的サービスに触っていないというのは非常にもったいないと感じています。

これについては、大きな時間を見つけられるかが課題です。ただ、新しいことへの挑戦としてこちらの方面も前向きな検討をしたいと思っています。(これに関しては、2025年の間も計画案として挙げていたので)

深層プログラム

低層 (低レイヤー) の開発に手を出してみたいという思いがあります。が、正直ハードウェアを触る機会がなさそうなんですよね…。(低層について学んでも今後使えない、というわけではなく、そもそも組み込みハードウェアを購入する必要がありそうです) 一応、エミュレーターという手もありますが、それはあまりおもしろくないですね。

そうなると、ハードウェアを購入するか、WebAssembly とかのあたりになりそうです。後者は WASI とかに興味があるので、試せたら面白そうですね。まあ、関連領域として、OS 開発 (Linux の Fork とか) でもいいかもしれないです。(KDE の知識を高められる)

新言語の学習

今までは C# に学習リソースを傾倒することで、圧倒的技術を得ようと考えていました。が、言語設計的な考えができるように、他の言語についてももっと知りたいという思いがあります。軽率ではありますが、Rust はやはりメモリ管理などの関係上知っておきたい言語として名前を上げておきます。CLI ツールについては軽量さ、高速さが重視されるので、Rust について学習を行いたいと強く考えています。

他の言語としては、C# と同じく GC を用いる言語でありながら、別のルートを行っている Go ですかね。ただ、Go は学習自体は面白そうですが、C# から旅立つ動機が弱いですね…。おそらく Go は C# よりもクロスプラットフォームなど優れている点がいくつかありそうですが、実用上の圧倒的な差は感じないので…。

ウェブ系

ウェブ系についてはもう、そんなにやることがないので今後も続けるかはわかりません。

ただ、tauri については本気でやったら面白そうだと考えています。(ただ、Rust の学習を先にする必要があります。Rust がわからなくても tauri は使えそうですが、それはいつも通りのウェブ開発と変わらないので)

それ以外なら、先述しましたが、Web Assembly あたりが技術としては面白そうです。

AI/機械学習

AI の開発については、人気すぎて、精度・速度・サイズはもちろん、独自性でも勝てる見込みがないのでやるつもりはありません。(現時点では)

機械学習は…面白そうですが。(ただ、データの準備などが大変なのでやる可能性は低いです) やる場合は、ライブラリを使うのではなく、簡単なものでいいので、理論から作成したほうが面白いし、機械学習への理解を深められそうです。(これについては理論理解のためで、実用目的ではありませんが)

AI の利用に関しても API を叩くだけで技術面であまり面白くなく、API 料金もかかるので微妙です。ブラウザで動かすとかは面白いかも知れませんが…。あまり前向きには検討していません。

開発一極化からの脱却/多様な分野への挑戦

3DCG

LRA としては2年近くやっていない気がします。(リアルでも2ヶ月前に久しぶりに触りましたが、その1回だけです)

建物とか作ったら面白いのですが…時間がかかるんですよね。Blender には拡張機能などで効率的に建築を作れるようなので、そのあたりを試してもいいですね。

ただ、結局小物を作って、マテリアルの設定をこだわるほうが面白いかも知れません。

(一応、2025年の計画では、東方風の家具を作るプロジェクト (スカコレ = スカーレット・コレクション) がありました。結局手を付けられませんでしたが)

2Dグラフィック

イラスト・ドット絵です。

まあイラストについては、ほとんど公開していませんが、たまに描いています。今後も公開するか、しないかはさておき、もうちょっとイラストを描いてもいいかもしれませんね。服のデザインとかを勉強したいという思いもあります。(図書館とかで服デザインの本とかを借りてもいいかもしれません)

ドット絵は「LynnePG」向けでしか描いていませんね。「LynnePG」も停滞気味なので、ほとんど描けていませんが。

もう少し各頻度を増やせたらいいかもしれませんね。楽しいので。

別の画風を取り入れてみたり、男性を書いてみたり、新しいものに挑戦するのも悪くないですね。

音楽

音楽作成はやる可能性は低そうです。新しい分野に挑戦、ということでやってもいいのですが、ほぼ初めてなので準備が大変なんですよね…。(旧 LEC 時代は適当な音楽を作っていたが、パソコンを変更したので、アプリケーションを再インストールしたり、音楽理論を学んだりしないといけない)

「音楽系 + プログラミング」については、リアルの活動の方でやっているのでこちらでやるつもりはありません。

ドキュメント/Blog

ドキュメント、Blog については、Qiita や本ウェブサイト (Lemonium.net) などでたまに書いています。今後は、今くらいの頻度で投稿できればいいと思います。楽しい、というよりも衝動的に書きたくて書いているようなものなので。(この文章も)

というか、Blog は正直、中期指針以外に書くことがないのですが。(一番大規模プロジェクトである Alice Project は Alice Docs を保持しており、Ivy Cafeteria は進捗が少なく、LRA 本部の開発も大規模なものはないので)

新しいアイデアの導入

イベント参加

以前の OSC Niigata みたいに、イベントに参加したら面白そうですね。OSC Niigata は OSS の中でも SQL 方面について知れましたし。(C# 関係、ウェブ関係、Linux (特に KDE) 関係、あたりの主要 OSS は認知しているつもりですが、それ以外の界隈の話は殆ど知らないので面白いですね)

(交通手段の予約とかが面倒であんまりイベント参加しないのですが)

今年の OSC で KDE のブースを出したいと思っていますが、準備が面倒かつある程度費用がかかるので現時点ではなんとも言えません。

記事・論文を読む

理数系の記事や論文でも読んで面白いアイデアがないか探してみましょうかね。

レナ改革

概要

レナ改革 (Lena Stream)¹¹ は、2026年第1期 中期基本指針 (2026Q1) の追加計画です。

本資料前半の内容を踏まえて、LRA の活動をより楽しくすることを目的として追加で設定しました。

(そもそも指針を設けること自体が義務感につながる可能性があります。これについては、無計画、無作為な開発になることを防ぐために組織運用上設定した参考値であり、拘束力は非常に低いものと考えてもらって構いません。途中での計画変更・未達成は全く問題がありません)

期間

2026年2月-3月

内容

• 新規計画
  • 中規模計画を1件以上作成 (実行、公開は必須ではない)
  • 小規模計画を3件以上作成、1件以上は実行と公開をする
• 既存計画
  • LynnePG の開発推進
• プログラム以外の活躍を1件以上公開する (3DCG、イラストなど)

まとめ/最後に

「GitHub コントリビューションの継続」は継続によって技術力を向上させること、「C# 重視」は言語を絞ることで学習時間が分散しないようにする、そういった目的で進めていた施策で、当初はそれに大きく貢献していたのに、末期には新しく変わることができない足かせとなっていました。今回の振り返りでは、成長するには「継続する」だけでなく、「変わる」必要があるのだと強く痛感させられたました。

この文章の執筆を通して、技術力と開発の時間という限られた「制約」を、どのようにしたらうまく使えるか、また、楽しい活動に回帰できるかについてよく考えることができたと感じています。ただ、ここで考え、文章で書いたことは、書いただけでは何も意味はなく、文章後半で書いた進むべき路線やそれを踏まえたレナ改革を実行できてこそ、楽しい LRA の活動が見えると考えています。だからこそ、この資料を「意味のない資料」ではなく、未来に影響を与えた資料としてうまく活用できるように努力を注ぐつもりです。