Developers Summit 2016 KANSAIに行ってきました

Developers Summit 2016 KANSAIに行ってきました。

熱いところに来てしまった @ 神戸国際会議場 https://t.co/STimuKiMsz

— 山下 (@yamamanx) 2016年9月16日

基調講演 クラウドの発展とデベロッパーの役割について

グロースクエストパートナーズ 鈴木雄介さん

基調講演間に合いました〜 #devsumi @ 神戸国際会議場 https://t.co/TdQm2NNjON

— 山下 (@yamamanx) 2016年9月16日

クラウドがもたらしたもの

インフラのサービス化

• SDx : ソフトウェアであらゆるものを定義する
• インフラを「所有」から「利用」へ

ミドルウェアのプラットフォーム化

• RDS データベースサーバを借りているのではなくデータベースサービス(バックアップ、メンテナンス、クラスタなど)を利用している
• Webアプリ基盤 : AWS ElasticBeanstlak
• 開発ライフサイクル込基盤 : AWS CodeDeploy , AWS CodePipeline
• PaaSによりアプリとインフラの境界線がなくなる
• 積極的にプラットフォームの制約を受け入れて利用する、そのほうが便利
• OSSライブラリと同じ、世界中で考えられた一番いい構成、使い方で使える

システム構成のコード化

• コードから操作が出来るので「構成する」ことの自動化が出来る
• 非機能要件がコーディング出来る

クラウドジャーニー

1. インフラのサービス化
2. ミドルウェアのプラットフォーム化
3. コードによる構成の自動化

ITサービス運営のスピードアップ

• システムを動かしてビジネス価値を生み出す事のスピードアップ
• コードを書くことが早くなるわけじゃない

クラウドの発展

クラウドが何をもたらしたか

15年前からITサービス運営のスピードアップに取り組んできた
すべてはアジャイルからはじまった
今自分がどの年代にいますか？今にいますか？15年前にいますか？それよりも前ですか？

• 2001年 アジャイル
• 2006年 DevOps,AWS
• 2011年 マイクロサービス化

アジャイルのはじまり

ウォーターフォール

• 最終成果物(ソフトウェア)へ向けてフェーズごとの中間成果物(ドキュメント)を定め段階的に品質を確認する
• やるべきことを終わるまでやる、一発リリースを保守運用

ウォーターフォール問題

• 欲しい最終成果物が変化する
• 中間成果物(ドキュメント)では確認出来ない(機能が増えてきた)
• エンドユーザーじゃない人が要件定義をしてテストをしても正解にたどりつきにくい
• 情勢の見極めが非常に難しく調整が後手後手になりやすい

アジャイル

• 期間とリソースを定めて、計画と評価を繰り返す
• 評価は関係者全員(エンドユーザー含む)
• 期限までに今やるべきことをやる
• 継続的な段階リリースと改善保守開発

アジャイルのメリット

• 「今」欲しいものを得られる、次のリリースがある安心感
• 定期的に評価が出来て、フィードバックを得ながら進めていける
• プロセスではなくてチームで状況を共有する

DevOps

• そもそも開発(改善変更)と運用(安定稼働)は相反する
• アプリは変更してなんぼなんでOpsを自動化して不要化する
• DevOpsが今すぐ出来ない理由は何もない、やればいいだけ

ブルーグリーンデプロイメント

• 新バージョン(ブルー)をにデプロイして現バージョン(グリーン)から一部だけブルーに切り替える、問題がないことを評価して問題がなければ全部ブルーに切り替える
• 可能な限りサービスを止めない
• カナリアリリース
• ダークカナリア : 開発者だけがアクセス出来るテスト用バージョンを本番環境にリリースする
• カオスモンキー : 本番環境をランダムにダウンさせるツール(冗長化のテスト)

マイクロサービスアーキテクチャ(MSA)

モノリシックなシステムの課題

• 部分の変更が全体に波及するので変更のスピードがあがらない
• システム全体を単一の構造で作るので技術の選択に幅がなくなる

MSAの特性(技術面)

• 部分の変更を全体に波及させない
• APIによる連携、APIは古いバージョンの互換性を保つ
• サービス同士を疎結合にしているのでいつでも変更してよい

MSAの特性(組織面)

• サービス単位でマネジメントすればよい
• サービスの切れ目でチームを分けてたくさんのチームでシステムを作る

いかにサービスを分けるか

• ドメイン(問題領域、業務領域) : 変更ベクトルの濃淡に境界線を引いたもの
• ドメインとUXはAPIを分割する
• ドメイン専門家の話を聞く必要がある

エンタープライズ

