スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

https://twitter.com/bayashimura/status/1542480802658652160?s=21

今回のゲスト(予定、随時更新)

• furoshiki.fmのみなさま
•  

過去の放送は、links欄にあります。

※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

ソフトウェア開発に携わってこなかった方向けに、アジャイルに開発を進めるってどういうことか？を伝えてほしい、という依頼がありまして、以下の流れで話しました。

1. ソフトウェア開発ってどういうものなのか (ユーザー企業観点)
2. 要件というのはどういう風に考えるのか (狩野モデル)
3. 新規サービス開発への狩野モデルの適用 (ユーザーストーリーマッピング)
4. スクラムとはなにか、DevOpsはなぜ必要なのか

ホロラボ社内や、クリエーションラインさんに呼んでもらって講演をしたのですが、なかなか好評をいただいたと思いますので、RSGTでもお話しできればと考えました。公開の場では今回が初のトーク提案になります。

企業運営をアジャイルにする、という文脈でよく語られる、「Beyond Budgeting」(脱予算経営) というのをご存じでしょうか。多くの企業で一般的な年次予算(もしくは半期、四半期)の管理方法を見直して、よりダイナミックに、各現場に任せる形で企業内の資金を運営していこう、という取り組みです。2000年代に北欧の銀行などで取り組まれ、BBRT (Beyond Budgeting Round Table) というコミュニティがその普及啓蒙を担っています。

毎年米国で行われている Agile Conference では、2014年にImplementing Beyond Budgeting (日本語訳: 脱予算経営への挑戦)著者の Bjarte Bogsnes 氏をクロージングキーノートに招聘して、話を聞いています(講演ビデオ)。彼は企業会計の専門家であり、石油掘削ベンチャーのStatoil社の企業会計に携わっています。その講演では、Statoil社での実践を中心に、アジャイルの時代の経営のイノベーションについて話しています。また、BBRTが公開している、12の原則についても紹介しています。

私は、2022年8月に、Joe Justice氏のアジャイルハードウェア開発の研修に参加したのですが、テスラ社やSpaceX社が行っている脱予算経営について、紹介してくれました。その際に、日本ではあまり脱予算経営が紹介されていないと感じましたので、本セッションを思い立ちました。予算管理というと、スクラムの現場からはちょっと遠い話と思われるかもしれませんが、「予算を申請する」「苦労して上司を説得する」「上司も苦労して経営陣を説得している」という作業にはほとんどの人が携わっていると思います。このやり方を根本的にシンプルにしましょうという考え方で、私たちの日々の活動について、一考を促すものだと思います。特に小さな企業は、既存の大企業の予算システムマネしてもアジャイルにはなれません。

本セッションでは、Agile 2014  での Bjarte 氏の講演をなるべくそのまま紹介しながら、必要な補足をしていきます。脱予算経営について、一緒に勉強してみませんか？

海外で行われているWomen in Agile(WIA) という活動があります。WIAは、アジャイルコミュニティにおける女性のネットワーク構築やキャリア促進を支援する団体で、アジャイル活動における平等と多様性の包摂を目指しています。

皆さんの周りでは、多様性は活かされていますか？アジャイルの実践者が集まる中で、私たちはジェンダー差異を感じることが実はあまりありません。それは何故でしょうか？

アジャイルやスクラムは人間的な側面に着目し、小さなチームで相手に向き合い、「小さな違和感」を取り除いていく特長があるからです。本セッションでは、多様な現場で働いている私たちが、働く中で感じる「小さな違和感」に目を向けることがアジャイルチームにとってどう役に立つのかを語ります。

「小さな違和感」の端的な例は、女性に対する差別のようなものは職場にほとんどないのに、なぜか職場に女性管理職が少ない、ということです。これは直接変化させることはできないほど大きな問題だと思いますが、その裏にはとても多くの「小さな違和感」が潜んでいるのではないかと思います。偏見とか、自己否定とか、少数派であるのでやりにくいこととか、さまざまです。

さああなたも「小さな違和感」に気づいてみませんか？

スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

https://twitter.com/bayashimura/status/1542480802658652160?s=21

過去の放送

https://youtu.be/5BZI9A3jhsY

https://youtu.be/0JDjMDSLqrE

※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

InnerSource インナーソース という取り組みがあります。「コードの共同所有 (Collective Code Ownership)」はXPの重要なプラクティスの一つですが、これを社内で行うためには、さまざまな部署が協調的に働く環境づくりが必要になります。しかし私たちは、その点について十分な移行戦略や説得のボキャブラリーを持っていないことが多いと感じています。

