夏サミ2017に行ってきた

今日は,「Developers Summit 2017 Summer」こと夏サミ2017に行ってきました。

http://event.shoeisha.jp/devsumi/20170728/

参加した感想

御茶ノ水で9:30から受付開始なので、普段の通勤に比べると朝がゆっくりできた.
会社なら遅刻って時間に起きた.

今回のテーマは
「エンジニアコミュニティが推進する新しい企業文化と開発の現場」
とのことで、コミュニティに関するセッションが中心.

【A-1】SIerとオープンソースの美味しい関係 ～コミュニティの力を活かして世界を目指そう～

発表者はNTTデータの鯵坂さん.
NTTデータでHadoopのサポートサービスに従事していて, Hadoopのコミッタ, PMC(Project Management Committee)をやっているという.

SIerとして, なぜオープンソースのコミュニティに参加しているのかという話をしてくれて

• なぜSIerが実施しているのか？
• Hadoopのサポートサービスを実施・継続するためにチーム内にコミッターが必要
• なぜサポートサービスをしているか？
• SIerとしてシステム構築だけでなく運用もひっくるため
• トラブルをお客様が満足する形で解決しなければいけない
• 自力でサポートすれば、お客様を満足させられるレベルのサービスが提供できる

という論理が、非常にしっくりきた。

また、コミッタになるため経過や、これからコミュニティに貢献するためのアドバイスとして
最初の一歩は、ドキュメントの修正がおすすめとのこと。

• 機能の進化にドキュメントが追従されていないことが多い
• ドキュメント通りに試してみて、間違いを修正するのがおすすめとのこと
• ドキュメントは読む人が多いので重要
• ソースは開発者だけ
• ドキュメントは開発者だけでなく、利用者も読む
• 利用者へのお願い
• OSSの誤りの知見を内部で抱えたり、3rd party forumに書くのはやめてほしいとのこと
• 誤った情報が拡散したり、コミュニティが想定していない workaroundが蔓延してしまうため
• レビューアへのお願い
• ドキュメントの修正をしてくれる開発者を大事にしよう
• コミッタを目指す人へのアドバイス
• 必要とされる技術(英語含む)は後から身につく
  • 基本的にコミッタを増やしたい
  • 必要な技術は教えてもらえる
• 活動を継続できるかが最も重要
  • コミッタになってすぐ辞められたら、コミュニティが困る
• 数年単位で活動し続ける覚悟はあるか？
  • なるまで１年、なってからN年
  • コミッタになって何がしたいか

この後の他のセッション含め、コミュニティへの参加をしていこうと思うセッションだった。

【A-2】SoRとSoEをつなぐ「エンジニアの役割」と「企業の課題」

発表者はパーソルキャリアの清田さん.

非IT企業がシステムを内製化できるようになるまでの取り組みとエンジニアの役割を紹介.

• 内製化の必要性
• Try & Errorが必要
  • やって気づく問題点
  • 蓄積されていくナレッジ
• リリース後、素早く改善したい
  • 従来の開発プロセスだとスピード感が出ない
  • ベンダの請負開発だと難しい
  • 内部でやろうにも仕組みを知らないため、改善もできない
• そのため、難易度が高くTry & Error が必要なもの、ナレッジを内部に残したいものは内製化に
• なぜ内製化できたか
• 最初は優秀なエンジニアが必要
• トップがテクノロジーで会社を変える強い意志を示した
  • 共感した優秀なエンジニアがJOINしてくれた
• エンジニア採用
  • まずはエンジニアに知ってもらう
  • メディア露出
  • 勉強会への登壇、主催
• 社内風土
  • エンジニアの価値をしってもらう
  • 小さい成果をコツコツ出す
  • 所属部署以外にも積極的に絡む
• プロジェクトを回せることをアピール
  • 5名程度のチームで、内製BIをスクラム開発
  • IT部門との調整・交渉
  • 企画部門の人を巻き込み一緒に開発できると認知してもらう
