bon now

めっちゃ報告が遅くなってしまったが、9/22のデブサミ九州に行ってきたのでそのレポートを書く。意外と長くなってしまったので2つに分けようと思う。
なお、僕の参加したセッションは以下。（敬称略）

1. 【B-1】「スクラム」で、多様な背景を持つメンバーをチームにする
   発表者： 吉谷 愛 [フロイデ/フロイデール]
2. 【A-2】Webフロントエンド、改善の積み重ね
   発表者： 穴井 宏幸 [ヤフー]
3. 【A-3】なんちゃってUX、なんちゃってサービスデザインにならないために
   発表者： 吉川 伸彦 [UX FUKUOKA]
4. 【A-4】アジャイルウェアがスクラムを？！スピード成長するパッケージ製品の開発とサポートに、アジャイルプロセスで立ち向かったお話
   発表者： 川端 光義 [アジャイルウェア]/平川 隆仁 [アジャイルウェア]
5. 【A-5】SKYDISCのIoTを支えるテクノロジー
   発表者： 大谷 祐司 [スカイディスク]
6. 【A-6】スケーラブルエンタープライズアーキテクチャという挑戦
   発表者： 横路 隆 [freee]
7. 【A-7】九州スタートアップ事例最前線
   発表者： 春山 慶彦 [ヤマップ]、カズ ワタベ [ウミーベ]

とりあえず順番に簡単なセッション内容と所感を述べる。 なお、僕はどの会社とも利害関係がないので、本当に思ったことをつらつらと書く。 さすがにどうかという表現は避けつつも、ちょっと辛辣になる部分もあるかもしれないがそこはご容赦いただきたい。

【B-1】「スクラム」で、多様な背景を持つメンバーをチームにする

https://speakerdeck.com/ai_yoshitani/sukuramudeduo-yang-nabei-jing-wochi-tumenbawotimunisuru

まずこれは僕が悪いのだが、デブサミはデベロッパー向けとは言いつつもどちらかといえばビジネス寄りのスタンスであることが前提である。 それを念頭に置いていなかったため、少し物足りなさを感じた。個人的にはデベロッパーなんだから開発者視点で物事を色々と語ってくれるんだろうと思ってたので、その点についてはちょっと残念であった。

共感できた部分は、「視野が狭くなればなるほどやるべきことができなくなっていく」というもの。 僕も大手SIから、教育制度もキャリアもきっちり決まっているわけでもなければ自ら何かしないとどうしようもない組織の壁みたいなのをベンチャー企業で感じているからすごくよく分かる。めっちゃ愚痴りたい。「社員を会社が育ててくれない」「あっちの組織が良い感じに連携してくれない」と。 発表者はこの現象から、上位30%未満のエンジニアは学ぶことをやめて、すべてを会社や環境のせいにして逃げる=成長できなくなる と説いている。 社員数の少ないベンチャーが、最初の人材増員でぶち当たる悩みみたいだなと思った。ようするに贅沢な悩み。成長できているということを裏付ける証拠だからだ。

というのも、人が増えれば自ずと価値観や信条も人間関係とともに複雑化・多様化するのが常なので、それを受け入れる体制や環境、制度の整っていないベンチャー成り上がり成長企業の器から大量の人間がこぼれ落ちてしまうのは、至極当たり前な話である。 企業が成長できていたのは、バイタリティに溢れた少数精鋭のハイパフォーマンス集団のおかげであることをここで認識するわけだ。贅沢だ。ゆっくりゆっくりと着実に成長していった凡人集団のベンチャー企業に対して、ごめんなさいしてほしい。まぁこれは半分冗談だとして、そういう状況から脱却するために発表者はどうしたのだろうか。その1つの施策が「経営をエンジニアに任せてみよう」であった。 これ、エンジニアならわかると思うけど、基本的にエンジニアリングしている段階での予算の確保や工数見積もり、日々の数値的報告などなどは、プログラミングという芸術作品の作業に没頭したいエンジニアにとって大変面倒で意味の分からない作業である。 なぜなら、その数値が自分たちの作業の「何に」影響するのかがわからないし、考えたところで目の前の問題は全く「なくならない」からである。 そういうわけで、結構適当になって結果上司やマネージャークラスからの徹底的な「束縛」が始まる。 こうなるとエンジニアは窮屈になって、知りもせず知りたくもやりたくもないノルマやタスクに忙殺されることで次第に逆恨みが強くなり、結果離職という結末だったり病気休職となったりする。IT企業あるあるネタである。 で、別のスクラム事例のセッションにて後述するけど、大抵の場合この状況に陥ると、人単位だけでなく組織単位で組織同士でいがみ合って歪が生じる。 これを解決する術が「スクラム」ということである。