一方でGAFAなどの米国大手IT企業では、シングルリポジトリ(会社全体で一つのコードリポジトリ)をやっているという話を聞いてきました。日本企業でシングルリポジトリになるのは、なかなか大変だなー、と思ってきた方も多いのではないかと思います。

米国のMicrosoftも、実はシングルリポジトリではなかった企業の一つです。事業間はある種競争関係でもあるので、基本的にはソースコードは共有しないもの、とされてきました。しかし、クラウド中心へのビジネス全体の転換を進める中で、ここ数年は1ES(One Engineering System) という、共通基盤の普及を進めてきたそうです。これを始めたのが Agile 2015 で基調講演を務めた Sam Guckenheimer 氏です(現在は引退、退職)。私も、2019年に彼のオフィスを訪ねています。

本セッションでは、Sam さんの下で働いたこともある服部さんに、Microsoft の 1ES の取り組みがどのようなものであったのかを紹介していただくところから始めたいと思います。一次情報がやっぱり一番うれしいと思いますので。そのうえで、その取り組みの先にある、企業をまたいだ活動である InnerSource Commons について最近私が勉強したことをまとめてみようと思います。

InnerSource Commons は内製化を進める大企業が参加し、どうやって部署をまたいだコードの共同所有を社内に生やしていくか？その中で他部署からのコントリビューションを得るにはどうしたらいいのか？そして、オープンソース文化では基本知識となっている、プルリクエストベースのコードのコントリビューションの仕組みや体制をどのように作っていくのか、開発者として何を学ぶ必要があるのか、について知見を整理してくれています。

「私の会社ではなかなかスクラムができないんです。上司が許してくれなくて。仲間もいません」....大丈夫です。Fortniteがあります。パソコン、Switch、PS4/PS5、XBox としっかりしたネットワークがあれば無料で参加できます。在宅ワークのために投資した自宅のワーキング環境を活かして、オンラインリアルタイムコラボレーションの世界に参加できます(注: 本セッションは、ゲームへの参加を勧誘するものではありません)。

品川アジャイルでは、モブプログラミングの勉強の一環として Fortnite を始めてみたんですが、それ以来、配信環境を強化したり、自宅ネット環境やPCを買い替え、徐々にのめりこんでしまい、一部メンバーによるよなよな Fortnite が２年以上続いています。その中で学んだスクラムやチーム開発との共通性をこちらで話したいと思います。

• スウォーミング
• 発話での状況表現
• 少人数のチームでのコラボレーション
• 自律的な参加、自己組織化
• 限られた資源を協調的に使う
• サーバントリーダーシップ
• イテレーションを通じてだんだん上手になる
• 変化する状況に対応する、変化の先を読む
• 序盤は生き残り、中盤で余力を溜め、終盤で勝利する戦術を組み立てる
• システム側に組み込まれたご褒美回路
• 世代を超えて楽しめる多様性

スクラムマスターは、開発者(たち)を信頼し、チームとして価値あるプロダクトを生み出すことを信頼し、環境を整えます。私たち品川アジャイルは、スクラムフェスやRSGTやDevOpsDays Tokyo といったカンファレンスにおいて、実践者の皆さんが活発に意見を公開し、よりよい未来を作っていただくため、技術面で勝手にお手伝いしています。ボランティアベースなので、お約束はできませんが、できる範囲で勝手にやっています。

カンファレンスは廊下こそ重要と、私たちは信じています。スピーカーと、廊下でセッションでは語られない裏話や、どうしてそういう活動をしたかなど、哲学(ケツバット)を語り合う。ほかの実践者と、哲学(ケツバット)を語り合う。そうした体験が、さらに次なる実践へとつながっていくと信じています。

哲学(ケツバット)について
https://twitter.com/kawaguti/status/1529340838358048768?s=20&t=9TKkfEIXtKRF7_rXgQ13GQ

ハイブリッドカンファレンスでは欠かすことができない、廊下の放映を提供したいと考えています。よろしくおねがいいたします。

「発表も好きですが、整理されていない対話の中で出てくるその人の思想、哲学みたいなものが好きです。
それがよく出てくるのが廊下だと思っていて、それを世の中にみんなが見られる形で残せればなと思ってたりします。それが私のケツバットです。」

https://twitter.com/bayashimura/status/1542480802658652160?s=21

過去の放送

https://youtu.be/5BZI9A3jhsY

https://youtu.be/0JDjMDSLqrE

