JOnsenでアンカンファレンスが始まるまで #JOnsenUnconf #JOnsen

ここ最近、Javaのコミュニティに出入りしているとよく聞く「JOnsen」というイベント。初めて参加しているので、ちょっとずつ様子を書き残します。

どんなイベント?

jonsen.connpass.com

温泉地に集いアンカンファレンスをする!それだけ。2017年から始まり、年1回の5月開催です。
企画や進行はStephenSebastianがオラクルの伊藤さんと一緒にやってくださっています。2年前に来日した際、北海道の温泉で思いついたイベントだそうです。
ちょうどJava Day Tokyoというカンファレンスのタイミングと合っていることもあり、海外のJavaチャンピオンやJavaエキスパートもたくさん参加します。彼らと2泊3日一緒に過ごすことができるあまりにも濃いお泊りイベントなのです。
ちなみにオラクルが宿泊費を負担してくださるので、交通費だけで最高温泉に行けちゃうんだな😉今回は露天風呂が本当に素晴らしい箱根の宿!!芦ノ湖に浸かってるみたいだったし富士山も見えました。

アンカンファレンスって何?

参加者がアイディアを出し合って、セッションのトピックをその場で決めて行うカンファレンスです。
JOnsenでは、テクニカルなトピック (Java SE 9、Javaの新しいリリースサイクル、マイクロサービスなど) も、そうでないテーマ (コミュニティ、教育、プレゼンテーション、カンファレンスなど) も扱います。誰かが資料を作って講義をするようなことはせず、皆で輪になってディスカッションする形式を取ります。


ここからはJOnsen 2018の報告です💁

オープニング

参加者が集まったら、JOnsenとアンカンファレンスについての説明がありました。
JOnsenは "The most relaxed unconference" であること、そして次のようなルールがあること。

  • 誰でも、どんな内容でも受け入れられる。ここは「安全な場所 (safe place) 」である。
  • (同時に2セッションが開催されているが、) いつでも出入りしてもう一方の部屋へ行ってよい。
  • 誰かが両手を上げたら「静かにして話を聞いてね」の合図である。

f:id:ihcomega:20180519220527p:plain:w120
大事なアナウンスをしたい1人が両手を上げだすと、皆黙ってそれに続き、話者に注目する。ディスカッションが盛り上がっていてもすぐ静かになってとてもよい。

シャイで英語に苦手意識のある日本人が多いため、「英語が母語じゃなくても大丈夫だからね、ここでは決して批判されないよ」ということがとても強調されていたのが印象的です。

さて、以上を皆が理解したら、自己紹介とトピックのアイディア出しに移ります。
f:id:ihcomega:20180519220018j:plain
輪になって、1人ずつ付箋に書いた案を説明していきます。うう、開始時、部屋がやたら暗かったのもあり写真の品質が悪い・・・

うろ覚えですが、皆が挙げていたトピックの例を。

  • プロダクション環境でのマイクロサービス(教科書的な話ではなく実践的な内容)
  • 関数型プログラミング
  • ワークライフバランス(仕事と、OSSへのコントリビュート/ コミュニティ活動)
  • 日本の小学生へのプログラミング教育
  • カンファレンスでスピーカーをするにあたって大事なこと

初JOnsenということもあり、この時点でかなり緊張していました。知らない強そうな方がたくさんいるし、英語だし、内容が適切なのかな〜とかどうしても思っちゃうし。ですが、本当に何を言っても許される雰囲気を皆が作り出してくれ、今思えば心配することは何もありませんでした。
記録も兼ねて、挙げたトピックをひとつ紹介。最近公私ともに忙しかったこともあり、持ちかけたのは「皆仕事以外で色々な活動をしていると思うけど、タイムマネジメントとかモチベーションの管理どうしてる?」といった内容です。ちょうど社会人になってOSSへの貢献が難しいと感じ始めたというきつねくんのトピックとマージされ、2日目に扱われることとなりました。
30人程度の参加者が挙げた付箋は結構な数になりましたが、タイムテーブルの決定は思ったよりスムーズでした。いい感じにトピックをカテゴライズしながら進行してくれるオーガナイザーたちの慣れが大きいですねー。

く〜ここから本編ですが、今日は疲れたし寝てしまいます😪つづく・・・
同室の人々、晩酌続けてるのか全然帰ってこない。と思ったけどまだ23時かー。

MTGにPCを持ち込まない習慣が思ったより良い

最近、ノートとペンで戦う場面を増やしている。もちろんケースバイケースだけど、自分用のメモはこれで十分、むしろプラスとなる部分が多いなと思い始めた。
それまではもうPCを触りながらMTGへ参加することに慣れきって、思考停止状態に近かったのでとても新鮮。

いいこと

  • MTGの度にPCのコード類をいちいち抜き差ししなくてよい
    • 電源アダプターとか、モニターとつなぐケーブルとか色々。地味に面倒だから嬉しい。
  • MTGに集中できる
    • これが1番大きい。うっかりSlack見たり、書きかけのコードにちょっとだけ手を入れたりしちゃわないので、集中度や理解度がアップする。
  • 図や絵も気軽に描ける
    • アイディアを出したり入ってきた情報を整理したりしやすい。
  • 後から見返しやすい
    • あの時のメモは大体この辺にあるなーとすぐ見当がつくのでよい。ファイルみたいに見つけやすいような命名を考える必要もない。もちろん検索は出来ないが、それで困るような内容のメモはない。
  • 文字を書くリハビリになる
    • これはおまけだけど、漢字忘れとかに立ち向かえている気がする。