認定スクラムマスター！めっちゃ響きがかっこいい。（実際は講習会に高い金を払って試験に受かれば誰でも認定してもらえるっぽいですが……さて？） そしてスクラムで組織が改善したー！うちの会社の紹介〜！という感じでセッションが終わったが、僕はもっとこう、スクラムとしてどういう問題にどうやって取り組んだのかとか、取り組み方の精神論や概念的思想ではなくて、メソッドを知りたかった。こんな風にちょっと悶々としながら終了。 実際、僕がここに書いた内容では、スクラムによって険悪な会社の雰囲気がどう改善したかについては全然わからないので、多分他の聴講者も分かってないと思いたい。ただ、言いたいことはすごく伝わった。 また、僕はどっちかというと数字が好きなので純粋なエンジニアではないなぁというのも漠然と感じた次第である。

【A-2】Webフロントエンド、改善の積み重ね

スライドと一緒に関連記事を貼っておきます。
https://www.slideshare.net/techblogyahoo/developers-summit-2017-kyushu
週1時間の取り組み「KAIZENアワー」は技術負債の解消にとどまらない、エンジニアが成長する場として機能【デブサミ九州2017】

いきなりエンジニア寄りの話。スライドにコードが出てくる。突然のGithub上のOSSツール紹介。これついてこれない聴講者めっちゃいるんじゃない？と感じるくらいに（笑） 実際、発表者の紹介したOSSツールについて既知だった人（会場内で挙手するように求められた）は、4人とかそのくらい。大目に見ても聴講者の1割にも満たないと思う。さすがYahoo!のJavaScriptの黒帯さん。我が道をひたすらゆく。

まず印象的だったのは広告のデモ。マーケティングやWebディレクションとは全く無縁の環境に身をおいているので、こういうふうにして遊ぶ（仕事する）のかーと感じた。その後実際にWebフロントエンドをどう改善していったかという話に入っていく。発表者はJavaScriptの人なので、話の内容も必然的にそれ。もちろんエンジニアならご存知のとおり、昨今のJavaScriptは技術やツール、ライブラリなど色々と日進月歩過ぎてまじで辛い。ガンガン改善していかないと負債をためまくること必須の凶器である。そのためJavaScriptには技術が陳腐化しないよう現在の流行を追いかけるというまるでファッションのそれのような様相を呈する。発表者の場合、最初はちまちまと改善を進めていた（主に発表者が）ものの、段々とプロジェクトのスピードや他プロジェクトとのコーディングスタイルの乖離が出始めて、「これ一人じゃ無理だわ」という状況に陥ってしまったようだ。これは僕も経験がある。業務委託でプログラミングをガンガンしもらうと、所々のスタイルが一致しておらず同じ機能でも違う画面や操作によって挙動が変わってしまうとかいう余計なバグの温床になるあれだ。最初からそれとなくコーディング規約を用意して必ずコードレビューを通すとかすることで未然には防げるだろう。しかし、1年経つと「そのコードスタイルじゃエラーになるんで」とか「それ今後はやめてね」とかいうのに必ず遭遇するのがJavaScriptだ。もう頭を抱えるしかない。

そのような状況になった後、同社では、サイボウズのシステムの悪いところや直したほうが良いところを改善する「KAIZEN文化」からインスパイアを受け、週末の1日1時間だけを業務時間から切り出し「KAIZENアワー」というルールを作り出した。この方針はプログラム開発だけではなく、プロジェクトの進め方とか、物事の取り組みなど、とても広義に活用できるものだ。例えば子どものテレビの時間が長く、お風呂に入る時間や寝る時間に影響が出ていることがわかった場合、ルールとして「テレビは1日2時間」とか「21時には寝室に移動すること」という明確な家庭内ルールを作ると思う。ことにプログラミング作業においてはエンジニアに対して大変自由度の高い裁量を与える場合が多いため、たとえ細かすぎるルールであったとしても、ある一定の方向性をもたせるためには必要不可欠である。もちろんそれはエンジニアが個人ではなくチームとして組織され、運用されることが前提だ。チームである以上、人である。物事の考え方も捉え方もバラバラなので、当たり前のようにプログラミングにおける表現方法や実装もバラバラだ。