• 「マインドセット」の変更を
• 態度 : be agile(定期的な改善)
• 技術 : プラットフォームの活用

クラウド時代のデベロッパー

• 非機能要件もコードにかけるようになった
• 制約にしたがってPaaS,OSSフレームワークを使ったほうが便利

システム開発からサービス運営へ

• 「要件を満たすアプリケーションを作る」から「価値があるサービスを運用する」
• 効率的に作るよりも効率的に動かす

「技術」の多様化

• 特定の技術の目的に沿った技術(IoT,AIなど)の登場
• 企画 : 戦略理解、ユーザ中心設計、機能リスト
• 開発 : アジャイル、各ツール
• 運用 : DevOps、各ツール

「技術」の使われ方を意識する

• 何に最適な技術なのかを理解して技術に無理をさせない
• 使い方にはマネジメントプロセスも含む

スキルを縦か横かに拡げる

• スペシャリストかゼネラリスト
• 開発 = 企画+開発+運用

開発者がビジネスの中心になる

• 「ITがビジネスの最重要課題」なら「デベロッパーがビジネス活動の中心」になるべき
• ビジネススキルが必要(チームビルディング)

正しいものを正しくつくる

ギルドワークス　市谷聡啓さん

組み込み→受託→
TIS(エンタープライズSier)→
楽天(コンシューマサービス)→
永和システム(アジャイル)→
ギルドワークス起業

間違ったものを間違いながら作る(DWW)

• 60年前から変わらない間違ったものづくり
• クライアントが求めるものがそれぞれ違っていたり、出来たものが違う
• テーブルの端から端までのクラスファイル
• 縦長の天井から地面まで届くWBS

DWWな質問

• 想定ユーザは実在するか
• 想定課題を持っているか
• 課題解決は出来るのか
• そもそもその課題は解決に値するのか

わかったフリ開発

• 要件定義という言葉そのものが、分からないまま進めているという事

DWWな業務システムづくり

• 声の大きい人基準の意思決定
• 気持ち反復開発
• 受託開発はわからないことをわからない人同士で作る

アジャイル開発

• 間違ったものを間違いながら作ることへの終止符
• 話したほうが早くわかる
• 動かしたほうが早くわかる
• 協調した方が早くいける
• 目の前の事実(変化)に従うほうが早くいける
• 目的は課題解決であり計画に従うことではない
• 分かった事を早くくための手法

間違ったものを正しくつくる(DWR)

• 間違っているかという問自体が存在しない
• 仮説検証がない、経験がない
• プロダクトオーナーが正解を持っているわけがない

理想的なプロダクトオーナー

• 仮説検証に長けており充分な知識と経験がある
• 新規事業を立ち上げるときにその人が稼働できる
• そんな都合のいい話は絶対にない
• 一生で出来るソフトウェア開発たかが300人月
• そもそも新規事業に携われる数は1か2

目的に忠誠を誓う

• 忠誠を誓うのはアジャイルでもない
• 忠誠を誓うのはエヴァンジェリストでもない
• 忠誠を誓うのは上司でもない
• 忠誠を誓うのはユーザーでもない
• 越境する気持ちがないと開発は前に進まない
• 「これは自分の仕事ですか」「これは私がやるのですか」そんな事はどうでもいい
• 目的に忠誠を誓う
• 目的は絶対的ではなく相対的

Start with Why

• 何のためにやるのか(Why)から始める
• 次にやり方(How)
• 最後にやり方(What)

正しいものを探すためのアプローチ

顧客開発

• スティーブン・G・ブランク氏が提唱する方法論
• 顧客発見 : 顧客を最初に見つける
• 顧客実証 : 買ってくれるか確かめる
• 顧客開拓 : 同じ人たちを探す

リーンスタートアップ

• エリック・リース氏が実践したプロダクト開発の方法論
• 正しいものを探す(仮説検証,価値探索)+正しいものを作る(プロダクト開発)
• ユーザーインタビューでの探索、ユーザーストーリーマッピングでMVPの特定を反復的に行う
• 仮設キャンバス

仮設キャンバス

• 目的 : なぜこの事業をやるのか
• ビジョン : 顧客にどうなってもらいたいか
• 状況,傾向

ユーザーストーリーマッピング

• オライリーの本を読んだほうがいい

分かったことを正しくつくる

• 正しいのもを正しくつくる = 事実として分かったことを正しくつくる
• 検証と価値提供の分離
• いかに早く安く検証出来るか
• MVP 実用的で最小限の範囲
• 早く、短く、何度も実験した後につくる
• 利用者の方を見た判断をする