よくないこと

あくまでPCとノートを自分なりの基準で使い分けているという前提だけど、今のところ特に思いつかない。ノートにとった記録をデータにしたい時は困るんじゃないの?という話だが、そういうときはもちろんPC持っていってその場で書いているし、ノートの写真で済む場合も結構ある。

という小さな記録でした。今日もお疲れ様です。

TrailblazerのReformを使ってRailsのフォームとモデルを分離する

これはFOLIO Advent Calendar19日目の記事です。昨日は@asuyakonoの「デザイナーの僕がいかにしてビデオゲームのUIから「インタラクション・デザイン」を学ぶのか」でした。ゲームをやらない私にとってもめっちゃ面白くて分かりやすい記事だったし、ブクマ数もすごいことになっていました。さ、さすが・・・
さて、このアドベントカレンダーは2回目の登場です。前回は割とエモい記事(証券会社のエンジニア・デザイナーが社外でも最大限活躍するためにFOLIOで取り組んでいること)だったので今回は技術的な話を・・・ということでRuby on Railsについて書きます。

FOLIOでは、サービスとして外部に公開しているフォリオのみならず、社内で証券業務を行うために使うシステムを自前で開発しています。Scala製のマイクロサービスたちがバックエンドに構えていて、そのAPIを用いて機能提供するクライアントとして稼働しているのがRailsで作られたアプリです。最近は専らそのシステムを担当しており、入社前はほとんど書いたことのなかったRubyとも仲良くやっています(たぶん)。


今回は、FOLIOでも一部導入しているTrailblazerというgem群から、Reformというgemについて調べてみました。

業務において

  • バリデーション、エラーハンドリング、エラーメッセージの指定をどのレイヤーでやるのがよいかな〜って悩んだ経験があること
  • モデルクラスにおいて、入力値(フォーム)とAPIから受け取る値の区別が曖昧で管理がしづらくなっているのを何度か見かけたこと

がきっかけです。

Trailblazerの概要

github.com

TrailblazerはRubyフレームワークに抽象レイヤーを提供するgemの集まりで、モデルやコントローラーからビジネスロジックを排除することを目指しています。純粋なRails wayでの開発にありがちなクラスの肥大化を防ぎ、メンテナビリティを上げるのに一役買ってくれそうなアーキテクチャです。
READMEも公式ドキュメントも丁寧だし、無料で手に入る情報だけで大事なことが詳しく分かります。

trailblazer.to

Trailblazerの作者が思想・使い方などについて書いた本もあって、最近気になる箇所だけつまみ食いのように読んでいます。著者も「興味のあるところから読んでね!」と言っているし、途中の章からでも理解できるような構成となっていて良いです。

leanpub.com

余談ですが、日本語の情報が少ない印象を受けますね。

Trailblazerを構成するgemたち

先程gemの集まりと述べましたが、どういったものがあるのか簡単に見てみます。

  • Operation: サービスオブジェクト。ビジネスロジックはこれに持たせ、モデルやコントローラーからは取り除く。
  • Cells: UIのパーツを表現するオブジェクト。テンプレートをレンダリングするオブジェクトとも言える。
  • Reform: モデルにバリデーションのためのフォームオブジェクトを提供する。
  • Representable: オブジェクトとJSONXMLなどドキュメント間の変換を行う(レンダリング・パース)。

その他、まだバージョン1.0の出ていないRoar、Formula、Disposableなんかもありますが割愛します。

Operationの使い方をざっと

Trailblazerの大きな特徴でありメインともいえる(個人の感想)gemです。Reformの解説でもちらっと登場するので簡単に紹介します。

Operationはいわゆるサービスクラスにあたり、ビジネスロジックカプセル化するのに有効です。サンプルコードを先に出します。

class Hoge::Create < Trailblazer::Operation

  step :process_hoge!
  step :process_fuga!
  failure :log_error!
  success :process_piyo!

  def process_hoge!
    # 処理。異常値を返したらlog_errorへ移る。
  end

  def process_fuga!
    # 処理。異常値を返したらlog_errorへ移る。
  end

  def log_error!
    # エラーハンドリングの処理。前段の処理でトラックが左側に移ったら実行される。
  end

  def process_piyo!
    # 処理。前段の処理でトラックが左側に移っていなければ実行される。
  end
end

ビジネスロジックを処理のまとまりごとに分け、それぞれメソッド(上の例で言うとprocess_hoge!とかlog_error!とか)として定義します。

http://trailblazer.to/images/diagrams/overview-flow-animated.gif
※公式(Trailblazer: Operation Overview)より

