TechとPoemeの間

Qiita に書かないエンジニア業の話

「玉子屋」の動画から見る「リーン」や「フロー効率性」

職場にてメンバーの持ち回りでやってる勉強会があるのだけど、自分の番が回ってきたので、かつての職場でやったように フロー効率性とかリーンの話を取り上げた。かつてはホワイトボードを使っていたけど、再現性と今後の内容のアップデートを出来るようにスライドを作った。2年前よりも内容についてしっくりと来ているなぁと実感出来ている自分がいた。 docs.google.com

リーンを突き詰めた弁当屋「玉子屋」

最後に参考のページとしてリンク集を設けたのだけど、特に仕出し弁当屋「玉子屋」の生産、配達プロセスはこのフロー効率性の観点から見るととても興味深いので紹介したい。 (テレビの動画のアップロードなので、もし削除されていたら検索してほしい)

www.youtube.com

いつの動画なのかわからないのだけど、玉子屋のビジネス成果として、この動画では以下のように紹介されている。

  • 1日の平均販売が6万食
  • 廃棄率0.1% (コンビニ平均は3%)
  • 原価率50%以上 (業界平均は言及されていないが、原価率の高さは販管費に無駄がないことを表す)

動画から読み取れるプロセス改善の工夫

リーンの原則から見ると、教科書的なアプローチを弁当の生産と配達という分野でどう適用しているかが伺い知れる。自分が解釈したのは以下のような点だ。

  • 1日のメニューを1種類に絞る (flow unit のばらつきを無くす)
  • ベルトコンベアを用いてラインの流れを一定にする。 (ステップごとのばらつきを抑制する)
  • ベルトコンベア内での作業内容が均一になるように材料配置のプロセスを分解する (ステップごとのばらつきを抑制する)
  • 曜日/天気等で需要を予測する。 (需要の予測可能性を上げる)
  • 10食以上の法人注文のみを受け付ける。 (需要の予測可能性を上げる)
  • 需要予測が立つことで、生産完了を待たずに配達便が出発できる (ステップ感の依存関係を断ち切る)
  • 注文数量確定後に追加製造、調整便を出す (供給の調整可能性を高める)
  • 作るだけでなく、顧客分析までをパイプラインに組み込む (なるべく広い全体最適を模索する)
  • 配送担当が市場調査担当 (聞き込み、食べ残し分析) を兼ねる (多能工化する)

こういうケーススタディというか、教科書と現実を繋ぎながら頭を使うのも大事だなーと思った。

自社イベント「Scramble!!」にて FOLIO のプロダクト開発について話しました #folioScramble

FOLIO では不定期で自社イベント「Scramble!」を開催しているのですが、昨日行った「Scramble! #3 FOLIO流 複雑なドメインとの戦い方」にて、「ありふれたもの、未だ見ぬもの: FOLIOプロダクト開発の現場から」というタイトルで 20min の発表を行いました。

タイトルはどう付けたら良いのか迷いに迷って変なものになってしまったのですが、要は「複雑なドメインの取っ掛かりの作り方っていくつかあると思うけど、コモディティであるものとオリジナリティのあるものに分けていい感じにアプローチしようよ」ということです。

後半の『どこにもない「テーマ投資」』のセクションでは、社内のメンバーがコラボレーションしている様子の写真も公開したのですが、こちらの写真は会場限定とさせてください。もし気になる方がいらっしゃったら、ぜひ弊社に遊びに来ていただけると嬉しいです。

およそ40人前後の方に来ていただいたのですが、中には以前証券会社で働いていらっしゃったり、現在進行系で金融系サービスのシステム開発に携わっている方もいらっしゃいました。

私のセッションでは、「すでに体系化された業界標準は正しく理解して実装する」「自分たちが作り出すオリジナリティは広い視野でコラボレーションしながら取り組む」という話をしたのですが、セッション終了後の懇親会では、この2つの見境をつけるのが難しいケースもあるよね、という話があり、興味深かったです。FOLIO のテーマ投資はわかりやすい独自性があるからこそ、この2つをそれぞれ意識することが出来るのかもしれません。

今回の Scramble は、テーマが「ドメインとの戦い方」と決まると同時に、「主軸は最近注目を浴び始めた Event Storming にしよう」という流れがありました。最近の FOLIO のシステム開発は、プロダクトをそのものをチームと、プロダクトを横断した「基盤」を取り扱うチームに大きく分かれています。Event Storming について発表した奥田 (id:yoskhdia) や横田 (id:ihcomega) は顧客基盤という基盤系のチームに属しているので、もう1セッション、プロダクトチームの事例紹介をすることで聴衆の方々に FOLIO の取り組みを幅広く知っていただくことができたらな、というのが今回のイベントの全体像でした。

セッション数の観点で Event Storming の間に挟まって自分のトークが浮いてしまうのではないかと心配もしていたのですが、蓋を開けると「いろんな立場の人で協力する」「新しい知識を作り出す」「知識の分散化に立ち向かう」など、共通して言及する問題意識も多く、1時間半にも満たないあっという間ではありましたが、FOLIO の今がリアルに伝わる会だったのではないかと思います。

そんな FOLIO では一緒に働く仲間を募集しております。また、Scramble には参加できなかったけどもっと詳しい話を聞きたい！という方もぜひ遊びに来てください。

hrmos.co

hrmos.co

hrmos.co

(他にもいろんな職種があるので 募集職種 | 株式会社FOLIO をチェック！)

ざーっと振り返る2018年

みんなが書いているから自分も書く

1月

前職で働いていたのだけど，12月の段階で後輩たちをはじめ，周囲には退職の意向は伝えていたので，ひたすら自分の知っている知識を伝授していた．1月にやったのか12月だったのか覚えていないけど，後輩2人と一緒になって スクラムガイド を全部音読したのは，学びも多かったし楽しかったなぁ．

その伝授の過程で教えたこととか，チームで編み出したやりかたとかブログにまとめてたりもした．この勉強会 あたりからアドテクスタジオ内のゼミのメンバーにも参加してもらったり，それがきっかけで他のプロダクトの勉強会に呼んでもらえたりした．

t-and-p.hatenablog.com アドテクスタジオは，どこもかしこも振り返りといえば KPT くらいの勢いだったのだけど，それに違和感を覚えていた自分が昨年末くらいから編み出していた名もなき手法*1をまとめてみたりもしていた．

