スクラムフェス大阪2019で発表してきた。 #scrumosaka

www.scrumosaka.org

無茶苦茶、緊張したけど、なんとか終えられることができて、一安心しております。 聴きにきてくださった方々には、お礼しかありません。 時間オーバーしてしまったのが残念でありますが、ツイッターを見ていると楽しんでいただけていたようで、脇汗をかきまくった甲斐がありました。

このセッションでは、コミュ障な自分がお客さんと直接対話する仕事に携わった時にとても参考になったCustomer Interaction Patternsを、自分の話を交えつつ紹介しました。

コミュニケーションを始めることが苦手なコミュ障の人にとって、コミュニケーションを始めるハードルが下がってくれたら嬉しいです。 エンジニアがお客さんに会いに行く、ってそんなことやる必要あるのかな？と思われる方も、エンジニアにとっても良いことがあるということをお伝えしたいことでした。 懇親会で数名の方々に声をかけていただいて、楽しんでいただけたようでホッとしました。

まだ明日もあるので、楽しんでいきましょう！

参考書籍

今回の発表準備や資料作成で参考にした本を紹介します。

パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)

クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う

この2冊はともに、パターン・ランゲージについての説明があり、今回はそこだけ参考にしました。 今回の自分の発表ではざっくばらんに紹介していましたが、「いきいきとした」や「美しい」ものを生み出す仕組みを作ろうという試みは大変興味深いです。

Keynoteで魅せる「伝わる」プレゼンテーションテクニック

プレゼンの魔法使いである長沢さんが書かれた本で、Keynote使いの人にとてもオススメです。 単にKeynoteの使い方の本ではなく、プレゼンテーションの作り方まで書いてあって、一冊でとても美味しい内容でした。 今回はここにあるのを色々試みようと思ったのですが、いい形にできず… 本番で使えるように、もうちょい練習をこなしていきたいところ。

カーネギー話し方入門 文庫版

全部は読めていないのですが、序盤のプレゼンテーションに関する心構えが読んでてとても興味深いものでした。 リンカーンなどの著名人がどのように演説に取り組んでいたのかといったエピソードがあり、それを今回は真似て、スライドの全体の推敲を繰り返して、スライドを作っていくようにしてみました。これは、先の長沢さんの本 自分の場合、ちゃんと言語化したりとか、話の構造を作り込んだりとかがまだまだだな、という気がしています。

Developers Summit 2019 2日目に行ってきた。

一日目はこちら。

昨晩のアンオフィシャル懇親会で飲みすぎたのか、今朝が冷え込んでいたせいなのか、はたまた虫歯のせいなのか、今朝は具合が悪くて、午前はまともに話を聞けなかった。

という気持ちにめげずに、参加したセッションについて忘れないうちに書き残しておきます。

ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～（太田 健一郎[スクウェア・エニックス]）

スクエアエニックスの某タイトルで実践した、AI for QAでの泥臭いデータの前・後処理についての話だった。 そもそもゲーム開発について自分は知らなかったし、テストについてもそんなに知識が無いので、色々と新しいことばかりで面白いセッションだった。

ゲームにおけるAIの位置づけは2つある:

• ゲーム内AI: ゲーム中に現れるキャラクターやナビゲーションで使用されるAI
• ゲーム外AI: ゲーム開発のために使用されるAI。開発支援ツールやQAなど。

このセッションで扱っているのはゲーム外の方だ。 ゲーム開発におけるQAもまた特殊で、品質についての観点が、期待どおり動いているかどうか、だけでなく面白いかどうかというもの。 後者は定義が難しいので自動化に向かないため、前者の期待通りに動いているかどうかを検証するためにゲーム外AIを使っていた。 ここで、狩野モデルを使っての説明で、前者は当たり前品質で、後者が魅力的品質。つまり、AIを使って、当たり前品質のQAを実装したとうことのようだ。

