iOS オールスターズ 2 で Swift らしさをたっぷり語ってきました。 #eventdots

勉強会

iOS オールスターズ 2 で Swift らしさをたっぷり語ってきました。

とにかく楽しい理想的な空間で、たくさんの嬉しさが得られる会だったように思います。

東京・渋谷の dots. で に開催された iOS オールスターズ 2 に招かれまして、Swift らしい表現を目指そう』というテーマで話してきました。

終わってみれば、参加者、登壇者、運営、みんながみんな、見事なまでに守り立ててくれたおかげで、とっても楽しい勉強会に仕上がって、そこに登壇者として参加させてもらえたことが、当日を振り返ってみるたびに思い起こされる、いちばん嬉しい出来事でした。

オールスターズ ⭐️

最初、この iOS オールスターズ 2 への登壇のお誘いを頂いたとき オールスターズというのは自分とかより、もっと誰もが認める素晴らしい成果物を残しつつ、業界の先頭に立って皆を引率しているような実力派エンジニアたちが集結するべきなのではないか と思って、最初は心境複雑だったのですけれど、見せてもらった登壇者リストに稲見さん（@inamiyさん ）がいらっしゃって、彼と同じ舞台で話したいという理由が勝って承諾したのでした。

でも、その判断で正しかったみたい。

終わって全部を振り返ってみれば、ここでいうオールスターズってもしかしてエンターテイナーのこと？みたいな感じで、みんな良い感じの個性派揃い、ものすごく楽しい勉強会になったように感じました。その一員として自分も全うできた心地がして、登壇者という立場としても、とっても充実感を覚えるイベントでした。ほんとに、オールスターズにふさわしい素敵なメンバーが揃った印象でした。そしてそんなメンバーたちに、めいいっぱい声援を送ってくれるみたいな、暖かい人たちが集った会のように感じたことも、嬉しい大事なポイントでした。

特にツイッターの反応が、暖かさで溢れていて嬉しかったです。そんな様子は iOS オールスターズ 2 #eventdots - Togetterまとめ にまとめてみたので、どうぞご覧くださいね。

発表順も BEST な印象

発表順も、どう考えてもこの上ないくらい、すごく良かったかなって思います。

勉強会って普通、事前に順番が決まっているものですけれど、今回の iOS オールスターズ 2 は当日のオープニング後に、みんなの前でくじ引きで決めることになっていて、天に運に任せる感じだったんですけど、この天がものすごく強靭なくじ運の持ち主だったみたいです。

1. 成田元輝さん

最初の発表は、成田さん（@motokieeさん ）で、今、最もホットな話題とも言えそうな RxSwift についての実践的体験談を、満面の笑顔と安定感のある口調、堅実かつ実用的な話題、そんなスピーチでみんなの気持ちをイベントに誘ったように思います。いよいよ始まりを感じさせる、とっても素敵な開幕でした。

特によかったなって思うのは、話題がRxSwift 本格体験記だったこと。そのおかげで、捉えやすいポイントとそうでないポイント、今までの考え方と Rx の考え方が対比的に語られていて、どんな考え方の転換をしたら良いのかが感じられるところでした。これは、もし自分が Rx に触れる日がきたとしたら真っ先に復習したい資料に感じました。

2. 田中賢治さん

登壇は続いて、東京在住のイケメン男子、田中さん（@ktanaka117さん ）で、ネタ、ネタ、ネタの嵐で、成田さんの作った朗らかな空気を一瞬でまるごと吹き飛ばした印象でした。内容は極めて有益なクリーンアーキテクチャーの体験・実用談で、丁寧かつ堅調な口調で語るそれに聞き入るんですけど、それさえも、ところどころに差し込む自分のネタで吹っ飛ばすみたいな豪快ぶり。

笑わせてもらうばかりで内容に意識を集中できなかった感は否めませんけど、会場の力を最大限に抜いてリラックスした空気をもたらしてくれたように思います。もしも全部がこんな調子だったらどうなってしまうんだろう…と想像はしてしまいますけれど、きっとそんな心配は不要で、彼以外にあのスタイルを通せる人はいない。こういうノリ、個人的にはけっこう好きです。

VC「もしかして...」Model「私たち...」「「入れ替わってるー！？」」を前前前世から防ぐ方法 from Kenji Tanaka

3. 稲見泰宏さん

