デブサミ2019福岡に参加してきた
Updated Date: 2024/01/01 02:55
だいぶ更新が遅くなってしまったが行ってきたのでレポートを書こうと思う。いつものことだが、散文かつ長いのでご了承いただきたい。
デブサミ自体は今回で1年ぶり2度めの参戦。会場から会社が近かったので助かった。
今回参加したセッションは以下。
- エンジニアフレンドリーシティ福岡界隈の兆候 松口 健司[サイノウ]/橋本 正徳[ヌーラボ]/熊野 良[グルーヴノーツ]/上原 里美[福岡市]
- Yahoo!天気・災害 天神拠点立ち上げ～新米リーダーの悪戦苦闘～ 藤本 一成[ヤフー]
- スタートアップが導入するべきデザインシステムとは 吉岡 泰之[gaz]
- モバイルゲーム運営における、認知資源をより有効活用していくための取り組み 倉持 和匡[ディライトワークス]
- ECにおけるAR・VRの今後 宮末 啓吾[ベガコーポレーション]
- サーバーレスは世界を救う...データエンジニアリング環境を爆速に構築する技術 手塚 卓也[スリーシェイク]
- ヤフー、メルカリ、ZOZO 東京の会社の福岡拠点で働くということ 大屋 誠[ヤフー]/岡元 秀憲[ヤフー]/髙橋 祐記[メルカリ]/大久保 貴之[ZOZOテクノロジーズ]
エンジニアフレンドリーシティ福岡界隈の兆候
もともと福岡市が提言したエンジニアフレンドシティは、最初地場のIT系企業では反対派と賛成派に分断されていた。そこを、面白そうだからとnulabの代表橋本氏が反対派の中核であったグルーヴノーツの熊野氏と会話する機会をセッティングしたとのこと。これ以外にも橋本氏はTwitterやコミュニティで出会ったエンジニアに都度都度絡んで秘めたる思いを聞き出していたそうだ。
そうやって実際に反対派の話を聞くと実際は反対しているわけではなく「こうしたほうがより良い」という意見が多数だった。エンジニアは口下手というか、文面では批判的に捉えられがちな内容を提案するけど、実際は論理的に考えた上で出てきた問題点だけを表現してしまうために、その裏に潜んでる本当の気持ちが表に出てきづらいそうだ。これについては僕もよく分かる。僕も自分の考えていることは比較的論理的であることを前提とする上で説明しようと心がけるので、結果的に話が長くなることがよくある。端折ればいいじゃん？と思われるひともいると思うが、そうすると今度は「なぜそう考えたのか」という追加の説明をするためにロジックを組み直さないといけないので、聞く方もしゃべる方も色々混乱する。
大体は僕自身がしゃべってて「やべぇ長くなってしまった」と思い焦り出して結局何言ってるか分かんなくなり、聞き手の人に要約してもらうっていう流れが多い。反省。
自分語りになってしまったので話を戻す。
その後、福岡市中央区にある西通りの一風堂に30人程度の関係者を集めて、がっつり議論しあったところ結果的には反対派も巻き込んで手を取り合うことになったというのがエンジニアシティの発端だそう。ラーメンは偉大である。
このセッションでは終始橋本氏の冴えた洒落が飛んでいて、Twitterでの発言通りの人だなという印象が強い(良い意味です)。また、グルーヴノーツの熊野氏としては、最大のつらさは「無関心」だったけど、他のエンジニアも関心を持って取り組んでくれるような仕組みが作れたことは良かったと振り返っておられた。
次にエンジニアの採用や今後の発展についての話になった。
海外エンジニアを確保するためには給与、有名なプロダクト、OSSが必要ということで発足したのがOSS Gate Fukuoka。福岡でもっと地元を盛り上げていきたいという志のあるエンジニアの方はぜひ参加してもらいたい。私も参加しようと思ってる。
また、英語によるコミュニケーションやキャッシュレス決済など外貨を意識せずに使える環境を整えて海外との差分を埋めることも大事で、そもそも海外に限らず東京や大阪などの都市部からも人を引っ張るネタを作る事もまた重要という内容だった。あと、エンジニアといえども挨拶は大事で、ちゃんと挨拶してコミュニケーションを推進することは特に異文化を受け入れるという意味でも重要だそう。確かに、異国の地で「オハヨ」と片言の日本語で同僚に挨拶されたら、嬉しくない人はいないだろう。そういうすごく簡単なところから信頼関係は培われていくんだと思う。
最後に学生や企業との接点の話。
学生と企業の架け橋を作り、大学へフィードバックしてというループも作りたいという話や、企業同士の横の連携も大事！福岡の地場企業がつながってエンジニアフレンドリーシティに参画すると有利になる仕組みを作りたいという話が出た。
このエンジニアフレンドシティについては福岡市が協力してくれているからこそできる施策がいくつもあって、例えば赤レンガがエンジニアカフェと言う形でリニューアルされたのも福岡市のバックアップがあったからだし、ベンチャー企業に福岡市が助成金を出すのもそうだし、僕は結構#FUKUOKAが好きでよく読んでる。これもまた福岡市のバックアップそのもので、魅力的なコンテンツである。
ただ、そういう情報媒体があることを知らないエンジニアもいるので、エンジニアにダイレクトにアピールしていくことも必要だと思う。特にSI系の大きな会社に至っては多分知らないんじゃないだろうか（エンジニアの母数としては確実に彼らのほうが多いだろうし）
とりあえず知り合いのエンジニアに「福岡市ってこんなことやってるんだよ」っていうのをお酒の場でもいいから話すと、少しずつそこらへんの認知度も上がっていくのではないだろうか。結局、個人の協力がなければ進まない部分は多いので、自分にできることを少しずつでもよいので継続的にやっていくことに尽きる。これは仕事も同じだ。
Yahoo!天気・災害 天神拠点立ち上げ～新米リーダーの悪戦苦闘～
新米リーダー（7年目）の苦悩の話。 2019/4に福岡天神拠点の立ち上げを任され、9月までの計画でYaoo!天気・災害アプリ（サーバーも？）の運用を完全に福岡のみでできるようなスケジュールでプロジェクトが発足。登壇者はもともと大阪の同プロジェクトのチームで仕事してたので、引き継ぎにはもちろんそのチームの存在する大阪と、今回立ち上げる福岡拠点間での連携が必須になったとのこと。
作業としては立ち上げ計画書、目標設定、カリキュラム（人材育成用）、スケジュールを作成したそうだ。 これはチームを持ちたいと思ってる人にとっては役に立つかも。 なお福岡拠点のエンジニアはリーダー含めて3人（うち2人はYahoo!天気・災害サービスは未経験）ということで、要するに素人集団ということ。
今回のプロジェクトでは「組織の成功循環モデル」を重視し、とにかくチームの関係性の質を向上させるため大阪チームとのコミュニケーションを図ることにしたそうだ。いろんな方法があるだろうけど、今回の場合は直接大阪に出向いて短期的な合宿を実施し、ガツ盛りチャーハンの洗礼を浴びたというのがハイライト。（どこのお店でしょう？）
今回の立ち上げの話ではリモートで仕事する苦労とリーダーが面倒見れない状況で仕事する苦悩の2本立てで、本当に大変だったんだろうなというのがひしひしと伝わってきた。
例えばリモートだと「XXさん知ってるけど顔がわからないから質問しづらい・・・」みたいな問題が起きてしまってコミュニケーションコストにより進捗が思うように進まない場面も多々遭遇されており、
SlackやZoomを使って朝会を大阪/福岡をつないで実施してもメンバーの何人かは「意味ないやろこの会議」と感じてたとか、大阪と福岡で考えてることが違って課題がうまく解決できないとか、リモートワークならではの問題が出ていた。
この辺についての対策としては会議の人数を絞る、意思統一の図れる仕組みを作る（今回の場合だとインセプションデッキ）、情報の集約される場所を設置し、ある程度ルールで絞る（SlackのチャンネルやWikiなど）
みたいなことが考えられる。
もう一つの「リーダーが面倒みれない」っていう状況が起きるときというのは、リーダーが別プロジェクトを兼任する（今回の事例がそれ）とか、リーダーがコーディングもするとかいうパターンである。 チームそのものが主体性もあって関係も良好でいわゆる「強いチーム」であればそれで問題ないのかもしれないけど、役割を担うべき人が減るのは全体でみても結局損しかない。なぜなら、その役割を代行する人が必ず必要になるので、その人の作業効率は確実に悪くなるからだ。
このセッションを聞いて思ったことは、「多くの失敗プロジェクトやアジャイル失敗事例で言われているアンチパターンを数多く経験されたんだな」ということだった。
特にこのプロジェクトの場合新任リーダーということもあるのでアジャイルで言われる「兼任」のアンチパターンは絶対に避けたほうがよい点だと思うけど、会社側のどういう意図があってそうなったのかわからないがこれはマズいと思う。また、インセプションデッキについてもアジャイルサムライに書かれている通り、これはプロジェクト発足時に書いておくことを良しとしているので、先に実施しておくべきだったものだろうし、全てが悪い方に向かってて個人的にはよく耐えたなぁという気持ちが強い。僕としては盛大な慰労会で大盛りのモツ鍋を食べていただきたいと思った。
スタートアップが導入するべきデザインシステムとは
デザインについては、ちゃんとしたデザイナーと協業して仕事をしたことがないっていう経歴のせいで僕には「これが正しい気がする」ってう答えが無い。仮説もないので検証することもできない。要するにこのセッションからは知らない世界知らない領域を学ぶことを目的としていた。
セッションは終始「スタートアップに必要なのは自分たちが何を成し遂げるかを見失わないための思考軸」という話だった。また、スタートアップといえどもシード期、PMF期と規模の違うスタートアップでは取るべきデザインシステムの手法を変えたほうが良いということも知見になった。
そもそも「デザインシステム」とは、それをベースにWebやアプリをデザインすることで、一貫性やコミュニケーションの円滑化を図ることができるというものだ。アメリカの有名な企業（Uber、Shopify、Atlassianなど）も取り入れている。このセッションを聞く前からデザインシステムの存在は知っていたけど、それはデザイナーがデザインをするために利用するものだと思っていた。でも実際はそうではなく、マーケターもエンジニアも、プロダクトに関わるメンバーがそれぞれ共通の認識を持つためのものであることを知れたのは良かった。
そもそもデザインはデザイナーの仕事であることが少ないスタートアップ企業の場合、エンジニアがなんちゃってデザインを担当することも多々ある。僕の知ってる界隈ではスタートアップ企業に限らず上場企業やSI、独立ベンダーでもデザイナーが絡むことのほうが少なかったけど。そんな感じの現状が今福岡のスタートアップで見受けられるということで、登壇者の経営するgazはデザインを外注できるサービスを提供している。
なお、このセッションで紹介されたミニマムなデザインシステムの定義を、僕が資料から色違いで写経したものを載せておく。
画像だけ見てもわからないと思うのでピラミッドの上から簡単に説明すると、「課題」と「ソリューション」はそれぞれスタートアップの持つプロダクトの課題とソリューションを言葉にしたものである。
次に「ビジュアルのデザインシステム」については、従来どおりのもので、ビジュアルでどう課題とソリューションを支えるかということを言葉にする。「機能のデザインシステム」においてはビジュアルでは解決できないインタラクティブな部分をどう実装するかを言葉にする。（とにかくわかりやすいUIとか、とにかく速い表示とか）
最後にビジョンはスタートアップの掲げるビジョンのことである。
つまり、プロダクトの課題やソリューションと、会社のビジョンとをうまくつなげるための手法として、2つの軸でデザインシステムを考えようということで問題ないと思う。
これはOKRにもちょっと似てて、結局会社のビジョンと組織・チームの行動目標や目的が乖離してしまうと何も生み出せないよねっていう問題は、結局デザインのほうでも同じように発生するということである。
どうでもいいのだが、このセッションでは経営用語(PMFとかPSFとかMVPとか)がいくつか出てきて、個人的にはこっちも勉強になった。 何事も経験は大事。言葉がより重くなるのは、経験と知識量で決まる（と思ってる）
モバイルゲーム運営における、認知資源をより有効活用していくための取り組み
Fate/GrandOrder英語版作ってるディライトワークスのチームの話。
サービス運用していると月々でどんどんやることが増えていくうえに、OS側の都合でSDKのアップデート強制やアプリの内部ポリシー変更が割り込みで発生する。そして某大陸からの不正BOTアクセスも多く、更には様々な社内でのトラブル相談対応で自分の作業時間はどんどん削られていくという内容で発表が始まった。もはやあるあると頷くしかない。
そして話は心理学に。「認知資源」は（1日の間で）有限である。ということらしい。学術的に色々と研究されているこいつを正しいと仮定した場合、物事を理解するまでにかかる時間というものは1日で使える限界が決まっているということだ。 ゲームのように課金すれば増えるようなスタミナでも石でもない。
ということで、色々と施策を打って認知するポイントを自動化することにしたというのがメインの話。具体的には
- プルリクリマインダーを作った
- Jenkins + Slackで溜まったプルリクについてリマインドされるようにした Github Hubsを駆使したとのこと。
- サーバーのメンテナンススケジュールの自動作成ツール作った メンテナーは10人くらいで、Confluenceに手書きしてたが、 前のスケジュールをコピペしてたのでヒューマンミスがよく発生していた。 さらに作業時間は手計算でめっちゃ時間かかってた。 それをConfluenceからGoogleスプレッドシートのテンプレートを使ってGASによる作業開始時間の自動計算、 Googleカレンダーへの登録、作業担当者の招待を自動でできるようにしたというもの。 さらにConfluenceに貼り付ける用のテキスト出力機能付き。
- アプリのダウンロードサイズ肥大化によるアプリ容量自動計算をJenkinsで実施
このセッションでJenkinsはまだまだ現役なのだなと実感した。あと、こういう地道な改善は重要なのだが、これがエンジニアの行動評価につながるためには数値的な改善のBefore/Afterが必要？って思うところもあった。もしこれが評価に入らない(あるいは評価として提案されないもの）場合、エンジニアとしてモチベーションが続きにくいところはあると思う。僕もよくそれを考えていたことがあるので、そういう意味でも効果を測定して評価できるようにすることは重要だと改めて感じた。
ECにおけるAR・VRの今後
ベガ・コーポレーションのLOWYA ARの話だった。
- 物販全体においてEC化率は6.22%
- 家具/インテリアは22%（比較的多い）
- ECで家具やインテリアを購入するとき、サイズや質感が自分の部屋に買うまでわからない！
- LOWYA 360も出した（Oculusにも対応）
- 今後はよりデータを標準化・整理した企業がEC市場で強くなれると思う
内容としては比較的サービスの紹介がほとんどだった。とはいえ、AR Quick LookをHTMLのaタグで囲むだけで、3Dモデル(USDZファイル)さえあればすぐにでもARに対応できるというのは目からウロコであった。
てっきり相当な改修を加えたのかと思ってたけど、全然そんなことはなかった。無知は恥ずかしい。
このように技術が単純化されたとしても、その見せ方や使い方によっては訴求力、UXにも影響があるのだと改めて思った。
あとデータの整合性を保つってのは本当に重要だと思う。手作業だと限界がくるし、人によって違うパラメータを入れてたり入れ忘れたりする。そうなったとき、「だろう」でいろんな実装を進めてしまうとデータ不整合であらぬエラーを引き起こすパターンも多くなる。
プログラミングでは「型制約」である程度弾くっていうのが若干トレンドっぽくなってるけど、データ入力ではそうもいかない。この辺もしかしたらビジネスチャンスがあるのかな？なんて思ってしまった。
サーバーレスは世界を救う...データエンジニアリング環境を爆速に構築する技術
最近流行りのサーバーレスアーキテクチャについての話。 3-ShakeのReckonerはGUIをポチポチすることで様々なデータを集計・加工し特定の場所に出力することのできるツール。他にRechDBというのも作ってるらしいがサイトに載ってない。
発表者はIstioとかやってるSREチームの人。データエンジニアリングはやることが多くデータ開発、インフラ構築、データサイエンスなどなどの作業を実装前にしなければならない。これらをサーバレスアーキテクチャを使うことで簡略化できるというものだった。
例えば以下のような構成。
Google Analytics + ユーザー/アクションDB > Lambda > S3 > Glue > 出力
GlueのCSV出力は遅いからAthenaを使い、高速化すれば全体的に良いレスポンスで対応できたということだった。 ちなみにこれをすべてオンプレで作ろうとすると以下の様な構成になるだろう。
HDFS: Spark > Filesystem > presto
最初っからHadoopやSparkあたりの知識と実装を学ぶというまあまあのツラみがやってくる。最初からつまづきそう。
とはいえ何でもかんでもサーバーレスにすればいいというわけではなく、 料金、ベンダーロックイン、依存関係、組織におけるサーバーレスサービスの管理境界、セキュリティなど考慮すべき点は色々ある。 このへんは各企業で明確な比較もしくは取捨選択用の資料を作っても良さそうと思った。
サーバーレスにすると色々と便利な反面、アーキテクチャをどれだけでも複雑にできることが問題に挙がると思う。色々と検討したうえで、変化に強いのか、スケールに強いのかなど様々な観点から考えないと、後々絶対ツラくなるだろうなぁというのはすごく感じる。 個人的にはReckonerは、エンジニアというよりはCSや営業が、顧客のデータの利用方法とか、契約数のダッシュボード作りたいとか、顧客から特定のデータの集計結果をくれと言われたとか、そういうときにちゃちゃっとGUIでやれてしまう手軽さに対してすごく期待感が強い。APIとかYAMLでの入出力に対応してくれたらJiraのDESK課題起票からの流れで自動化することもできるだろう。Salesforceの対応も首を長くして待ってる。
ヤフー、メルカリ、ZOZO 東京の会社の福岡拠点で働くということ
前半は予定されていたFAQを、後半はSlidoで受け付けた質問をその場で回答するという感じだった。
- ヤフーは企画が東京にいるので連携必須
- メルカリ、ZOZOは単独でやってる メルカリは例のごとくDDDよろしく、福岡オフィスは「問い合わせ」周りのドメインを一手に引き受けているため、別組織と連携することはほぼない（もちろん共通処理とか基盤部分での連携は発生するだろうけど） ZOZOは研究なのでほぼ福岡、たまに青山。そもそもZOZO自体青山と幕張で組織間連携やってたこともあり、福岡拠点立ち上げも特に苦労はなかったとのこと
- 給与体系に違いはない 物価も地価も安い地方の方が儲かる…！
- 勉強会は東京よりも少ないが、その反面組織規模も大きくはないのでノイズは少ない
- 自分から動かないと情報が得られにくい部分はある
- Slackはどの会社もほぼフルオープン
組織の情報はできる限り隠さない方が良いのだろう。オープンな関係は組織ひいては個人の自主的な判断や方向性の決定などに寄与するもので、隠せば隠すほどその行動に制限や制約がかかってしまうと思う。 今回の対談のように、ある程度社会的にうまくいってると思われる会社には共通して「情報はオープン」というものがある以上、多分それはうまくいく上で必要な要素なんだと感じた。