ちょっと話が前後しちゃうのだけど，2月に FOLIO に入ってみたら，僕のブログを読んだバックエンドエンジニアのチームがすでにこの手法を取り入れていたり，最近はモバイルアプリを開発しているチームとかが使うようになって，普段あまり一緒に仕事しないメンバーから「あれってむらみんさんが考えたやつなんですか？」とか言われたりしたり，発信冥利に尽きるような反応もたくさんあった．

RSGT2018 行った．昨年は部分的にしか行かなかったけど，2日間どっぷり浸かれてよかった．

t-and-p.hatenablog.com

そういえばこの時期からホットヨガに通うようになった．ジム通い半年くらいしなくなってた頃だったのだけど，単に筋肉鍛えるだけでは出来ない動きもできるようになったなぁと今になると思う．

2月 ~ 3月

FOLIO に入った．今でも同じこと思っているけど，本当に周りのメンバーの知識のレベルとか高くて，いろいろ大変なことも多いけどめちゃ楽しく仕事してます．

入って2ヶ月くらいは，普通の開発仕事もしつつ，スクラムとかフロー効率とか「アジャイル」という文脈で出てくる知識の啓蒙とかも進めてた．

4月 ~ 8月

この時期は仕事が大変だったのでアウトプットほぼなし… 仕事何してたっけな… いろいろやってたけど正直あまり成果が出せなくてもどかしかった時期です．

そんな時期にインタビュー受けてました． press.forkwell.com

9月 ~ 12月

会社が新しいプロダクトのサービスを始めたり，いろんなステークホルダーとのコミュニケーションが絡まりきってて成果までのスループットが出てないなぁという課題に直面し始めてきて，それまでよりも大きな範囲の仕事をさせてもらえるようになった．それの話をまとめたのが今月の2本のブログです．種を撒いて成果が出るまでどれくらいの時間が必要かわからないけど，来年はこれの続きをちゃんと自慢できるようになりたいですねぇ．

t-and-p.hatenablog.com

t-and-p.hatenablog.com

あと，会社がスポンサーしたイベントでスポンサーセッションとして喋ってきました．　

speakerdeck.com

自分で CfP 出して登壇したのではないので，自分の実力じゃないわけだけど，それでもこういう経験させてもらってラッキーだったなぁという感想．もちろん，会社として技術的にどういう取り組みしているの？というのはもっと発信しなきゃいけないなぁとは思っているので，来年も続けていきたいというか，来年は自分で CfP 出して話したいですね．

ということで来年も頑張ろーっ．

*1:今でも名前がない

FOLIO を支えるエンジニアリング組織の七転八倒記: 2018年冬

この記事は何

昨日， Engineering Manager Advent Calendar 2018 にて 今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間 という記事を公開しました．その記事の続編かつ実践編として，本記事では， FOLIO が2017年から2018年にかけてどのようにエンジニア組織を形成し，課題を抱え，その解決のためにどのようなアプローチを取ってきて，更にその後どのような課題に取り組もうとしているかを紹介しようと思います．自分が FOLIO に入社するよりも前の頃の話も多く含まれていますので，その点はご留意ください．

この記事は, FOLIO Advent Calendar 2018 14日目の記事です．

adventar.org

βリリースまで: 職能組織

FOLIO がサービスのβリリースを目指していた頃，FOLIO で開発中の「プロダクト」と呼ばれるものは「国内株によるテーマ投資」ひとつしかありませんでした．*1 そして，当時のプロダクト開発を行う組織は「フロントエンドエンジニア」「バックエンドエンジニア」「インフラエンジニア」などといった職能による区切りのみがあったそうです．

自分は当時の組織を直接見ていたのではないのですが，どちらかといえば，フルスタックにスキルを持つタイプのメンバーよりは，自分の得意分野に深い知見を持っていたメンバーの方が多かったために，このような配置になっていたのかなと想像しています．一般的にはコミュニケーションのオーバーヘッドや局所最適を引き起こすとされる職能ベースの組織ですが，βリリースの後も長くに渡ってサービスを支えるソースコードやシステムの基礎を高いクオリティで作りあげるという点ではメリットがあったのかなと理解しています．

プロジェクト体制

FOLIO のテーマ投資プロダクトは，2017年7月のβリリースまでは漕ぎ着けたものの、まだまだ足りていない機能が山のようにあるような状態でした．この頃になると，足元にある課題を着実にひとつずつ解決していくためのプロジェクト制が明確に組織の中に組み込まれるようになり，職能ベースのチームを保ちつつも職能を横断したプロジェクトベースの組織が複数組成されるようになりました．

「プロジェクト」という単位が明確に組織の形に落とし込まれることで，当然ながらその時々でどのような目標を持ったプロジェクトが存在するのかがわかるようになります．(逆に言うと，それよりも前はこういったことも上手く開発プロセスの中で管理できていなかったというわけなのですが…)

進行中のプロジェクトが扱っている開発中の仕様のドキュメントや，プロジェクトのスコープや課題の一覧をまとめるpj-doc と呼ばれるプラクティスが社内で確立したり，開発ボリュームの見積もりについても様々な失敗を経験しながら知見を溜め続けるなど，特にここ1年で組織全体的にプロジェクト運営の練度が上がったかなぁという実感があります．

www.slideshare.net

組織組成においてプロジェクト色が強くなることで起きた問題

プロジェクトベースでエンジニアリング組織を運営することで，ビジネス展開を行う上でのプロダクトの課題は着実に解決されるようになってきました．一方で，ほぼすべての開発をプロジェクトという体制で行うようになったことで出会う成長痛もありました．ちょうど，自分が FOLIO に入ってミドルマネジメントに関わるようになったのが，これらの問題に直面している頃でした．

マイクロサービスのオーナーシップの不明瞭さ

FOLIO のバックエンドシステムは23個*2のマイクロサービスからできています．1つのプロジェクトですべてのマイクロサービスに手が入ることは基本的になく，プロジェクトごとに大きく開発が必要になるサービスは異なります．プロジェクトが終わればそのプロジェクトのメンバーは他のプロジェクトに取り組みます．しかし，プロジェクトが変われば全然違うマイクロサービスを触らなければいけないことも珍しくありません．

一般的にマイクロサービスアーキテクチャというと，組織がドメイン境界に応じて細かく分かれており，それと同じようにシステムもドメイン境界で分かれているようになるような形を取ります．しかし，FOLIO の場合はシステムこそマイクロサービス的に細かく分かれていたものの，それを作る開発チームはどちらかといえばモノリシックにできているような状況でした．