メソッド化した各処理は左右2トラックのフロー(パイプと呼ぶらしい)に分かれ、正常系では右側のトラックを上から実行していき、異常系に遷移したら左側のトラックへ移ります。定義する際に step, success, failureといった3つのAPIを使い分けることでどちらのトラックに配置するかを指定し、意図した順序で呼び出すことが可能です。

  • step: 処理を右側のトラックに置く。異常値を返す処理が実行された時点で、パイプが左側のトラックへと移る。
  • success: 処理を右側のトラックに置く。処理の返却値は考慮しない。
  • failure: 処理を左側のトラックに置く。エラーハンドリングが目的。処理の返却値は考慮しない。

ネストが減ってフラットに処理が並ぶので流れを追いやすいし、正常系・異常系に分けて考えられるので分かりよいです。

Reformの使い方をじっくり

さて、この記事の本題へ。

特徴

Reformは先に書いたとおりバリデーション用のフォームオブジェクトを提供します。

  • フレームワークに依存せず、Rails, Sinatra, Hanamiなど多くのプロジェクトで使える
  • データベースは意識しないので、どんなORMと一緒でも使える
  • データベースアクセスはせず、モデルのプロパティの書き込み・読み込みのみ行う
  • モデルをフォームオブジェクトにマッピングすることが出来る

といった特徴がありますが、このあとの使い方を見てしまった方が理解しやすいはずです。

使い方

なお、ここからはビールが当たるキャンペーンの応募フォームを想定して話を進めます。画面の構成要素はこんな感じ。

  • 名前入力用テキストフィールド
  • 住所入力用テキストフィールド
  • あなたは20歳以上ですか?確認用チェックボックス

f:id:ihcomega:20171219095553p:plain ※イメージ

定義

ではコードと一緒に使い方を見ていきます。
Reform::Form を用いてクラスを定義するところから。フィールド定義はproperty, collectionというキーワードで行い、バリデーションもこのクラスで指定します。

class ApplyBeerForm < Reform::Form
  # フィールド定義
  property :name
  property :address
  property :over_nineteen
  
  #ActiveModel::Validationを用いたバリデーション
  validates :name, presence: true, length: { maximum: 20 }
  validates :address, presence: true, length: { maximum: 100 }
  validates :over_nineteen, acceptance: true
end

バリデーションの定義はActiveModelの他にdry-validationも用いることができるようです。というかActiveModelは非推奨となっている模様ですね・・・(詳しくは: installation)。

なお、オペレーションの中ならcontractを定義してやるとReform::Formインスタンスが生成されます(詳しくは: validation)。

contract do
  property :name
  property :address
  property :over_nineteen
  
  validates :name, presence: true, length: { maximum: 20 }
  validates :address, presence: true, length: { maximum: 100 }
  validates :over_nineteen, acceptance: true
end

Reformはフォームとモデルを分離する仕組みを取り入れている(詳しくは後述)ので、両者を別物として扱うのが比較的容易です。そのため、例えば「フォームには存在するがモデルには不要な値」なんかも自然に定義出来て便利です。この例だと、20歳以上かのチェックがそれに該当しますね。

インスタンス生成

コントローラーかオペレーションでインスタンスを作ります。
まず、Applicant(応募者)インスタンスを新しく作ってフォームインスタンスに渡すパターン。

@form = ApplyBeerForm.new(Applicant.new) #モデルのインスタンスを生成して渡す

続いて、作成済みApplicantを渡すパターン。渡したインスタンスは編集対象となります。このとき、Reformが既存のApplicantインスタンスに1度だけアクセスし、値を読み込んでくれます。

@form = ApplyBeerForm.new(Applicant.find(1)) #findしたモデルのインスタンスを渡す

バリデーション

#form_forとかを使ってフォームインスタンスレンダリングしたのち、validateメソッドを呼び出します。バリデーションの対象はフォームオブジェクトのフィールドとして定義した値のみで、それ以外が渡された場合は無視されます。

if @form.validate(params[:applicant])
  @form.save #後述
else 
  #エラーハンドリングする
end

バリデーションの結果、問題なかった場合はフォームに値が反映されます。一方、バリデーションエラーとなったら、errorsがエラーメッセージを返します。
重要なのは、値が有効で無事フォームの値が更新されたとしても、モデル側(ApplicantModel)にはまだ変更が入らないことです。

モデルに反映・永続化

インプットをモデルにも反映するには、#save#syncを呼び出します。これにより、Reformがモデルのsetterを使って値を書き換えにかかります。

@form.save #モデルに反映し、永続化する
@form.sync #モデルへの反映のみ行う

バリデーションが終わり、明示的にメソッドをコールするまではモデルの更新が行われないというわけです。フォームとモデルが、意味的にも実際の挙動としても綺麗に分かれてくれていることがよく分かりましたね。

順番をおさらい

Reformの使い方を追ってきましたが、流れをまとめるとこんな感じです。

  1. 定義
  2. インスタンス生成
  3. バリデーション
  4. モデルに反映・永続化

この手順を踏むことについて、Trailblazerの作者は「やることが多くて面倒だと思うかもしれないけどシンプルなんだよ」みたいな予防線を張ってますが、自分は割とすんなり理解・納得できました。