目的にかなうプロダクトを適した手段でどれぐらいつくれているか

話を聞いて、じゃあ明日からできるのかというわけではなく、 考え方や学び方を得ることが出来る。だから今日終わってから何を始めるかが重要なんだと思う。そう思えるセッションが好きです。 #devsumi

— 山下 (@yamamanx) 2016年9月16日

尼崎から世界へ！モノタロウの海外展開を支えるDevOps基盤

ECアプリケーショングループ 海外案件チーム
古畑耕輔さん

モノタロウ

• 177万口座
• 関節資材のECサイト
• 年間売上556億円(2015年)
• 一物一価
• 数十万点の在庫がある

組織

• 部門 : 管理、商品、物流、CS、マーケ、IT
• PC管理、勤怠管理、分析、基幹、EDI、WMS、大企業連携、販促、会計
• IT部門 : システムインフラ、基幹CRM、基幹SCM、物流システム、WebAPI、EC AP，コンテンツ、大企業、データ基盤
• 以前はパッケージを使っていたが、OSSに変更して内製
• そうすることで時代の変化に素早く対応、スピード感、競争優位

ECサイト運営

• 商品検索エンジン
• レコメンドエンジン
• データ分析、機械学習
• CVR改善、SEO、SEM
• アプリ開発、Web開発
• 使う技術も自然と増えていく
• 国内ECサイトは基本週一リリース
• リリースタイミングを集中させる事で問題発生時の対応を局所化し開発にリズムをもたせる
• 海外案件はリリースサイクルを持っていない、機会損失を防ぐため

海外進出

• 2011年 韓国向けECサイト公開
• 2013年 シンガポール向けECサイト公開
• 2016年 東南アジア 5カ国にもECサイトオープン

海外案件チーム

• 4人(兼任マネージャ、リーダー、若手2人(中国籍))
• 海外ECサイトの流入、売上をX倍に増やす
• 期待効果の高い施策を立案、実施
• 保守・運用にかける時間を減らす
• 案件着手からリリースまでの期間を短縮
• Route53-ELB-WebApp-DB(ECサイト) + CloudFront-S3(商品画像サイト)
• Googlebotがやりすぎてサイトが落ちた
• 約40万の商品✕7カ国=280万ページある
• Googlebotのためのチューニングはなんか無駄だけどサイトが落ちてはならない
• AutoScaleを導入して対応

課題

• 開発環境はWindows + XAMP
• 結合試験用のサーバーは1台だけ
• 秘伝のタレ化したセットアップ

対策

• Docker導入
• ローカルにDocker Machine導入
• 結合試験にECS
• Docker RepositoryにAmazon ECR
• Dev(Docker Machine(VirtualBox)) -> Bitbucket -> Jenkins -> ECR,ECS
• 今後さらにECR -> Jenkins Test ->本番ステージング
• そろそろ自動テストもやってみたいがテスト工数で負荷はかかってないので優先度は低

そういやデブサミで雑談してた時に教えてもらった
「人によってスイッチは違う」
そうなんですよね。ほんとに。
だから「こうなんだ」って思ってやってもそうならなかったりするんですよね。
でも環境づくりってそのスイッチを探し続けることでもあったりするんですよね。
悩もう。悩み続けよう。

— 山下 (@yamamanx) 2016年9月17日

エンジニアの教育と成長についての課題と、組織で行っていること

株式会社はてな

大西 康裕さん(執行役員 技術本部副本部長)

組織

• 全社員100人中、エンジニア40名ぐらい

育成について

• 「育てる」ではなく「育つ環境にする」
• 自らが育っていく事を促す
• 学ぶ意思のない人は採用しない

アウトプットの後押し

• アウトプットする事でより成長出来る
• 全体の総力の向上にもつながる
• アウトプットをすることを明示
• 技術ブログ執筆推奨
• Hatena Developer Blogでも個人ブログでもいい、はてなブックマークで200以上ブックマークされるとお祝い
• 目標 合計25,000ブックマーク

毎週技術勉強会

• エンジニア・デザイナー持ち回り
• 20分発表✕2 + 技術共有

イベント開催補助

• 勉強会、輪読補助

エンジニア実績システム

• 特定の行動をコミットする

株式会社さくらインターネット

江草 陽太さん
2014年新卒入社2年目で執行役員 技術本部副本部長

X理論→Y理論へシフト

• お金のためや仕方なくではなく、達成したい事があって仕事をしているはずという理論
• 自主性を尊重する経営手法へシフトする
• 性善説
• ルールを減らし自由度を高める
• 部門を越えて複数のプロジェクトに任意に参加出来るようにした
• 月の平均残業時間 8時間
• GM(グループマネージャ)の設置
• 本や少額備品は事前承認なく購入可能
• フレックスによる時間の変更(早く来て早く帰るなど)は承認不要とした