この、田中さんから稲見さん（@inamiyさん ）への繋がりが、個人的には特に好みでした。稲見さんと言えば、正統派・超実力派というイメージがあって、そして田中さんが破壊的に和ませたムードを一瞬にして程良いところまで呼び戻してくれた印象でした。ほんと、田中さんの次で最適だったと思う。田中さんのあの雰囲気に完全に打ち勝てる人は、今回のメンバーではきっと稲見さんしかいない。

話題は、稲見さんご自身が以前に話されていた Parser Combinators in Swift の続編として、型安全な URL Routing について話されていました。関数型プログラミング、すごく高度な印象がして自分にはまだ追いつけない領域、そんな世界を垣間見させてもらえて嬉しいです。そしてこの領域って Swift の基礎がたくさん詰まっている気がして、いいかげん自分もこの辺りを修得しておかないと、そろそろ時代から取り残されそうな予感がしています。

4. 吉川和成さん

続いて、吉川さん（@codelynxさん ）の PDF の話題でした。こちらもとても深い話でしたけど、前の話題が超高度だったのもあってか、なんかとっつきやすく感じるという不思議。途中で『疲れましたか？』みたいにみんなに問いかける場面もありましたし、実際、確かに大変なボリュームでしたけど、次の時間が幸い休憩だったりして、もうちょっと頑張ればお休み！みたいな心地で身構えられる安心感も良い感じでした。

PDF ってなんか時々、生成したくなりますよね。でもちょっとかじってみるも上手く行かずにとりあえずやめておこうみたいなあったりしたので、こうやって初歩的なところから実用的なところまで見させてもられるというのはとても貴重です。情報も、PDF を扱う話って『この API を呼んでこうするとこう』くらいの、躓くといっきに置いていかれそうなスマートなのが目立つ気がするんですよね。その観点でも、このお話は体験談がしっかり綴られていてすごく良いなって感じました。

5. 森本利博さん

それから休憩を挟んで、後半最初は森本さん（@dealforestさん ）による Xcode の話題でした。休憩によって休められた頭に、彼が醸し出すユルめな空間が上手にマッチするように思いました。ここから後半の始まり、みんなのホッと落ち着いた中に、良い雰囲気を作ってくれたように感じました。

内容は Xcode の、知ってると便利だけど自力で調べるにはくじけそうになるところ、うっかりハマって苦労するところ、小技的なところ、そんなあたりが紹介されてて、興味深い内容でした。Xcode そのものってなかなか注目されないところもありますしね。道具を手足のように扱えるって、職人（エンジニア？）として大事なところと思うので、それに意識を向けさせてくれるこのお話はすごく良いテーマかなって感じました。

6. 伊藤恭平さん

そんな良い滑り出しから続く、伊藤さん（@kyoheig3さん ）は Protocol Buffers という、このところ何かと耳にする魅力的なワードで始まって、前のリラックスムードもあって、良い感じにこの世界に落ちて行けたような気がします。

そう、最近 Apple が力を入れ始めた様子が窺えて、気になるところですよね。同時に、使うための準備とか、バイナリーならではの互換性配慮とかも気になって、現段階でどれほどの価値があるのか、そこも気になるところです。JSON でも、ルールを決めることは重要なのでもしかして JSON に DTD みたいなものを取り決めて足並みを揃えるという手もあるかも知れないし、型安全なら JSON も ikesyo/Himotoki みたいなもので表現できる…けれど「数字」とか「文字列」とか漠然としか決まってないのが問題なのかな？、あと転送サイズが気になるならばもしかして ZIP 圧縮とかを暗黙的にかけるとか（HTTP Compression とか）で十分だったりするのかなとか。そんな感じで Protocol Buffers と聞くと、いろんな想像が膨らんで楽しいです。ともあれもし今の事前準備作業とか、今のところの非標準なあたりの手間が解消される日が来たら、いっきに花開きそうな予感も感じさせてくれますね。

7. 米川健一さん

そうして楽しませて頂いた次は、米川さん（@yonekawaさん ）の Dependency Injection の話題、こちらもまた、日常の中でよく耳にする注目ワードのひとつですよね。後半はこうして、みんなの身近な 知りたい欲 を立て続けに刺激する感じが、とてもいい流れに感じました。