こうなることで，コードを書く上でも「将来的に誰がこのコードを触るかわからないから」と，無難なコードであったり設計をすることしかできなくなります．また，特定のマイクロサービスにオーナーシップを持つメンバーが明確でないため，コードベース上の技術的負債の管理にオーナーシップを持つメンバーがいないという問題にも悩まされました．*3*4

社歴が長かったり，いろいろなマイクロサービスの基礎を作ったりしてきた特定の詳しい人に負担が集中するようなことも当然発生しており，持続可能なプロダクト開発を実現するためには何らかの手を打たなければなぁ，と考えざるを得ない状況でした．

作って終わりではない「プロダクト」

「証券会社を支えるシステム」と一口に言っても，それを構成する各パーツひとつひとつが既存の証券会社では一つの部署になるほどに巨大であり，また複雑です．FOLIO はそんな証券会社をゼロから証券会社を作るという特性上，常に足りていない機能を作ることに奔走しています．一方で，スタートアップとして事業やプロダクトを成長させるという観点では，本来は KPI と常に戦い続け，その KPI に沿って何を作るかを決めるという判断の軸も間違いなく必要でしょう．

狩野モデル - Wikipedia という製品品質モデルがあります．顧客がサービスやプロダクトに対して求める品質を5つにカテゴライズしたもので，その中でも特に「当たり前品質」という，あって当然だと顧客が認知していて，欠けていれば不満に思う品質と，欠けていても特に何とも思われないが，充たされていると顧客が喜ぶ品質という対象的な2つの品質があります．

証券会社としての「当たり前品質」は，要件が比較的明確でありながらもひとつひとつが巨大であり，これらを満たしてゆくためにはプロジェクトベースの組織は有効でした．一方で，これまでに前例のないようなターゲティングの取り方や金融商品の魅せ方をする FOLIO が「魅力的品質」を伸ばしてゆくためには，そもそもどのような施策に効果があるかもわからず，大きな機能追加も細かい改善も必要になるし，もっと経験主義的に問題発見と解決をする必要があるよね，という課題感はなんとなく社内に漂っていました．このまま，何かプロダクトに手を入れるときに必ず「プロジェクト」という形を立ち上げなければならない組織では，プロダクト開発の中で充分な機動力が得られないのではないか，という課題意識が浮かび上がってきました．

実際，今年の前半には，LINE 上でのテーマ投資を可能にする LINE スマート投資 向けの機能開発プロジェクトと，投資一任型による分散投資ロボアドバイザーである おまかせ投資 リリースに向けた開発プロジェクトという2つの巨大な新規開発プロジェクトにほとんどの開発リソースを集中させており，テーマ投資単体での，商品の魅せ方や取引体験の向上といったプロダクトの進化に力を割くことが難しかった時期もありました．

ウェブサービスと証券システム, または SoE と SoR

FOLIO では，口座開設を希望されるお客様が提出してくださった書類を審査する業務や，お客様からのお問い合わせにメールや電話でお答えするカスタマーサービス，お客様にお選びいただくテーマやテーマを構成する銘柄の選定，入稿を行う業務や，そのテーマの紹介文を編集し，その文言のコンプライアンスチェックを行う業務など，様々な業務フローが存在します．

これらの業務をサポートするための社内向けウェブアプリは，かつては単純に「管理画面」と呼ばれていました．しかし，これは単純に「管理画面」なのではなく，その奥にあるのは証券会社のバックオフィスシステムであり，お客様に提示するサービスと同等かそれ以上に重要なシステムであるという意識やモチベーションを会社全体で共有するため，これらのバックオフィス系証券システムを指す概念として「PORT」という名前がつけられました．

これらの経緯は，昨年の Advent Calendar にて公開された記事でも取り上げられています ．自分が FOLIO に入社したのは「PORT」という言葉が生み出されてからかなり経った頃でしたが，実際に入社してみて，名前を付けることがもたらす，作る人と使う人が持つシステムへの愛着を強く実感したのを覚えています．

f:id:mura-_-mi:20181209183703p:plain
PORT と FOLIO の関係 (2017年に描かれたもの)

もちろん，「FOLIO」というお客様向けのプロダクトと，それを支える業務システムである「PORT」という分類の背景には， System of Engagement (SoE) と System of Record (SoR) によるバイモーダル戦略 があったわけです．

しかし，今年の1月~3月ごろにかけて， FOLIO と PORT で開発チームを分けたり，開発サイクルを分けてみるという試みをしたのですが，結論から言うとうまくいきませんでした．ホットで巨大なプロジェクトが立ち上がり「PORT というプロダクトの開発」にリソースが割けなくなったという不可抗力の事情もありましたが，お客様の個人情報を取り扱う API や， FOLIO でお客様にご提示するテーマ一覧を CRUD する API などを始めとする多くのコンポーネントを FOLIO と PORT の両方が参照しており，既存のシステムを簡単には二分できないという，より本質的な課題にも直面しました．

バックエンドエンジニアのサブグループ化

ここまでで，「プロジェクトベースの組織が主になれば組織の顔ぶれは安定しない」という問題と，「SoE と SoR によるバイモーダル戦略を用いてシステム全体を二分しようとしても綺麗な境界を引くことはできない」という問題に直面したわけですが，特にこの影響を受けていたのばバックエンドシステムエンジニアたちでした．今年の10月の時点でバックエンドエンジニアは16人いたのですが，この人数は "Stable Team" として運営するのには多すぎるし，バックエンドシステムの守備範囲の広さを考えても，「全員で全部のシステムを理解する」ことは難しいと言わざるを得ませんでした．

そこで着目したのは，別段新しいことではなく，「ドメイン境界に向き合う」ということでした．Scala 関西 Summit 2018 でのセッションでもご紹介した以下の図から，そんなドメイン境界を垣間見ることができます．*5 FOLIO と PORT という二分はこの図には現れていませんが，各サブドメインが必要に応じて社内向けに特有の機能を提供しましょう，という意識は今でも健在です．

このようなドメイン境界の整理ができれば，あとは「逆コンウェイ戦略」に則ってバックエンドエンジニアのサブグループをつくっていきます．人数とマイクロサービス数を勘案して，4~8ほどのマイクロサービスを担当する3~6人ほどのチームがいくつか立ち上がりました．そして，このサブグループごとにプロジェクトに取り組むようにしつつ，プロジェクトの粒度にならない開発も合わせて行うように仕事の進め方を変えていきました．