このセッションで扱っていたのは、とあるタイトルのガチャのQAについて。 ガチャにも決まりがあって、確率をユーザーに表示しなければならず、なおかつその確率どおりにアイテムが排出されることを保証しないといけないらしい。 ここまでの話なら、ひたすらガチャを回して、分布を検証すれば良さそうに思うのだが、ここでもゲーム開発特有の難しさが出てくる。 実機での検証なので画面のキャプチャを撮り、そこに写っている確率の表示を抜き出して、マスターデータの確率の値との比較をする手順となっているのだけど、

• ゲームの世界観を作り込むため、フォントが独自に作り込まれている
• Google Computer Vision APIを使っていたが、フォントを学習させるといったことができない
• アイテムなどの組み合わせによって色味とか変わってくる

と、かなり難しい要素が。自動での認識が怪しいところがあるが、偽陰性より偽陽性の方がゲームとしてインパクトが高いので、そちらを手動で修正できる仕組みで対処。 ここで、とても参考になったのは、「自動処理に一貫させようとせず、手動処理と組み合わせる」ということ。 本来の目的（大田さんの場合、全体の作業時間の短縮）を見失うことなく、全部できなくても部分だけで実現していくスタイルは真似ていきたい。

途中紹介していた前処理大全が泥臭いデータの扱いについて書いてあるそうなので、読んでみよう！

前処理大全[データ分析のためのSQL/R/Python実践テクニック]

ことばだけでは足りません、描いてシェアして伝えていこう！（高野 明子[Sider]）

Devsumi 2019 ことばだけでは足りません、描いてシェアして伝えていこう！ from akiko_pusu

SiderはSideCIのころからちょくちょく使っていて、いつもお世話になっております。 このセッションのスピーカーの高野もいつからかわからないけど、Twitterでフォローしていて、

• 絵でわかりやすく技術のことを解説する人
• お母さんエンジニア

というイメージを持っていた。なんだかわからない一方的な親近感があったので、このセッションには何故か「行かねばなるまい！」という気持ちで参加しました。

セッションタイトルから、「グラレコとか絵のテクニックとかそういう話かな」と勝手に思っていたのですが、予想を裏切る良い話を聞けました。 「インターネットは優しい世界」というのは、同感しかありませんでした。自分もOSS活動の中で、Pull-requestやIssueを貰ったりする時に優しさを感じます。 何のお返しもできない無償なのに、なぜこうも動いてくれたのか、と。 また、自分も今がキャリアの分岐点と思っていたころだったので、先を行く人がどのように考えているのかを知ることができ、大変参考になりました。 「若い人の方が成長が早く、すぐに追い越していく」という時代の中で、自分は競うことしか考えてなかったのですが、自分の持ち味や好きなことを生かしていく道というのがあるのだと思いました。

おそらく、ここには書かれてないような辛いことや苦労したことがあるのだと思います（勝手な妄想）。 それでもなお開発が好きでいられるエンジニアとして歩んでいる人がいる、ということが知れて、とても励みになりました。

あ、でも絵の書き方とか練習のコツとかも教えてほしいなぁ🎨

デブサミ、ありがとう

漆原さんと高野さんの話には、これから先もエンジニアとして開発をやっていきたい自分にとってとても励みになった。楽しいと思えるからこそ、やっぱり続けていきたい。 高野さんの話にも含まれていたし、1日目の角さんと永瀬さんの話でもそうだけど、自分より年下の人たちの方がより新しいことに真っ先に触れているし、そこからの伸び率も高い。 そういった人たちと今後どう付き合っていったらいいのか、そういうことを考えるための参考にしたいと思いました。

毎年そうなんですけど、今年もお腹いっぱいのデブサミでした。 実行委員の皆さん、スピーカーの皆さん、ありがとうございました！

Developers Summit 2019 1日目に行ってきた。

devsumi2019

毎年恒例のエンジニアの祭典Developers Summit 2019に行ってきた。 今年はスピーカーでも当日スタッフでも無く、ただの参加者です。 やっぱり個人スポンサーになっておくべきという後悔を初っ端からしてしまった。最前席がやはり最善。