• 見えた課題
• 非エンジニアとのエンゲージメント
  • エンジニアが能動的に動かなければいけない
  • 社内調整、業務要件整理など地道な活動も必要
  • 言われたことだけをやるのではない
  • 企画、営業とサービス、プロダクトについて議論すべき
• 非エンジニアの上司とエンジニアの関係性
  • Tech Leadへの権限移譲
  • 育成、チーム運営についてTech Leadと一緒に考える
• 変化が激しく、現場は混乱している
  • テクノロジーが増えすぎて選べない
  • スタンダードが決まるまで待てない
  • ビジネスにあうものがなければ、自分たちでやるしかない
  • 事業会社にはアーキテクトが必要
• 企業風土
  • 現場に権限が与えられているか
  • チャレンジが推奨されているか
  • トップの強い意思があるか
• 改善
  • 無駄なプロセスを削る。従来のプロセスは正しいか？
  • IT部門の強化。ベンダー任せはダメ。自分たちで動く
• チャレンジ
  • しっかりしたシステム基盤(土台)が必要
  • 土台が安定していてこそチャレンジができる
• エンジニアの役割
  • たった一人にエンジニアの力で大企業の風土を変えるポテンシャルがある
  • 今は60人くらい
  • 枯れたことだけではダメ。
  • 新しいことだけでもダメ
  • ビジネス(サービス、お客様、社員)によいものを選択する
• 企業の課題
• トップの強い意思がなければどうしようもない
• エンジニアにも得意なフェーズがあることを意識する
  • 0 -> 1 にするフェーズ
  • 1 -> 10にするフェーズ

SIerに勤める自分にとっては、ベンダではなく内製化にとりくんでいく風習は少し悲しいところもあるが
現在のベンダとの関わりとシステム開発の多様性を考えると、こちらもやりにくいところがあるので仕方ないのかと思ってしまうところもある。

【B-L】Yahoo! JAPANのコミュニティが生み出す価値

発表者はYahoo! JAPANの善積さん。

ランチセッションということで、サンドイッチとお茶が提供された。
無料のカンファレンスなのに嬉しい限り。

• 企業がコミュニティを形成する目的は?
• 採用
  • イベントを開催し、自社を知ってもらう
• 成長
  • 本セッションはこちらの話
• なぜコミュニティから成長を生み出したいのか
• 2008年はウェブエンジニアのみ
• 2017年はPC, iOS, Android, スマホWebと増え
  • 多機能化、高機能化にともない複雑化する開発
  • バーティカル(特定分野に特化)に強いエンジニアが活躍
• このままでは価値のあるプロダクトを提供し続けるのが難しくなるのでは？
• 社外コミュニティへの参加支援を始めたが課題もある
  • 自分たちの課題が解決できるとは限らない
  • 規模の大きなイベントに偏りがち
  • 行く人と行かない人のギャップが生まれる
  • バーティカルな領域を跨ぎにくい
• 企業がコミュニティを形成するのはどうか
• 課題を解決することを目的にする
  • 同じような課題に取り組む企業とも共有しやすい
• 勉強しに行くより、課題を解決しに行けるように。
  • モチベーションを醸成しやすい
  • 持ち帰って事業に活かしやすい
  • 組織の壁を取り払うことができる
• バーティカルな領域をまたげるようにする
  • iOS、Android, デザイン、グロースハックからスタート。
  • 各領域をひとつの目的でつなげることがキモ
  • 全体をまたいでフォローする組織を設立
  • イベント運営は領域をまたいだメンバーで行う
• 実現するうえで乗り越えたこと
  • 泥臭くコミュニティを定着させる
  • とにかくオープンに開催する
  • 小さな成果をとにかく拡散する
  • ときには自らハードルを下げにいく