サブグループにチーム意識を植え付けることで，技術的な負債や課題，運用上のトイルに対しても個人でではなくチームで立ち向かう意識が出てきたり，ドメインモデリングを行うワークショップを行って知識共有をするチームが現れたりと，良い副作用も見受けられるようになってきました．

複数プロダクト時代へ

当初は「国内株によるテーマ投資」のプロダクトのみを展開していた FOLIO でしたが，LINE スマート投資 を10月に，「おまかせ投資」 を11月にリリースし，複数のお客様向けプロダクトを展開してゆくフェーズに突入しました．

更に，今年の11月に行われた LINE Fintech Conference にて発表された LINE スマート投資上でのワンコイン投資プロダクトなどを始めとして，これからも多数の投資プロダクトの展開を予定しています．

プロダクトが違えば技術的な特性も違うし，ビジネスモデルや追うべき KPI も異なります．これまでだと一つのプロダクトを進化させるために組織全体でどのプロジェクトから順番に取り組むか？という考え方で組織運営ができましたが，複数のプロダクトがある中で一つの優先度にすべてを落とし込むことも難しくなってきました．

職能組織の限界

同時に，職能組織の限界も見えてきました．職能チームの中でも担当しているプロダクトやサブドメインが違っていたり，職能は異なるが同じプロダクトに関わっているメンバーの間でのコミュニケーションオーバーヘッドが目につくケースも増えてきました．

また，フロントエンドエンジニアがバックエンドに転身したり，バックエンドエンジニアがデータ分析系のエンジニアに転身したりというケースも増えてきました．

例えばフロントエンドからバックエンドエンジニアに転身したメンバーは，バックエンドのチームにいるから Web サイトのコードに手を加えてはいけないというルールは設けていませんし，むしろ一つのプロダクトをフロントエンドからバックエンドまで一貫して触れるようになったほうがメリットは大きいはずです．

組織上の異動は伴わずとも，既存の職能の境界にとらわれずに仕事をしたい！という意思を表明してくれるメンバーも増えてきており，ボトムアップの方向からも「職能の軸からプロダクトの軸へ」という機運が高まってきたのかなという実感があります．

プロダクト組織へ

ここまでの流れなどを踏まえて，職能を越えて「プロダクト」という軸で組織の編み直しをしようとしているのが今のフェーズです．

組織の編み直しをする際には，いきなりすべての既存の枠組みをなくすことはできず，どう上手に「過渡期」を作るかが重要になると考えています．一方で，いつまでも過渡期をダラダラと続けていても良いことはないので，どこかに思い切りの良さも必要になってくるわけで，そのバランス感には常に頭を悩ませています．

これまではProduct Manager という役割を担って仕事をしているメンバーはおらず，経営レイヤで事業やプロダクトの重要な意思決定を行ってきたのが実情です．今後はプロダクト軸でシステム面・ビジネス面の課題を整理しつつ，KPI 達成をミッションとするようなロールを担うメンバーを設けられるようにするべく，経営メンバーまで巻き込みながらいろいろな準備をしているところです．

まとめ

今年のはじめに50人ほどだった FOLIO のメンバーは，今や100人に迫る大所帯になりました．本稿でも触れたように，今年1年だけでもプロダクトの展開など組織を取り巻く状況は大きく変わってきました．今年1年を振り返りながら本稿を書き，その時々の事情に合わせて適切なアクションを取った組織運営をすることが大事だな，と改めて思いました．

2019年も，この流れでプロダクトもエンジニアリングもすいすいと進化していけるような組織にできるように頑張っていきたいと考えています．

明日の FOLIO Advent Calendar 2018 - Adventar は， ふじたく (@magie_pooh) | Twitter さんです．弊社の Android アプリは Google Playベストオブ2018 で隠れた名作部門賞大賞を受賞したのですが，この Android アプリ開発の中心にいたのが ふじたく さんです．開発開始からリリースまでの長きにわたるストーリー，今から楽しみです！

*1:実際には，この頃からロボアドバイザープロダクトのローンチまで構想がありました

*2:2018年12月上旬時点の数字です．この問題が顕在化してきたときは20弱くらいだったと記憶しています．

*3:後からコードを触ることになるメンバーのためにユビキタス言語を wiki に残すような取り組みも始まったのですが，やはりコードを説明するドキュメントは腐りやすいので，できれば組織の安定で解決したい問題だと考えています．

*4:FOLIO のバックエンドシステムは大半が Scala で書かれており，アプリケーションのレイヤ分けと，ドメインレイヤにおける知識の型情報による表現でキャッチアップを用意にする取り組みは効果的だったかなと考えています．こういった取り組みは Scala でつくる証券会社とスタートアップ / Securities and Startup with Scala - Speaker Deck にて紹介しています．

*5:説明の簡略化のために，FOLIO 単体のテーマ投資に限って配置を書いたり，一部のマイクロサービスを省いたり，実は1つのマイクロサービスの中に含まれてしまっているのだけどこの図の上では独立しているように書いていたり，逆に複数のマイクロサービスから成立しているけれどもドメイン境界としては1つにまとまるので図の上では1つにしたりという，図を描く上での "お化粧" が多く施されている点にはご留意いただきたいです

今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる

株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです．

Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。

本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコンテキストで特に意識しているトピックやセオリーを，エンジニアリング組織構築に馴染みの無い人へ動機なども含めて説明することを主眼に記述しています．*1 この記事の内容は所属する企業の公式見解ではなく，個人的に仕事をする上で大事にしていることにとどまっていることにだけご留意ください．

この記事は，Engineering Manager Advent Calendar 2018 の13日目の記事です．どちらかと言うとソフトスキルとかピープルマネジメントとかエンジニアリングマネージャーのキャリアとかの話が多い今回の Advent Calendar ですが，僕の記事はどちらかと言うとセオリーの棚卸しって感じですね．

目次

リソース効率とフロー効率, 制約理論

プロセスを設計する上で，「効率の良さ」を求める際に，その「効率の良さ」はどういう側面のものなの？という話．今年の頭に前職の後輩たちにレクチャーした話をこのブログに書いた けど，昨年くらいからよくエンジニアリング組織のマネージメントをやってる人の文脈で聞くようになった概念かなと思います．