全部のコマをセッションで埋めるつもりは無いので、聞きたいところに行き、なるべくAsk the speakerでスピーカーにお話を伺うのがやはり良いなと思いました。 こういうスタイルのイベントを長く続けているのは本当に尊敬する。 その中でも、少しずつスタイルを変え続けていて、今年はスタッフの方々がスタッフTシャツを来てて、お祭りっぽさがあってとても楽しい雰囲気を感じる。 例年だと、スーツのホテルマンみたいな見た目だったから、ちょっと話かけづらかった（個人的見解）。

以下、参加したセッション

❤一生エンジニアを楽しもう❤夢中が最高！！ 漆原 茂 [ウルシステムズ]

タイトルにあるようにずっと「一生エンジニア」でいるための方法について、それがなぜ良いのか、そしてそれを裏付ける様々な分野の研究の成果を紹介してくれた。 昨年、ほぼ同じタイトルの話をしていたので、また聞きたいなー、と思って来ました。 けれど、昨年に比べて、追加で新しい話が加わっていたので、非常に面白かった。

プログラマー35歳定年説を否定するものとして、そもそも何かを学ぶことについて年齢での衰えが無いという話、もしそれが劣化するとしたらそれは環境要因の方が大きいという話はだいぶ希望をもらえた。 特に、環境要因として4つ挙げていた。

1. 毎日プラスになるサプライズがある
2. 未来を楽しみにしている
3. 同じ気持ちの仲間がいる
4. 幸せにあふれている。

幸いなことに今はこの4つを満たせていると思っている。 1は毎日何か新しいことを学ぶ時間をきっちり取るようにチームで決めて、実施している。2は、自分たちの気質上なのかそういう話が多い。3は、1と2がチームでできているので大丈夫だと思う。4は、1から3の状況が自分としては幸せな環境だと思っている。 色々なことがあって、偶発的にできているような感じもするので、どうやったらこれを再現できたり、まわりに拡大できるかは考えないといけないんだろうな。というところで、示唆を与えてくれるセッションだった。

Togetterのまとめは、こちら。

togetter.com

大学におけるイマドキのエンジニア教育 角 征典[ワイクル] 永瀬 美穂[アトラクタ]

産業技術大学院大学や筑波大で行われている文科省プロジェクトenPiT、東工大で実施されている産学連携のPBLであるEDP（エンジニアリングデザインプロジェクト）で教えている実践的な開発の教育についての話だった。

永瀬さんの話では、「学び方を学ぶ」というのがとてもおもしろかった。 大学の教育だと課題（おそらく情報理論とか線形代数のような科目）を教えていくのは、今後も変わらない理論ならいい しかし、ソフトウェア開発やそこで使う技術は数年単位で変化しつづけるので、それを学びつづける必要が出てくる。 なので、「学び方」自体を学ぶ必要があるということだ。午前に聞いた漆原さんの話と少し繋がるところがあって、面白い。 正直、自分が学生だったら、こういう授業がある大学を選びたいなって思った。

角さんの東工大のEDPの話は、詳しくは書籍に書いてあるのでプロジェクト自体についてはそちらを読むとグッとくるんだろうなと思う。 個人的には特に角さんが書いた章の文体というかノリがとても面白いし、そういうふうに面白く書けるだけのプロジェクトだったんだなという風にとらえている。 あと、裏設定として採用につなげているところなんてのも、とても良いと思った。 自分が就職活動中に難しく感じたのは、企業で働くイメージが想像しづらいというところだった。 PBLで擬似的にでも何らかのやりとりをスポンサー企業とやっていれば、かなり働くイメージがつきやすいと思う。 これは学生側だけでなく、企業にとっても同じだろう。

エンジニアのためのデザイン思考入門

途中で参考書籍として挙げていた、金出先生の本も読んでみたいなぁ。

独創はひらめかない―「素人発想、玄人実行」の法則

EDPの情報はかなり公開されてるので、あとで眺めてみよう。

titech-edp.github.io

そして、こちらもまたセッションの最中のツイートがToggetterにまとまってる。

togetter.com