• バーティカルな領域をまたげそうな成果を発揮
  • デザイナーがグロースハックをはじめる
  • 導入すべきツールの意思決定
  • 小さいチームの施策を大きなチームが導入

コミュニティに参加する目的を勉強から、課題の解決に考えるのはなるほどと思った。
確かに新たな情報収集や勉強もあるけど、今ある課題の解決のヒントを求めているのも大きい。
解決できるためにコミュニティを形成するというのもわかる。

【A-3】コミュニティ活動と企業の相互作用 ～コミュニティへの貢献と組織活動への還元～

発表者はメルカリ/ソウゾウの上田さん、日高さん

• エキスパートエンジニアという役職のお二人
• エキスパートエンジニア職の役割
• エンジニアリングの世界では技術の進歩が早い
  • 最先端の技術を取り組む
  • 社内、社外半々
• 新しい技術へのチャレンジ
  • 技術のサイクルを生み出す
  • 社内に新しい技術を取りこむ
• カンファレンス、勉強会
• 技術をアウトプットするところに技術は集まる
• 技術コミュニティの多様性を活かして多くの地検を集める
• 海外カンファレンスで日本では得られない知識を得る
• 海外のゲストを呼ぶ
• 海外の著名なエンジニアの話を聞く機会を作る
• 日本のコミュニティの状況を海外に伝える
• 社内に還元する
• 社内勉強会やレポートなどを通じて知見を共有する
• Go Friday (社内勉強会の名称)
  • 社外で得た知見の共有
  • 社内の各プロダクトで得た知見の共有
  • 社外へのアウトプットの練習
  • 短期的なインパクトよりも継続することが最も大事 (確かに)
  • 資料の準備を頑張らない
  • 社内なのでソースコードでも
  • なぐりがきのWikiでもいい
  • スキップしない
  • スキップすると癖ができてしまう (これは納得だけど、難しい)
  • 雑談ベースでもいい
  • APIチームに関わる相談でもいい
• 技術の普及には教育が重要となる
• 最初は誰もがビギナー
  • ビギナー向けの情報や書籍が重要
• 技術コミュニティがビギナーを支援
• 貢献と還元を考える
• コミュニティへの貢献
  • カンファレンス開催
  • 技術分野への貢献
• 積極的に発信し、コミュニティを支援する
• 同期的な活動
  • カンファレンス、勉強会
• 非同期的な活動
  • 書籍の執筆、ブログ、情報共有
• プロダクト開発をみつめる
  • 間接的、直接的にOSSを利用している
  • AndroidにおいてはOSSなしには成り立たない
• どこまでが自分のプロダクトか？
  • OSSライブラリは別か？
  • コミットメントの濃淡で意識の外にいきがち
  • 価値を構成しているので実際はOSSも含まれる (確かに)
• 今すぐできるコミュニティへの貢献
  • 欲しい機能、不具合の報告
  • 海外ではよくある
  • 中の人は結構求めている
  • 何もフィードバックがないOSSは廃れて行く
• プロダクトで使った際の挙動報告
  • 修正や使用方法の誤りを指摘もらえる
• リリースに対する動作確認
• プルリクエスト以外にも開発者へのフィードバックは可能
• コミュニティへの貢献が組織を変える

エキスポートエンジニアという役職がいいと思った。
また、アウトプットするところに技術は集まるというのに納得。(あんまりできてないけど)

【B-4】時代の先端で躍進するクラウド・デベロッパー達が語る！～AI、IoT、ブロックチェーンなどのテクノロジーを使いこなして活躍するためには？～

パネルディスカッション
IBMの方をモデラー、横井さん [日立製作所]/佐藤さん [DIGC/アイク・ラボ]/金本さん [アンター]