チーム開発をしたことのない自分が個人的に DI と聞いて思い浮かぶのが、引数として依存性を受け取る必要があるのかな？というところ。よくデバッグと絡めて紹介されることが多いのでなおさらなのですけど、仮にそれがデバッグ性だけに着目したものだったとしたら、それが引数に現れるのは保護範囲的にどうなんだろう。もしかして Phantom Type … とはちょっと違うと思うんですけど、例えば『通信のやり方』という観点に着目するなら、型パラメーターで表現するのも妥当なのかな？と思ったり。もちろん、依存インスタンスの再利用性とか、そもそもきっと DI Container までを視野に入れるともっと広い世界を描いてくれそうで、そういうところがきっと醍醐味なんだろうなって感じさせてくれるお話でした。

8. 熊谷友宏

そして、最後は自分の番でした。

自分の発表、内容的にどこに入っても浮きそうだなーって思って、それなら最後がいちばんいいのかなって思っていたので、くじ引きで８番を引いたときには思わず嬉しくてニヤけました。その代わり、最後の最後までずっと自分の資料のブラッシュアップをしていて他の人の話をゆっくり聴けなかったのですけれどね、でもそのおかげでもう少し分かりやすくするためのスライドを追加できてよかったです。

全体の流れ・雰囲気的にも、いちばん最後でちょうど良かった気がします。

話した内容としては、何かと話題にのぼる『Swift らしさ』を、すごく標準ライブラリーに近い位置から眺めてみたものになります。でもそう、Swift らしさってきっと、みんなそれぞれの喋り方とか仕草とか、そんな感じだと思うんですよね。ガイドラインは学校教育みたいな感じで、同じ日本語を使うのだけれど、みんないろんな口調や表現方法があって。それによって個性が描かれ、ひいては人それぞれの魅力が生まれるのかなって思いながら綴ってました。

Swift API Design Guidelines でも、それぞれのコンテキストに合わせて美しく描こうみたいに記されているので、あまり気張らず、囚われすぎず、表現の仕方に迷ったときの参考にでもしてもらえたら嬉しいかなって思います。

Swift らしいコードを目指そう #eventdots from Tomohiro Kumagai

自分の発表の補足

そんな自分の発表でしたけど、いくつか補足したいなって思えるところがあったので、ここに記しておくことにしますね。

イニシャライザー名の流れについて

イニシャライザーの表現の流れはあまり意識しなくて良いという観点は、主に Swift API Design Guidelines の Strive for Fluent Usage にあるイニシャライザーについての言及を根拠にしました。

そのほかにも、変換イニシャライザーの命名規則、構造体に自動実装されることがあるメンバーワイズイニシャライザーなども加味すると、イニシャライザー名については、英文法的な流れは Swift 標準ライブラリー近隣ではそれほどこだわっていない様子が窺えます。

タプルの比較

そう、タプルの比較、面白いですよね。スライドでは 37 ページ のところ、具体的にはこういうコードです。

struct Int128 {

	fileprivate var low: UInt64
	fileprivate var high: UInt64
}

extension Int128 : Equatable {

	static func == (lhs: Int128, rhs: Int128) -> Bool {
	
		return (lhs.low, lhs.high) == (rhs.low, rhs.high)
	}
}

ここの主題の Equatable を説明するにあたって == を実装した時に、最初は次のようにコードを書いてみていたのでした。

extension Int128 : Equatable {

	static func == (lhs: Int128, rhs: Int128) -> Bool {
	
		return lhs.low == rhs.low && lhs.high == rhs.high
	}
}

自分もこれまで、タプルで比較ってする機会あるのかなって思っていたんですけど、ただ、このように書いたとき なんか読みにくいな…？ って感じてしばらく考え込んでしまって。というのも、なんか、読まないとわからないんですよね。『左辺の下位値と右辺の下位値の一致性を調べて、左辺の上位値と右辺の上位値の一致性を調べて、その両方が真だった場合に等価とする』みたいに。

もっと簡潔な表現ってないかなって考えていた時に、そういえばタプルを思い出して書いてみたら、けっこう良い感じに描けたように思います。表現的には『左辺の上位と下位を束ねたものが、右辺の上位と下位を束ねたものと一致するか』みたいに。

もっと楽しい描き方とかあるのかなって思って、もう少し考えてみようかなとも思ったんですけど、それなりにスマートに表現できた気がするのと、このタプルによる比較表現って意識して使えばもっといろんなところで使えるのかもしれないなって思って、そんな存在の紹介も兼ねて、今回はタプルによる一致比較を紹介してみることにしました。