セッションの中身はスライドを見ていただければわかるように、大変具体的にコードスタイルの統一や静的解析をどうやって進めていったかについて述べられている。ESLintやFlow、jscodeshift、jestなどを使って、JSXをふんだんに使ってやばくなったReactのコードをいい感じに変換・解析する方法や、チーム間でバラバラになってしまったコードスタイルの統一をやりたいという場合は、是非一度資料に目を通していただきたい。

ちなみに僕はマネジメントよりのエンジニアなので、改善の内容よりその取組そのものに興味を持った。自分のとこでもなんかしら施策が打てるといいなぁと思いつつ、作業のリードタイムが求められる現場なので、1週間のうちの1時間を捻出することさえももったいない気がしている。というか、文化づくりより先に先ず隗より始めよということで、発表者のように自らが率先して行動し、そこから見えてきたやるべきことややったほうが良いことをチームに議論してもらう方針のほうがいいだろうなぁとは思う。僕が全く以て二流エンジニアであるということを除けば、だが。。 （やっぱりなんといっても重要なのはアウトプット能力とそれが表に出てくるまでの時間の短さだと思っている。要するに裁く力）

【A-3】なんちゃってUX、なんちゃってサービスデザインにならないために

https://speakerdeck.com/nobynoby/nantiyatuteux-nantiyatutesabisudezainninaranaitameni

このセッション、僕の参加したなかでは唯一写真撮影が禁止だったので、あ、資料公開されないんだろうなとか思ったんだけど、普通に公開されていた。。

さて、本セッションはエンジニアにとっては多分いちばんの門外漢なネタであろうUXについての話。でも僕は言いたい。WebアプリケーションやWebサイトにおいては、５感のうち視覚や聴覚の2つは余裕でデザイナーが解決できる話ではあるが、全体的なフィーリング(感覚)においてはそうではないと。そして、多くの人間が違和感を覚えるのは、この一番曖昧でわかりづらい体験についてである。例で言うと、クソほど遅いWebシステムは、「なんかページに遷移するまでがなんか遅い」という意見が上がるだろうか、これについてでは実際何秒くらい遅いですか？何秒くらいがちょうどよいですか？と問うても、だいたいバラバラの答えが返ってくる。それは、その顧客が持つデータ数だったりデータの依存関係だったり、もしくは顧客のインターネット回線を含むインフラ環境だったり、曖昧かつ予測不可能な事象が多次元的に組み合わさって発生しているからだ。

と、そんな感じでエンジニアが取り組むべきUXの概念は実はちゃんと存在していて、デザイナがーとかいってるうちは絶対その域にはたどり着けない。ということに気づいてないエンジニアはけっこういるというのが僕の持論である。そして往々にしてその方々は、自らの表現（要するにプログラミングで言うところのきれいな実装や素敵な抽象化、単純明快な美しいアルゴリズムなど）に価値を置く。お客の目には絶対に止まることのないブラックボックスの中に想いを馳せる。大変残念である。 先述通り、僕自身はマネジメント寄りのエンジニアであるため、視点としてはどちらの視点も持ってると思ってるし、バランスを保って価値を提供したいと思っている。その考え方の延長線上にあるのがおそらくUXを考えるということなのだと思っている。 発表者も「アウトプット大事」と言っているので、まじで自分の思っていることは言葉なり文書なりでしたためて、組織のみんなに見えるようにした方が良い。僕自身も前職・現職では僕がおかしいなぁと思ってたりもっとよくできるんじゃないかと感じていたりしている点を、社内SNSとかWikiに書きなぐってた。幸か不幸かそのおかげで部署以外の人から声かけられることも増えたし、何より「あいつは色々考えてる」感を醸し出せる。何かやろうというときに声をかけてくれる可能性も増えるし、いいことばかりだ。 とはいえ、実際は心の底で思っていることは全く書いていなかった。それは組織への反逆心だとか信頼性のなさが原因なんだけど、結局僕は僕なりに、自分の力でなんとかしたいという思いの強いところがあって、そこだけは他人にどうこう言われたくないし、言おうとも思わないことを持っている。それがおそらく、信条とか価値観という個人の尊厳に値するものなんじゃないだろうか。もしいま、自分の仕事への取り組みを振り返ったときにそれらがなければ、探したほうが良いと思う。多分その作業はすべて現状の組織のあり方や仕事の取り組み方を整理し、改善すべき点や継続すべき点の洗い出しを行うことになるからだ。そうなれば、きっと今以上に自分のすべきことや考えるべきことが見えてくる。これがおそらく発表者の言うところの「ものさし」や「目の獲得」という概念につながるのではないだろうか、と思いながらUXやっぱよくわからないやという印象だった。