リソース効率とは，プロセスを構成するパーツの稼働率の高さを指し，一方でフロー効率とはプロセスを流れる価値を付加する対象 (flow unit) に価値が付与される活動が完了するまでの時間の短さを指します．

非常に単純化した例を挙げれば，1人で取り組めば3日かかり，3人で取り掛かれば1.5日で終わるタスクがあったときに，3人が別々のタスクに3日間取り組み続けるのがリソース効率を重視した配置です．この場合，すべてのタスクが3日目に完了します．また，すべてのタスクを一人で行うので知識移転も発生しません．

f:id:mura-_-mi:20181205164006j:plain
リソース効率を重視した仕事の配置

一方で，5日間かけて，3人一緒になって1つのタスクを順々に消化していくのがフロー効率を重視した配置です．タスク A は2日目に完成しています．

f:id:mura-_-mi:20181205164041j:plain
フロー効率を意識した仕事の配置

もちろん現実世界ではこんな単純に話がいくわけではありません．今回の例だと3倍の人を一つのタスクに投入しても1.5倍の速度しか出ませんでしたが，人数を投入するのが有効なのか，一人で淡々と取り組んだほうが早く終わるタスクなのかも場合によります．

リソース効率とフロー効率どちらを取るかのゼロイチの話でもなく，また，単純にタスクを完遂するという観点以外にもメンバーの感情面や育成という観点も考慮する必要があります．今回の例だと複数タスクの依存関係なども考慮していません．

事業やプロダクトによってどちらの側面をどれくらい重視するかが異なるかと思いますが，何も考えずにリソース効率を上げるアプローチを取っても，プロセスのボトルネック自体を解消せずにフロー効率を向上させないと，プロセス全体の生産性は上がりません．このことを「制約理論」と呼びます．

エンジニアリング組織の設計と運用も，プロダクトを生み出すためのプロセスを設計するという話なので，制約理論やリソース効率とフロー効率の違いはしっかりと意識するべきです．

職能組織と機能チーム*2

チーム・グループを作る上で何を軸とするかの話です．リソース効率・フロー効率とも綿密に結びつく話です．

職能組織

似た技能を持っているメンバーを集めて作られたチームを職能組織と呼びます．*3

似た技能を持つメンバーが集まるので，メンバー同士の切磋琢磨がワークして技能スキルが上がりやすいというメリットがあります．また，労働市場で希少性のある技能や，特殊性のある技能，会社内の複数部署やチームに横断して仕組みを整えることが効果的だと判断されるケースでこの形態が取られるケースが多いのではないでしょうか．例えばデータ分析や機械学習，人工知能に基づいた技能を持つエンジニアの特殊部隊や，ITインフラの構築・運用に長けたエンジニアのチームといったものを想像すると良いかもしれません．

職能組織が多かったり，職能組織間の境界がしっかりと設定されていると，複数の職能チームが必要なプロジェクトを完遂するためのリソース効率は高めやすい反面，チームの間での情報伝達のオーバーヘッドがかかるなどの理由でフロー効率は下がりやすい傾向があるかと思います．

機能チーム

職能を横断し，顧客に提供する価値を作る単位に基づいて組成する組織を機能チーム (Feature Team) と呼びます．

顧客に提供する価値の最大化にフォーカスが当たりやすいのでフロー効率は高く保ちやすい一方で，チームの中のすべての職能が常に必要とされるとは限らないという点でリソース効率が落ちがちであるという特徴があります．

また，一言で「職能を横断する」と言っても，どの程度まで横断するかも重要になります．例えば，エンジニアの中でフロントエンドもバックエンドもインフラエンジニアもデータ分析も合わせるというレベルもあれば，さらにビジネスサイドのメンバーまで一つのチームとする，という職能横断も考えられます．職能横断の範囲が広ければ広いほど最終的な顧客の価値にフォーカスした組織が作れますが，その分マネジメントの難易度は上がるでしょう．

マトリクス組織

職能組織と機能チームの両方のメリットを享受するために，両軸を兼ね備えたマトリクス組織という構造がしばしば見られます．

マトリクス組織は，人事評価や指揮系統などの点で難易度が高く，しっかりとした制度設計や取り決めがないと難しいとされます．

f:id:mura-_-mi:20181205164112j:plain
極めて単純化したマトリクス組織の例

例えば上述の図の場合，赤い ☆ の部分に属しているプロダクト A のエンジニアは，プロダクトAのマネージャーとエンジニア組織のマネージャーの両方から評価や指示を受けたりしますが，マネージャー同士の評価や指示が矛盾したときにはどうすればよいかはどう判断すればよいでしょうか？また，メンバーの配置はどちらのマネージャーが主導権を握ればよいでしょうか？決まりが明確になければ社内政治や縄張り争いのようなものに発展してしまうのも想像に難くありません．

組織の寿命，プロダクトとプロジェクト

組織の寿命を長くするためにどうするか？そのために，極力 プロジェクトではなくプロダクトで思考しよう ，という話です．

Stable Team

ここでいう Stable つまり「安定」とは，比較的長い時間に渡って顔ぶれが大きく変わらないことを指します．なるべくメンバーの増減が起きないようにする動機は様々あります．

  • ステークホルダーを含むチームの外部が，チームの誰にコミュニケーションを取ればよいかがわかりやすくなる
  • 将来の予測を立てる上での不確実性を減らすことが出来る
  • メンバー同士の関係も長く存続するので，チーム内のコミュニケーションコストが下がる傾向がある
  • ブルックスの法則*4 に遭遇することを防ぎやすくなる

もちろん，そういうことを言っていられないような状況も多々発生しますが，なるべく組織の寿命を長くし，その組織に属するメンバーの顔ぶれを安定させるにはどうしたらよいか，がソフトウェア開発の文脈では重要になるのではないかと思います．

プロジェクトに基づく組織

プロジェクトとは，ある事業の中で期限と範囲を決めて完遂するための計画と言えます．事業が続いても，事業の中のある計画が完了すればプロジェクトは終了します．

基本的に，プロジェクトのために組成された組織は，プロジェクトが終了すれば解散します．上手に組織を設計しなければ，プロジェクトが終了した後のことはプロジェクトにおける考慮から外され，部分最適が生じることもあるでしょう．逆に，何より完遂することが大事なときにはプロジェクトベースの組織を作れば良いとも言えます．