Equatable の発音について

Equatable の発音にはあまり関心を寄せてなくて、とりあえずなんとなく読んでたくらいなので、そんな感じで受け取ってくださいませ。他の人の反応を眺めていると、もしかすると "イコータブル" が発音的に適切なのかもしれないですね。

enum の文字列表現

そう、ここがとっても面白いところなんですよね。コードでいうと次の通りで、スライドでいうと 42 ページ です。

enum Device : CustomStringConvertible {

	case iPhone, iPad, appleWatch

	var description: String {

		switch self {

		case .iPhone:	
			return "iPhone"

		case .iPad:
			return "iPad"

		case .appleWatch:
			return " Watch"
		}
	}
}

列挙型で、列挙子を文字列で表現する方法っていくつかあって、かなり迷うポイントなんですよね。実際、今回の勉強会でもそういう日々の悩みを抱えている人が多かった様子が窺えて、自分はこれが最適なんじゃないかな？っていう提案も兼ねてこのコードを選んだので、それに対するみんなの反応に触れられてとても嬉しかったです。

列挙型ってたぶん３つほど、文字列表現のための構文が用意されているんですよね。まずはどれが良いかという観点を抜きにしてそれぞれがどんな表情を浮かべるかを見てみましょう。このような感じです。

列挙子

ひとつが、列挙子そのものを文字列表現として使う方法です。

enum OperatingSystem {
    
	case osx
	case iOS
	case watchOS
}

例えば、こういう列挙型があった時、次のようにして普通に文字列化できます。

let os = OperatingSystem.osx

print(os)                 // "osx\n"
String(describing: os)    // "osx"
"OS: \(os)"               // "OS: osx"

ちなみにいつだったか、少なくとも確か Swift 1 では、列挙子とは別の文字列に変換されていたと思います。これは個人的な解釈というか予感なのですけど、この文字列変換はインスタンスに入っている列挙子が何かを知るのに十分なテキスト表現に変換するためのものなのかなって思います。

ただ、少なくとも現行の仕様では、列挙子名とまったく同じ文字列を取得できる期待度は高いので、その列挙子の文字列表現が確実に列挙子と同じである場合には適切なのかな、とは思います。ただし同時に、列挙子とテキスト表現が完全に一致することは、少なくとも表示用のテキストを想定しているときには滅多にないようにも思います。

Raw Value

もうひとつ、列挙型には Raw Type というのが設定でき、列挙子にその型の値（厳密には、対応するリテラル）を設定できるようになっています。これを使うと先ほどの列挙型は、次のように定義できます。

enum OperatingSystem : String {
        
	case osx
	case iOS
	case watchOS
}

このように定義しても、先ほどと同じコードで文字列化したときに、全く同じ結果が得られます。

let os = OperatingSystem.osx

print(os)                   // "osx\n"
String(describing: os)      // "osx"
"OS: \(os)"                 // "OS: osx"

じゃあ、全く同じことをしているのか？というとそうではなくて、厳密には次のように、各列挙子に対して割り当てる文字列値を省略している形になります。規定で割り当てられる文字列は、列挙子と同じ文字列です。

enum OperatingSystem : String {
        
	case osx = "osx"
	case iOS = "iOS"
	case watchOS = "watchOS"
}

そして Raw Value というのは、厳密には RawRepresentableプロトコル で表現されていて、列挙型の場合はつまり列挙子と１対１で対応する、原始的な値表現を意味するもので、列挙子と Raw Value との相互変換もできるようになります。

let string = OperatingSystem.osx.rawValue      // "osx"
let value = OperatingSystem(rawValue: "osx")!  // osx

原始的な値表現とはどういうものかというと、例えば Swift の列挙型は列挙子そのものに値を割り当てなくても、名前だけで抽象的に存在して使うことがでるけれど、Objective-C の列挙型は列挙子に名前を当てるだけでは存続できず、必ず数値を割り当てないと存在できないという差があります。後者のこの数値がちょうど Raw Value です。特に Objective-C の場合、むしろ Raw Value に名前を割り当てているとも言えそうです。

