こんにちは、ひろかずです。
某ちょんまげ人の熱い檄文にほだされて、行ってきました。
開場は大田区産業プラザPio
カンファレンスホールは空間を贅沢に利用できる感じで、ゆったり聞くことができました。
例によって、リアルタイム執筆になりますので、誤字脱字表記ゆれはご容赦下さい。
お品書き
- オープニング
- ものづくりを変える開発者ファーストの４つのカイゼン
- クラウド労務サービス「SmartHR」を支える開発チームの作り方
- 新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた
- カイゼン・ジャーニー 〜たった一人からはじめて、「越境」するチームをつくるまで〜
- サーバーレスいいとこどり
- リアルストーリー：「うちのカイハツ、セキュリティやばい」からの脱却シナリオ
1. オープニング
有限会社アリウープ 柏岡 秀男
タイトル明日の開発カンファレンスについて
明日とは
- 様々なイベントで素晴らしい発表があるが、現場への落とし込みのところでどうするかーで終わってしまっていた
- 明日から使えるような、現場感がある内容がいいと思っていた
開発とは
- 海外技術の逆輸入では、なんかチグハグする傾向がある
- 日本の開発に組み合わせて、いけたらいい。
2. ものづくりを変える開発者ファーストの４つのカイゼン
株式会社デンソー 佐藤 義永
認定スクラムマスターを持っているが、バックボーンはDeveloper
デンソーは、新しいITサービスを始める。しかもアジャイルで。
今日はその集大成と経験をお話して頂けるとのこと。
ものづくりの中心には開発者がいる
開発者が価値の源泉
開発者が力を出せるようにするには？
デンソーは作っているモノの殆どがハードウェアのグローバル企業
- 売上の98%がハードウェア
- ここに危機感があった
ITの位置づけ
- これまではビジネスを実現する手段であった
- これからはデジタルトランスフォーメーション
UI/UXが主眼になっていく
- まったく未知の分野。どうやったらいいかから始まる
Uberのユーザー体験
- 車が欲しいのではなく、移動手段が欲しい
- 自動車会社は、Uberのサプライヤーのような位置づけになることが予想される
- 自動車産業に破壊的イノベーションが起きる可能性について、十分に考えられていない
- 裾野分野にも影響がある
IT投資の目的。日米比較
日本
- 守りのIT(基盤)
米国
- 攻めのIT(投資)
デンソー内のITの位置づけ
- 法務と同列
- 情報の保護が目的
- サービスの開発はスコープ外であった
- そこで、デジタルイノベーション室が生まれた
コネクテッド・カーを作っていくが、自動車が中心ではない
- サービスに自動車がどう関わっていうかというところに力を入れていく
ITやアジャイルをやったことがないデンソーが、どうやっていく？
- スタートアップのやり方はどこも似ている。
- 日経BPの記事に、類似点が掲載されていた
- オフィスが洒落てる
- でかいホワイトボードにポストイットがたくさん
- ユーザーを巻き込んだテスト
- 試作品を作ってテスト
- スタンフォード大学のデザイン思考が体系づけていた
イノベーションには方法論があった
- 同じ土俵に立つために、同じものを手に入れる
取り組むべきキーワード
- ゼロから位置を作るデザイン思考とサービスデザイン
- 早く安く作るためのクラウドとOSS
- 作りながら考え、顧客とともに作る内製化とアジャイル開発
ものづくりを変える取り組みの目的
顧客との繋がり方（開発のゴールのカイゼン）
開発メンバに無駄・不要なものは作らせないように、顧客が必要とするものを全員で共有できる関係
アジャイル開発チームのゴールは、市場/ユーザーに受け入れられるビジネス
- 安く早く作れるものではない
- ユーザーが何が欲しいのかを一緒に考えるためのProcess
- NG：仕様を決めずにできるところから
- NG：品質を犠牲にして、とりあえず実装
ウォーターフォール開発でありがちなこと
- 当初仕様では製品化できない
- フェーズ毎の追加仕様と削除仕様に工数がかかる
- 使われない機能もバグがあるかもしれないので、メンテナンスが必要になる
スクラム開発の進め方(全体Process)
開発前(スプリントゼロ)
- ゴールの設定(コンセプトの共有)
- 一ヶ月後に何が欲しいか
- プロジェクト、ビジネス、プロダクトのゴール
- 開発者としてどんなスキルセットが必要か
- ユーザーストーリーマップ（後述）
スクラム開発の進め方(ゴールの設定)
事業のゴール(目標)ではなく、プロジェクトのゴールを明確にする
- いつまでにどういう状態を達成？
- そのための優先度(日付、金、etc)
ユーザーストーリーマッピング
- 提供価値、必要機能、構成要素から、最低限必要な機能を割り出す
- 割り出しには、プロダクトオーナー（最終結果責任者）も開発メンバーといっしょにまとめていく
開発者のスタイル
開発メンバが楽しく幸せに働いていける開発プロセスにする
課題
- 残業が多い、休めない、やりたいことができない
- なんで？
情報伝達遅延
- 隙間時間や待ち時間
- プロジェクト兼任(ご意見番から実装に引きずり込まれる)
- 途中参加と離脱メンバ
開発外業務
- 大量なドキュメント作成とレビュ
- 質問攻めと引き継ぎ
- 大量の定例会
スクラム開発チーム
4-5人のチームでやってる
- Developer：システム開発者・チームの中心
- プロダクトオーナー：ビジネス面での意思決定者
- スクラムマスター：プロセス面での支援者
- ７人でやったらうまく行かなかった
- 人数を変える
優先順位決め
- 優先度ではない！
- 客に任せないで、一緒に決める
マルチタスクをしない
- 掛け持ちは生産性を下げる
- 役割ごとに、やること、やらないことを明確にする
やる必要があるか、やらない方法を考える
- 何を決定する会議？
心理的安全性のカイゼン
メンバー集めとチームビルディング
- チームスポーツとか
失敗から学ぶ文化
- 早く失敗する
- 責任を個人に押し付けない
- 冷静な分析
言いたいことを言い合える
一週間のタイムボックス
- 午前と午後に分ける
- 朝会 → 昼前にデイリースクラム → 夕会(共有)
- 火曜：プランニング
- 水曜〜月曜：スプリント
バックログをReadyにせよ！
受け入れ基準を明確にする
付箋の色分け
- 黄色：タスク
- 赤色：バグ
座席のカイゼン
シマは上手くいかない
- 背中合わせの方がよかった
デザイン思考
仮説検証型の限界
- 問題を解決するのではなく、問題の本質へのアプローチが必要だった
プロトタイピング
右脳型
- 雑＋不正確だけど、迅速に何度も、どんどん失敗して、ゴールに近づけていく
現場の声
もう今までの開発スタイルには戻れない！
他にも続々ありました。
スライドの公開が待たれますね！
3. クラウド労務サービス「SmartHR」を支える開発チームの作り方
株式会社SmartHR 芹澤 雅人
現場の泥臭い裏話が聞けるとのこと！
SmartHRとは
- 人事労務の手続きを簡単にするクラウドソフトウェア
- 書類をたくさん書かないといけなくて大変
- 難解な書類の山
- 役所(ハロワ、年金、労基)のはしご。ピーク時は２時間待ちとかザラ
- ペーパーレス年末調整(はい、いいえ)で年末調整が作れる！
ローンチから現在に至るまでの変化をお話します
ローンチ前
3人で開発
ビジネスサイド
- 営業
- ヒアリング(100もの顧客に)
- ヒアリングテクニックの社内共有
プロダクトサイド
- 初期からスクラムを採用
- 続けていくと、１スプリントでの作業量がわかってくる
- ロードマップが作れるようになる
- 開発者の過重労働を避けられる
スタートアップバトル2015で優勝した！
ローンチ後
人が増えた！
ピンチ１：使いものにならない問題
使えないって意見の投稿
- 当初想定ユーザー：10名規模（社長が片手間）
- 現実のユーザー：100名規模（専任者が月次業務）
求められる機能が全然違った
解決策：企画フローの見直し
利用ユーザーの声を聞く
- 10社同じような要望が挙がったら実装
労務現場経験者主導による開発
お世話になっていた本
キャズム２
- プロダクトがマーケットにフィットするかどうかを論理武装するのに役立った
- 期待プロダクト
- 拡張プロダクト
ピンチ２：Trelloが崩壊。タスクの優先付が課題
利用者企業の規模が1000人規模の会社が増えてきた
組織が大きくなって、プロダクトへの要望が多様化
解決策：JIRAの要望
要望はバックログに起票
週次でバックログ整理(やるやらと優先順位を整理)
解決策：プロダクト指針の全社共有
範囲に一回、前夜合宿で今いちばん大切なことを決め、それを最優先事項とする。
- 1000人規模会社
お世話になっていた本
ライトついてますか - 問題発見の人間学 -
- 組織が大きくなってくると問題が増えるが、誰がそれを解決するのかという意識が必要
- 不適切な人にアサインして中途半端になるのが痛い
- 問題の本質を見極めるのに役立った
ピンチ３：タスク専門化に伴う暗黙アサインの増加 / スプリントプランニング時間の増加
暗黙アサインによって、タスクの偏りが発生
他の人のタスクの話をしている時の待ち時間が長くなる傾向
解決策：チームの分割とスクラムのカスタマイズ
タスク担当者をプランニング中にアサインするのはNGなのだが、あえてやる
担当が強制的に決まるのでチャレンジできる
ピンチ４：個々人で解決できない問題(組織的な問題)
組織規模が大きくなってきたので、個人で解決できない問題をどうするか
解決策：1on1の継続
個人が感じている問題を拾って、打ち上げる
解決策：エンジニア定例を開始
エンジニア全員で集まって、チーム内の課題や出来事を共有
モチベーションサーベイでモチベーションの推移を観察
- Reebokを活用している
- モチベーションの管理は難しい
4. 新卒3年目のぼくが、でぶおぷす???なオジサンだらけのエンプラ金融PJにAnsibleを導入してみた
新卒3年目のぼくが、でぶおぷす???なエンプラ金融PJにAnsibleを導入してみた - SlideShare
フューチャー株式会社 齋場 俊太朗
技術者の心が聞けるいい話とのこと
今までのPJのやり方や文化と先進的なツールの結びつけ
おじさんとは
- いろいろ知らないひと。新しいことをやりたがらない人。
経緯
- 金融系プロジェクトの基盤公開にNW下っ端としてアサイン
- 設計書はアテにならない
- サーバは、ブラックボックス
- 超エンプラ
当然簡単じゃない
- 懐疑的な声（変わるでしょ？セキュリティ大丈夫）
- 神Excel手順書からの脱却
Ansible導入の道筋
サーバー構築は元気玉！？
- ダブルチェック、構成管理、いつの間にか変わる設定、検証環境と違う挙動
インフラチームのボスへの提案
RHEL印は役に立った
デモして、開始承認を取り付けた
小さい範囲からAnsibleで自動化
- hostsファイルの配信とかからスタート
リーダー陣へはビジョンを掲げる
ファンを増やす努力
- みんな大好きなExcelから、Ansibleコードを生成
- ソースコードとの差分(手動変更)は自動検知して、通知（自動チクリ機の実装は効果があった）
- 誰でも使える手順書とラップスクリプトを整備(とにかく書きまくった)
- 簡単なことから作業改善を提案
- 考え方の押し付けではなく、いっしょに考える。これまでのやり方との調和。
今までのセキュリティポリシーは守る
- パスワードは手入力
- ネットワーク経路はこれまで通り。ファイルを保守チームに渡すとか
大切にしたこと
今までの文化にツールを合わせていく
- ベストプラクティスは、神じゃない
- わかりやすさ優先。使えることが大事
あきらめない
- 判ってもらうまで諦めないで説明を繰り返す
- 絶対にサーバを手で触らせない
引き継ぎ
これからの理想を伝える
自動化するか、しないのか
- 変化しないリスクは、想像するより大きい
- 最後は煽った(周りは変化するのに、変化しないの？)
まとめ
- 説明するより見てもらうのが優先
- プロジェクトメンバーは、意外に好意的だった（課題の解決方法を知らないだけだった）
- 新しい文化を作っていくのはやっぱり時間が必要
5. カイゼン・ジャーニー 〜たった一人からはじめて、「越境」するチームをつくるまで〜
ギルドワークス株式会社 市谷 聡啓
80分のロングセッション
書籍になぞらえて、エモい話が聞けるとのこと
なにか新しいことを始めたり企てたりするときは、たいてい独り
- 周りを巻き込んでいくのだが、どんなプラクティスがあるのかを紹介している。
- みんなより先に気づいてしまった自分が組織を変えるまでに寄り添う本
ぼっち曲線
- たいていの人が気づいていて、緊急度が高いものはみんなでやってる
- 気づいているけど、緊急度が低い(と思われている)もの ~
あなたは何をしているひとですか？
置かれている世界を変えるにはどうしたらいいか？
どのあたりの世界？
- 利己 ~ 利他 の軸
- 一人に影響 ~ 多数に影響 の軸
どのくらい共感されるかは、人と状況による
- 初めに気づいた人は、越境する必要が発生する
越境とは目的のために...
- 役割を選ばない
- あらゆる人を巻き込む
- あらゆる手段を取る
- 目的を問い続ける
越境サイクル(周囲の温度が上がるのを待つほど、人生は長くない)
- 問から始まる(このままでいいの？)
- 踏み出す
- 踏み出した、その結果をあらわす(人を巻き込むために結果をあらわす)
- 共感を得て巻き込む(ゆるやかなギルドの形成)
- 協働や応援を得て、また踏み出す
- このサイクルの源泉は
パッション
サイモン・シネックのゴールデンサークル
- 何を？どのように？からではなく、何故やるのかから始めることで考えが整理され、人にも伝わる
目的を徹底的に揺さぶる
- 自分の視座や視野を強制的に広げる
- 事業や組織、社外、世間まで広げる
- 一方で細部まで寄る
- 自分と相手の関係者を一回り広く変える
- 過去と未来からも捉える
Whyに向き合った後に始めること
踏み出すこと
- 考えすぎない
- 準備しすぎない
- 計画しすぎない
- 一気にやらない
答え合わせは後からやる
- 何が正解なのかやお手本を気にしすぎると、先に進めない
- 世の中にある価値や原則は、点検のために借りてくる
視点である - 原理と原則は、答えではなく、問として借りてくる。
- xxできている？
- １つ形にすると、原理と原則とのDiffが取れる
時間が最も貴重なリソース
- 時間をかければかけるほど踏み出しは遠のき、消える
- 今最も貴重な資源は、お金ではなく「人間の使える時間」
- タイミングを待っているほど人生は長くない
実用的で最小限の作戦から始める
- 下手に広げない
- 巻き込んだ人数の分だけ、失敗時の巻き返しに苦労する。
- 一人なら、一人の範疇での責任しか発生しない
次のジャーニー
- 一人の境界
- チームの境界
- チームの外の境界
どうしてもすぐに進めないといけない場合は、外部有識者の力を借りる
境界を利用する
- あえて境界を超えない選択
- スクラムチームとそうでないチームとのコラボ
踏み出した次は あらわす
自分の思いを伝える人は、自分以外には居ない。
- 伝えたい相手の外側(外部活動を通じて)や内側から伝える
成功も失敗も全て成果
- 全ての経験が成果
- 一年は24時間365日しかない。人生は300人月
- 経験を伝えあうことでなら、時間を超えることができる
ハンガーフライト
- 航空機が安全ではなかった時代、格納庫でそれぞれの経験を交換し合った
人は巻き込むのではなく巻き込まれる
越境は引力
- 引力は、ありたい方向へ先に自分が飛び込むことで発生する
巻き込めなかったら
- 本当に周囲と共有すべきWhyだったか？
門を用意する
- 企てに参加できるためには、わかりやすい入り口が必要がある
話を大げさにする
- 一万人の会社でもハンガーフライトの呼びかけには数人しか集まらなかった
- スコープを会社全体にした結果、100人規模まであつまった
越境によって得られるものは大きい
- 得られる経験は、越境した人だけに与えられる報酬
- 立ち位置が変わるから、見える景色が変わっていく
他人を周回遅れにしろ
- 速く行くなら一人で
- 遠くへ行くならみんなで
- 速く遠くへ行くなら一人で進む。
- 周回した後、出会った人といっしょにもっと遠くへ行ける
上手く行かなかったら
- 戻る
- 巻き込む範囲を絞り直す
- 一人まで戻ってもいい
- 自分を受け止めてくれるところへ帰る
- 家族、友人、コミュニティへ、いつでも帰れる
前進するのも戻るのも自分次第
- ジャーニーは自分のもの
- 世界は、帰ってくるのを待っている
QA
一人から始めた時の経験談(うまく行かなかったけど、こうしたらうまくいった的な)
- Devサミで感銘を受けての声掛けに7人しか集まらなかった
- やめればいいとも考えた
- その時に力が良い感じで抜けたのがうまくいった。
越境サイクルがn周目になった時に、居なくなる人が出てくるのは仕方ないこと？
- 必ず居なくなる人は出てくる
- はじめてのハンガーフライトに来た人は、ほとんど残ってないだろう
- みんなが見えてる景色が変わってくるので、自然な流れ
- 止めることはできない
- 越境して得た報酬は、その人のもの。どう使うかはその人の権利
企ての内側にいると入り口の問題に気づきにくい問題の解決法は？
- ありがちなので、最初に考えておくといいと思います。
高すぎる/低すぎる視座の嗅覚はどうしたら？
- そう感じた時。疲れたとか。
越境を続けるうちに疲弊していく人がいる。どうしたら？
- 声掛け（コメントやフィードバック）は良いと思う。
越境という言葉に今ひとつピンとこない
- やりたいこと(目的)のために、自分の組織内の立ち位置を超えて、その世界を作っていくということ
結果が出なくて辛い時に、続けるための秘訣
- 角度を0にしない
- 角度を0にすると、1にするのが大変
- 角度1でも残しておけば、しばらく休むとかした後で角度を再設定できる
やりたいことがズレた時にどうする？無理？強制？妥協？
- スレを受け止められるか？大枠の方向感が合ってるとか
まずやってみると、車輪の再発明がありそうだけど、体験を通したモノが腹落ち度が高いので、やった後にDiffを取るといいと思う
- そのとおりですね。
6. サーバーレスいいとこどり
株式会社セクションナイン 吉田 真吾
- サーバレスのコンサルティングの立ち位置
- このセッションのモデレータ
株式会社キャラウェブ 中山桂一
株式会社WHERE 仲山昌宏
- サーバーレスのサービサーとしての立ち位置
実際のサーバレス現場のモヤモヤについて語られそうとのこと！
細かい技術話はしません。
現場中心でお送りします。
言葉合わせ
サーバレスとは
- サーバが抽象化
- イベントドリブン
- 従量課金
原則
- マイクロサービス指向
- リアクティブなArchitecture
- 認証認可に基づくリソースサービス
- DRY(汎用機能はアウトソース)
Serverless Application Lens - Well Architected Framework
- どの機能がどのサービスに対応するとかのマッピングが掲載
サーバレス開発でどのツール使う？
- AWS SAMは伸びてる（吉田）
- cloud9が出てくるんでは（中山）
Serverless PaaSは黎明期@ガートナー
- ナレッジは共有していくフェーズ（吉田）
現場の話
自身の現場の話をお願いします
- 電子書籍配信システムの開発と運用をやってます。iOS/Androidの配信やってる。アプリのみサーバレス。Web方面は旧来の実装。置換えの予定。置換えられないものがない限り、全てサーバレスにする原則にしている（中山）
- 一部のお客のコーポレートサイトやちょっとしたシステムのサーバレス化もやってる（中山）
- Bluetoothのメッシュネットワークを使ったIoTの情報を、クラウドに上げるようなことをしている。エッジはプロトコル変換くらいで使っているけど、ある程度の処理ができるといいと思っている（仲山）
自社利用と顧客提案で、提案の保守軸は変わる？
- できるだけ実績のある提案をしているが、未本番のものであってもニーズがあり、お客が乗り気なものは提案している（中山）
現場でサーバレスを導入する流れについて
中山さんのターン
エンジニアが居ない会社(有名企業の部長が立ち上げた会社)で、クラウドとかもよくわからない会社。情報共有が回覧板(バインダー)
- 一番最初に会社のメールにストレスを感じた。好きなメーラを使ってとか。
サーバーレスに行き着く話？
- メールをGSuiteにすることで、クラウド利用の否定の道を潰した
- EC2にサーバ建てるとかから始めた。メンテナンスコストと大きめのスケールの事前準備でコスト高だった。
- これからはサーバレスだと思った
- 新しいサービスは、サーバレスにするという方向で進めていた
抵抗はなかった？
- 半ば独断で進めていた。
- できてみたら、こんな便利なものを今まで使わなかったのかとか言われた
- 三菱電機がサーバレスを採用したニュースも後押しになった
第三者認証が後押しになった？
- 役員レベルだと実績の方が後押しになった
セキュリティについては心配されなかった？
- 国防総省が採用しているとかが後押しになった
仲山さんのターン
これからはBluetoothの時代だという鶴の一声で始まった
- 実装する人が一人という状態
- サーバー準備に時間は使えない
- ２週間後にリリースとかの状況
- サーバートラブルまで対応している時間はない
- 予想外のコストを減らす手段はサーバレスだと思った
PoCからプロジェクトに進む割合は？
- 出てきてはいるけど、
- 一応回る分のお金は貰っている
サーバレスに行けない案件もあるのでは？
- データ集計やデータのクラウド転送とかはサーバレスでやってる
- サーバーはSORACOMのVPNサーバと踏み台サーバくらいだけ
- 一時的なバッチ集計とかでも使うことはある
学習コストは？
中山さんのターン
採用は？
- サーバーレス経験者を採用するのは難しいので、高級言語が使える人を入ってもらってから叩き上げている。
Function単位での開発？外注してる？
- 複数機能は持たせないので、シンプルになる。
- 工数もそんなにかからない
- 進捗管理しやすい
- DBのテーブル設計とCI/CDのパイプラインを用意しておけば、外部ベンダーはコードとテストを書けば納品できる
- 外注によるリスクは
人材を育てるという観点では
- Lambdaの制約がハッキリしているので、やれることだけ学べばいい
- そういう面では学習しやすい
仲山さんのターン
採用は？
- 採用は苦労している。
- 設計やセキュリティまでやろうとすると結構厳しい
サーバレスの課題
吉田さんのターン
マイクロサービスの繋がりになるので、構成図が大変なことになる。
- マイクロサービス・デス・スター
- Lambdaにはエージェントを
- ログアグリゲータのスケールに問題がある
- モニタリングもサービスはあるけど...
オブザービリティ
- I/Oパイプ：FunctionをI/Oパイプのモジュールでラップして、LambdaのモニタリングデータをSaaSに飛ばす。(レイテンシが若干上がるので、本番ではちょっと)
- Epsagon：Cloudwatch Logsに独自のデータを吐き出して、それを集計する
仲山さんのターン
オブザービリティについては、物によってはサーバレスを諦めるという選択肢もある。
中山さんのターン
大事なのはデータなので、リージョンレプリケーションをしている
7. リアルストーリー：「うちのカイハツ、セキュリティやばい」からの脱却シナリオ
株式会社アスタリスク・リサーチ岡田 良太郎
サイボウズ株式会社 伊藤 彰嗣
フューチャー株式会社 神戸 康多
+ ゲスト
デンソー 佐藤義永様
クラウドネイティブ 斉藤慎二 様
セキュリティは、共通の悩み
諦めない現場のセキュリティについて