極めて単純化した例を示すと，「地球を出発し，月の周りを周回して地球に帰還する」という活動は，どのようにこの宇宙旅行を完遂させるかが最も重要なので，プロジェクト組織が適すると言えます．

一方で，宇宙ステーション開発は，宇宙ステーションを構築して終わりではなく，その後の宇宙ステーションを活用した宇宙開発が安全に安定して行われることが重要なので，宇宙ステーションを作り切ることだけに特化した組織にならないことを注意しなければいけません．

プロダクトに基づく組織

ここで，プロダクト とは，事業を行う上で顧客に届ける価値と定義します．事業が存続する限り，プロダクトは存続します．

プロダクトに基づいた組織は，もちろんプロダクトが存続する限り存続するでしょう．基本的に，プロジェクトに基づいた組織よりも長く存続する傾向があるということができます．長く存続する可能性がある組織であるということは，プロダクトの長期的な価値や組織の生産性などにフォーカスがあたり，技術的負債の管理にも責任を持つ動機づけが働きやすい傾向があるのではないでしょうか．

ここまで，プロジェクト組織とプロダクト組織を対比的に書きましたが，プロダクトとプロジェクトは，対立関係ではありません．プロダクトに基づいた組織は，その時々のプロジェクトに取り組むことができます．

プロダクトに基づいた組織を構築する際に難しいのは，プロダクトの範囲や組織の裁量の範囲を定義することでしょう．プロジェクトに基づく組織は，プロジェクトの定めるスコープが明確に決まっているはずなのでこの部分にはあまり苦心しません．一方で，プロダクトに基づく組織は，定義を一言で表すことは簡単でも，色んな事情があって境界付けが難しいこともあります．求められるミッションと組織の持つスキルセットに差があって苦心することなどもあるでしょう．

プロダクトの境界とコミュニケーション

境界の話

プロダクト組織のところでも出ましたが，職能横断チームやプロダクトの定義は，広く取れば取るほど最終的に提供される価値にフォーカスしやすい組織となるが，その反面コミュニケーションのオーバーヘッドがかかったり，価値判断の難易度が上がったりするなど，高度なマネジメントが求められる傾向があります．

以前に私が書いた 組織境界の話 や プロダクト定義の話 でも取り上げましたが，現実的には以下の3つが重要になるのかなと思っています．

  • 境界を広げ続ける努力
  • 適切に境界を設定して「望ましい部分最適」が働くようにすること
  • 必要に応じて境界を見直すこと (一度設定して満足してはいけないし，フェーズが変われば最適化するべき KPI も変わる)

「コンウェイの法則」と「逆コンウェイ戦略」

コンウェイの法則とは，「組織の設計するシステムには，その組織のコミュニケーション構造をそのまま反映した設計になるという制約がある」という有名な法則です．

コンウェイの法則はもともと，組織の成果物を分析した結果であり，組織の構造を所与として成果物のアーキテクチャの傾向を説明するものでした．これを逆手に取り，プロダクトの構造を変えたり，新しくプロダクトを作る際に，どのような設計を実現するかから逆算して組織のコミュニケーションフローをデザインすることを「逆コンウェイ戦略」といいます．

SoE と SoR によるバイモーダル戦略

「逆コンウェイ戦略」では，どのような設計の青写真を描くが重要になります．ではどのような設計を目指せばよいのか？その答えはもちろん事業や組織の特色に依存しますが，一つのヒントになるのが SoE と SoR によるバイモーダル戦略です．

System of Engagement (SoE)

System of Engagement とは，プロダクトと顧客のつながりを確立し，強化することを主眼としたシステムです．

一般的な toC のサービスで言えば，インターネット上に展開されるサービスサイトや，モバイルアプリ，メールや郵送物などによる CRM チャネルなどが SoE に当たります．

特に toC 向けプロダクトの場合，どのような改善施策が効果があるかや，潜在市場がどこに潜むかは経験主義をもとに探し当てる必要があります．「リーンスタートアップ」や「アジャイルなプロダクト開発」が特に効果を発揮する分野と言えるかもしれません．小さく高速に実験して学習することが求められます．

System of Record (SoR)

System of Record (SoR) とは，出来事が正しく起きることを保証し，起きた出来事を正確に記録し管理するためのシステムを言います．

金銭管理や，法令や規制に基づいた報告義務のあるようなドメインなどがこれに当たります． SoE と比べれば，情報の取りこぼしやシステムダウンはより致命的であり，リスクを抑えて安定稼働することが求められます． 事前に要件を明確化してコーナーケースなどを慎重に考慮することが求められるので，いくら「アジャイルなソフトウェア開発」を標榜しても，大きな設計を洗い出し*5，正しくシステムが稼働するかの検証にも力を入れる必要があるでしょう．

バイモーダル戦略

SoE / SoR の特性を理解し，開発するプロダクトや，システムを構成する全体の中でも特定のエリアの性格に対応したチーム構成やプロセス設計などのアプローチを取る戦略を「バイモーダル戦略」といいます．比較的大規模なシステムを開発するとき，そのシステムの中にも SoE の特性を持つ部分と SoR の特性を持つ部分があるので，そのことを自覚しましょう，という話です．

これらを実際の組織運営・組織構築に応用すると？

ここまでが，今の自分が意識している組織構築・運営を行う上でのセオリーやパターンでした．エンジニアリングマネージャーそれぞれの取るアプローチは，当然所属する組織の文脈によって変わってくると思います．皆さんは普段どのようなことを考えていらっしゃいますか？

FOLIO Advent Calendar 2018 にて明日公開する記事 では，FOLIO のこの1年半くらいの開発組織の変遷や，今抱えている課題についてご紹介する予定です！ (このブログで紹介します)

*1:世の中には エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング という，より網羅的に，さらに発展的な内容まで網羅した書物があります

*2:『エンジニアリング組織論への招待』では機能別組織と機能横断型組織と記載されていますが，本稿では LeSS における Feature Team を一つの道標にしているため，このような用語を使っています

*3:呼び方はいろいろありますが，FOLIO ではこう呼んでいます．

*4:プロジェクトの後期に人員を追加投入することは，開発速度を向上させず，むしろプロジェクトの遅延を引き起こす

*5:Big Design Upfront と呼ぶことがあります

社員数が100人に迫っても社員と社長との距離を保つ「CEO Radio」の取り組み

チームビルディング 文化づくり