• マネージドAIサービス
• Amazon AI
• Google Cloud Vision API etc
• IBM Watson
• Microsoft Congnitive Services
• 横井さん Node-RED
• Rasberry PIに標準搭載
• GUIで簡単にIoTを組み合わせられる
• AWS, Azure, Watsonなどと連携できる
• 金本さん 商用AIを活用したサービスの開発
• ルールベースエンジンとAPIを融合したチャットボット
• APIは切り替え可能にしている
• さくらインターネットのサポートで使われている
• 佐藤さん Antaa QA
• 医師が医師に聞くQAサービス
• Watsonを使ってチャットボットを作っている
• ディベロッパーのポジションとキャリアは？
• 医療業界ではAIへの期待が高い
• 業界の人と近いところで密接にコミュニケーションしてPDCAを細かく回してビジネス課題をスピーディに改善していく
• アウトプットしていくことが大事
  • 海外でも意外にQiitaを翻訳してみてたりもする
• マルチクラウドについて
• 今後お客様に提供しようとおもうと大前提になってくる
• 4つのAIサービス全て使っている
  • その上でお客様にとっていいものを選択している

IBMのWatsonが実際のサービスでも月数千とか１万ちょっとというのに驚いた.
マネージドAIサービスは面白そうなので、試してみたい。

【A-5】組織と文化のリファクタリング

発表者は、リブセンスの海野さん、内山さん

• 組織と勉強会の改革(リファクタリング)の話
• 勉強会のリファクタリング
• 始めてた勉強会が10回で終わった
  • 飽きてきた
  • いつも同じ人が発表
  • 他の人が参加しづらい雰囲気
• 見直すため企画会議
  • テーマ縛りのLT大会
  • クラフトビール飲みながら技術のことをワイワイ
  • テーマを毎回選定して、いろんな人が掘り下げることで立体的に知れる
• テーマの選び方の改善
  • やりたいテーマから勉強したいテーマに
  • 最も興味あるテーマへの投票すると、多くの人の２番目、３番目にやりたかったものが黙殺される
  • Instant Runoff Voting
  • 投票そのものがエンターテイメントに
• 新規参入者の促進
  • 新人の人でも良い
  • どのレベルの参加者もフルメンバー(正会員)のような気持ちになれるように活動を設計すること
• 資金面の工夫
  • 投げ銭形式で募る
  • LINE Payを使って基金のクレジットカードに
  • その基金から飲食代や発表に使うAWS/GCPの利用料金を支払い

テーマ縛りのLT大会というのは面白そう。
テーマ決めを単なる投票ではなく、Instant Runoff Votingという方法を使うことでエンターテイメント化させているのが面白かった。

【C-6】CIにおけるセキュリティテストの組み込み方について

発表者は、ユービーセキュアの最首さん

• 最近のDDoS攻撃
• 昨年秋に市場最大のDDoS攻撃
  • ピーク時、665Gbps
• フランスでも発生
  • IoT機器が乗っ取られてbotnetが出来上がって1TbpsのDDoS攻撃
• DDoSのボットネットのMiraiが原因
  • ソースがGithubに公開されている
• IoT機器のアカウントをデフォルトのまま運用は危険
• DevSecOps
• 2012年にGatnerにコンセプトを提示
• スピードをいかしたままセキュリティプロセスを取り組み、セキュリティ品質も確保する一連の手法
• ツールで診断を自動化し、脆弱性の検出を前倒す
  • 開発者自身が診断実施者になる
  • ベンダだとブラックボックスになる
  • 自身がやることでホワイトボックス
  • 診断実施タイミングのコントロールが容易
  • 診断実施範囲の確定が容易
• 2種類の脆弱性診断ツール
• SAST : 静的 Static Application Security Testing
  • ソースコード・モジュールに対して診断
  • 実装時
  • データフロー解析
  • すべて検出できるわけではない
  • 過検知が多い傾向
• DAST : 動的 Dynamic Application Security Testing
  • アプリケーションに対してチェック
  • 統合時
  • 擬似攻撃リクエストを送って診断する
  • SASTに比べ過検知が少ない
  • 診断時間がかかる。対象の性能にも依存。
  • ログインなどアクセスコントロールはマニュアル診断が必要