※品川アジャイルの活動は、ボランティアで行っていますが、機材や旅費などのサポートをスクラムフェス大阪、新潟、三河、仙台、スクラムギャザリング東京(RSGT)、DevOpsDays Tokyo の収益の中からサポートをいただいています。ありがとうございます。

スクフェス大阪のオンサイトの端っこを借りて、現地からずっと配信し続けます。
こんな感じで・・・は出来ないかもだけど、iPad駆使して配信したいと思います。

品川アジャイルの人が雑談してたり、
オンサイトやオンラインにいる各地域のスクフェスオーガナイザーの人と雑談してたり、
近々行われたスクラムフェスや、これから行われるスクフェスの裏話や苦労話を聞いていたり、
セッションを見ながら雑談してたりできるといいなぁと思っています。

あとはDiscordとかのコメントを拾ったりできるといいなぁ。

NINNOの一室を借りて、現地からずっと配信し続けます。こんな感じで

品川アジャイルの人が雑談してたり、
オンサイトにいる参加者登壇者の人が雑談してたり、
セッションを見ながら雑談してたり、
登壇者が意気込みを語ったり、
登壇を終えた人が感想を語ったりなどができるといいなぁと思っています。

あとはDiscordとかのコメントを拾ったりできるといいなぁ。

アジャイルでモダンな組織を作っていくうえで、テストに関する考え方は極めて重要になると思います。もし、要件定義、開発、テスト(品質保証)をそれぞれ別のチームで行っている場合は、根本的な体制の組み直しが必要になると思います。

その際に、突きつけられ、迷子になりがちなのが「我々はなぜテストをするのか？」という問いです。独立していたQA担当をチーム内に入れるべきなのか？開発者自身がテストをするべきなのか？POやPdMがテスト項目を記述すべきなのか？組織的にはさまざまな問いがあるだろうと思いますが、おそらく自分たちの文脈において「我々はなぜテストをするのか？」を考えられないと、ただ組織を組み替えて、足りない部分を誰かに押し付けて終わってしまうのではないかと思います。

最近、３つの講演に出会いました。KANOメソッドで有名な狩野紀昭先生による、日科技連の歴史を振り返る講演、Jonathan Rasmusson氏による Spotify などのユニコーン企業でのテストについての講演、それから BDDの提唱者である Dan North 氏による BDD is not Testing です。このセッションでは、この三つの講演から、「我々はなぜテストするのか？」について、考え直してみたいと思います。

なにぶんテスト専門家でもありませんので、みなさんに十分な知見をお届けできるかわからないのですが、議論のきっかけになれば幸いですし、間違っているところがあればご指摘いただければ幸いです。

一応、私の実務者としてのバックグラウンドはこんな感じです。もうだいぶ時間たってしまったので、あんま意味ないかもしれませんが。

• 社会人になって、私が最初に配属された部門は「情報部門」というところでした。データを作る部門、という感じですが、主な仕事は、アナログな情報のデータ化でした。ファックスや印刷物、メールなどで飛び交う情報の特定部分を抽出して、ちゃんと整理してデータベースに入れる仕事です。ここで行われるテストは、入力した情報が間違っていないかどうかの、２～３重の確認でした。これを間違えると、重要な経済指標の算出が間違ってしまい、しかもそれ以降の計算も間違っていくので、とても重要な仕事でした。間違いが許されない。
• その次に携わったのは、そうしたデータを入力するシステムの開発です。人々が間違った情報を入力してしまわないように、見比ベることを容易にしたり、振り返って直せるようにするための仕組みです。ユーザビリティを高める必要がありました。
• そして、数年後には、もっと複雑な仕組みに携わるようになりました。リアルタイムデータ。取引情報をリアルタイムに表示する仕組みで、これをどうやって間違わないように行うのか？パターン無限にあるやん。また、さまざまなクライアントでそれをきちんと再現するにはどうしたらいいのか？さらに問題が起きたときに情報を収集する仕組みを作る必要がありました。
• 最後にやったのが、サーバインフラに、間違わずに環境を届ける仕事です。システムそのものの正規の状態を作り上げ、それを間違わずにデプロイによって複製する仕組みです。しかも、そのあとは動いているシステム同士が間違っていないことを確認し続ける必要があり、問題がある場合は、問題が起こる前のサーバー状態と入れ替えて再生する必要があります。

昨年の DevOpsDays 創始者 Patrick Debois さんのトークでも触れられた、DevOpsという言葉ができるきっかけになった2009年の講演「10+ Deploys per Day」をとりあげます。その講演で何が語られたのか？について、短い時間でお伝えすることはしてきたのですが、今回は時間をちゃんと使って、話してみたいと思います。