つまり Raw Value が存在するということは、それは対応する列挙子と同じ重みを持つ Raw 表現であり、列挙子名と同じくらいに、いったん決めたらそう簡単に動かしてはいけないものと言うことができます。列挙子と違ってハッキリと具体的な値を持つため、たとえば String 型の Raw Value なら永続化キーとして使えたりしてより具体的なところで使えるようになることや、変更てもコンパイラーが検出できないため、ともすると列挙子よりも動かしてはいけないものだったりするかもしれません。

Custom String Convertible

そして、もうひとつは発表の中で紹介した CustomStringConvertible に準拠させる方法です。

enum OperatingSystem {
        
	case osx
	case iOS
	case watchOS
}

extension OperatingSystem : CustomStringConvertible {

	var description: String {
            
		switch self {
                
		case .osx:
			return "osx"
                
		case .iOS:
			return "iOS"
                
		case .watchOS:
			return "watchOS"
		}
	}
}

こちらは、テキスト表現を既定するプロトコル CustomStringConvertible を使うことで、各列挙子をどうテキスト表現するかを明記しています。それ以外に言いようのないくらい、非常にシンプルかつ的確な目的表明がされるのが、ある意味プロトコルの最大の特徴であり、メリットとも言えそうです。

余談ですけど、今の Swift は、厳密にはすべてのものをテキスト表現できるようになっています。

システムの既定の方法で勝手に文字列化するんですけど、その中でも『この型には独自の明確な文字列表現がある』と言うのを主張するためにこの CustomStringConvertible プロトコルが存在しています。このプロトコル名に Custom と言う名前がついているのは、きっとそう言う所以なのでしょう。ちなみに最初に挙げた、列挙子をそのまま文字列にする方法がいわば "既定の文字列変換" です。そして今回のが "カスタム文字列変換" です。

その目的に、どれがいちばん、役割として適切か

ここで、列挙子の文字列表現を変更したくなったとします。具体的には『列挙子 osx は、表示時は OSX にしたいよね』となったときを想定します。

列挙子をそのまま文字列として表現している場合、列挙子そのものを osx を OSX にしないといけなくなります。このときに考えられる問題は、例えば Swift API Design Guidelines を尊重していた場合、これだけで Lower Camel Case の名付け原則が立ち行かなくなります。また、列挙子そのものが変更になることによって、この列挙型を使っている全てのコードに影響を与え、広範囲の実コードについて書き換えが必要になってくるはずです。

Raw Value を使って表現している場合、割り当てる Raw Value を明記すればいくらでも変更が効きます。列挙子自体は変わらないので、そこだけ見れば既存のコードに影響を与えないように見えます。ただ、たとえばその Raw Value を永続化キーに使っていたりすると、キーが変わって永続化した値が読み込めなくなるみたいな影響も出てきます。要は、表示用の文字以外の用途で使っていたとするとそこに影響が出てくるということですが、むしろ Raw Value を表示用に使う方が "別用途" なのかなって感じます。

CustomStringConvertible で表現している場合、それで規定される description プロパティーが返す値は、絶対にその値のテキスト表現です。ここで返す文字列を変えてあげればそれで完成ですし、表示する場面以外には影響しないはずです。たとえば永続化キーでの利用などの他の用途で使われることはない前提で考えて良くて、むしろ別用途で使われていたら訂正す対象はそちらになるはず。具体的な影響が現れるとすれば、たとえばテキスト表現で出力したログを解析して処理する場合、テキスト表現が変わればフォーマットが変わって正しく処理できなくなることもあると思いますけど、これは "当然" ですしね。

限りなく狭く、目的を表現しているものを選ぶ

何れにしても、その用途よりも広い表現を選んでしまうと、それに対する変更が発生した時に、その広い範囲全体に影響してしまうというというのがポイントなのかなって感じます。

今回の CustomStringConvertible の場合、その意味が『そのインスタンスのテキスト表現 (Textual Representation) を規定するもの』な役目なので、列挙子の文字列表現を決める手段としてもっとも的確な範囲を表現しているとも言えます。こういうものを選ぶようにすると、何か変更があった時に影響範囲が最小限というか変更対象そのものに絞れます。

それにそもそも、そういう仕様変更が発生しなかったとしても『表示用の文字列を作っている』ことが目で見て確実に把握できるので、可読性が高まりますし、文字列表現を変更したら実は永続化キーにも使われていたみたいな思いがけない影響を予防する上でも大きな効果を発揮してくれます。

ムックムックラジオ