• SCA
  • 使用しているOSSの脆弱性がないかチェック
• OWASP ZAP
  • 無償の動的Webアプリケーション脆弱性診断ツール
• SAST導入
• 複数のSASTを導入し、早く開発者へフィードバック
• 過検知は次回検出されないように設定変更すること
• 専用の診断環境を用意した方がよい
• DAST導入
• 専用の診断環境を用意する
• 診断用のテストデータを用意する
• 診断時間がかかるため、高い性能の環境を用意する
• DASTの診断時間
  • 画面の繊維改装が浅い
  • リクエストパラメータが少ない
  • ⇨簡素なアプリケーションがセキュリティを保ち安い

SAST, DASTという表現は初めて知った。あとDevSecOpsという言葉も。
DASTは初回か大きめの改修時にベンダでというのが多いのでプロセスに組み込んで継続にやるのは重要と思った。

こっそり教える有名コミュニティの裏話 ～Tensorflow、Java、PyData～

パネルディスカッション
モデレータ 漆原 茂 [ウルシステムズ]
スピーカー 下田 倫大 [ブレインパッド]/寺田 佳央 [日本マイクロソフト]/池内 孝啓 [slideship]

• 下田さん TensorFlow User Group (TFUG)
• テンソルフローと読む
• Googleの人に見つかって主催することになった
• 寺田さん Japan Java User Group (JJUG)
• 2007年4月設立
• 6600名以上のメンバーが参加
• イベントに1500人登録して1000人が参加
• 池内さん PyData.Tokyo
• Pythonエンジニアとデータ分析者のコミュニティ
• 画像解析、自然言語処理、強化学習を扱うMeetup中心に活動
• PyDataコミュニティは世界64拠点
• compass.comでは2427人
• コミュニティ運用の裏話
• ゲストスピーカーの選定
  • ブログ、スライドを出している人
  • 参加者のつて
• 内輪すぎず、多すぎずの塩梅が難しい
• 回数を重ねると初心者とディープな人と分かれてくる
  • 分科会などを作成
• 人気が出ると、参加できない場合がある
  • スピーカーになると優先で入れる
• 規模が大きくなるとお金もかかる
  • 法人化していないので全てお金をクリアにしている
• 当日キャンセルは仕方ない
• サイレントキャンセル
  • キャンセル待ちがいるが枠だけ埋まってしまう
• 失ったもの
• 週末が多いので、週末が埋まってしまう
  • 仕方ない。理解してもらう。
• コミュニティの色が着きすぎる
  • Googleの人とか、PyDataの人と思われ他のことが注目されない
• 参加者からコミュニティへの貢献方法
• 質問をする
  • スピーカーの満足度が上がる
• 参加して得られたことを発信する
• ボランティア
• 英語のドキュメントの翻訳
  • 今後は翻訳してくるのが減ってくる
• Javaであればアーリー版を触ってフィードバック
• 運営に向いている人
• パッションがある
• ホスピタビリティがある (奉仕できること)
• 軍師タイプ
  • 前には出ないけど、参加者が楽しめるようにすることができる
• 日本のIT, エンジニアが世界と戦えるようしたい。そのためには
• コミュニティが不可欠
• 世界と同じ情報が得られる
• 新しい情報を得る、広める
• コミュニティに参加して、得た知見を職場など周りに広めてほしい

最後の寺田さんの日本のITが世界と戦えるようにはコミュニティが必要というのは、
最近カンファレンスなどによく参加していて感じるし、寺田さんの熱い思いに共感した。

最後に

１日参加して、普通に仕事をしているのと同じくらい疲れた。
でもいろんな話を聞けて、仕事へ反映していければと思う。

mabushiisign

Twitter

B'zとdoaとミスチルと登山が好きな40代のプログラマです。 普段は、SIer企業で働いています。