アジャイルを機能させる外枠について
2017/12/15のエンタープライズアジャイル勉強会 2017年12月セミナーの企画は僕がやらせてもらいました。
テーマは「アジャイルを機能させる外枠」とし、アジャイルチームがうまく機能するために、あえてチームの外側で解決した方がいいこと、を整理してみたいと思いました。
アジャイルチームというのは、実際にモノを作り、サービスを動かし、ユーザーからのフィードバックを付けて改善を行っていくことが目的です。その目的を達成するためにはアジャイルチームの外枠をちゃんとする必要性があると考えています。
アジャイルを機能させる2つの外枠
1つ目の外枠は「何を作るべきか」という観点。チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん（@papanda）にお願いしました。市谷さんの講演は「アジャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。
2つ目の外枠は「どう作るべきか」という観点。ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました（参照：大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp）
というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。だいぶ振り幅があるテーマになったな、と思う一方で、けっこう実感もあります。アジャイルを導入しようとしている人の悩みってプロダクトオーナーかアーキテクトに落ちてくる気がします。
見積もれないことをチームに持ち込まない
なお、これは「チーム内にいるエンジニアは外側のことは考えなくていい」と言っているわけではありません。もちろん、外側のことを考えてもいいし、場合によっては解決に携わってもいいのですが、ただ、それはチームの作業としてカウントすべきではないと考えています。そうしないとアジャイルプロセスがうまく回らないからです。
アジャイルプロセスをうまく回すコツは「チームが見積れないようなバックログを積まない」ことです。スプリントプランニングにおいて「曖昧で見積もりができない」「リスクが大きすぎてタスク化できない」というようなことは避けるべきです。そういうものを無理やり見積もっても「勘と経験と度胸（KKD）」になってしまい、生産性を計測することができなくなります。そうするとチームのベロシティが把握できず、結局、安定したチーム運営ができなくなります。アジャイルは期間とリソースを安定させることで開発速度を安定させ、それによって将来における変更対応を担保しています。この根幹が揺らいでしまうと、プロダクトオーナーと開発チームの信頼が崩れてしまうのです。
いまだにアジャイルは「適当だ」という認識の方がいるかもしれませんが、実際は逆で、アジャイルでは適当さが許されなくなります。ウォーターフォールではバッファと呼んで規模やスケジュールに紛れ込ませて適当にやってきたことを、アジャイルでは明確にしないとプロセスがうまく回りません。
そもそも、外枠の話はウォーターフォールでも一緒、ですよね。過去、プロセスに紛れて適当にやってきたがために、明確に議論できなくなっているだけなのでしょう。結局、エンジニアに良い仕事をしてもらうためには「何をすべきか」「制約がなにか」を先に明確にしておいたほうがよい、という当たり前の結論になっただけかもしれません。
最後に
呼びかけに応じて参加してくれた市谷さんに感謝します。付き合いは長いですが、こうやって2人で縦並びで話をするのは初めてな気がします。たぶん。全然違う話を1つの線でつなげられるというのは、とても刺激的ですね。これからもよろしく。
大きなアーキテクチャ設計と小さなアーキテクチャ設計
2017/12/15（金）にエンタープライズアジャイル勉強会2017年12月セミナーで「アジャイル開発を支えるアーキテクチャ設計とは」という話をしました。資料は以下から。
僕の話したかったのは「アーキテクチャ設計といっても『大きなアーキテクチャ設計』と『小さなアーキテクチャ設計』というレベルがあり、後者はチーム内で解決すべきだが、前者はチーム外で解決すべきだ」ということです。
大きなアーキテクチャ設計：システム間連携のレベル→アジャイルチームの外で実施
小さなアーキテクチャ設計：システム内連携のレベル→アジャイルチームの中で実施
なぜ分けるのか、というと、それぞれのレベルで求められる性能も可用性も保守性も違うからです。
小さなアーキテクチャ設計は「チームが好きにすればいい」わけですが、大きなアーキテクチャ設計は「チームをまたがって企業内でそれなりに最適化されるべき」です。
よって、「チームがアジャイルに、自治的に小さなアーキテクチャ設計を進められるようにするためには、大きなアーキテクチャ設計をチームの外に意図的に出すべきである」という考え方になります。これを混ぜたまま進めようとすると、
- 大きなアーキテクチャ設計についてチーム内の部分最適で判断したために余計な問題やコストが発生した
- 小さなアーキテクチャ設計に関わることなのにチーム外が全社最適で判断しようとしてチームが動けなくなってしまった
というようなことが発生します。特にアジャイルチームではチームが小さいがゆえに、大きなアーキテクチャ設計に巻き込まれるとリソース不足に陥ったり、スケジュールの遅延が発生し、なによりもモチベーションを著しく下げることになります。「なんでもいいから早く結論を出してよ。それに合わせてサービスの実現度はPOと話して決めるからさ」みたいな。
一方で、このレベル感を混乱させるのがマイクロサービスアーキテクチャ（MSA）です。MSAでは「システムを構成するコンポーネント（＝マイクロサービス）同士をネットワーク越しに連携させる」ことが主流になっています。一方で、昔から「システム同士をネットワーク越しに連携させる」というのは一般的です。
だからこそ、その連携が「システム同士の連携」なのか「マイクロサービス同士の連携」の差というのが分かりくくなっている気がしています。もちろん、あるサービスにとって、それが「システムからの連携」なのか「システム内のコンポーネントからの連携」なのかは見分けがつきませんし、付ける必要もありません。これまでのシステム間連携だって同じことですから。
MSAは、これまで大きなアーキテクチャ設計でしか語られていなかったシステム連携を、小さなアーキテクチャ設計に持ち込みました。ネットワーク連携の様々なオーバーヘッドを許容できるだけの技術の発展があり、その変化を許容しやすくなるメリットが享受できるようになったからです。
というわけで、MSA環境では大きなアーキテクチャと小さなアーキテクチャは見分けにくいのですが、見分けないといけません。繰り返しますが、それは技術論ではなく求められる性能も可用性も保守性が違うから、です。
MSAでは前者をプラットフォームよび、後者をマイクロサービスと呼ぶことで分離していくのでしょうね。プラットフォームチームはアジャイルチームから分離すべき、です。
「大きなアーキテクチャと小さなアーキテクチャ」はエンタープライズ界隈でアジャイルに取り組もうとするときに問題になりがち、という実感のうえで提唱しました。まだまだ粗い整理なので議論の余地もあります。
エンタープライズ界隈でも、改めてアーキテクチャ設計が重要性が高まっているからこそ、無用な混乱を避け、各エンジニアが的確な活動ができる助力になればと思います。
MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない
「低レベルなマイクロサービスアーキテクチャ（MSA）」というのは「ただの基幹システムとのファイル連携」でいいんだよ、という話。
Level 5 | Richmond, Virginia | Rebecca Morgan | Flickr
MSAというのは「どこかに存在する完成されたシステム」ではなく、現状のシステムを不断の努力によって進化させていった結果です。MSAに決まった構成はありません。あくまでもプラクティスやパターンがあり、それらの実現を手助けするソフトウェア製品（OSS）があるだけです。
というわけで、「MSAに取り組む」というのは道は遠くても（見えなくても）「目の前のシステムの継続的な改善に取り組む」ことでしかないのですが、最先端の話しかないと差が大きすぎてどう取り組めばいいのか分からない、あるいは再構築しか道はないと感じてしまうのだと思います。そこで段階的なレベル上げができる、というか、段階的なレベル上げをするしかない、という説明をしたいと考えています。つまり、MSA化のレベル定義。
MSAのレベル感
原典であるMartinFowler.comのエントリ「Microservices」に書かれたMSAの特徴をゆるめに表現すると以下のようになります。
- 全体システムを、機能別のシステム同士が連携することによって実現させていること（Componentization via Services）
- ビジネス機能にそった開発チームが組織されていること（Organized around Business Capabilities）
- WF型の一括構築ではなく、継続的に新機能開発を行うこと（Products not Projects）
- SOAのESBやEAIのような連携基盤を頼りすぎず、サービス自身が同期/非同期API連携を整備していること（Smart endpoints and dumb pipes）
- 開発規約やフレームワークなどを標準化をしすぎないこと（Decentralized Governance）
- マスタデータは可能な限り個別システムで管理すること（Decentralized Data Management）
- インフラ関連の作業は可能な限り自動化すること（Infrastructure Automation）
- 連携先システムが停止しているケースを想定すること（Design for failure）
- 一括再構築を避け、段階的に部分再構築をしていくこと（Evolutionary Design）
こう書いてしまうと、実は常識的なことしか書いてありません。MSAの基本的な考え方というのは複数のシステムが連携して、全体が機能することを目指しており、そのために最適な組織や障害要素を低減する必要がある、というだけです。
ですから、従来型のシステム群であっても、ファイルとはいえシステム同士が連携はしますし、チームは業務によって組織されています。その他のトピックするもやれるだけは取り組んでいるのではないでしょうか。これがレベル1。
そして、これらを突き詰めていくと最先端の企業の事例にあるような「最小サービスは1週間ぐらいで作れる大きさ」であり「1画面で数百のサービス」が動き、それらが「数万ノードに自動デプロイ」され、「リリースは1日の数十回～数万回」も行われている、ということになります。これがレベル5。
MSA化モデル軸
次にMSA化をモデル化する軸として、以下の4つを考えてみました。
MSA化レベル定義
そして、レベル感は以下のようなものを考えています。レベル上げのポイントや取り組むべき具体的な作業については別途。
| Lv | 疎結合化 | 自動化 | 基盤化 | 自律化 |
|---|---|---|---|---|
| 0 | 完全に統合されたシステム | ビルドは職人芸、コードは個別管理 | 物理インフラ | 厳格なトップダウン型 |
| 1 | 大きなシステム、ファイル連携やデータ共有 | ビルドはコマンド化、CVS/SVN | インフラの仮想化 | ウォーターフォール、標準化強め |
| 2 | 大きめなサービス、キューによる非同期連携 | ビルドパイプライン、Git/ブランチ戦略 | 認証/ログなどの基盤化、パブリックPaaSの利用 | アジャイル風、標準化弱め |
| 3 | 適度なサービス粒度、データ分離 | ブルーグリーンデプロイ | 様々な汎用基盤サービスの活用 | 複数のアジャイルチーム、個別最適 |
| 4 | 小さなサービス、非同期ストリーム、イベントソーシング | コンテナオーケストレーション | 様々な独自基盤サービス | たくさんのアジャイルチーム |
| 5 | かなり小さなサービス、独自プロトコル連携 | 数万ノード、数百回リリース | 自作基盤をOSS化 | すごくたくさんのアジャイルチーム |
いかがでしょうか？これも軸にあるべきだとか、このレベルにはこういうものが必要だ、とかあれば、ぜひ教えてください。
おじさんにも分かるITトレンド説明と日本のエンプラITの限界
タイトルは煽りです。某勉強会向けに作成した資料ですが許可を得て掲載します。
2001年アジャイル、2006年クラウド、2009年DevOps、2014年マイクロサービスという一覧のトレンドを解説しつつ、最後は「日本のエンプラITはついて行けていないよ」という話。1時間ぐらいで話せますので、自社のことを考えて残念な気持ちになりたいというドM気質のエンプラ企業の方はご連絡をお待ちしております。
ハイライトは以下のページですかね。
合わせて読みたい：事業会社におけるマイクロサービス化について
事業会社におけるマイクロサービス化について
がちがちのエンタープライズ系で既存システムのマイクロサービス化に取り組むときに注意したいこと。
儲かる機能をマイクロサービス化する
マイクロサービスの最大の目標は「サービス化された機能のリリースサイクルを、その機能を管理するチームが独自に決定できるようにする」ことです。つまり、システム内の他の機能や他システムとの調整をしないで、いつでも好きなようにリリース可能であることが大事です。もちろん、日中に。
それは何のためかというと「機能をどんどん改善して儲けたい」からです。これまでは、儲かる機能を改善をしようとしても、その他の機能や他システムとの調整や影響範囲調査やリグレッションテストに時間がかかってリリーススピードをあげることができませんでした。この問題が解決できればウハウハできるはずです。
マイクロサービスのサービス分割点について聞かれることが多いですが、それは「ビジネス部門が『早くリリースできたら儲かる』って言っている部分で切ればいい」です。マイクロサービス化によって儲かる度合いが増える、というのが大事です。で、それをビジネス部門と合意する。
とはいえ、そんな自由に切れないわけで、エンジニアはビジネス部門がやりたいことを理解しつつ、良い感じの分割方法や制約条件を整理します。もちろん、できないこともあるでしょう。ただ、それは「基幹システム側の都合に引きずられるからであって、このシステムのせいではない」ことを説明しましょう。そっちに言ってくれ、と。それ以外にも疎結合化（非同期化）は、かならずシステム間で不整合を生み出す可能性を持っています。ビジネス部門に制約を提示し「儲かるから、その制約は飲むよ」と言ってもらうことが大事です。ここでビジネス部門をちゃんと巻き込みましょう。
意思決定システムや運用ルールを変えていく
「機能を改善して儲ける」というのは「儲かる機能を考える」「その機能を作る」「その変更を含んだリリースをする」という一連の流れを前提としています。つまり「作る速度を上げる」という話では、まったく足らないということです。
そこで問題になるのが「儲かる機能を考える」や「その変更を含んだリリースをする」といった部分のプロセスです。
「儲かる機能を考える」の代表的なプロセスは稟議であり「事業部門が儲かる機能を企画して、見積をとって、稟議書を書いて、多層的にROIをチェックされ、なんか指摘に対応し、開発ベンダーを計画書を書かせ、それを精査して、契約を取り交わす」ということをになっています。普通に1ヶ月かかったりします。遅い、遅すぎる。
「その変更を含んだリリースをする」の代表的なプロセスやISMSなどに従った運用プロセスであり「変更を説明する資料を作り、それが安全な変更であることを証明する資料を作り、いろいろなテスト結果を説明し、リリース要員を手配してスケジュールを確定し、多層的に承認を取って、リリース資産を作成して登録し、それをしずしずと本番環境に転送し、サーバ停止しますと掲示を出して、本番環境を1つ止めちゃアップデートし、全部ができたらテストをして、問題なかったら掲示を外してアクセスを許可する」ということになっています。普通に1ヶ月かかったりします。遅い、遅すぎる。
いずれも現在のルールをすぐに変えることはできないでしょう。でも、なんとかしないとスピードが上がらないことも事実です。なんとかするように企画部門と運用部門にも頭をひねってもらう必要があります。
追記：ルールを変えられないなら「リリース内容も決まっていないけど3ヶ月先のリリース日を先に決めて、締め切り駆動でプロセスを進める」というのが推奨になります。
エンジニアをチームでおさえる
良いエンジニアをチームでおさえましょう。少なくとも1年間はチームを維持することを前提にすべきです。チームのサイズは4-8名程度が良いでしょう。ざっくり単価100万だとするなら、年間で5000万円～1億円ぐらいは払うつもりがあるべきです。もちろん、1つのサービスだけで維持できないこともあるでしょうから、その場合は複数のサービスを管理してもらってもよいです。
なお、エンジニアを外部調達に頼る場合には準委任問題が出てきます。出てきますが、なんとかするしかありません。会社同士の関係が良好であれば請負契約（＋変更管理）でも対応できます。内製化もよい判断でしょう。ただ、経験者は必要です。最初は外部メンバーに入ってもらい、段階的に内製化を促進していきます。
分割に備えてプラットフォームを整備する
実際にサービス側のチームとは別にプラットフォーム側のチームが必要になります。システムを分割していこうとする場合、多くのサービスは同じような課題にぶつかります。そういったものはプラットフォームとして提供（あるいは外部のPaaSを採用）することになります。代表的なのはSSOとログです。
1つのシステムだったものを2つに割る場合、それらの2つの間で認証情報を共有する仕組みが必要になります。OAuthのように認証画面から丸投げできる機能を構築してもいいですが、そこまで不要であれば認証情報をキャッシュする先を用意するだけでもよいでしょう。
2つに割れると、統合的にログ分析したくなります。そこでログエージェントをいれて、ローカルの吐かれているログを集約して検索可能にする仕組みがあると便利です。サービス間でAPI連携するならトランザクションIDを発行してログに載せるのも有効です。
プラットフォームを整備するチームは個別のサービス管理するチームとは別に用意しましょう。目的が異なるため、同一にするとサービス管理チーム側にオーバーヘッドがかかり、本来の生産性が測りにくくなるからです。
僕はプラットフォームまで含めた全体配置を考えるのを「大きなアーキテクチャ」と呼び、個別のサービス内の構造や構成を考えるのを「小さなアーキテクチャ」と呼びます。大きなアーキテクチャはプラットフォームチームの管轄であり、小さなアーキテクチャはサービス管理チームの主管です。標準化すべきはプラットフォームへのアクセスインターフェースだけにすべきで、各サービスのフレームワークではありません（プラットフォームを利用するためのクライアントライブラリとかはいいです）。
Agile、Cloud、DevOps、Microservices
マイクロサービスというのは「アジャイルを機能させるための技術的な基盤」であると言えます。2001年のアジャイルソフトウェア開発宣言から、我々はITサービスの提供サイクルを最適化しようと努力をしてきました。2006年のクラウドの登場により、インフラ構成やミドルウェア構成をコード化できるようになり、DevOpsムーブメントは運用機能を自動化し、コードによってオペレーターを不要にしていくようにしていました。結果として、管理ノードの増加に耐えられるようになりMicroservices的な仕組みが実現できるようになったのです。
マイクロサービス化というのはアジャイルソフトウェア開発宣言からの16年間を一気に学ぶ、ということです。いろんなものをすっとばして「サービス分割すりゃいいんでしょ」じゃないんです。マネジメント論と、それを実現するアーキテクチャ論であることをきちんと理解しておくべきでしょう。
明日から取り組め。できないなら、一生できない
マイクロサービス化は明日から取り組めます。ウォーターフォール型で「次回の再構築はマイクロサービスで」ではありません。そんなの絶対にうまくいきません。ちょっとづつ取り組みましょう。
取組みの開始はシステム分析でもビジネス部門の啓蒙でも経営層の説得でもいいです（大抵の場合は経営層から下りてきている話でしょうが）。結局、上記に書いたような様々な変更を行う際に障害になるものを取り除かなくはなりません。その障害を「再構築のタイミングで全部変える」というのはムリです。絶対にムリ。結局、既存のしがらみから抜け出せず、中途半端な理想論と技術論の結果、意味もなくサービスが分割されて、制約ばかりが増えて再構築自体が意味が無かったことになります。
最初に書いたとおり、まずは「儲かる機能を見つけて、分離する」ということをしましょう。そして、それをやるための障害を少しずつ乗り越えていくのです。そうやって3年もやれば良い感じになってきます。そのぐらいかかりますが、再構築で3年使うよりも、よっぽどマシな結果が得られるでしょう。
まとめ
最近、マイクロサービス化のご相談をいただくことがありますが、僕は技術的な実現手段はなんでもいいと思っています。AWSでもAzureでもオンプレでも。大事なのは会社の戦略プロダクトとしてITサービスを捉えてもらい、会社の営みとして持続的にITサービスの提供を行うようにしていくことです。これが僕の考えるマイクロサービス化です。
マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
2017年月31日開催されたAWS Dev Day Tokyo 2017で「〜マイクロサービスを設計する全ての開発者に送る〜クラウド時代のマイクロサービス設計徹底解説！」という講演をしました。
諸般の事情でタイトルは煽り気味ですが、40分しかないのに徹底解説というのもあれなので僕としては「マイクロサービス化設計入門 」ぐらいの雰囲気です。マイクロサービス化にむけて設計をする場合に気にすべき点について整理をしています。資料はこちら。
巨大なシステムであってもマイクロサービス化によって柔軟な変更が可能になります。ただし、既存のモノリシックなシステムから品質方針の変更が必要になります。
モノリシック
- 単一システム内で不整合を発生させない
- 障害を発生させない
マイクロサービス
- 複数サービス間で不整合が発生する前提で頻度やリカバリ方式を検討する
- 障害が発生しても影響を一部に抑えてシステム全体をダウンさせない
講演後のQAでも、ここらへんの進め方について「ビジネス部門に不整合発生をどうやって納得してもらうか」という質問をいただきました。
回答としては「サービス分割自体は適切に検討した上で、サービス間の不整合の発生を前提として、その『発生回数を減らす』『リカバリを自動化する』といった方式についてコストを提示していくしかない」になります。サービスを分割する以上、技術的限界もあって完全に不整合を排除することはできません。この割り切りがうまくできるほどマイクロサービス化したメリットが高くなります。
何かを得れば、何かを失う。
そして何ものをも失わずに次のものを手に入れることはできない。
とは小説家 開高健の名言ですが、まさにその通りなのです。
ここら辺を掘り下げる話も、どこかでしてみたいですね。
2017/6/15追記。動画が公開されました。
JJUG CCC 2017 Springを開催しました #jjug_ccc
昨年の12月からブログを書いていませんでしたね。こんにちは、JJUG会長の鈴木雄介です。2017/5/20（土）に20回目となるJJUG CCC 2017 Springを開催しました。
まずは、参加者、講演者、スポンサー各社、ボランティアスタッフ、そして幹事のみなさま、参加ありがとうございました、そして、お疲れ様でした。
参加者は1034名（申込1874名）となり、過去最高を記録しました。20回目で1000人越えという大きな区切りを向かえることができました。
ともかく混雑してましたね。満席で部屋に入れない、部屋間の移動が大変、懇親会が満員電車などなど。我々としても、あの会場で1000人越えは厳しいな、と感じています。
結果「会場が狭い」「混雑しすぎ」という意見はメールやSNSを問わずにいただいています。はい、おっしゃるとおり。
そして、それに対して私も含めて感情的な反応が出てしまったことを申し訳なく思います。「事情も知らないのに文句を言うな」という感じで。この増田が分かりやすい指摘かと。
初めてJJUG CCCに参加した後輩が「聞きたいセッションがいっぱいで残念だった、もうちょっと広い会場でできればいいのに」と言っていたところに、「運営側の苦労も知らないで文句言うな」という意見が流れてきてむしゃくしゃして書いた。
Javaのイベントでは、会場の狭さに文句を言うことは許されない
運営側からすれば、色々な制約の中で選んだ会場であり、そう簡単に広くもできないという事情の中、参加者の一部からは好意的な言葉（「運営は頑張っている、狭いのは我慢すべき」）をもらっていると、どうしても文句に対して敏感になります。運営ハイの最中なので、なおさらです。
そんなわけで感情的な反応については心からお詫びをしたいと思いますが、一方で「幹事だって人間だもの」という広い心でお許しいただければ幸いです。
ところで増田に書かれている「コミュニティ慣れしていない人への対応」ですが、僕としてはコミュニティ初心者を歓迎したいです。コミュニティ文化を知らない人、あるいは「お客様気分」の人、そういう人がコミュニティに触れて、その混雑も含めて楽しさを見出し、もっと参加したい、次も来よう、いつかは登壇しようと思うきっかけになってもらいたいのです。そうでないとコミュニティは継続しません。
ですから、副作用的に文句が出ることも当然だと思っています。コミュニティの事情が良く分からないと「運営をどうにかしてくれ」と思うのは当然です。副作用は仕方ないのですが、それがネガティブな思い出になってコミュニティ初心者に伝わるのも避けなくてはいけません。
幹事にも言いましたし、いわゆる「常連」な皆様にもお願いですが、事情を知らない人にも優しくしてあげてください。ただ、甘やかす必要は無いので、（説教にならない程度で）コミュニティの事情や状況を話してください。1000人規模のボランティアイベントなんだ、参加者みんなで創り上げるもんなんだ、と。それを聞いても文句がある方は、次回から来なくなると思います。
僕としては「Javaとコミュニティ」みたいなセッションを毎回やったほうがいいんだろうな、と思いました。JUG（Java User Gourp/ジャグ）とは何か、Javaの仕様がどう決まるのか、標準JavaとOSSの違いはなにか、JJUGはどうやって運営されているのか、あたりでしょうか。
「そんなに真面目にやらなくても」という意見もあるかもしれませんが、社会人としてコミュニティのエコシステムを知ることは大事なことだと信じています。世の中を効率化するのに会社を超えたコミュニティは欠かせない存在です。
さて、「事情」は色々ありますが、私から話せるのはお金に関わることです。
今回のCCC実施にかかる費用は400万円ぐらいで、これをスポンサー費でまかなっています。今回は19社に協賛してもらいました。ちなみに日本オラクルさんは立場的にダイヤモンドスポンサーをお願いしていますが、大きなお金を出しているわけではありません。Javaコミュニティに賛同してくれている大事なスポンサーの1社です。
明細は以下の通りですが、ボランティアで運営しているため人件費はかかっていません。
- 合計：398万円
- 会場：290万円（ベルサール新宿グランドの料金表）
- 外注（通訳など）：6万円
- レンタル（無線機、延長ケーブル）：14万円
- 懇親会（フード、ドリンク）：50万円
- コーヒー：10万円
- 交通費（地方講演者支援分）：15万円
- 託児：13万円
たいていは費用が先支払いで、スポンサー収入が後になるため、一時費用は事務局企業に肩代わりをしてもらっています。つまり、毎回400万円の借金を背負いながら企画をしています。これまでスポンサーが足りない、開催できないといったことはないわけですが、常にリスクがある中で準備を進めています。ま、なんとかするしかないんですけど。
で、会場を拡げることは金額的な難しさと、物理的な難しさがあります。現在の会場は「会議室」であって「ホール」ではありません。これをホールにすると金額が数倍になります。JavaDayなんかは立派なホールですね。スポンサー費を数倍にすることも、スポンサー数を数倍にすることも現実的ではありません。そして、運営的にも広い会場には難しさがあります。音響や照明管理、誘導、椅子の移動など、スタッフに専門性と人数が必要になってしまうのです。
そんなわけで今の会場は程よい大きさと部屋数のバランスが気に入っています。もし、都内で10部屋以上で1000人以上収容できて、全部屋に1分以内でいけて、1日300-400万円のところがあれば、ぜひ教えてください。乗り換え検討しますので。他にも部屋別予約システム、全部屋無線LANなども検討していますが、いずれも数十万円単位で、かつ、完璧なものではありません。
そして人件費をゼロにするためには「幹事も含めてボランティアで回るぐらいの運営負荷にする」ということが大事です。CCCの運営は修業ではありませんし、儲けがあるわけでもないので、スタッフも苦労しつつも気持ちよくやれる、というレベルを維持する必要があります（打ち上げも割り勘です）。当日ボランティアスタッフは継続的に参加していただいている方もいて練度があがってきました。非常に感謝しています（参考：JJUG CCCボランティアスタッフのススメ - 我らねぶた馬鹿）。
また、本家のような有償化（数万円レベル）は考えていません。日本におけるJavaはエンプラを中心としつつ、OSSを含めれば非常に幅広いユーザー層が対象で、そこまで尖ったイベントをするのは難しいと思います。ただ、懇親会では「交流ではなくご飯だけが目的の人が増えてきた」という話もあるので、大きな負担にならない範囲で有償化を検討します。
もちろん、幹事も毎回のように改善を続けています。ただ、反省がなくなるわけではありません。次回は1000人超えをどうするのか、あるいは人数を絞るのか、幹事会で議論をしていきたいと思います（参考：JJUG CCC 2017 Spring 運営の人の話 – hotchpotch）。
結論として現時点では1000人を大きく超えるようなイベントをボランティアで回せる気がしていません。JAWS DAYを参考にすれば、とも言われたので、誰か中の人がいれば事情を教えてもらいたいです。五反田TOCメッセって、どうなんでしょう。
そんなわけでCCCは続けていきたいので、色々な試行錯誤をしきたいと思います。次回は11/18（土）を予定していますので、そこに向けたフィードバックはいくらでもお待ちしております。どうぞ、ごひいきに。
※年次定期総会資料