ちなみにこんな、列挙型の Raw Value については、ちょうど次回 月曜日 18:00 以降に配信予定の 熊谷と繪面がプログラミングコードの内から聴こえてくる声に耳を傾けて楽しむラジオ の第７話にて、繪面さん（@eduraaaさん ）と一緒に探検してみていたりするので、興味がある人はぜひ聴いてみてくださいね。

プロトコル志向プログラミング

そしてこれ、とっても興味が湧きました。

たしかに、これを拝見してなるほど これをプロトコル志向プログラミングって呼んだらいいのか…！ って思ったんですけど、その言葉のより具体的な意図が成田さん（@motokieeさん ）のレポート iOSオールスターズ2に登壇しました&まとめ に記されていました。

「型の "性質" に着目する」と言う言葉で Protocol Oriented を丁寧に解説している

なるほど、そう、自分はけっこう『プロトコル志向』みたいな言葉が苦手で、そういう言葉で考えると何を指しているのかが判らなくなってしまったりとかよくあるんですよね。なのでついつい身近に転がっている言葉を拾って喋ることをよくするみたいで、そういえばそんなことを以前に他の友達からも同じように指摘されたのを思い出しました。

余談ですけど、難しい言葉を知らなくても見えることってたくさんあるので、たとえば Swift を始めて間もない人とか、難しい言葉に出会うことってたくさんあると思いますけど、あまり気にしなくて大丈夫かなって思います。カジュアルに Swift を楽しみましょう。

それにしてもこういう気づきって、個人的にとっても好きなところなんですよね。しかも実は今回のお話はどちらかというと "ジェネリックプログラミング" を意識して描いたところだったりして、おかげさまで自分の中の "プロトコル志向" という言葉が指す世界観がさらに広がりを見せてくれて嬉しい感じです。

成田さん、素敵な投げかけ、ありがとうございました！

Swift 3 への移行について

今回の Q&A タイムで『Swift 3 への移行はどうやってますか？』という質問が挙がりましたよね。

自分はそのあたり、全くと言っていほど工夫をしないで地道にみたいな感じだったので当日は完全にスルーだったんですけど、これについて繪面さん（@eduraaaさん ）が 今、Swift2 で書いている同胞達へ。最低限やっておきたい、Swift2 のままで始める Swift3 対策 - Qiita とスライドの２つで興味深いお話をされていたので、紹介しておきますね。

楽しさを再認識した心地

さて、そんな今回の iOS オールスターズ 2 でしたけど、それを通して、改めて「楽しさ」というものを感じさせてもらえた心地です。

というのも自分は昔から、それこそ自分が初めて参加した勉強会 iphone_dev_jp 東京iPhone/Mac勉強会 のときからずっと、勉強会における "楽しさ" が関心どころで、どうしたらみんなが楽しい時間を過ごせるのだろうって、ずっとその気持ちを大切にしながら今日まで過ごしていたんですよね。

ほんとうに、今回の iOS オールスターズ 2 は楽しかった。理想に近い方向で。

エンターテインメント

そんな楽しさなんですけど、いろんな側面があるんだなって感じるようになってきて、この頃にふと身近の登壇者仲間に目を向けてみたとき、もしかして登壇者って "表現者" なのかなって思ったりしました。表現者とひとくちに言っても、注目を一身に浴びながら、みんなに楽しさを振りまく表現者、それってすなわち "エンターテイナー" に近いのかな、とも思ってみたり。

野中彩花さん

それを最近に特に感じさせてくれたのが、先日 に開催された Swift Summit 2016 でお会いした野中彩花さん（@ayanonagon_jpさん ）でした。

舞台の上で、とっても楽しそうに話されている姿はもちろんのこと、なんか会場のみんなを自然と巻き込んでる様子がとても印象的だったんですよね。敢えて何か煽っているわけでもなさそうなのに、会場から普通に声が上がるみたいな、あの姿はとても理想的に見えました。

Pyxis

それともう二方、声優アーティストユニットって呼ぶのか判らないですけど、伊藤美来さん（@InfoItomikuさん ）と豊田萌絵さん（@toyotamoeさん ）のユニット Pyxis でした。