このトークの周辺の事情については私の過去のトークで、私の整理をお伝えしてきましたが、今回はこのセッションそのものをお伝えしまーす。

DevOpsの時代
https://speakerdeck.com/kawaguti/age-of-devops

アジャイルとDevOps
https://www.slideshare.net/kawaguti/agile-and-devops

10+ deploys per day (動画)
https://www.youtube.com/watch?v=LdOe18KhtT4

10+ deploys per day (スライド)
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

2011年、スクラムの父、Jeff Sutherland 博士を日本に初めて招いて「イノベーションスプリント2011」を行いました。そこで行われた講演が "Roots of Scrum" でした。残念ながら撮影まで手が回らず、ビデオが残っていません。スクラムはどこから来たのか、日本から何位を学んだのか、多くの示唆のある講演だったと記憶しています。

スクラムは実践と学びを繰り返し、スクラムガイドが作られ、アップデートが繰り返されています。多くの実践者が書籍を出し、保管できなアイデアで貢献してきました。しかし、スクラムガイドでは語られない源流とストーリーがあります。

2005年に行われたカンファレンスで、 "Roots of Scrum" のビデオが公開されています。現在見ても、多くの示唆がありますし、もしかしたら多くの人はまだこれを見ていないのかもしれない、と思うところがあります。

そこで、この60分の講演ビデオの内容を、できるだけ多く、日本語で伝えなおしたいと思います。

オリジナルサイトより
https://www.infoq.com/presentations/The-Roots-of-Scrum/

スクラムの生みの親であるジェフ・サザーランド博士は、60分のJAOO2005講演で、スクラムの創始から、ケン・シュウェーバーとともにスクラムを産業界に展開することに参加し、Easel、Fuji-Xerox、Honda、WildCard、Lexus、Googleに影響を与えたことまで、スクラムの歴史を説明しています。スクラムのタイプA、B、そして「一気に」タイプCについて考察し、XPを開発する際にケント・ベックがスクラムのプラクティスを「盗んだ」というユーモラスな噂を確認している。

2011年1月に「10分でスクラム」という資料を出してから、10年が経ちました。
https://www.publickey1.jp/blog/11/10_5.html

それから10年が経ちました。アジャイルマニフェストからは20年です。
当時の私がどのようにスクラムと出会い、そして誰かにスクラムを伝えたくなったときに何をしたのか。
少し思い出しながら、話してみたいと思います。

同じような境遇になってしまった皆さんに、周りに自分なりのスクラムを伝えるきっかけができれば幸いです。
もちろん、スクラム全然知らない！という方にも、知っていただける機会になると思います。

最後に、2021年版の「10分でスクラム」を話してみたいと思います。

Agile 2012 のキーノートで、スタンフォード大学経営学部のボブ・サットン教授が基調講演をしました。当時出版されたばかりの本 “Scaling Up Excellence” を題材に、幅広い調査を元に、よい組織文化をスケールさせるには、どうしたらいいか、なにをやってはいけないか、について話してくれました。

その時に書いたブログがこれです。
Agile2012 Day2 : 基調講演: よい組織文化をスケールさせるには by ロバート・サットン

最近、私は新しい会社 (HoloLab, inc.)にジョインしました。このまだ小さな会社にジョインするにあたって、ふと、ボブの基調講演で学んだことを思い出しました。あわせて当時のインタビューをいくつか見直して、人が増える会社にとって覚えておくべき重要なことを学びました。彼らの研究手法はGTAという質的研究手法を使っているそうで、統計的に有効性が証明されたものではないのですが、うまくいっている企業に共通する要素をとりだしてまとめる、ということにおいて、説得力のある情報が多く含まれていると感じました。一個人の経験や気づきをまとめた自伝やジャーナリストが書いた本とは違い、一定の研究手法にしたがって行わたであろう点も信頼できます。

本セッションでは、そこでボブ・サットン教授がなにを教えてくれたのかを、自分なりにレビューしてみたいと思います。

『教育心理学概論』という書籍があるのはご存じかなと思います。この書籍を書いた三宅なほみ先生は1986年に発表した博士論文"Constructive interaction and the Iterative Process of Understanding" (通称「ボビンの論文」) で、ペア作業の観察を通じて、理解というものはなにか？複雑な問題をペア作業によってどのように進めていくのか？に迫りました。「建設的相互作用」を提案した論文として多くの影響を与えているそうです。

