「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか？
はじめに
このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。
ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。
ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰かが、壇上に立つ法務部の人間に、こんな質問を投げかけました。
「たまにお客さんから『アジャイルで開発したいんだけど、契約は一括(作成請負)にしてほしい』って言われるんだけど、こういう場合はどうしたらいい？」
あまりに驚いたのでその後の経緯をあまり覚えていないのですが、確か壇上の人間には答えられず、会場脇にいた講師役社員の上司にあたる人物が、「契約をできるだけ細かく区切るしかない」みたいな回答でその場は収まったような記憶がおぼろげながらにあったり無かったりします。
そのやり取りを聞いていたオレは、「どうしたらいい？じゃねーよ！契約以前にやること山ほどあるだろうか！！」と怒鳴りつけたくなるところでしたが、この場は法務研修、アジャイルの議論をする場ではない、とそっと胸の内の矛を収めた次第です。
今回のQ&Aで出てきた、客からの「開発をアジャイルで」「でも契約は一括で」という要望は、いったい何が問題なのでしょうか？
開発費用が高くなる
問いに対して法務部の上役が回答した「契約をできるだけ細かく区切るしかない」は、おそらく開発プロセスに「スクラム」を採用して開発を進めることを想定して言ったのでしょう。巷では昨今どうやら「アジャイル」＝「スクラム」というイメージが定着しているようなので、ソフトウェア開発を主務としていない法務部の人間がこう勘違いしてしまうのは、まぁ止む無いことだと思います。(質問してたヤツは絶対許さん！)
スクラムでは1イテレーションの開発対象(タスク)を確定すると、基本的にそのイテレーションの最中はタスクの変更は行いませんので、イテレーション単位で見積を作成しその都度契約を行うことは、まぁ可能か不可能かでいえば可能でしょう。
でも、契約作業にかかる工数は、非常に膨大です。工数見積を作成して、付帯条件作って、利益乗せて、正式な見積書作って、顧客側企業内で稟議通して、発注して。どんなに早くても2～3日はかかるでしょうし、1週間～10日はかかるのがザラ、というのがオレの個人的な感覚です。ところが、スクラムのイテレーションは、長くても3週間、短いところでは1週間というところも多いです。1ヶ月のイテレーション期間、というのはオレは今のところ聞いたことが無いので、少なくとも単月契約よりは短いスパンで契約作業が強いられることになります。これをやるのは相当シンドイですよ？
SIerサイドは契約作業にかかる工数を明示的に顧客に請求したりはしない(「見積は無料」という悪しき文化が定着している)ので、開発工数のいづれかにまぶして請求することになるのでしょう。結果、開発工数は多くなり、費用も高くなる。「アジャイルで開発する費用」として見込んでくれているならいいですが、費用が高くなることを顧客サイドは了承してくれているのかは甚だ疑問ではあります。
スクラムのメリットが失われる
またもや「顧客のいうアジャイル開発」＝「スクラム」という仮説に基づいて弁を進めます。
以前たしか、原田騎郎さん(「カンバン仕事術」や「ジョイ・インク」「スクラム現場ガイド」らの訳者のお一人)がこんな事をSNSでおっしゃられていたと記憶しています。(ニュアンスが異なっていたり、そもそも発言者が原田さんじゃなかったらスミマセン)
「スクラムは開発チームにマーケティングを取り入れるための開発プロセス」
そもそも開発対象にブレが無かったら、ウォーターフォールで開発した方が楽ですし確実です。そうではなく、市場やユーザーのニーズに対応し随時開発の方向を見直す必要があるからこそ、スクラムでイテレーションまわして開発する必要があるのです。*2
イテレーションごとに契約を行うことによるオーバーヘッド増加について前述しましたが、費用だけでなく開発スピードにも弊害が生じます。仮に、イテレーション期間を3週間として設定し、契約手続きに毎回1週間必要だとすると、最低でもイテレーション開始2週間前にはそのイテレーションで開発する対象を確定し、見積を開始する必要があります。結果、実質1ヶ月強も開発対象を変更することが出来ないわけです。前イテレーションで作ったものが気に入らなかったとき、顧客側はどうするつもりなんですかね？ SIer側に無理を言って強引にねじ込むのでしょうか？ それとも泣く泣く我慢して次の機会を待つのでしょうか？
また、一括(作成請負)契約にする時点で、顧客側の担当者がどの程度このプロダクトにコミットする気があるのかが気になります。理想としてはプロダクトオーナーとしてフルタイムをプロダクトにコミットするのが望ましいですが、そこまで行かないにせよ、ある程度開発サイド(チーム)と対話しやすい距離にい続けることは非常に重要です。それにも関わらず、開発を発注した時点で要件をすべて伝えた気になり、以降をSIerに任せきりにするつもりなら、そもそもスクラムで開発する意味は皆無でしょう。開発契約を一括にしたい理由が、値段を先に決めたい・社内稟議を通しやすくしたい のであれば、心情的には理解はできますが、単にITに関わる作業を丸投げしたいだけであれば、おまえちょっとチャランポラン過ぎないか、と思わなくも無いです。
客がそもそも「アジャイル」が何なのかを分かっていない
だいたいにおいて、「開発をアジャイルでやりたい」とか言い出す輩ほど、アジャイルのことを何も分かってないケースが多いです。
そもそも「アジャイル開発」などと言うものは存在しません。「アジャイル(agile)」は「俊敏な」「素早い」「小回りのきく」といった意味を示す形容詞であり、「アジャイルな開発」というものはあっても「アジャイル開発」という開発手法や開発プロセスがこの世にあるわけではないです。アジャイルソフトウェア開発宣言(アジャイルマニフェスト)とその背後にある12の原則に沿う開発プラクティスがいくつも存在し、それらを総じて「アジャイル」と呼ばれているのに過ぎないのです。
前述のように「アジャイル＝スクラム」のイメージを持っていてくれているならまだマシですが、そんなレベルにさえないことが残念ながら大半のようです。
一年ほど前、「アジャイルがダメだと思う7つの理由」について議論する会というイベントが開催されました。その3年ほど前に鈴木雄介さんが問題提起した「アジャイルがダメだと思う7つの理由」について、もう一度議論してみようというのがイベントの主な目的。
この会でオレは「6.手段が目的になっている」の議論の場のファシリテーターを担当しました。アジャイルな開発を実施する上で「Don't do Agile, Be Agile.」(アジャイルをしようとするな、アジャイルであれ)という有名な格言があります。この格言の指摘にもあるように「アジャイル開発をすること自体が目的になっていないか？」というのが、この議論の場の主な議題。もっともこのイベントの参加者はアジャイルな開発に熟練しており、さすがに手段と目的を履き違えているような方はお一人もいらっしゃいませんでしたが、一方で面白い話が議論の中心になりました。
「最近は顧客から『アジャイルで開発してほしい』と言われることが多い」
冒頭のうちの会社の話とまるで同じです。が、でも詳細を聞いていくと、アジャイルで開発してほしいと言ってきた顧客の、実際の要望はまったく違うようです。
当たり前ですが、開発の本質はアジャイルにしようが何も変わらないので、アジャイルな開発手法に変えても吉野家のごとく旨く早く安く開発対象が出来上がることはありません。普通に考えれば当たり前なんですが、アジャイルという言葉がIT業界に定着した今、ユーザーサイドにはそれがバズワードとして広まり、背びれ尾びれが付いた状態で、まるで魔法かなにかのように認識されているのでしょう。前述のイベントの最後に自分たちの議論の場のまとめを簡単に発表したのですが、まるで童話の「オズの魔法使い」だなと思い、皮肉を交えて以下のように紹介したところ、会場からは大爆笑を頂戴しました。笑い話で済めば幸せだったのですが、残念ながらこれが今のソフトウェア開発の現実のようです。
「『アジャイルやっている』と言うと愛だの勇気などを要求されることがあります」 #アジャイルがダメだと思う7つの理由
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) 2016年5月18日
顧客から「開発をアジャイルで」「でも契約は一括で」と言われた時にすべきこと
では、SIer側は「開発をアジャイルで」「でも契約は一括で」と顧客に言われた場合、どうすべきでしょうか？ オレのたしない頭で3案考えてみました。
1.アジャイルに何を求めるのかを確認する
要は顧客に「お前の言うアジャイルってなんなんだ？」と確認する、ということです。コストダウンがしたいのか、なんとなくモノをヨロシク作りたいのか、要件があいまいでフワフワした状態から開発を始めたいのか、流行だからなんとなくやってみたいのか。顧客にこんなことを聞くと失注するのでは、と不安に思うのかもしれませんが、そこをあやふやにしたまま契約しても、双方ともに不幸を見るだけです。勇気を持って、まずは要求を明確に確認するところからはじめるべきでしょう。間違っても「アジャイル＝スクラム でやりたいのね」などと早合点しないように。
2.準委任(SES)契約を勧める
スクラムで開発することになった場合、納品物を最初に確定する一括(作成請負)契約はとてもリスキーです。契約期間中に数イテレーションを挟めば、最初の要求と異なる成果物になる可能性が十分ありえるからです。であれば、契約物を確定しない準委任(SES・作業請負)契約を勧めるのが望ましいです。準委任契約は成果物を保証しないので、顧客から嫌がられる場合が考えられますが、であればスクラムで開発を諦めるか、選択を迫ってみるべきでしょう。
3.一括契約ながら成果物をあいまいにしておく
スクラムで開発することは断れない、でも一括契約も避けられない、失注もしたくない。そんなジレンマを抱えた時の最終手段です。開発期間と案件参画人員数を単純に掛け算して工数を算出し、それを元に見積を作成、しかし成果物はなるべく明確に定義しない、という契約にします。一括契約ながら中身は実質準委任契約、みたいな契約にすることを目指したものです。顧客が「値段を先に決めたい・社内稟議を通しやすくしたい」という目的で一括契約を望んでいるのであれば、ある程度実現性はあるのかな、と思います。ただ、成果物があいまいになる都合、開発中に問題が発生して、最悪裁判沙汰になったりした場合には、結構大変なことになりそうな気がします。成果物とは異なる作業エビデンスを随時残しておく必要は出てくるかもしれません。
おわりに
色々書きましたが、こういうノウハウを持って対処していらっしゃる企業さんはきっといるのでしょう。どこかでそういうのを共有出来る機会*3があるといいんですけどね。
今オレは現場に出ていて、顧客企業内で働いています。この現場では、一応ウォーターフォールプロセスで開発しているんですが、要求はプロダクトバックログで管理して、都度(3ヶ月単位)でビジネスサイドからの要望を見直して開発対象を決めていたりと、ちょっとスクラムっぽいところもあるんですね。こういうやり方もあるんだなぁと密かに感心してました。
ちなみに今のオレの契約は準委任……いや、上司からは時間清算って強調されたなぁ、時間に見合った成果物が出せないとすぐリリースされるから、そうならないようにちゃんと働けよと散々釘を刺されました。ハーイ、気をつけマース。
上記に書いたような内容は、以前SlideShareに資料をあげてますので、良かったらそちらもご覧ください。
ロジカルシンキングのことを「ロジシン」と呼ぶ営業マンがいた
ものすっごいロクでもない話なんですが。
今週火曜だったかな、定時ダッシュして山手線で内輪で開催・運営している社外勉強会に向かっている最中のことです。ちょうど時間は帰宅ラッシュ、社内はかなり混雑しており、オレも吊革で体を支えながらiPhoneでポチポチとソシャゲなんぞをこなしていたんですが、ふと目黒あたりから混雑した車中でも良く通る男性同士の会話が聞こえてきました。ふと声の方に目をやると、いかにも営業マンな男性2人組が、おそらく仕事に関する内容なのでしょう、一方がもう一方に仕事の進め方についてレクチャーしているように見受けられます。その様子はずいぶんと熱を帯びており、周りの混雑もはばからず一生懸命に話していました。
そんな様子を特に気にも留めず耳にしながら再びiPhoneに目を落としていたのですが、ふとレクチャーする側の営業マンの口から、とても気になる言葉が飛び出してきました。
「だからさ、ロジカルシンキングってのはあの売上表に数字を入れていくためのツールなんだよ！」
……………………はぁ？
一瞬我が耳を疑いました。まさかそんな馬鹿な。でもそれは聞き間違いではありませんでした。その後もレクチャー側の営業マンは同様の内容を繰り返します。聞く側の営業マンも特に訂正もせずにウンウンと熱心に耳を傾けています。挙句の果てには「つまりロジシンをさ！」などと「ロジカルシンキング」という用語を略し始める始末。「ロジシン」なんて略語、聞いたこともねーよオレは！
やがてオレは品川で電車を降りたので、それ以上その会話を聞くことはありませんんでしたが、精神衛生上それで本当によかったと思っています。
わざわざ後述するまでもありませんが、「ロジカルシンキング」は「ツール」ではありませんし、ましてや営業上の数字を入れるものでもありません。彼らが使っていた「ロジカルシンキング」という言葉は、明らかに意味が間違っています。Web辞書で調べてみると、以下のように解説されていました。
論理的な考え方と、その技法。
― goo国語辞書
ロジカルシンキング（logical thinking）とは、一貫していて筋が通っている考え方、あるいは説明の仕方のことである。
論理的思考法。物事整理して考え、論理的に筋道立てて、他の人に分かり易く説明する手法。また、その能力のこと。
「スピーディーにスムーズに相手に分かりやすく物事を伝える」こと。コミュニケーション能力を推し量る指標の一つ。― はてなキーワード
これはあくまで想像に過ぎない(しかも彼らに対してかなり好意的かつ同情的な)んですが、おそらくは彼らの会社もしくは部署で、とあるツールに対し、なぜか「ロジカルシンキング」などという名前をつけてしまったのでしょうね。これが事実であったなら、その命名者のセンスと語彙力は壮絶に残念なものであることは言うまでもありません。かつ、彼らが不勉強で「ロジカルシンキング」という一般ビジネスパーソンにとって割と当たり前(少なくともちょっとWebで調べれば意味が分かる)用語を知らない・他で聞いたことが無いならば、まぁこういったことがあるのかもな、と思いました。思いましたが、彼らが自信満々声高らかにラッシュアワーの山手線で喋った内容が、実は周囲が眉をひそめるようなものであったこと、彼らがビシッと決めたスーツも髪型も胸元のバッヂもすべて台無しにするものであったことは、きっとソッとしておいてあげるべきなんでしょうな。
さっき上記の記事を読んで、そんなことを思い出しました。ロクに意味も分かってないで横文字使ってる人、非常に多いんでしょうね。オレもこれを他山之石とせず、今後の自戒としたいと思います。だって、あんな格好悪い目に遭うの、オレ絶対にヤだもの！
5/24「AWS Blackbelt Online Seminar Amazon Elastic Compute Cloud (EC2) - Windows」受講レポート
はじめに
Amazonが配信している「AWS Blackbelt Online Seminar Amazon Elastic Compute Cloud (EC2) - Windows」を受講しました。以下受講メモ。
メモ
Amazon EC2 Windows概要
- AWS Windowsのイノベーション
- Amazon EC2
- Amazon Systems Manager
- Amazon EC2またはオンプレミスのシステムに対して自動構成と継続的な管理を可能する一連のサービス
- マイクロソフトライセンスモビリティ
- 既存のMS製品ライセンスをAWS上に持ち込み可能
- ソフトウェアシェアランスの特典として提供
- 仮想コアライセンスなどMSのライセンスモデルに応じてデフォルト手何紙のEC2インスタンス上で利用可能
- 対象製品
- マイクロソフト製品条項(PT)に定義
- 毎月更新される
- 対象製品
- Exchange Server
- SharePoint Server
- SQL Server
- 対象外
- Windows OS(クライアント/サーバー)
- デスクトップアプリケーション
- EC2 Dedicated HostsによるBYOL
- 占有環境で利用する
- ライセンスのコンプライアンスを維持
Amazon Machine Image(AMI)
インスタンスの設定
モニタリング
- Amazon CloudWatch
- AWSの各種リソースをモニタリングするサービス
- メトリクス監視
- アラーム作成
- ログ監視
- CloudWatchへの情報送信
- ローカル設定ファイル
- EC2 Systems Manager/ステートマネージャー
- EC2Rescue
- トラブルシューティングに役立つツール
- ダウンロードして活用
- インスタンスから以下のデータを収集
- イベントログ
- メモリダンプ
- ログファイル
- レジストリ
- システム情報
- ブート構成
- Winddowsアップデートログ
ネットワークとセキュリティ
- キーペアとWindowsインスタンス
- セキュリティグループ
- リモートデスクトップ接続
- キーペア
- IPアドレス
- Administratorパスワード
- 拡張ネットワーキング
- ディレクトリ復元モード(DSRM)のサポート
- PVドライバにより異なる
まとめ
5/23「AWS Blackbelt Online Seminar AWS認定試験準備に向けて」受講レポート
メモ
- AWS任手プログラム紹介
- 準備作業の紹介
イントロダクション
- AWS・クラウドの現状を紹介
- AWS認定
- エキスパートの証明
- キャリアアップ
- 名刺にAWSを貼れる
- コミュニティ参加
- AWS認定保持者
- 高い年棒だよ
- 技術的な信頼獲得に役立った
- 同僚から頻繁に相談されるようになった
- 認定プログラムについて
- ソリューションアーキテクト
- DevOpsエンジニア
- デベロッパー
- DevOpsエンジニア
- システムオペレーションアドミニストレーター
- DevOpsエンジニア
- それぞれに
- アソシエイト
- プロフェッショナル
試験内容について
試験準備
感想
まぁそんなに特筆すべきこともないのですが。
会社の今期の自身の評価基準に、うっかり「1つ以上のAWS認定資格の合格」を入れてしまったものだから、ぼちぼち(つまり6/末までに)受験しなくちゃいけないんですけど、そういえばちゃんと調べてなかったなぁと思って、ザックリ把握するために受講してみました。いやー、やること多いですね。本当に残り1月で合格できるのか、オレ？ 元々あまり資格取得に興味が無いので、正直放置できるなら放置しておきたいところなんですが、そうも言ってられないので、とりあえずトライだけはしてみようかなと思います。
そういや、今回のオンラインセミナーは女性の方が講師でした。今まですべて男性だったから珍しいですね、内容も技術者向けバリバリって感じでもないので、営業さんだったりとかしたのかしら？
Amazon AthenaでCloudFrontログを解析しようとしたらエラく苦労した話
この2日間、さんざん悩んだので、メモメモ。
Amazon AthenaはS3に格納したログファイルとかを、まるでRDBのようにSQLで検索・分析できる、いわゆるサーバレスなサービスです。
このAmazon Athenaで、S3→CloudFront経由でダウンロードしたファイルのアクセス数をカウントするような簡単な分析を行いたい、というのが今回の要件。CloudFrontはS3にgzip形式(拡張子:「.gz」)でアクセスログを吐くので、こいつを無加工(gzipを回答したりファイル群を結合したりせずに)で検索できるあたりがAmazon Athenaとても便利なところです。
Amazon Athenaは割と最近リリースされたばかり(「AWS re:Invent 2016」で発表)なので、社内に知見もなく、Webの記事を参考に構築を試みました。……がこれがどエラい苦労しました。
参考にすべきものがあって何故苦労したか？ これじゃまともに動かなかったからです。各記事のテーブル作成SQLでテーブルを作ると、なぜかログファイルのレコード行が空白で取り込まれ、ヘッダー行が1カラム目がやはり取り込まれない状況でした。
結論から言うと、以下のSQLで正しくテーブル作成ができました。カラム名を「` (アポストロフィ)」で囲む必要があったのです。今回はSQLを直接エディタに書くのではなく、コンソールからチマチマ入力してテーブルを作った際、このSQL文が生成されたことで違いに気づけました。
CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_log ( `date` date, `time` string, `x_edge_location` string, `sc_bytes` int, `c_ip` string, `cs_method` string, `cs_host` string, `cs_uri_stem` string, `sc_status` int, `cs_referer` string, `cs_user_agent` string, `cs_uri_query` string, `cs_cookie` string, `x_edge_result_type` string, `x_edge_request_id` string, `x_host_header` string, `cs_protocol` string, `cs_bytes` int, `time_taken` int, `x_forwarded_for` string, `ssl_protocol` string, `ssl_cipher` string, `x_edge_response_result_type` string, `cs_protocol_version` string ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe' WITH SERDEPROPERTIES ( 'serialization.format' = ' ', 'field.delim' = ' ' ) LOCATION 's3://sample-cloudfront-log/logs/' TBLPROPERTIES ('has_encrypted_data'='false')
※S3バケット名は記事記述用のでたらめなものです。ご注意あれ。
参考にした記事らは以下。参照した記事のうちのほんの一部です。
- Amazon Athena で CloudFront のログを分析してみる
- Amazon AthenaでCloudFrontログをSQLで解析する #reinvent #athena ｜ Developers.IO
- Amazon Athena で Amazon CloudFront のアクセスログを分析する - Qiita
これらの記事の内容が間違っていた、とはオレは思いません。何故なら、同時期に書かれた記事で同じようなSQL文が書かれており、実際に検証した結果の画面スクリーンショットも張り付けられていたからです。
おそらくは、かなり直近……おそらく昨日今日のレベルで、Amazon Athenaで仕様変更があったんじゃないでしょうか？ 詳細は分かりませんが、今後突然CloudFrontログ分析がAmazon Athenaで行えないケースが増えそうな気がしたので、自分用のメモを公開しておきます。
※何か誤りあればご指摘頂けますと大変助かります。
「AWS Black Belt Online Seminar AWS for Game Developers」受講レポート
はじめに
Amazonが配信している「AWS Black Belt Online Seminar AWS for Game Developers」を受講しました。以下受講メモ。
メモ
講師
- 畑 史彦さん
ゲームの進化とゲーム開発
Amazon Lumberyard
- Cloudとccrowdの力を活用しAWSとTwitchを深く統合させた無料のAAAゲームプラットフォーム
- AWSと非常に深く統合
- 共通のネットワーク接続を簡単に作成
- マルチプレイヤー
- ソーシャル
- 分析
- 動的コンテンツやライブコンテンツの更新
- 新しい・素晴らしい体験
- 手続き的なゲームプレイ
- 人工知能
- 多くのプレイヤー
- クライアント - エンジンプラットフォーム
- Lumberyard Editorの基本機能
- 基本的なゲーム開発に必要なものは大体そろってる
- レンダリング
- モバイルサポート
- VR
- ワークフロー
- New IDE
- Component Entities
- Gem
- Lumberyardのゲームプロジェクトをっ拡張するためのコードやアセットが含まれているパッケージ
- 現在Lumberyardには、すぐ利用できる26のgemが用意されている
- Modular Gemシステム
- ゲームプロジェクト間でコードとアートアセットを共有するための管理インフラストラクチャ
- プロジェクトのコンテンツの追加と削除が容易にできる
- コアエンジン部分は必要なテクノロジーのみに
- UI Editer
- GridMate
- CloudCanvas
- Cloud Gem Framework
- Lumberyard IDE
Amazon GameLift
- セッションベースのマルチプレイヤーゲーム専用のゲームサーバ管理サービス
- 設計
- プロトタイプ構築
- 本番環境構築(複数回)
- スケーリングに関わるたちの悪い問題
- UIダッシュボード構築
- リリース
- 24/365保守
- コストの最適化作業
- ビルドとフリート
- 開発者のワークフロー
- 開発環境
- AWSアカウント
- Lumberyardのゲーム
- ネットワーク
- 開発ステップ
- 4ステップで実現可能
- デプロイ
- プレイヤーから透過的
- 進行中にゲームプレイに影響しない
- Alias
- フリートによりプレイヤーの乳流を制限
- セッション管理
- 稼働している世界中のゲームサーバーを継続的にスキャンし、プレイヤーからのゲーム参加リクエストをマッチング
- リアルタイムで情報を把握
- 世界展開
- 9リージョンから配信可能
- オートスケーリング
- ルールベース
- リアルタイムな利用可能量に基づく調整
- プレイヤーセッション
- サーバ
- インスタンス
- 利用料金
- 従量課金
- 採用事例
- STREAM LINE
- Proletariat Inc.開発
- Unreal Engine，Unityを含むすべてのC++/C#ゲームエンジンをサポート
- Amazon GameLisft Local
- クライアントサイドのデバッグツール
Twitch
- ソーシャルビデオプラットフォーム・コミュニティ
- 新しいゲームプレイ体験を提供
- 視聴者がゲームに参加
- チャットコマンド
- 配信者からの招待
- ゲーム画面にゲーム状況をオーバーレイ
まとめ
- ゲーム開発者向けのEnd-to-Endソリューション
- インフラ管理に労力を割くのではなく、コンテンツ制作とゲーム制作に注力できる
感想
オレ自身、ゲームを開発したことはないですし、その予定もないのですが、今回はAWSの提供サービスをざっくり把握することを目的に聴講しました。聞いている限りでは、確かにインフラに関わる部分をかなり省力化できそうな印象を受けました。ソーシャルゲームなんかは当たり外れが大きいので、オンプレで1からやるよりはこういうプラットフォームを開発・運営に活用するのは良さそうですね。グランブルーファンタジーのような超大規模ソーシャルゲームは、クラウドだと調整しきれないのでオンプレで運営しているという資料を読んだことがありますが、あそこまで大規模になるかどうかはリリースしてみないと分からないでしょうし、まぁ別物と考えていいんじゃなかなと思います。
4/26(水)、「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」参加レポート
はじめに
東京丸の内：株式会社IDOMさんで開催されたGitHub社・クラスメソッド社の合同開催勉強会「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」に参加してきました。以下、聴講メモ。
メモ
開催概要・諸注意
- クラスメソッド：佐々木大輔さん
- How we ship GitHub
- DevOps
- 色んな人が色んな意味で使ってる
- インフラ効率化
- リリース自動化
- ただの何かのツール
- 大事なのは
- 価値を無駄なく遅滞なく届けること！
- 近年起きていること
- アジャイル
- 三角形はさかさまに
- スコープがFix、リソースとタイムを動かす
- →リソースと時間がFix、スコープを動かす
- →世の中の変化の方が早いので
- イテレーティブに開発しましょうね
- コラボレーションがやりやすく
- 中央集権型→分散型へ
- CI
- 必須のプラクティス
- Continuous deliveryy
- 今のDevOpsブームが目指しているところ
- Continuous deployment
- 常に本番にデプロイされている状態
- ここまで行くべき
- 例
- ネットフリックス
- GitHubでは？
- 数十回デプロイ/日
- GitHubberは世界中に散らばっている
- 60%はリモート
- 日本は11人
- 実際にはもうちょっといる
- 米国が明らかに多い
- 米国各地に散らばっている
- 地理的にもタイムゾーン的にもバラバラ
- どうやっているか？
- GitHub Flow
- Guide.github.com
- Masterを
- 常にデプロイ可能な状態に保つ
- 本番とイコールに
- 必ずブランチを作って開発
- 生存サイクルを短く
- 溜め込まずすぐPull Requestを作り、フィードバックをもらう
- Hubotが大活躍
- Pull Requestブランチを各環境にリリース
- 問題ないものだけMasterにリリース(マージ)
- もし現在のMASTERブランチの内容がPull Requestブランチに無い場合は、まずMSTER→Pull Requestにマージ
- もう一度テスト
- Masterにコミット
- Hubot(ChatOps)
- ディスカッション上で重要な役割
- OSSチャットボットの仕組み
- GitHubで一番働いてるのは人間じゃない！
- チャット上で様々なオペレーションを行う
- なぜチャットか
- Shared Console
- 誰がやっても同じ結果が出る
- 他人がやってる様子をチャット上で見て学べる
- いつでもどこでもリモートワーク
- デプロイだけならスマホでもできる
- さすがにコード書くのにはPCが必要
- Pull Requestリリース時に、自分がどこにリリース可能か、教えてくれる
- Deplyment API
- チャットコマンド上で手軽にリリースできる
- 「queue for github」
- プロダクションへのデプロイ待ち状況をHubotが教えてくれる
- 待ちが発生している間は他の人がデプロイはできない
- Deployment confidence
- デプロイしたものが本番環境でどのように動作しているかを確認できる
- 様々な形での支援
- 自動でISSUEを立ててくれる
- etc
- チャットやグラフで確認可能
- 様々なことを全てChatで
- CIのセットアップ
- 営業的な見積
- メンバーの居場所通知
- Google Map確認
- 画像(ランダム)
- GIF画像
- 近くにいる人
- メンバーのプロフィールをhubotが紹介
- 様々なツールを活用
- GitHub
- Hubot
- Slack
- Janky
- Heaven
- Heroku
- gPanel
- sentinel
- etc...
- まとめ
- 市場のニーズはすごいスピードで変わっていってる
- DevOpsは必須
- さらにその先へ
- リモートで非同期に
- ChatOpsは企業をグローバルかつフレキシブルなスタイルに
- AIが絡んでくる？
DevOpsとAWSサービス
- DevOpsとは？
- DevOpsの目的
- ビジネスに使う時間を増やす
- デプロイ：月1回→毎日10回
- 運用者：10人→3人
- -
- CIとは？
- ビルド・テストの自動化
- 小さくたくさん回す
- 継続的デリバリー(CD)とは？
- CIにデプロイまで含む
- 統合テスト
- AWSサービス紹介
- CodeCommit
- CodeBuild
- CodeDeploy
- CodePipeline
- ビルド・テスト・デプロイ・承認などのワークフロー管理
- CodeStart
- ここまでのCodeXXXを使ってCI/CD環境を一発で作成できる
- マイクロサービス
- Lambda
- API Gateway
- ECS
- Dockerオーケストレーション
- ECR
- コンテナレジストリ
- 他色々
- 時間がないので猛ダッシュで
- サービスをどう選ぶ？
- 時間がないので後で見てね♪
- 実装例
- 例1：CI/CD EC2でBlue/Greenデプロイ
- 例2：CI/CD ECS
- まとめ
- 安全に早くたくさんリリース
- ユーザーに提供する価値を増やす
- リリースフローの見える化、自動化
- モニタリング可能に
- 開発者・運用者・経営者、三方良しに！
感想
とりあえず「GitHubすげえな！」と。チャットってあんなに活用できるもんなんですね。正直ビックリしました。
同様にhubot凄い。オレの友人に頻繁に承認欲求を満たすために褒めることを要求してくるメンドクサイ奴がいるんですが、そいつのメンタルも管理してくれねーかな。(冗談ですよ、ジョーダン)
個人的にはお二人目の千葉さんの発表はかなり参考になりました。ちょうどAWS使い始めたばかりだというのもあり、サービス概要を把握してなかった、というのもありますが、今すぐ活用できそうなサービスがあったのも個人的には嬉しかったです。早速明日試してみようかｎ……いや、明日はダメだ、見積資料作らないとマズイ。
逆に三人目の中山さんのお話は、そもそも情報量が多かったことと、かなりディープな内容だったこともあって、AWSもGitHub Enterpriseも初心者なオレはあっという間に振り落とされました(笑)。最初の事例くらいまでは理解できたんですけどねぇ、GitHub Enterpriseってそんなに色々やんないと使いにくいモンなのかな？ 全然使い込みが足らないオレには、その辺がいまいちピンと来なかったです。でもまぁ実際にニーズがあってお客さんがあっての事例でしょうから、必要なんだろうなぁ。
それはそれとして、クラメソさんの勉強会って、だいぶ久々(数年ぶり？)に参加しました。Adobe Flexとかの頃にはよく参加させて頂いたんですけど。オレ自身、遅まきながらここ最近になってAWSを触り始めたので、また積極的に参加したいですね。