アンオフィシャル懇親会

connpass.com

例年懇親会はなく、勝手に集まって飲みに行ったりとかはあったのですが、今年はアンオフィシャルという名の実質公式懇親会が開催されました。 参加者とスピーカーの人たち、そして本当はデブサミ行きたかった人とかデブサミに想いがある人達が集まっていた感じがしました。 ノラLTしたり、コミュニティの告知したりしながら、寿司をつまんでわいわいできたので、とても楽しかった。 途中で、やっとむさんの心理的安全性ゲームで遊んだのだけど、とてもおもしろかった。

運営してくれた滝川さん、会場提供のAkatsukiさん、ありがとうございました！

とりあえず初日はこんなところで。

二日目も書きました。 satoryu.hatenablog.com

DENSO Meetup Yokohama #1 に行ってきた。

自動車業界の中でも有名なデンソーさんが、新横浜に独立した内製の開発組織を作っていて、その部署とクリエーションラインさんの共催イベントの第一回目に行ってきました。 Attractor社の吉羽さんがコーチに入っているという話を以前に伺っていて、昨年のデブサミでも講演していたり、大企業の中でアジャイル開発の導入を取り組んでいることは知っていました。 このイベントでは、1年半前のオフィス立ち上げから携わっているエンジニアの方々の話を聞くことができました。

connpass.com

オフィスの一室のでっかいテーブルとでっかいディスプレイをわいわい囲んで、ひさびさに「勉強会」っぽさあるミートアップでした*1。

RoR未経験なのに、3か月でプロトタイプ開発した話 @hiroky_814

最初はGoで書いていたサービスを酔った勢いで本人も使ったことが無かったRailsにしようという提案が採用されて、そこからどういった開発や学びの話でした。 チームで意思決定できる環境で、新しいことにチャレンジしやすい反面、過去に作ったものが負債になってしまうということや、機能ごとに実装した人しかわからなくなってしまうような属人化があるなど、スピード重視で作ったときのあるある感がありました。 しかし、開発の途中から「品質を優先」として、rubocopを入れたり、OSSを読んだり、外部からRubyistを呼んでRails Wayを学ぶといった取り組みをしたそうです。 新しくチームが立ち上がった時に、レビューには他のチームの人たちを招待するという取り組みはとても面白いと思いました。

AWSの機能が増えすぎて、Ruby実装をやり直した話 @じゅんじゅん

SQLのためのRubyでバッチ書こう！
→ AWS Lambda がSQS対応
→ じゃ、Pythonで書こう！
→ AWS Lambda Rubyで実装可能に （イマココ #densohack

— さとりゅう 🌸 たつや学院 (@sato_ryu) 2019年1月23日

パブリッククラウドのアップデートと開発との追いかけっこしてしまった話でした。 作ったり、作ってる最中にほしかったものがリリースされるのありますねーｗ

テスト駆動開発(TDD)の紹介 @安井 力(やっとむ)

昨日は、TDDBCの資料をベースに、TDDの説明とFizzBuzzを例に実演をしてくれました。

TDDBCの資料はこちら。 speakerdeck.com

• 動かない汚いコードから、きれいで動くコードへ向かう道は二通り。きれいにしてから動くようにする、もしくは動くようにしてからきれいにする。
  • 前者はきれいにすることにいくらでも時間を注いでしまいがちで、きれいにしてから動くようにする時にうまくいかないことがわかったりする。
  • 後者はTDDのとる道。動くようにし、動くとは何かをテストで書いて、それを維持したままきれいにしていく。
• まずはToDoリストを作るところから始める。
• テストの方が負債化しやすい。だから意味のあるテストを残し、それがわかりやすいようにする。
  • RSpecではdescribeのネストができるので、それを使って、ToDoとの関連を記述していたのは学びだった！例えば、 describe "3の倍数"みたいに。
• テストを取り除けるのは書いたあとすぐ。時間が経つと除去していいのか不安になる。そして他人が書いたコードとなるとさらに不安。