ちなみに、序盤でフォームの扱いに悩んだことがあると書きましたが、最近フォームを扱う画面を作る際は

  • フォーム用モデル(Reform::Formではなく、form以外のモデルと同様に定義している)をつくって、そのクラス内でバリデーションする
  • オペレーションにてバリデーション結果をチェック(し、エラーハンドリング)する
    • バリデーションにひっかからなければ右側のトラックで次のステップへ進む
    • ひっかかれば左側のトラックへ移り、エラーメッセージをコントローラーへ返す

こんな感じにしていて、これはこれで割といい感じにまとまりつつある気はしています。ただ、Trailblazerだけで教科書通りやるとこうなるんだなーという学びは面白かったし、フォームもモデルも複雑な画面で使うとどうなるのかしらという思いがあるので、業務でもちょっと試してみたいです。


Trailblazer、FOLIOでは主にAPI呼び出しに関連する部分から徐々に取り入れています。そういった部分的な導入により既存コードのリファクタリングをしていく方針を作者も良しとしており、本でも推奨されています。それもあってRails wayとの共存がしやすい作りになっており、導入しやすいのもメリットかなぁと思います。
機能はまだまだたくさんあるし、また何か困ったことがあったらちょっとずつ試してみたいなーと思います。自分が担当しているシステムはドメイン知識もたくさん要求されるし複雑な部分もあるので、せめてアーキテクチャは工夫してメンテしやすさを追求していきたいものです💪

モデリング言語の魅力を知り、快適な図示ライフを送ろう

これはGeek Women Japan Advent Calendar 7日目の記事です(大幅納期遅延ごめんなさいごめんなさいごめんなさいごめんなさい)。

物事を理解するためのアプローチには色々ある中で、自分は割とを大事にしています。よく「人に説明出来てこそ本当に分かったとみなせる」とか言う気がしますが、言葉での説明のみならず、理解した内容を頭の中で図示出来るかを考えることが多いです。wikiを書いたり、プレゼンで何らかの概念を説明したりするときも、チャンスがあれば内容を噛み砕いて図を入れるようにしています。
個人的には、全体をパッと把握することも部分にフォーカスすることも可能な一枚絵で表現するのが好きです(上手に出来るとは限らない)。

さて最近、ちゃんとルールのある図…というか所謂モデリング言語を学ぶことが面白いし、何より便利だと感じています。今更かよとは思うんですが、以前は超オリジナルなお絵かきか、クラス図、フローチャートくらいしか使ってこなかったんですよね。それ以外は正直「納品のために整理するドキュメント」みたいな良くない思い込みのもと、価値も分からぬまま敬遠(反省)。しかし、図を描くのはゴールではなく目的を果たすための手段だと実感して以来、態度を改めました。

というわけで、モデリング言語について個人の感想レベルですが綴ります。


まずモデリング言語とは何ぞやという話ですが、とりあえずWikipediaを覗く程度としましょう。色々あるなぁ・・・VRのとかもある。Javaモデリング言語っていうのもある。へぇ・・・
モデリング言語 - Wikipedia

良いところ

積極的に使うようになってから感じたうまみを挙げてみます。

  • 作業の本質だけに時間を割くことが出来る
    表現の仕方やレイアウトを考える時間が無駄なケースってありますよね。モデリング言語の本来の目的と自分がやりたいことがぴったりマッチした場合とか、見せ方にこだわる必要がさほどない場合とか。そんなとき、ルールが決められている記法に頼ってしまえばすぐに手を動かせます。設計なら設計そのものだけに時間や労力を費やせますね。
  • 誰にでも分かる
    図を共有さえすれば相手がすぐに理解できるのはとてもよいです(まぁ標準化ってそういうことなんだけどw)。メンテする人を選ばないのも利点ですね。独自ルールで書かれた図はどうも他の人が手を入れにくいものです。
  • ツールが豊富である
    ユーザーが多く、広く普及したモデリング言語だと特に、便利ツールも色々あります。例として、愛用しているPlantUMLを後ほど挙げてみます。
  • 先人の知恵がつまっている
    経験値や知恵の蓄積によって練られた記法なので、上手く使うと便利です。ここぞというときに活用出来るようにしておくと頼もしいのは自然なことですね。

付き合い方

いつもこんな意識で使ってるよーという話もしておきます。

  • 学習コストを恐れない
    モデリング言語には分厚い仕様があったり、いつ使うねんっていうコンポーネントが存在したりするもので、一見複雑に見えることもあります。しかし、自分の表現したいものが必要とするのはきっと一部。見よう見まねで使ってみたら手に馴染むかもしれません。
  • 使う図に迷ったら、まずラフに描いてみる
    何かを図示しようと意気込んだ時、「この内容なら使えるモデリング言語あるかも!?」という直感が働いたらとりあえずググってみましょう。使えそうなものが運良く見つかったら、途中までざっくり描いてみるとよい気がします。複数候補がある場合の比較にも使えます。自分はnu boardを使ってお絵描きしてみることが多いです(FOLIOではnu boardが流行っている・・・というか結構多くの人が持っていて、影響を受けて購入した)。
    例えば、会社で某承認フローを分かりやすく表現したくてスイムレーンを採用したことがあるのですが、そのときはまさにこんなプロセスを踏みました。
  • レイアウトにこだわる余地があればこだわる
    格通り描くものの、色とか文字の大きさを使い分けることでより効果的な図に出来そうだったらトライしています。