生涯エンジニアというマインドを活かしてYahoo!天気アプリを成長させたPM手法

ヤフー株式会社 湯澤 秀人さん

• 三菱電機ソフトウェアエンジニア -> ヤフーITエンジニア -> 任天堂ネットワークエンジニア -> ヤフー天気災害アプリ担当
• 人に「ありがとう」と言われる作品を作りたい、自分の作品に納得と責任を持ちたい
• エンジニアとして生涯現役でいたい、仕事は楽しくやりたい、常に自分を成長させたい
• 初期のヤフーカテゴリ検索をエンジニアとしてリード
• ヤフー知恵袋を立ち上げから担当していた
• エンジニアは職人であるべき、なので「作品」
• ITサービスは公開がスタート

ここ1年で個人でやったこと

• iOSアプリを開発して公開してみた
• ElasticSearch + kibanaで地震ビジュアライゼーション
• LINE Bot + AWS ガチでネットワーク構築

ヤフー大阪

• 社員数200名
• ITサービス担当 100名

ヤフー天気災害アプリ

• 災害速報通知の意識が強い
• 2015年フルリニューアル
• 累計2300万ダウンロード
• 前年増加率3位のアプリ

PJチーム

• ヒエラルキーではなく面でとらえる
• PMは担当が埋めきれないスキマをフォローする
• エンジニアとしてPMをしているからそのスキマが見えやすい
• 全体意識を持つ
• 仕事を通じて成長する
• 作品に誇りと責任を持つ
• 広く新しい技術を常に身につける
• PMはひまであるべき

定めたこと

• 2015年の梅雨台風シーズンまでに初回リリース
• 天気予報を見やすくする
• 雨雲レーダー
• 雨雲近づく機能にインパクトを与える

「自分でやってみてこそわかる事がある。だから仕事でその担当でなくてもそれを個人でやってみる。」ですよね〜。本当に。 #devsumi #devsumib4

— 山下 (@yamamanx) 2016年9月16日

カイゼンの基本 ～組織・プロダクト・プロセスをどう改善するか～

Ryuzee.com 吉羽 龍太郎さん

カイゼンの基本 ～組織・プロダクト・プロセスをどう改善するか～資料

アジャイル開発とカイゼンの関係

• トヨタ生産方式 -> リーン生産方式 -> リーンソフトウェア開発
• 完璧を目指すならまず終わらせろ

7つのむだ

• 作りすぎ、手持ち、運搬、加工、在庫、動作、不良

カイゼン

• 今より「安全」にする
• 今より「簡単」にする
• 忙しいからカイゼンできないのではなくカイゼンしないから忙しい
• カイゼンはニーズに基づいてやる
• 持続可能なペースで続ける
• 問題、意見、事実、解決策なのかをはっきりして話をする
• 自工程内のカイゼンは効率より効果、穴をふさぐことに効率を求めない
• 穴があるまま効率を上げると問題が生産され続ける
• 一気にやらない、継続してやらないと効果はない
• 見えないもの、事実がなく想像だけではカイゼンできない
• バリューストリームマップ モノと情報の流れ図
• 工程をなくす
• 工程を統合する
• 工程の順番を入れ替える(逆流している場合)
• 工程を単純化する
• チームの能力を見える化する, スキルマップ,エース、得意、一人で出来る、助けがあれば出来る、出来ない

「大事なドキュメントを削除してもしばらくはばれない」ww #devsumi #devsumib5

— 山下 (@yamamanx) 2016年9月16日

懇親会

はじめてご挨拶させていただく方や、見たことはあるけど話すのは初めての方、そしていつもアドバイスいただいている方々、本当に楽しくためになる、貴重な時間を過ごさせていただいてありがとうございます！

珍しく2件目いってしまいました。

思った事

昨日はデブサミ2016関西、参加いたしました〜。やり方、考え方に触発されて、またやりたいことが増えたと思います！やります！
運営の皆様、登壇の皆様、スポンサーの皆様、関係者の皆様、 ありがとうございました！ #devsumi

— 山下 (@yamamanx) 2016年9月17日

最後までお読みいただきましてありがとうございました！

「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。

「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第2版」という本を書きました。

「ポケットスタディ AWS認定 デベロッパーアソシエイト ［DVA-C02対応］ 」という本を書きました。

「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

「AWSではじめるLinux入門ガイド」という本を書きました。

@yamamanx

開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。

このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。

また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。