TDDってコードだけではわかりづらくて、どう書いているか流れを見たかったので、こっそり動画に撮ってたんですが、アプリが固まって保存できてなかった… 一昨年に出た新訳のテスト駆動開発は、サンプルコードに差分が載っていて、どう変更していったのかが追いやすくなっていると教えてもらいました。

テスト駆動開発

懇親会とふりかえり

クリエーションラインさんからヤッホーブルーイングのクラフトビールの差し入れをいただき、懇親会。 自己紹介したり、今やってることの話しをしたり、TDDの話をしたり、ワイワイしてた。

#densohack でよなよな！ #creationline さん、ありがとうございます😊 pic.twitter.com/ffj1RjMP1H

— さとりゅう 🌸 たつや学院 (@sato_ryu) 2019年1月23日

第1回目のふりかえりは、@yattom さんがいたので、もちろんここはFun-Done-Learn。

やっとむさんとFDLの話ができて楽しかった。

次回は秋葉原のクリエーションラインさんで開催するみたいな話が出てました。

おまけ

爪痕を残した(๑•̀ㅂ•́)و✧

#densohack DENSO meetupに参加頂いた皆さん、ありがとうございました！
なぜか、ローマの休出だけが変に頭に残ってます

— avance7 (@Sen_Koizumi) 2019年1月23日

*1:勉強会っぽさって何だよ、というツッコミはお控えください。

Regional Scrum Gathering Tokyo 2019のスタッフをやってきた。 #RSGT2019

年に1度のスクラム開発の祭典Regional Scrum Gathering Tokyo 2019 に、当日スタッフとして行ってきました。 正月休み明けの三日間、新年の始め方としてはとても有意義な始め方になりました。

来た理由

本当は今年は来るつもりはありませんでした。昨年のRSGT2018が終了した時には、そう思ってました。 2014年からほぼ毎年スタッフやらスピーカーとして参加してきたのですが、昨年の時点ではちょっと飽きを感じていました。「特別面白いセッションが無ければ来ないなぁ」なんて思っていました*1。 今年来た一番の理由は、弊社新卒の勇姿を見るためです。昨年の夏、突如訪れた新卒向けのエンジニア研修で、最＆高な姿を見せつけてくれた彼らがRSGTのオオトリとして発表してくれた。研修最終日のデモで与えてくれた感動を再び魅せつけてくれました。思わず泣きそうになった人も少なくないはずではないでしょうか。 素直で真面目で、それでいて楽しもうという気持ちを忘れない、そんな彼らがいくつもの壁を乗り越えた話はいろいろな方々に知ってほしいです。セッションの詳しい内容については、以下の記事をご参照ください。

• 学習する／Unlearnするチームへ #RSGT2019 | TAKAKING22.com

やったこと

スタッフとしては、セッションのタイムキーパーやスピーカーの呼び込みや、その他の雑務諸々を落穂拾いのようにやっていました。 それとは別に、（自分が勝手に）担当していたのは、「賑やかし」でした。

• スタッフとして参加者のみなさんに声を掛けるときに、少しでも楽しい気分になっていただくために、つまらないことを言ってみるとか、
• Twitterのタイムラインに会場の様子などを書き込んでみたりとか、
• RSGT名物「ハイタッチ」への呼び込みをしたりとか、
• クロージングキーノートの前説をやってみたりとか、

をしていました。少しでも楽しんでいただけたのでしたら、嬉しいなぁ。

次回予告

さて、今回のRSGT2019ではプロポーザルを出したのですが、落選でした。なんと、その落選してしまった内容を来月に大阪で開催されるScrum Fest Osakaてお話させていただけることになりました！ ここでは、自分がこの4、5年くらいの間にエンジニアとしてユーザーやお客さんと接してきた中でやってきたことと、それの助けになってくれたある教えについてお話します*2。

confengine.com

www.scrumosaka.org

ということで、ほなサイナラ。

*1:いやーいかにも受け身な感じで嫌なやつだわ。自分で面白いセッションを作ればいいのに、と今更思う。

*2:周りにも話をしたことないので緊張するわー