今年の2月より、FOLIO という会社で働いています。本業はバックエンドシステム開発とかエンジニアリングマネージメントなのですが、それとは別に、「社長による社内向けの音声コンテンツ」の企画及びインタビュアーをやっているので、その話をしようかな、と思います。

この記事は、そんな FOLIO のアドベントカレンダー 2日目 の記事です。昨日は id:ken5scal による 『踏み台環境でテレポートする』でした。

adventar.org

組織の「100人の壁」

自分が入社したときの FOLIO は50人から60人という会社でしたが、私の加入後にも続々とメンバーが参画し、今では100人に迫ろうとしています。 一般に、組織には「100人の壁」と呼ばれる、会社規模が大きくなることで発現する組織課題があると言われています。実際に FOLIO でも、今年の初めには1フロアだけだったオフィスも3フロアまでに拡大し、コミュニケーション不足を感じることも増えてきました。

中でも、社員と社長の関係という観点では、去年は CEO の甲斐ががオフィスをフラッと歩いて社員と気軽に話して事業のビジョンなどを共有することができたものが、メンバー社歴やオフィスの中のよく活動する場所、仕事の内容によっても甲斐と慢性的に距離のある立ち位置にいる社員が出てきたのも事実です。もちろん、甲斐もそのことは理解しており、各メンバーとコミュニケーションが取れるように考えたり動いたりしてくれますし、実際お昼時にオフィスの真ん中でメンバーの皆とカレーを食べている姿もよく見かけるのですが、「気をつける」のではどうしようも出来なくなるのが、「100人の壁」の特徴のひとつなのかもしれません。

理想を述べれば、社員の一人ひとりが社長のビジョンを理解し、共感できることが大事であることは疑いようがないでしょう。特に、今年の FOLIO は LINE との資本業務提携を発表したり、新しいサービス「おまかせ投資」の提供を開始したりと、会社としてのこれまでにない動きも多かったので、今、社長がどのようなことを考えていて、自分の仕事にはどのような意味があるのか？をメンバーがより深く知る機会を設けることは非常に重要でした。

その理解を助けるための試みとして今年の7月から始めたのが、CEO Radio です。

CEO Radio のきっかけ

f:id:mura-_-mi:20181128202013p:plain
CEO Radio の社内向け配信サイト (2018年12月現在)

CEO Radio は1回10分~20分程度、CEO の甲斐と、聞き手の私、そして時には FOLIO の様々なメンバーが何らかのトピックについて話したものを、社内でメンバーが好きなときに聴ける音声コンテンツです。

この CEO Radio の始まりは、6月のとある社内の食事会にて、社長とバックエンドエンジニア数名で、「最近の会社の課題」に関する話題になり、上述のような課題をメンバーが挙げた際に、私が言及したのがきっかけでした。

FOLIO のメンバーは原則として、ジョインする際の選考プロセスの中で必ず CEO の甲斐と話すようになっており、メンバーの多くが甲斐の「世の金融の常識を変える！」というビジョンに共感して参画しているのではないかと思います。それでも、甲斐の考えを、入社時や偶発的なコミュニケーションだけではなく社内の興味あるメンバーには継続的に伝えられるようにし、しかも形に残すことで将来ジョインするメンバーにも FOLIO の文化や価値観を知ってもらえるようにすることは有意義なのではないか、と考えたのが CEO Radio の始まりでした。

私の頭の中にあった先行事例

私が「CEO Radio」を提案した際、頭の中には2つの先行事例がありました。

ひとつは、 2017年にあった 「XP祭り 2017」にて、ソニックガーデンの倉貫社長が紹介されていた、ご自身が取り組まれている「社長ラジオ」です。ソニックガーデンはほとんどの社員がリモートワークをしている会社であり、メンバーと社長のフェイス・トゥ・フェイスのコミュニケーションが比較的少ない会社であるために、会社全体のことを伝えたり、会社の価値観や動機づけになるような話をするための仕組みだったそうです。

また、私の前職であるサイバーエージェントの「カルチャー推進室」が、私の頭の中にあったもうひとつの事例でした。
サイバーエージェントは広告・ゲーム・メディアという大きく3つの部署に分かれていますが、その部署の垣根を越えて仕事を行わないメンバーというのも多く (私もその1人でした)、部署などの組織ごとに独自の慣習や価値観が醸成されている会社でした。しかしながら「サイバーエージェントらしさ」という価値観や文化は明確に存在していましたように感じました。その全社で一貫した文化の醸成に一役買っていた仕組みのひとつが「カルチャー推進室」の活動だったと私自身は理解しています。各部署のキーパーソンへのインタビューや、社歴の長いメンバーのキャリア遍歴、過去にメンバーが苦闘したプロジェクトの歴史などが社内ポータルサイトや社内刊行物などを通して全社員に発信されており、サイバーエージェントにジョインしてすぐのときに感動したことを覚えています。

明確に形に残されているものを追うことで、文化や会社の歴史に対する理解を深めることができました。私にとっては初めての転職であり不安も大きかった中で、「お客さん」になってしまって会社の文化に馴染めないようなことがなかったのはとても大きかったなと感じています。

CEO Radio を支える技術

f:id:mura-_-mi:20181201111525j:plain
最近の CEO Radio の収録風景

CEO ラジオの収録を行う際には、以下のような機材を用いています。

マイクなどの各機材は、当初は社内メンバーの私物のマイクを使っていたこともあったのですが、回数を重ねて CEO Radio の有意義さに対する理解が会社全体に浸透してきたタイミングで、会社の経費で購入したのが現行の機材です。

機材選びで気をつけたポイント

マイク選びは、複数の話者がいるなかで1本のマイクを利用するので、当然ですが無指向性マイクを利用すること。そして、盲点になりそうですが重要なのがサウンドカード選び。サウンドカードを単純に「USB と 3.5mm ジャックのアダプタ」と捉えると痛い目を見ます。実際、当初購入した安価なサウンドカードでは細かい音が全く拾えず、後から現行のサウンドカードに買い替えたことでしっかりとトークの内容が聞き取れる音声を収録できるようになりました。

収録と編集

収録ソフトは、以前は QuickTime Player で収録して、特に編集もせずそのままアップロードという形にしていました。回を重ねるにつれて、収録後に一部カットが必要になったり、複数の音声ファイルを接合しなければならない需要も出てきたため、GarageBand で最低限の編集をするようにしています。やってみて改めて思うのですが、編集は凝ろうと思えばどこまでも手を入れられてしまうのですが、私の本業は別にあるので、時間を使いすぎないよう気をつけています。