というのも、ずいぶん関係ない話ですけど、自分が最近に渋谷で始めた勉強会 みんなで Swift 復習会 の第１回目が自分の中では不完全燃焼で、その再起をかけた第２回目の日。次にもし、自分の中で楽しく進められなかったら来てくれた人たちに申し訳が立たないと思って、とにかく準備に専念するためにカラオケボックス JOYSOUND 渋谷南口駅前店 を訪れたところ、Pyxis のミュージックビデオが完全エンドレスで放映されていたんですよね。

そこに映し出される彼女たちの姿が、とても楽しそうで、そして全身で嬉しさを表現されているように見えて。

自分はここ 10 年以上 小松未歩さん 一択だったので、こういうアイドル系？のミュージックビデオを眺めるのってものすごく久しぶりだったんですよね。普段だったら BGM 音量を思いっきり絞って作業をするのですけど、エンドレス Pyxis なその室内では、しっかりした音量でその曲に耳を貸しながら、その日の成功を祈りつつ準備を進めた記憶が懐かしいです。

みんなアイドル？

ともあれそんな姿を見ていたら、なんかさらに前に参加させて頂いた勉強会 Haskell Day 2016 の Simon Peyton Jones さんを思い出してみたりして。

彼もまた壇上をめいいっぱいに使って Haskell の楽しさを表現されていたんですよね。そんな姿を拝見したとき、自分もそれにけっこう近いところまでは来れているかなって思えていたんですけど、それに今回の Pyxis の姿が重なって、プログラミング勉強会の登壇者はみんなアイドルなのかもしれないみたいなことを思ったのでした。

もちろん主軸はプログラミングの勉強会なので、わざとらしいパフォーマンスとか必要以上の演出は必要ないと思うのですけど、そんな辺りをわきまえてみると、ほんとなんかそっくりかなって思える。自分だけではダメで、登壇者の努力があって、参加者がいて、応援してくれて、そんな期待を背負って、お礼に楽しさを振りまいて。

そんなイメージを大事にしながら臨んでみて、おかげさまで みんなで Swift 復習会 はその２回目以降、今のところ、自分にとって納得できる会に辿り着くことができてる手応えです。そして今回の iOS オールスターズのみんなを眺めてみても、少なくとも自分の興味の向きは、やっぱりこっちでいいのかもしれないなって感じたりしました。

円卓

それと今回、というか dots. さんだとお馴染みなのかな？ 登壇者がみんなひとつの円卓に揃うのもとっても良かったです。

始まる前は、同じ場所へ集うものだからご挨拶もついつい自然に捗るし、お互いに日頃の行いを讃え合うし、みんなここで MacBook に向かって資料作りに励んでいるし。会が始まれば、登壇の順番が巡ればここから出発、登壇が終わればここへ戻ってきて、お疲れ様とか、良かったとか、言葉を交し合えるし。仲間意識がたっぷり芽生える、すごく素敵な場所でした。

自分の知識も案外、役に立つみたい？

ところで、今回の iOS オールスターズ 2 を通して思ったんですけど、自分の知識も案外、実務でも役に立つものなのかな？

自分のやっていることって、実務とは程遠いところな気がしていて、趣味のそれこそプログラミングを楽しむことに特化した領域のように感じていたんですけど、今回の話が、思った以上に実践を重ねる人たちからの反応がもらえて嬉しかったです。

どうなんだろう、実務のエンジニア界って見たことがないからイマイチよく判らないんですけど、自分のこのプログラム言語そのものが好きみたいな方向性でも何か貢献できたりするのかなって、ちょっと感じたひとときでもありました。

iOS オールスターズ、とても貴重な機会でした

そんな感じで iOS オールスターズ 2 は、得られるものが本当にたくさんありました。

わざわざ足を運んでくださったばかりか暖かく盛り上げてくださったみなさま、楽しい時間を一緒に築けた登壇者のみんな、機会そのものを生み出してくれた dots. および 小沢さん 、滞りない会の進行に尽力してくれた 後藤さん と 並木さん 、その他 dots. に携わる全ての皆さま、そもそも登壇者として推薦してくださった方、そしてその人を推薦してくださった方、素敵な機会をどうもありがとうございました。

こんなにたくさんの人たちが織り成さなければこの日が成立しなかったと思うと奇跡的、日常って不思議だなって感じるこの頃です。

あとそう、主催中の主催の小沢さんが、会終了後に、みんなの勇姿を思いっきり褒め称えてくれたところがとても嬉しかった。そういうのが自分の、きっとみんなの原動力。どうもありがとうございました。