Developers Summit 2018 KANSAI（デブサミ関西2018）に参加してきましたので、参加したセッションの紹介と、所感を書いていきたいと思います。
毎度のことながらデブサミは特定の技術にウンウンというよりは、いちエンジニアとしてこれからどうやっていくか、とてもポジティブに頭を活性化させることができる、とてもよいイベントです。今回もとても勉強になりました。
本も書いましたよ！
今日の戦利品。缶バッジも攻撃力上がりそうなのを厳選して買ったぞ。 #devsumi pic.twitter.com/F0DO8uMx9W
— Koji Saiki (@saikou9901) 2018年9月28日
【C-1】Mackerelの200週連続リリースの舞台裏とこれから
https://event.shoeisha.jp/devsumi/20180928/session/1814/
内容
所感
うちは受託開発なので関係がないよう・・・ということは全然ありません。
いくつかのポイントで、受託開発でも心がけていきたいことがありました。
- スモールスタート
ある程度要件ががっつり固まった業務システムではなく、お客さんと一緒に作り上げる受託開発（というよりはこういうときは準委任契約でしょうが）はありますよね。こういうときには何が本当に必要なのか、ということは最初の時点ではわからないことがあります。
それに「要件ががっつり固まった」とは言ってもその要件が本当に必要だったのか、ということは最終的にリリースされるまでわかりません。作ったのに使われない、という場面を、私と同業者の人はなんども目にしてきたと思います。
その場合も「これは後で考えませんか」という手段を、とっていくことはお互いに悪いことにはならないと思います。
- メンバー入れ替えによる鈍化を防ぐ施策
SIプロジェクトでも、負けず劣らず人の入れ替わり（特に派遣、SESの方が）というのは激しいものです。
その時チーム内でどのようなことが行われるかというと、だいたい「歓迎会」として飲み会開催して終わり、あとはコミュ力高い（ように見える）人が会話たまに会話するくらいで終わり、という現場は多いと思います。 もし歓迎会の開催者が内々で「これはその人の特性を知るための機会なんだ」と思っていても、それをメンバーが認識してないこと・その施策によって知ることはできないこと、ということがわかっていれば、短絡的な手段にはならないわけですね。
その人から掘りだすスキル、お酒を飲める・飲めない、みたいな不安定・刹那的なものではなく、スキルマップのように客観的に・メンバーが平等に閲覧可能な手段を用いることが、ダイバーシティ（ドヤ）なんじゃないかなーと思います。
ほかにも、うちではこういうふうに応用できるぞ！というポイントはきっとあるんじゃないかと思います。発明していきたいですね。
【B-2】B2Bクラウドサービスをゼロから立ち上げて、利用社数が1000社を超えるまでの道のり（仮）
https://event.shoeisha.jp/devsumi/20180928/session/1808/
内容
※資料未公開（参加者アンケートの配布だけかな？）
INGAGEさんと、サービス「Re:lation」の経緯、その中で起きたトラブルの紹介のお話。
40歳ぐらいで家庭もあったのに、スタートアップに臨んだ勇気がすごい。
所感
後の方のセッションでもありましたが、サービスを検討するにあたっての「MVP(Minimun Viable Product)」が永遠の課題なんだろうな、ということを感じました。 同時に話にあった「でも、食べていかないといけないので、一部で要望されたものを実装することもある」ということもある。 これは、わたしたちが開発しているものが"サービス"である、ということを再認識させる。芸術作品ではなく、理論に基づく製品であるということ。
次のセッションの内容を見ると、サービス業向けの製品でも、ちゃんと理論に基づいて開発することの重要性がわかると思います。
【B-3】ユーザー体験にフォーカスした管理画面の実装
https://event.shoeisha.jp/devsumi/20180928/session/1809/
内容
この資料について解説が次のブログ記事にあります。後から読むならこっちの方がいいかも？
所感
本当に素晴らしい！って心から思いました。 デザインはセンスだと思っている人にぜひ読んでほしいですね。 やっぱりアプリケーションのデザインは工業デザインであって、理論が存在するんですよね。 全体的に研究発表感あって、とても読み応えあります。
定量的計測は数値をもって、定性的計測はアンケートをもって計測しましょう。言葉にするのは簡単ですがこうやって実測してそのデータが見られる機会は少ないと思いますので、とてもありがたいです。資料も丁寧でわかりやすい。
適切なボタンデザイン、画面上のレイアウト、SIにおける画面設計においても目をつむったり無脳になることはできても、避けて通ることはできません。同じ人間である以上、同じような物事を行う、同じようなコンピュータシステムの画面を取り扱う時の傾向や反応というのは、同じ（傾向になる）はずです。
動画でアイトラッカーの映像を見せてもらいました。ブログ見たところこれですかね。
SteelSeries Sentry Gaming Eye Tracker 視線測定機 69041
- 出版社/メーカー: SteelSeries
- 発売日: 2015/04/28
- メディア: Personal Computers
- この商品を含むブログを見る
２万円くらいで買える、という話でしたが、こういうのもあるっぽいですね。
Tobii Eye Tracker 4C Gaming Peripheral
- 出版社/メーカー: Tobii
- メディア: Video Game
- この商品を含むブログを見る
SIにおいても、運用・保守の中での改善施策として、このお話は大いに役立つと思います。
必読！ #devsumi https://t.co/BoBC7utfCg
— Koji Saiki (@saikou9901) 2018年9月28日
【A-4】なぜYahoo!カレンダーはPHPからKotlinへ技術移行を進めるのか
https://event.shoeisha.jp/devsumi/20180928/session/1803/
内容
所感
2000年からあるYahooカレンダーをKotlinでリニューアルしている話。
過去の慣習（資産じゃないよ）を忘れて、目的を見据えて本当にあるべき姿を目指して検討、実施する。理想的なエンジニアリングだなぁと感じました。
理想的なエンジニアリングを進めるのに大事なのは、周囲のメンバーの理解・協力だと思います。それを1 on 1や期待値合わせで実施している、という感じかと思います。 Yahooさんも結構入れ替わりがある会社だと思うので、そのあたりのケアを「実践することへの理解がある」のかな、と思います。
【B-5】
https://event.shoeisha.jp/devsumi/20180928/session/1811/
農家と流通業者のタッチポイントにLINE Botを導入した話
内容
所感
なんたって、これです。
「開発者が適切な設計をすれば、誰でも使えるようになる。」響く。 #devsumi #devsumiB pic.twitter.com/hIFtBEceuA
— Koji Saiki (@saikou9901) 2018年9月28日
ITサービスの提供先として、次数の少ない産業、地方、高齢者などさまざまなターゲットがありますが、この視点を忘れてはいけないと思います。
人間の適応能力というのは高いもので、生きていく上で避けて通れないものになると、簡単に慣れてしまうものです。 スマホが大きくなっても、１週間も経てば違和感がなくなります。
実際セッションの中でも、農家さんから「電話やメールがほとんど無くてもよくなった」という声があった、というお話がありました。
こういうエンジニアリングが、真にインクルーシブなエンジニアリングなんだと感じます。見習っていきたいです。
新技術で未来の扉を開け！ - Node-REDの環境構築と社内導入 -
内容
www.slideshare.net
Node-REDという開発ツールの紹介でした。
端的には、JavascriptコードをWebブラウザ上のGUIで開発するツールですね。
出来上がるコードとしては、基本的にイベントフローですかね。
- イベントのトリガー
- 最終的にどこにどんなイベントを投げるのか
- その間をつなぐ変換（ビジネスロジック）
という感じですかね。
所感
セッション内でもありましたが、べつにIoT機器だけにしか使えないわけではないです。 イベントトリガーにHTTPがあるので、Webアプリケーションの開発としても利用できるわけなんですね。
ちょっとしたツールを作るのに使えそう。こんど試してみます。
【C-6】Javaを活用したマイクロサービスのためのKubernetes活用
https://event.shoeisha.jp/devsumi/20180928/session/1819/
内容
資料は非公開のようです。
本日のてらだよしおさん。
セッションの紹介には
- 本番環境でDockerやKubernetesを活用するためのノウハウをお届けするケース・スタディ・セッション
- 既存のオンプレミスのアプリケーションをKubernetes環境に移行するためにどのような所から手をつけるのか、さらには12 Factorの手法を利用したマイクロサービス・アプリケーションの開発、クラウド・ネィティブ・アプリケーションのKubernetes上での活用方法などを詳しくご紹介
- CI/CD環境を数クリックで構築可能なDevOpsプロジェクトや、サービスメッシュ技術の一つIstioを利用したカナリー・デプロイなどKubernetes周辺の有用なツールもご紹介
とありましたが、当日は内容変更。大切なエモい話が中心となりました。
ざっと概要を。
今後のアプリ開発は、企業・エンジニアのそれぞれで二極化していく。
企業は、デジタルネイティブの世の中で生き残っていくために「ソフトカンパニー（※ソフトウェアという意味と、企業として柔軟、といういみもあるのかもしれない）」にならないと生き残れない。
同じ事業を行なっている企業でも、ソフトカンパニーになりきれない企業は世界の時価総額ランキングから消えていった。時価総額ランキングにNetflixはあるが日本の民放は全くない。イエローキャブのマーケットはUberに取って代わられている。
エンジニアにとって、過去の経験や技術を使ってそのままモノをつくることは、安定していてリスクが少ない。しかし、先に挙げたようにそのままのモノをつくることは企業にとっては大きなリスク（生き残れない）になる。
エンジニアは学び続けることが、生存戦略になる。だが、日本のエンジニアにはそもそも学ぶことにおいて大きなハードルがある。それが英語。
企業のシステムをどう変化させるのか、というのに正解はない。企業にはそこに存在する人間がいて、その人間は他人である。だからよくある「他社で成功した事例」をそのまま持ってくることは、適合することはない。
銀の弾丸はない。「マイクロサービス」「Kubernetes」が必ずしも正解であるということはない。「とりあえずやってみたい、コンテナ導入したい」これが一番よくない。
クラウドネイティブは、ものづくりの仕方が大きく変わる。12 Factor App、Agile、チーム構成、Reactor Manifest、Devops……
システム障害は起きる。長年起きないようにがんばってきたが、起きる。起きても大丈夫なような構成（※フェールソフト）、分散コンピューティングを意識した開発が必要になる。そこで「Release It!」という本はおすすめ。
Kubernetes、入門サイトなどでHello Worldレベルがこんな短いyamlでもうデプロイできますよ！というのはあるが、実際それだけでは本番運用できない。しっかり要件を落とし込んで設定を記述することが必要。
Kubernetesはまだ始まったばかり、安定していると思わないほうがいい。そこを正しく認識する。
またKubernetesはDev（開発者）のものではなく、Ops（運用）のものでもない。DevOpsのものである（チーム作りに必要な要件）。
Javaもスピードアップして変化していて、これは当たり前の流れ。いまは何年もかけて固めてリリースしても使い物にならなくなってしまう。JDK10からコンテナ対応が強化され、JDK11では多くの既存パッケージ削除、カスタムJRE作成機能がある。
ITエンジニアは世界を変えられる力をもっている。明日からではなく今日からはじめよう！
2018/10/25追記
CodeZineからセッションレポートがでてきましたので掲載。
所感
おそらく上記のような内容に変更になったのは、舞台によるものかな、と思います。
デブサミは広く多くのIT関係者が集いますが、そのなかでこういったタイトルにすると、「うちも導入したい」という感じでセッションを聴講する人もいると思います。そういったレイヤーの人たちに、現実を意識合わせして考えていきましょう、という警鐘・気づきを得てもらうための内容変更かな、と思います。
私自身まだデジタル変革の現場に携わったことがないので、少なくともエンジニアとして押さえるべきところは抑えていきたいですね。
大変勉強になりました。
今日のてらだよしおさんの教え「英語をやるんだ」 #devsumi
— Koji Saiki (@saikou9901) 2018年9月28日
【B-7】勝てる「開発プロセス」の作り方 ―そのプロジェクト計画、本当に成功を確信して書いていますか？
https://event.shoeisha.jp/devsumi/20180928/session/1813/
内容
www.slideshare.net
所感
すばらしい。本当にたくさん新しい視点を教えていただきました。
なぜプロジェクトが怖いかというと、うまくいったところを想像できないから
プロジェクト活動において全ての行動は「価値探索」「試行錯誤」「製品化」のどれかになる
アジャイルを導入しようとする動機のほとんどは「不純！」（本当に言ってた）。アジャイルは「要求の正しさを素早く確認するもの」「要求の変化に追随するもの」。
など。
しかし、このセッションで本当に大事だと感じたことは、内容そのものよりもこの内容を生み出す源泉となる「なぜこうなっているのか」「どう考えれば良いか」というもう一歩自分の立ち位置から離れて考えることだということです。
でなければ、最初の「なぜ怖いか」やそのあとの「プロジェクトの三態」（このフレーズ自体は岡さんが今回考えたものだそう）を考えつくことはなく、今回の資料を後から読んだとして、「うちでも適用するぞ！」としかならないと思います。
これは、先ほどのてらだよしおさんのセッションのところで記載していた
- 企業のシステムをどう変化させるのか、というのに正解はない。企業にはそこに存在する人間がいて、その人間は他人である。だからよくある「他社で成功した事例」をそのまま持ってくることは、適合することはない。
に通じるものがあると思います。プラクティスをそのまま使う、ってやつですね。
そしてそれらも踏まえて辿り作るところとして、どんな現場でもそこで働いているのは”人間である”というところなんですよね。だからこそ、最後の「Work Together」という言葉が生じてくる。チーム作りと物づくりは切り離すことはできないということになるかと思います。
おわりに
「どんな現場でもそこで働いているのは”人間である”」と書きましたが、全体を振り返って、全てのセッションでそこに繋がる部分があったな、と感じています。
出てきた所感をならべます。
その人から掘りだすスキル、お酒を飲める・飲めない、みたいな不安定・刹那的なものではなく、スキルマップのように客観的に・メンバーが平等に閲覧可能な手段を用いることが、ダイバーシティ（ドヤ）なんじゃないかなーと思います。
話にあった「でも、食べていかないといけないので、一部で要望されたものを実装することもある」ということもある。
同じ人間である以上、同じような物事を行う、同じようなコンピュータシステムの画面を取り扱う時の傾向や反応というのは、同じ（傾向になる）はずです。
人間の適応能力というのは高いもので、生きていく上で避けて通れないものになると、簡単に慣れてしまうものです。
Devも、Opsも、その先のお客さんも、そのお客さんが相手にするお客さん（今回でいうとB-5の農家さんとか）も。
それぞれの人間が、本来持っているポテンシャルを引き出すこと。
こうやってITについて考えてると、結局、”人間”というものについてよく考えることになります。
私たちは人間なんですが、人間のことよくわからないですよね。いっしょに、人間について考えていくことで、本当に平和になってなんちゃらかんちゃら、なるのかもしれませんね。
こちらからは、以上です。人間です。