社内配信

社員への配信方法は、当初は Slack アプリケーション内で再生できる形でアップロードしていたのですが、最初の配信から2回ほど回数を重ねたタイミングで、とあるエンジニアが社内のみから閲覧できる配信サイトを構築してくれました。もともと社内サイトの立ち上げは考えていたのですが、あっという間にできてしまうスピード感にとても驚いたのを覚えています。 このサイト立ち上げを契機として、今では社内で行われる勉強会やワークショップも有志が音声もしくは動画を収録し、このサイトでアーカイブをいつでも視聴できるようになっています。

CEO Radio で何を話しているか

CEO Radio でどのような話題を取り上げるのかについては、特に決まりはなく、いろいろな試みをしているのですが、その中のいくつかをご紹介してみようと思います。

会社の直近の動きに関わる話

今年の11月に、投資一任型のプロダクトである「おまかせ投資」をリリースしたタイミングなどで、なぜ FOLIO はこれまで展開していた「テーマ投資」のみならず、複数のサービスを展開するのか、そこにどのような狙いがあるのか？今後どのようなプロダクトを展開するのか？などについて語ってもらったりしています。 FOLIO が提供する投資プロダクトや開発するシステムはそれぞれ単体で充分に巨大であり、メンバーは自分の担当範囲のことは知っていても、それ以外の部分についてはどうしても疎くなったり、複数のプロダクトやプロジェクトが会社全体の観点からどのようにつながっているのかも意識しづらくなってしまうことも、しばしばあります。CEO Radio で会社全体からみた各プロジェクト・プロダクトの位置づけをフィードバックし、メンバーのモチベーションに繋がるようにしています。

You は何しに FOLIO へ？

FOLIO メンバーをゲストに呼び、ゲストが FOLIO にジョインする前に何をしていたか？なぜジョインしようと思ったのか？について語ってもらうシリーズ。あるメンバーは「FOLIO に入るか、プロのポーカープレイヤーになるかを悩んだ」と語ったり、甲斐が、あるメンバーとの初対面を振り返って「最初は感じの悪い子だと思った」と思っていたという、今でこそ言える話が出たり… FOLIO メンバーの個性も相まって、毎回楽しく興味深い話を聞かせていただいています。

スタートアップ入門

もともと投資銀行でのトレーダーというキャリアを歩んできた甲斐が、スタートアップを立ち上げるうえで気をつけたこと、大切にしていることを教えてくれるシリーズ。いずれは FOLIO で成長したメンバーが "FOLIO mafia" として新たなベンチャー企業をどんどん立ち上げて行ってほしい、という甲斐の願いが込められているシリーズでもあります。

お便りのコーナー

社内のみからアクセスできる投稿フォームがあり、ここに集まったお便りに甲斐が答えるコーナーを定期的に設けています。FOLIO メンバーからはよく鋭い質問が飛んで来ますし、質問した人が納得できるようなトークにできるのかという意味で、聞き手としては比較的緊張するのがお便りのコーナーだったりします。個人的には、最近収録した「FOLIO のミッションとバリューに込めた意味や意図を教えてほしい」という回が非常に良かったなぁと思っています。

まとめ

FOLIO での、会社規模が大きくなってもビジョンや文化を組織の隅々まで浸透させるための取り組みについてご紹介しました。もちろん CEO Radio を聴くかどうかは社員にとっては任意ですし、このような取り組みで全てを解決しようとは考えていないからこそ、他の手段も使いながら組織のスケールアップに合わせた文化形成は引き続き頑張っていきたいと思っています。

そんな FOLIO では、一緒に働くメンバーを募集しています。少しでも興味を持った方は、一度気軽に FOLIO のオフィスに遊びに来てみませんか？ www.wantedly.com

明日の FOLIO Advent Calendar 2018 - Adventar は、いつも何から何までお世話になってる kenchan0130 による Google App Script の話 です！

Scala関西Summit 2018 で喋ってきた

昨年は参加者だったけど、今年はスポンサーセッションを喋る立場になった。去年の記事はこちら↓↓

t-and-p.hatenablog.com

去年の9月に Scala関西Summit 2017 に参加して、懇親会で id:itohiro73 に誘ってもらったことがきっかけで FOLIO に入社したので、1年経って FOLIO の人間としてしゃべるようになるというのは不思議というか、この1年が色んな意味で激動だったなぁとしみじみ思いました。

登壇資料はこちら。FOLIO のバックエンドシステムがどうできているか、いろんな側面からご紹介できるないようになっているかなと思います。20分という時間の制約がなければもっとお伝えしたいことがあったので、それはまた近いうちにどこかの機会で。

speakerdeck.com

ここから先は比較的エモい話。

そもそもこういうイベントで登壇するのは初めてだったことと、しかもそれが僕個人の発表ではなく、会社がスポンサーとしてお金を出してくれて、なおかつスポンサーセッションとして弊社の取り組みを紹介するという重大任務だったので、いろいろと頑張った。結果として、エンジニア採用などでも使えるような資料ができたり、トークの内容を考えることで気づけること、仕事自体にフィードバックできることもあったので、ちゃんと取り組んで良かったな、と思う。 会社の Slack を見返したら8月11日にまず話す叩きを作ってた。これを id:itohiro73 と id:matsu_chara にレビューしてもらったりしてた。

もちろん3ヶ月間ずっとこれやるわけではなく、時々思い出したようにちょっとずつ進めたりしてたんだけど、2週間前くらいからはスライド作って、一人で喋るだけじゃなくてメンバーに見てもらってどう思うかを聞いたりと、ひたすら叩いてもらう機会を作らせてもらった。こういうのに付き合ってくれたメンバーに本当に感謝。

そして、一部デザインに凝ったスライドは CDO の広野 (https://hajipion.com/) に手伝ってもらった。いろんな場面で思うけど、職種とかも関係なく惜しみなく協力しあえる関係は、この会社にいて心地よいなぁと思う理由の一つだったりします。感謝。

そして！Scala関西Summit に来たからには食い倒れも重要！

1日目の朝はカフェのモーニング

1日目のランチは天満のお好み焼き「千草」豚肉めちゃ肉厚！

2日目は前日の懇親会の後3次会まであって二日酔いだったので、かすうどん。かすうどん初めて頂いたけど良いな

2日目終了後は梅田食堂街にて食いだおれます