仕事での活用例

仕事では主にUMLやBPMNを使う日々('ω')せっかくなので図の活用例とツールを紹介してみます。

シーケンス図を用いてコミュニケーションすることがこれまで何度かあったのですが、そんなときに同僚たちの真似して使い始めたPlantUMLというツールがとても便利です。

PlantUMLを使うと、こういうDSL(書き方は公式を参照してね)を描けば

@startuml beer.png
actor よこな as yokona
participant 注文用タッチパネル as orderMachine
participant コックさん as cook
participant ウエイター as waiter

loop
yokona -> orderMachine: 注文🍺
note left: 飲みたい
orderMachine --> yokona: 注文結果
orderMachine -> cook: 注文内容
cook -> waiter: 料理🍺
waiter --> cook: 了解
waiter -> yokona: 提供🍺
end
@enduml

画像を吐き出してくれます👏
f:id:ihcomega:20171210133409p:plain

処理が複雑だとか、整合性を担保するため情報を整理したいとか、理由は色々ありますが開発者が必要だと思ったらシーケンス図を描くことが割とよくあります(強制ではなく都度判断している)。コードを書き始める前にシーケンス図だけレビューして認識をすり合わせると手戻りやバグの防止になってよいです。pumlファイル自体はテキストなのでGitで差分も見られるし。
あとはユニットテストを描く時網羅性の確認に使ったりもします。簡単に言うと、全部の矢印に大してテスト書けてるかなーとかalt網羅してるかなーとかチェックする感じです。これもわざわざ改めてパターンを洗い出す必要がなくて便利だなーと思ったことがあります。

ちなみに私はIntelliJ IDEAにPlantUMLプラグインを入れて使っています。

編集中はリアルタイムに図が表示され続けるし、
f:id:ihcomega:20171210133434p:plain

文法の間違いにもすぐ気付くことができます。
f:id:ihcomega:20171210133454p:plain

PlantUML、社外のエンジニアお友達に聞くと意外と知られていなかったりするみたいなので、本当にライトですが紹介してみました。クラス図や状態遷移図など、他にも色々描けます。

適材適所('ω')

ところで、当たり前ですが全ての図という図をモデリング言語で表現したいわけではなくて、大事なのは使い分けです。オレオレ記法の方が目的を達成する近道だと判断したならばそれもよいと思います。

不要なコストをかけずに、伝わりやすい表現ができるのは何か?というのを考えて、最適と思われる選択をしていきたいものですね。知っている図は活用しつつ、時々新しい図もインプットしながら華麗な図示ライフを送りましょう💪

証券会社のエンジニア・デザイナーが社外でも最大限活躍するためにFOLIOで取り組んでいること

これはFOLIO Advent Calendar1日目の記事です。

株式会社FOLIOというテーマ投資型オンライン証券サービスを提供している会社でバックエンドエンジニアをしています、よこなです。
会社のことをブログに書くのは5月の入社エントリ(リンク)以来。おかげさまで入社して半年以上たちました!毎日クソ楽しいです。自慢。

今日は入社以来開発の傍ら取り組んできたFOLIOブランディングについて書いてみます。「ブランディング」が何かはこのエントリ内で徐々に明かしていきますが、OSSに貢献したりイベントで登壇したりQiitaに記事を書いたり、そういった「社外でのアウトプットに関するなにか」だと思って読み進めていただければ幸いです。設立2年目のスタートアップということもあって、いけいけどんどんの精神でがむしゃらに活動しています!という話ではありません。既視感ある内容だと侮ることなかれ・・・我々はスタートアップ企業であると同時に証券会社なのです。そんな金融機関ならではの一味違うチャレンジについてご紹介します!

ちなみに私、19日(火)もこのアドベントカレンダーに参加しており、そちらでは技術の話をする予定です。

クリエイターブランディングのこれまで

まずお伝えしておきたいのですが、FOLIOではものづくりをしてユーザーに価値を届ける存在、すなわちデザイナー・エンジニアをあわせて「クリエイター」と呼んでいます。

立ち上げ - FOLIOメンバーが活躍している場を知るところから

同僚の伊藤 (@itohiro73)と、「クリエイターの対外発信、推進していきたいね〜」とか「FOLIOでもエンジニア向けイベントやりたいな」とか言いつつ行動しだしたのがことの始まりです。

ちなみに推進と書きましたが、「もっと外へ出ていこう」「アウトプットしてみよう」といったはじめの一歩を支える働きかけみたいなことではありません。それをするまでもなく、イベントで登壇したりブログをバズらせたり本を出したりと、FOLIOのクリエイターたちは社外でも活躍している状況でした。なので、そういった個々の活動を会社のイベント*1と連動させてより大きくポジティブな効果を生み出すとか、イベントのスポンサーシップや個人へのインセンティブなどで支援すべく制度を整えるとか、戦略的に動く組織を作るイメージでした。