スクラムの源流が80年代の製造業のプロダクト開発を観察した1986年の論文 "The New New Product Development Game" にあることはもちろんご存じですよね。この論文については、スクフェス大阪で読みました。https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15403/the-new-new-product-development-game

２つの日本人による論文が同年に出ていることは全くの偶然ですが、異なるアプローチで人間の協調作業に迫っていることが興味深いです。

本セッションでは、「ボビンの論文」と「The new new product development」を機械翻訳をかけながら読んだ経験を振り返り、理解とは何か、組織にとって必要な小グループ活動、ペア作業の効果に関して議論していきたいと思います。また、普段モブプロをやられている方や、ファシリテーションに取り組まれている方にとって、人間の意識がどうなっているかがわからないのは悩みのタネであろうと思います。そうした方にも気づきがあるのではないかと思います。

Scrum Fest OSAKAの「mogiriちゃん」の記憶冷めやらぬ昨今。
モブプロでなんかいじりたいという邪な気持ちだけでプロポーザルを書いています。
世の中のモブプロの理解が全く間違っていると感じる昨今。
本当のモブプロをここでお伝えしたい！その気持ちだけでこのセッションを設計しています。
昨年、大好評を博したイキトメモブプロに続き、ついに第二弾をお届けします。

お待たせしました。いや、お待たせしすぎたかもしれません。
全裸監督2、いや全力でやります。
ちなみにメインスピーカーの村林は新婚のため参加できません。前代未聞。

XP祭り初のビブリオバトルで川鯉さんが優勝した『教育心理学概論』という書籍があるのはご存じかなと思います。この書籍を書いた三宅なほみ先生は1986年に発表した博士論文"Constructive interaction and the Iterative Process of Understanding" (通称「ボビンの論文」) で、ペア作業の観察を通じて、理解というものはなにか？複雑な問題をペア作業によってどのように進めていくのか？に迫りました。「建設的相互作用」を提案した論文として多くの影響を与えているそうです。

スクラムの源流が80年代の製造業のプロダクト開発を観察した1986年の論文 "The New New Product Development Game" にあることはもちろんご存じですよね。この論文については、スクフェス大阪で読みました。https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15403/the-new-new-product-development-game

２つの日本人による論文が同年に出ていることは全くの偶然ですが、異なるアプローチで人間の協調作業に迫っていることが興味深いです。

本セッションでは、「ボビンの論文」を機械翻訳をかけながら読むことを通じて、理解とは何か、ペア作業の効果に関する新しい視点を得ることを目標にしたいと思います。また、普段モブプロをやられている方や、ファシリテーションに取り組まれている方にとって、人間の意識がどうなっているかがわからないのは悩みのタネであろうと思います。そうした方にも気づきがあるのではないかと思います。

事前の準備は不要ですのでさらっと来ていただければと思います。

※本セッションはアギレルゴコンサルティング株式会社のスポンサーセッションとして提案するものです。

皆さんは、スクラムの源流が80年代の製造業のプロダクト開発を観察した論文 "The New New Product Development Game" にあることはもちろんご存じですよね。そこにどんなことが書いてあったか、知りたいと思いませんか？現在論文は無料で Harvard Business Review サイトで公開されているので、誰でも読めるのですが、英語なのでちょっとハードル高いですよね。一緒にみんなで機械翻訳かけながら読んでみませんか？

昨年の Scrum Fest Osaka 2020 @ Online から、カンファレンスの参加者の交流やさまざまな連絡にDiscordを使うようになりました。それからいくつかのカンファレンスで使ってきたのですが、スタッフ側でちょっと頭の痛い作業が「受付」です。

もちろんリアルのカンファレンスでも結構大変で、長年頭を悩ませてきたのですが、Eventbriteのアプリの出来がいいのが救いでした。しかし、Discordの受付にはそれが使えず、しぶしぶGoogle Spreadsheetを使いながら、スタッフがポチポチ確認作業をするということをしてきました。

それから約一年たちまして、さすがに運用も安定してきましたし、DiscordのボットとEventbriteのAPIを使って、自動化をやってみようかなということで、やってみました。プログラムとしては大したことはないですし、うれしいのもほとんどスタッフだけですし、これといった感動する苦労話もないのですが、こんな話を聞いてもらえるのもスクフェス大阪くらいかなと思い、プロポーザルを書いてみます。

mogiri
https://github.com/kawaguti/mogiri

この小さなアプリを、どのように維持したり、育てて行ったらいいか、皆さんをご意見やご示唆をいただければ幸いです。