はじめは伊藤と私というJavaコミュニティ寄りな人間だけの組織だったので、その他インフラ、フロントエンド、iOSAndroid、デザイン、サイエンス担当のクリエイターたちにランチを食べつつヒアリングするところから始めました。コミュニティやイベント事情、OSSのこと、情報収集でどんな人やサイトをウォッチしているかなど、色々教えてもらったのを覚えています。
ブランディングを手探りでスタートして分からないことだらけな上に、入社したばかりでまだ皆とのコミュニケーションにぎこちなさも残っており、毎回緊張しながら臨んでいた記憶が・・・。でも、未知の世界だったデザイン界隈やサイエンスのことを知れたり、皆の思いが聞けたり、今考えても貴重な場だったなぁと思います。ちなみに、FOLIOアドベントカレンダーをやろうという話があがったのもフロントエンドエンジニアとランチした場でした。

皆に聞いた話を参考にしつつ、まずはカンファレンスレベルの大きめなイベントをウォッチするところから始めました。あとは、自分の専門外のイベントであっても社員が登壇する時は足を運んでみました。ブランディングとして出来ることは様々ですが、技術イベントは入り口として自分に合っていたためです。準備なしに参加できるし(運営・登壇者のみなさまありがとうございます・・・)、雰囲気を掴むのにちょうどよいし、元々コミュニティ運営をやっているのもあってイベントが好きだし。抵抗なく取り組めるところからやっていったのは今思えばよかったです。活動を継続できている理由にもなっている気がします。

徐々にFOLIOからの発信も増加、反応も上々

もはや何がきっかけだったかも忘れましたが、FOLIOがメインで進める発信にも取り組んでいきたいねという声が挙がるようになってきました。入社して2ヶ月もした頃には「ブランディング」という言葉も社内で広がりつつあったし、クリエイターブランディングチームとして定例MTGを始めたりもして組織らしくなっていきます。メンバーも増えた上に、人事やマーケティング担当も巻き込んで、色々やれるようになりました。

FOLIOからの発信でどんなことをやってきたかについては、実際にものを見ていただきたいです!

Wantedlyでのクリエイターインタビュー記事

いろんなチームのクリエイターに、取り組んでいる仕事や大事にしていること、ビジョンなどについて存分に語ってもらう記事です。人事担当と協力して作ってきました。メンバーの個性がよく出ているし、FOLIOで働くことのイメージが伝わりそうな、個人的に気に入っている企画です。

www.wantedly.com
www.wantedly.com
www.wantedly.com

reladomo-scalaというOSS

FOLIO初のOSSです。
github.com

次の記事に詳しく記載していますが、開発秘話や機能については社外のカンファレンスで語られたこともあります。
www.wantedly.com

そんなこんなで色々試みていますが、最近我々の発信が届いているなーと感じさせるエピソードも出てきました。採用面接にお越しの方が「記事を見て興味を持った」とおっしゃってくださったり、エンジニアの友達が「Reladomo面白そうだね」と声をかけてくれたり。嬉しいことですね。

衝撃の事件

順調に手を広げながら挑戦を続けていたのですが、とある事件が起こります。
技術イベントで会社としてノベルティを配ろうとしたところ、コンプライアンス部からストップがかかったのです。別におかしなものを配ろうとしたとか、道徳的に良くないアイテムを用意したとかではありませんwクリエイターにとっては至って普通の、FOLIOオリジナルグッズでした。

何やら急に出てきたコンプライアンス部って?馴染みのない方もいらっしゃるかもしれませんが、法令違反のリスクなどを未然に防止し、経営や組織の健全性維持のため存在する部署です*2

さて、肝心のノベルティ待ったの理由は

「広告」に該当する可能性があるため、金融商品取引法等の規定に抵触していないか審査の必要がある。

ということでした。

???

法?規定?????

驚きました。

いやいやそんなこと言われても、エンジニアやデザイナーのイベントで法律まで意識するとか聞いたことある?どこがダメ?なんでダメ?広告だなんて、そんなつもりないからセーフでしょ。
色々な思いと言い訳と疑問とが浮かんできたのを覚えています。そして、それを持ち出してコンプライアンス部を説得・・・というか論破すればなんとかなるもんだと思っていました。

しかし審査の結果どうにもならず、そのときはノベルティを配ることを断念。当時は正直全然納得がいきませんでしたが、金融機関における「コンプライアンス」の存在が自分の中で大きくなり始めた出来事でした。おそらく他のクリエイターたちにとっても同じだったはず。

必死に環境整備する今日このごろ

先に述べた事件は衝撃が大きく印象的であったものの、何も急に厳しいことを言われたとか、いきなり禁止をつきつけられたとか、そういうわけではありません。FOLIOは創業当時から、ノベルティ配布に限らずコンプライアンス部による社外活動の管理を行ってきています。

一方で、管理体制があるのみでクリエイター側の理解は十分でなく、そこに改善の余地があるのも事実でした。門外漢なのでよく分からないけどコンプライアンス部の言うとおり動くしかないな・・・という状態(ノベルティを諦めたときは正直そんな感じだった。今これを読みながら、なぜかノベルティ配布を禁止されたっぽいな?どういうこと?って思っているあなた、その感覚です)は望ましいものではないので、クリエイターも法令遵守の意識をきちんと持った上で、適切な判断が出来るような仕組みづくりこそが必要でした。

こうした課題をふまえ、最近は目下そういった整備に取り組んでいます。ルールをメンテナンスしたり、その背景や考え方などを正しく伝えるための研修を行ったり、 クリエイターからの疑問に答えるべく有識者への確認や調べ物を行ったり・・・。

技術コミュニティで「金融機関に勤めながら、全社を巻き込んで対外活動に向けた取り組みをしています!」というような方には会ったことがないし、私のキャリアに証券のバックグラウンドは一切ないし、新しいことだらけ、戸惑いだらけです。でも、「資産運用をバリアフリーに。」というミッションで「金融の難しさ」を取り払うことを目指す我々にとっては、これも宿命といえるべき挑戦だと捉えています。入社前は、半年後に自分がこんなことしてるなんて予想もしていませんでしたがw

Advent Calendarも証券会社としては新しい取り組みであり、こうして形になって、25日間完走を目指す段階に至ることが出来たのはとても嬉しいことなのです。いやぁほんとうに。

なお、法令遵守の環境整備といっても、ただ制約を課す、活動を制限するといったものではなく、のびのび情報発信できる環境を目指しながらも「絶対にこれは守らないといけないよね!」という意識や自覚が皆の中に根付くような取り組みを目指しています。究極の理想形までの道のりは険しそうですが、協力者としてコンプライアンス部がいてくれるので少しずつ前進中です。同じインプットに対し必ず同じアウトプットが返ってくる関数が大好きなエンジニア脳にとって、「法解釈」というものはなかなか理解が難しいですが、ちょっとずつ考え方も学んでいます。

今は少なくとも、ノベルティにNGが出たとき真っ先に思った「コンプライアンス部を論破」しようという思想には至らなくなりました。月並みですが、歩み寄ってこそ会社としてのパワーが発揮されるからです。たとえ社員を論破したところで、我々が対峙するのは法律であり、国なのです。大きい・・・!同じ方向を見て力を合わせようとするのが、証券会社のブランディングチームとして大事な心構えかなぁと思っています。

知っていることも、大事にするものも、これまでの働き方も、すべてがあまりに違う者同士で協力するのは面白くもあり、難しくもあります。でも順調に、知らないところをカバーし合い、文化の違いも考慮しながらポジティブに頑張っているところです。例えばコンプライアンス部のメンバーがSlack、Confluence、GitLabなどを覚えて使ったり、クリエイターが証券外務員の資格を取ったり、法律を学んだり。

そんな中、ブランディングというミッションをいかにスピーディかつ効果的に遂行するか、そこがブランディングチームの腕の見せ所です。とにかく我々に何が出来るか?どうやったら上手くいくか?頭の回転を止めず、諦めず、考え抜くことを大事にしたいです。まぁ弊社のクリエイターたちはおかしいと思ったら何でもズバズバ言ってくれるので、意味のないことや効率の悪いことをやろうもんなら皆が軌道修正してくれる安心感もありますw

なぜ続けられるのか

色々書いてきましたが、ぶっちゃけ、なんかめんどくさそうですよね。法律なんて、聞いただけでぎょっとするし。一体なんでそんなことまでして・・・と思う方も多いのではないでしょうか。自分も(良くも悪くも)ゆるふわweb系エンジニアであることに慣れていたので、外野だったらそう感じていたに違いありません。

なぜやるか。それはただFOLIOが魅力的で、挑戦したいと思うからです。FOLIOは代表の甲斐が公言しているくらい、クリエイターを大事にしてくれる会社です。それぞれが抜きん出て得意なことを持った、魅力的なメンバーが集っています。それは私が語るまでもなく、きっとこのあとに続くAdvent Calendarの記事をご覧いただければ伝わるはず。

そんなFOLIOメンバーの面白さとか、よいサービスを全員が真剣に考え高いスキルをもって作り上げようとしている会社なんだなーってこととか、その他あれもこれもいろーーーんなよい側面がもっと広がっていったら嬉しい!そんな思いで挑戦するクリエイターブランディングチームなのでした。

さきほども述べましたが、証券会社によるAdvent Calendarはきっと前代未聞!?25日間ぜひぜひチェックしてくださいな〜!!!


全てが挑戦続きのFOLIOは、一緒に働く仲間を全力募集しています!

私がいるバックエンドチームの求人はこれ:
www.wantedly.com

他にも幅広く募集しています:
www.wantedly.com

まずはぜひ遊びにお越しくださーい!(最近移転もしたよ: FOLIO Office Tour @半蔵門 | 株式会社FOLIO)

以上、お付き合いいただきありがとうございました。明日はchocoiさんの「AWS Direct connectの利用に関して」です!

*1:例: サービスのローンチ、業界にインパクトあるメンバーの入社

*2:そもそもコンプライアンスとは、経営や組織の健全性を維持するために、法令や諸規則に基づき、ルールが制定された趣旨や背景を十分に熟知し、それらを遵守し実践していくこと

JJUG CCC 2017 Fallで基調講演する機会をいただいた #jjug_ccc #ccc_e1

11月18日(土)、ミッキーさんの誕生日にJJUG CCCを開催しました。

転職したての頃からJJUG幹事業はお休みモードにさせてもらっていたので、今回運営にはほとんど協力できておりません。ぼちぼち復活していきたいな・・・

しかし、基調講演という大きなミッションをいただくことが出来たので、そちらには全力投球しました。


幸運にも新卒1年目のときにコミュニティと出会い、会社にいるだけでは出来なかったであろう色々な経験をしてきた身として、これまであったことや思っていることを伝えたかったセッションです。ギリギリ若手を自称できる(?)今だからこそできる話をしてきました。
資料は公開しているものの、語った言葉こそが大事なので、とにかくご参加いただけた方が少しでも楽しんでくださっていれば幸いです。朝早くからありがとうございました。


(こちら嬉しいツイートオブザイヤー受賞)

そのあとはちょっとだけ幹事の仕事もしましたが、15時くらいから抜歯のため1度抜け(抜歯だけに)、戻ってきてマスクのまま懇親会を楽しみ、二次会には出ず直帰して1日を終えました。お酒が飲めず我慢している私に「アルコール消毒しよう」と言ってくる大人がたくさんいるJJUGが大好きです( '_' )

ということでこれまでと比べたらあまり参加した感がないのですが、色々な方に会えたよい1日でした。
幹事、ボランティアスタッフ、登壇者、参加者のみなさん、本当にありがとうございました。お疲れ様でした。また半年後!

仙台IT文化祭のため初めて仙台に行った #sendaiITfes

10月28〜29日の2日間、仙台IT文化祭なるものに参加し、人生で初めての仙台へ。昔から関東より北の地域とは疎遠なんですよねぇ。こんな機会でもなければまだしばらく訪れることがなかった気がします。

今回は、Java女子部でお子さん向けのプログラミング基礎講座をやるのが主な目的でした。それ以外の時間は頑張ってセッションを聞くわけでもなく、ただ仙台での休日を楽しめればいいや〜とゆるふわな過ごし方を選びました。結果、食い倒れ1人旅になりましたが、ノープランだった割にそこそこ満喫した気がします。ということで雑にようすをメモ。

Java女子部の登壇

「ゲームで学ぼう、プログラミング!」ということで、遊びながらプログラミングの考え方(変数、座標、繰り返し、条件、配列)を学んでもらいました。対象年齢は小3くらいで、それに合わせてスライドも小3までに習う漢字しか使わないという小さな工夫をしていたのですが、その作業をするたび自分が習ってない漢字や公式を乱用したがる小学生だったことを思い出しました(どうでもよい)。

お子さんたちみんな、2時間弱のセッション中ずっと一生懸命取り組んでくれて、よい刺激を貰いまくりました。単純に子供らしさに癒されたり、夢中になる姿にぐっと来たり、最近忘れていた何かを取り戻したように思います。

あと、参加者の1人がセッション後にてらださんと会話している様子が印象的でした。その子はプログラミング経験者で、我々の提供した課題も物足りなかったらしく裏メニューをやってもらっていたほど。自分が取り組んでいることを仕事にしているプロとおはなしする機会って、普通に小中学生やってるだけじゃなかなかない気がするんですよねぇ。学生さんやお子さんを大事にしているこのイベントの良さを感じさせる一幕でした。

まーやさんの登壇

まーやさん、この長さの技術セッションは初とのこと。でも落ち着いていたし、JShellを使ったデモもスムーズでしたねぇ。お忙しい中の準備、本当に大変だったんじゃないだろうか・・・お疲れ様でした!

唯一興味駆動で聞いたセッション

楽天さんのおはなしを聞いてきました。

togetter.com

キャラクター大好き勢としてはとても興味深かったです。こういう仕事やってみたいw

ごはん

あとはひたすらご飯を貼りつつこのエントリはおしまいにしまーす。

まずは東北大学の学食。これしか食べるものなかったんや・・・

お次。仙台初心者にはマストな牛たん。なんか量多いしカウンターでカップルに囲まれるし1人なのがとことん辛かったけど、たたきは感動的に美味しかった。



牛たんのあと、偶然ふじたくさんも仙台にいることが分かったのでちょっとだけ一緒に飲んだwハロウィン仕様でわちゃわちゃしており知らない人とも結構話した。

ラスト飯、会社の先輩に教わったコスパ最強寿司。マグロの頭肉よかった。

そして、まったく期待してなかったのに本当に美味しかったずんだシェイク。1人でいたのに「えぇっ美味しい・・・」って声出た。

帰りの新幹線も大事。しかしビールは普通だったな。ほやはもっと美味しいやつを食べたかった。

以上。

仙台IT文化祭、今年始まったイベントだと思うのですが、初回とは思えないほど元気なイベントでした!参加者も多く登壇者も豪華、おまけに景品が最高な抽選会(何も当たらなかった)まであってすごかったです。運営のみなさんには頭が上がりませんね。本当にお疲れ様でした―!!!また参加したい💪

あと大学生になって青春したい