読書記録 - カイゼン・ジャーニー
読んだメモです
全編通してストーリー仕立てで、スクラム開発とその周辺のフレームワークがガッツリ登場する。合間に入る解説も砕けた文体なのでささっと読めるのが良かった。
反面、軽く触れるだけのモノもあるので詳しくは原典を漁る必要があると思うが、キーワードを知るだけでも価値はある。
チームビルディングだけでなく、SIの現場における提案、製品開発のクオリティ指針に繋がる話など、読む価値のあるターゲット層が幅広い。マネージャや開発者サイドだけでなく、営業やマーケも目を通しておくとタメになりそう。
「第2部 チームで強くなる」以降はロールとしてプロダクトマネージャ、スクラムマスターが登場するが、これらが存在しているチーム構成かつスクラム開発前提でカイゼンの方向で話が進むため、レガシーな環境だとまずこの時点で人材と開発ノウハウが不足する。とはいえ少しずつエッセンスを取り入れて、自分達のチームにフィットする取り組みをどう実践するかの取捨選択をしながら徐々にチャレンジする必要はあると思う。
---
以下は、後で調べる的なメモ。
タスクボード
計画づくりをした内容を見える化する
タスクの状態に対応するステージを用意する
※ツール的にはTrelloがまさにそう
タスクマネジメント
仕事の背景や目的を理解する
うまくいかない要素を早めに見つける
仕事が大きいなら小さな独立タスクに分ける
ふりかえり
仕事のやり方やその結果を棚卸し、次の計画づくりに活かすことを目的とする
朝会
タスクボードの変化を反映するタイミング
決まった時間場所リズムで行うのが原則
昨日は何をやったか、それを踏まえて今日は何をするか？困っていることはあるか？
スクラム
スプリントを繰り返し設計・開発・テスト・デリバリーを実施するフレームワーク
※アジャイル開発の手法の一つ
デイリースクラム
スプリントのゴール達成のための進捗、優先順位、障害の確認のミーティング（15分以内）
プロダクトバックログ
顧客要求のひとつひとつ
優先順位でリスト化し一元管理する
スプリント開始前あでにプロダクトオーナーが完了させる
ゴールデンサークル
中心からWhy, How, Whatの円
Whyから思考を開始する（Whatから始めるほうが楽）
なぜこのプロダクトづくりなのか？
なぜこのプロジェクトを始めるのか？
Working Agreement
チームで仕事をする上で合わせておきたいこと
スローガンは避け、具体的で誰もが同じ見解で判断できるもの
動きにくくなるほどの縛るルールにせずチームの生産性を高めるため
チームのメンバー自分たちで決める（リーダー、マネージャが決めない）
インセプションデッキ同様、ふりかえりで更新していく
ファイブフィンガー
問題を抱えている人をチームでサポートする状況をつくるためのコミュニケーション促進。
テーマは全員に共通するもの
プロジェクトの今後、チームの状態など
全員で一斉に5本の指を使って表現する
5本.とてもうまくやれている
4本.うまくやれている感触あり
3本.可不可なし
2本.不安すこしあり
1本.全然だめで絶望的
ネガティブな本数のメンバーの意見から聞く
狩野モデル
差別化要素を伸ばすか、当たり前品質のモノにするかプロダクトの戦略に寄る
品質の定義
魅力的品質
満足を与え、不充足でも仕方なし
一元的品質
満足を与え、不充足であれば不満
当たり前品質
充足されて当然、不充足であれば不満
インセプションデッキ
外側、プロジェクト関係者における期待のすり合わせ
やるべきことの目標、目的の共通認識として持つためのドキュメント
えらい人だけで決めるのではなくて、メンバー全員でやるのが必須
・われわれはなぜここにいるのか
エレベーターピッチ
パッケージデザイン
・やらないことリスト
スコープ確認
あとで決めることも時間の経過とともに変化する
・ご近所さんを探せ
ステークホルダー確認
・夜も眠れなくなるような問題
解決案を描く
・トレードオフスライダー
期間の見極め
何を諦めるのか
何がどれだけ必要か（人、時間、お金）
むきなおり
進むべき先を捉えて現在を正す
評価軸を見定め、あるべき姿と現状の課題を洗い出す
インセプションデッキの「われわれはなぜここにいるのか」がブレていないこと
合宿
集中
宿のチェックイン・チェックアウトの決められた時間の中で、外部からの割り込みがない
リードタイム短縮
全員でまとまった時間を一気にとる
高揚感
非日常な空間と時間をつくる、お互いの価値観を知る機会
アンチパターン
いつもと同じ場所
ゴールがあいまい
アジェンダ（やること）の詰め込みすぎ
アクションプラン（やること）が未設定
必要な人がいない
まずい飯
星取表（スキルマップ）
プロジェクトで必要なスキル、メンバーの表
スキルの習熟度合いを5段階で描く
☆：エース級、○：一人前、△：ヘルプが必要、↑：習得希望、ー：できない
インセプションデッキのAチームが項目づくりの参考になる
項目づくり、スキル埋めはチームメンバー自身で議論しながら作成する
チームビルディング初期に役立つ
詳しい人に聞く、依頼するなどにも使える
定期的に確認して、チームの成長度合いを測る
チームビルディング三種の神器
インセプションデッキ：
プロジェクトの目的や方法論
ドラッカー風エクササイズ：
チームメンバーの価値観
星取表：
目的を達成するために必要なスキル
モブプログラミング
みんなで一つの画面を見ながらコードを書く
ドライバーは１人、他はナビゲータ（指示をする）
全員が交代でドライバーをする
時間交代（１０分程度）
５人くらいまでが望ましい
メリット
プロセスフロー改善
同期、承認、手戻り、レビューが一切いらない。
その場で解決。プルリクもマージもその場でやっているイメージ
コミュニケーションカイゼン
ワイワイガヤガヤやることで思考を共有する
向く先は画面と課題であり、ボスでもリーダーでも実装者でもない
学習効果
建設的相互作用
達成感
全員で解決していく
否定ではなく提案をする
プログラミング以外でも使える（その日の作業の流れの書き出しもモブでやる）
止まって考える時間を設ける
TWI
Training Within Industryの略、職場教育手法
バリューストリームマッピング
プロセスの見える化とカイゼンするためのコミュニケーションツール
リードタイムとプロセスタイムを意識し、局所最適化にならないようにする。全体最適化が大事。
“遅い“のカイゼンのための可視化
カンバン
自分たちの仕事の流れに着目した可視化
開発だけでなく開発と運用が同時進行するような状況で力を発揮する
ステージ(列)はバリューストリームマップの、マッププロセスが利用できる
計測するのは2つ
1. 着手ready状態のプロダクトバックログアイテムが完了するまでの期間の記録
2. 定期的に、完成したプロダクトバックログアイテムの数を数える
スピード、どこで滞るかが把握できる
ポストモーテム
プロジェクト終了後の事後検証
場の設定ポイント
時間厳守
全員参加
目的の共有
ゴールの明確化
記念写真
ルールのポイント
人事評価には関係ない
気軽で自由な発言
グランドルールを３つくらいつくる
議論のポイント
具体的な内容を語る
事実を集めて課題を見つける
事実と意見/解釈を分ける
ポジティブな問題解決
次のプロジェクトの糧にする、メンバー各自のTry事項をつくる
ファシリテーターのポイント
個人攻撃になりそうになったら対象を問題に対するよう促す
考えを代弁しない、メンバーが発言のために思い出さす時間を耐える
タイムラインふりかえり
メンバー全員で年表をつくる
時系列に事実（チーム単位、個人単位どっちも）を記載する
感情やモチベーションをグラフ化
今後どう活かすかを考える
ドラッカー風エクササイズ
内側、チーム関係者における期待のすり合わせ
人と質問のマトリクスをつくり、他のメンバーと共有する
・自分は何が得意なのか
・自分はどうやって貢献するつもりか
・自分が大切に思う価値は何か
・チームメンバーは自分にどんな効果を期待していると思うか
・その期待はあっているか？他のチームメンバーが5段階で回答する
1.完全に合っていない
2.あまりあっていない
3.ふつう
4.だいたいあっている
5.完全にあっている
モダンアジャイル
4原則
・人々を最高に輝かせる
・安全を必須条件にする
プロジェクト（CIでのテスト）やチーム（人を非難しないメンバー関係性）など
・高速に実験＆学習する
・継続的に価値を届ける
プランニングポーカー
開発メンバーである自分たちで見積もる。上司、コンサル、上流工程のSEではない。
相対的な見積値
全員に1組のフィボナッチカード
プロダクトオーナーがユーザーストーリー読み上げ
開発チームメンバーが各自カードを選び一斉オープン
一番高い、低い人の意見を聞き、根拠や懸念点を話し合う
再度全員でカードを選び直す
リリースプランニング
プロダクトバックログにリリースの目安（マイルストン）を引く
１つのリリースは複数のスプリントで構成されるのが一般
遠い先まで詳細にした緻密な計画ではなく、妥当なレベルの正確性を重視
スプリント毎の検証を活用し、情報を反映させていくので、目安の線は上下する
パーキンソンの法則
仕事の量は完成のために与えられた時間を満たすまで膨張する
計画はたいてい上振れし、バッファは消費されていく
CCPM(Critical Chain Project Management)
各タスクに個別バッファを持たず、プロジェクト全体としてのバッファを持って管理する
プロジェクトバッファの求め方
例）五分五分の確率で達成でき見積の合計値の半分の値をプロジェクトバッファにする
プロジェクトバッファだと各タスクの作業を期限ギリギリまで消費する現象が回避できる
プロジェクトバッファを使っても責められない場づくりが必要
SoE(Systems of Engagement)
顧客との絆を築く
利用主体は顧客
迅速なリリース、顧客体験
フロントエンド
スマホアプリ、Webサービス
開放的
サービスレベルを決めにくい
仮説検証
SoR(Systems of Record)
事実を記録する
利用主体は社員
安定性、信頼性
バックエンド
基幹業務システム
社内・公開限定的
サービスレベルの保証
業務検証
YWT
むきなおりフレームワーク
Y：やったこと
W：わかったこと
T：次にやること
定期的に実施し、T→Yとなるようにループする
スクラムオブスクラム
スクラムチームの代表者同士が話をする
・チーム内作業の情報
・チームで解決できない障害
コンウェイの法則
アーキテクチャは組織に従う。組織はアーキテクチャに従う。
組織の分割が進むとオペレーションの幅が狭まり、組織の壁ができる。コミュニケーションが減る。
デイリーカクテルパーティー
ミーティングに構造をもたせる
＋プロジェクト全体ミーティング：プロジェクトマネージャ, 各専門担当者
＋専門担当者ミーティング：各機能開発チームリーダー(テスト, バックエンド, フロントエンド, インフラなど)
＋スタンドアップミーティング(朝会)：各機能開発チーム
仮説キャンバス
目的：なぜこの事業をやるのか
ソリューション：提案価値の実現手段
優位性：自社がやるべき具体的なリソース・状況
評価指標
提案価値：顧客にもたらす価値
意味：顧客にとっての意味
ビジョン：顧客にどうなってもらいたいか
顕在課題：顧客が気づいている課題
潜在課題：顧客が気づいていない課題
代替手段：課題解決の現状手段と不満
チャネル：顧客に出会うための手段
状況：対象顧客の状況
傾向：状況に基づく顧客の傾向
収益モデル：ビジネスモデル
ユーザーストーリーマッピング
時間の流れに沿ってユーザの行動の変遷を可視化する
人物像を描き、場面と行動を書き出す
各行動に対するストーリーを書き出す
ストーリーの優先順位をつける
各行動の最優先のストーリーをMVP（Minimum Visable Product）とし、リリースロードマップとする
MVP
ユーザーにとって価値があり、かつ最小限の機能性を持った製品
価値検証
プロトタイプ型
DIYなどの図工の青果物、試験やデモ用
ハリボテ型
プレゼンやPhotoshopのような画面イメージと画面遷移を体験する
ボタンやリンクは動かず、プログラムコードは存在しない
動画型
ストーリーベースの動画作成
コンシェルジュ型
システム化はなく、人が中に入って検証する（有人自動販売機）
再利用を考えず、捨てる前提。
ユーザーインタビュー
ユーザーが何を求めているか、お金を払ってでも解決したい悩みを思い込みだけで進めないため。
ユーザーが本当のことを話していない可能性がある。
無意識のうちに意味のあることを話すために事実を変えて答える
主語が自分でなく推測になる
どう思う・考えたかではなく、どんな行動を取る、取ったのかを掘り下げ推測と事実を切り分ける
準備
仮設を立て、その仮設が本当に存在するかユーザの考えとの合致、解決ができるかをインタビュースクリプトにまとめる
実施
テクニック
ペーシング、ミラーリング、ラポール空間
貴重な時間を割いている相手に敬意を払う
分析、解釈、判断は後で行う。事実や話題をメモする。
検証
無加工のインタビューログの共有
考察や分析は解釈が偏らないようにする。
声の大きい人の意見に寄る、根拠の無い見立てで判断するなど。
SL理論（Situational Leadership）
チームやメンバーの成長に合わせてスタイルを変える
S1~S4の段階を経てメンバーが成長していく。
S1 教示的リーダーシップ：具体的に指示し、事細かに監督する
S2 説得的リーダーシップ：こちらの考えを説明して、疑問に応える
S3 参加的リーダーシップ：考えを合わせて決められるよう仕向ける
S4 委任的リーダーシップ：仕事の遂行の責任を委ねる
ハンガーフライト
経験の共有。
経験や勘にもとづく知識が蓄積され、血肉となる
社内ハンガーフライト（勉強会の実施）
日程と場所
参加者の熱量が上がるテーマ
コアメンバーと登壇者
業務時間外
理解ある経営陣や管理職からの応援の承諾
軽食、ビールなど
運営はボランティア
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- 作者: 市谷聡啓,新井剛
- 出版社/メーカー: 翔泳社
- 発売日: 2018/02/07
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
アウトドア記録 - 桐の木平キャンプ場で川遊び
シルバーウィークを使って桐の木平キャンプ場に家族で行った記録です。
キャンプ概況
- 2019/09, 2泊
- 気温13~27℃
- ケータイ電波は入らない
- 川の水温はかなり低い
- 時期の問題でアブはほとんどいない
- フリーサイトも区画サイトも場所が広く取れる(場所により小川張り可)
- 買い出しは沼田ICから15分弱のスーパーが吉
- 温泉はキャンプ場周辺に悩む程ある
- 休日の川場田園プラザは超混雑
天気はホドホド
2泊するも、連日晴れ>曇り>雨と目まぐるしい天候で
昼間の日陰で27℃、明け方4時に13℃になる数日間でした。
予めフリースにアウターの着替えを用意したものの、夜は妻は寒さを感じたとの事で、
いい加減年代物のシュラフを刷新したほうが良さそうだ。
平日設営だったためフリーサイトは他に1組しかおらずほぼ貸し切りだったのはとても良かったが、惜しむらくは星空が見えなかった点。仕方ない。。
川の冷たさにビビる
キャンプ場そばを流れるのは薄根川の源流にあたるポイントだそうで、とんでもなく水が冷たい。30秒も水に入ってたら感覚なくなってくるレベル。
9月になると流石に厳しいかなーと思ったが、管理人さんいわく8月も水温は変わらないらしい。さすが源流部だ。
子供は水温なんて気にならないらしく、テンションMAXで遊ぶ。
普段スマホやタブレットやテレビにしか触れない子供に川遊びさせるのは目的の1つなので、この点は予定通り。よしよし。
アドレナリンが出ると、おじさんも15分くらいは耐えられる。
奥利根ゆけむり街道
2日間で2つの温泉をまわる。
小住温泉
調べると閉館などの記事が出てくるが、2019年1月にリニューアルしたそうで通常営業中。平日の夜だったせいか完全貸切状態だったため子連れ目線では非常に良かった。
泉質はアルカリ性で温度が低め。中でも源泉に近い露天風呂は28℃らしい。プール入ってるかのような気分になったけど、たしかに硫黄の匂いも明らかに強く温泉っぽさが非常に強い。もうちょっと普通の温度ならしっかり入ってたかったけど、日が沈んでから長湯はちょっと厳しいものがあるかな。
花咲の湯
大きめの施設で岩盤浴などもあるようで、温泉よりはスーパー銭湯的な佇まい。送迎バスも出ているらしく外観も内観もかなりキレイで立派な設備だったが、如何せん混みすぎていた。
また、Webページに載っているような源泉かけ流し、つぼ湯、高濃度炭酸泉などは一切見かけなかった。露天風呂は何故かギリシャ彫刻のようなタイルと柱のつくり。女湯にしかないのか…？温泉は和風がいいよ。。
温泉の帰り道に野生の鹿が道路を横断しているのを見かけたのがハイライト。
---
また泊まりに行きたいけれど、サイトトップにもある通り公共工事(水力発電だそうな)の関係で営業が1年休止するかしないかの立地のキャンプ場。
2019年は営業中のようなのですが、見聞きする限りは来年あたりは工事期間に入ってしまうかも？良いタイミングで遊びに行けてラッキーでした。
読書記録 - 筋トレ英会話
読んだメモです
筋トレから外れた作品になると書いてあるが、筋トレ本だった
くだけた文体で説明しているのでさくっと読めるのが良い
Muscular!!!
- 中学,高校レベルの英文法を筋トレをテーマにして超簡易的に説明
- 出てくる単語が意図して偏ってる
- e.g. workout, gym, dumbbell, lift weight, bench press
- 英語習得の心得
- 自信を持て！
- 他人の目を気にするな！
- ふてぶてしくあれ！
- 英語学習は質よりも量
- Be a doer, not a talker
筋トレ英会話 ビジネスでもジムでも使える超実践的英語を鍛えなおす本 (単行本)
- 作者: Testosterone(テストステロン),大岩秀樹(東進ハイスクール),イワイヨリヨシ、小松聖二
- 出版社/メーカー: 祥伝社
- 発売日: 2018/07/01
- メディア: 単行本
- この商品を含むブログを見る
#builderscon tokyo 2019 - もしもハッカーの「サイバー攻撃日誌」が読めたらレポ
builderscon初参加しました。
おうちに帰るまでじゃなく、ブログ書くまでがビルコンらしいので書きます。
あまりセッションを見られなかったのですが、動画/スライド公開なしの以下のセッションについて、後学のために記録しておこうかと思います。
※ 記憶と少しのメモを頼りに書いています。
導入
- @Tsubomitchさんの自己紹介の時点でざわつく場内
- 日替わり変更されるパスコードのある物理部屋に侵入するなど
- ゴール設定は一番守りたいものを狙うこと
-管理者権限の奪取、重要データの入手、機密エリアの物理侵入など
- 「いろんな会社様を攻撃する」
概要
- 現実のサイバー攻撃を可能な限り忠実に再現する仕事で、Red Teamと呼ばれる。
- 会社間契約で決められたスコープの中で手段を問わずサイバー攻撃を仕掛ける。
- 管理者権限の奪取などゴールを設定し、抜き打ち実施。
- 攻撃対象は特定のIPやシステムだけでなく組織全体。
- システムの脆弱性だけではなく、人やインシデント対応といった包括的な組織の状況を把握をするためのサービスで、驚異ベースのペネトレーションテストと同義。
メモ
- ユーザの情報はソーシャルハックで取れる
- SNSなどで指名、出身、学歴、所属等
- フィッシングの材料
- どうしても人の対応に依存する
- 数撃ちゃ当たる
- 感染した端末から通知を受け取る
- 感染端末を起点に権限昇格、横断的攻撃
- pcadminはだいたいどこの会社にもいるのでターゲットにする
- ハッシュ化されたパスワードはクラックするだけ
- 二要素認証はめっちゃいい
- ユーザとパスワードは大抵割れるが、トークンは難しい
- 突破できないことないが、非常に手間
- トークン取得済みのユーザのセッションを使うなど二要素認証の突破自体は回避
- ユーザがランチに行くなど、席を外すタイミングを狙ってリモートログインする
- 大抵の情報はマイドキュメントにある
- パスワード、座席表(部門と氏名)、知識ベースの2段階認証など
- わざわざそこまでやるやつはいないだろう、と誰かが言うたびにわざわざそこまでやるやつが現れる
感想と学び
- 標的型攻撃は基本的に防げない。検知できるかどうか、検知後の初動対応が攻撃者との時間勝負となるのでポイント。監視と即時対応の体制が必要。
- RedTeamとしては、設定したゴールは今までほぼ達成しているとの事。つまり、攻撃側が本気になると撃退することは難しい。
- 二要素認証は入れられるだけ入れた方が良い。BtoCで効果を発揮すると思っていたが、一度入り込まれた後の事を考えると社内システムでも有益。
- セキュリティ、脆弱性の情報は勉強会や海外の情報サイト、Twitter等で収集する。
- 体系的に学ぶ
- サイバーキルチェイン
- NIST CSF
- ATT & CK Framework
- 実際に攻撃（される側）を体験する
- Hardening Project
なかなか聞けない貴重な話で、質問者が大勢いたのも納得。
みんな気になるガチハッカーセッション、とても楽しかったです。
Secureworks Red Team テスト
https://www.secureworks.jp/capabilities/security-risk-consulting/real-world-testing/red-team-testing
天気の子で厨二心になる
本当に便利な時代になった。
僕はVHSでテープが擦り切れるまでBTTFシリーズやインディージョーンズやグーニーズなどなど齧りついてたし、定期的にビデオレンタルショップでXファイルを借りては返し借りては返し、半永久的に観ていた少年だった。
毎年ドラえもんの映画を家族で観に行き、中学生になればタイタニックを見るために名古屋駅まで自転車で走ったりもした。
ここ数年はというと、猫も杓子もストリーミング配信になり貸出中のラベルに泣くことは無くなったし、TVも50インチがミドルサイズ扱いだそうだ。
個人的には子供を連れて映画館に行くハードルは高く、映画に浸れる環境は家で十分と自己暗示かけている。
そんなワケで近年は映画館に行くことがめっきり少なくなったけれど、今回はタイミング良く映画館に出向く時間も取れたので観てきました。
新海誠の映画は『ほしのこえ』を当時何かの拍子に観たのが最初で、ものすごいインディー色ながらもメチャこだわってるのが伝わってくる光の描写が印象的。話は退廃的な世界を舞台にしたSFで、主観だと少し前にあった最終兵器彼女という漫画に近い空気感。刺さる人には刺さる作品だったと思う。
今作は、『君の名は』が爆売れしたのもあり、客層は10代〜50代くらいの幅広さはあったかも？前作のようなキャッチーなストーリーが知名度を上げたのは間違いないだろうと思う。『ほしのこえ』みたいな尖った世界観の映画だと難しいのかな。SFというジャンルも厳しそうだ。。
そういう意味で『天気の子』は
お約束的なボーイミーツガールの展開を引っ提げて
実在の街を超絶綺麗に描いた聖地巡礼推奨の風景で
現代を舞台にしたファンタジーをメインストーリーに
複雑な10代の気持ちを表現しつつアクションシーンを散りばめる
そんな前作に負けないレベルのキャッチーさが詰め込まれてた。
並べ立てるとベタ過ぎて批判っぽくなるけど、全体通して飽きない展開で面白かった。
世界観としては基本は大人の世界をリアルに表現していて、主人公は振り回される側の立場が多い。社会（それも東京の極端な部分）に揉まれる描写が多いので、このあたりはちょっと苦手意識とか好きじゃない人がいるかもしれない。
ただ、この主人公の青臭さとか、反発する心境とか、思春期の雰囲気が抜群に上手い。この厨ニ感が刺さる人はノスタルジーを感じ取れたと思う。嫌いじゃない。
ストーリー展開的には強引なところもあるし消化不良な伏線もあったけど、主人公ふたりのボーイミーツガールと映像美があればお腹いっぱい満足です。
ちなみに一緒に観に行った嫁は大満足。
非常に面白かったとの感想だったが、「端々に謎の童貞感がある」と言っていた。
なるほど、なんとなく解る気がする。。
DeNA.go #2でアーキテクチャとテストについて考える
チーム開発で、Goに本格的に取り組むことになって少し経ったところなのですが、最近Goで気になっているのはアーキテクチャまわりとテストだったので、その点に注目して参加してきた。
## 1 新ゲームサーバ基盤TakashoでのGo言語活用事例の紹介
- 自社ネイティブアプリ（ゲーム）の共通サーバ基盤のお話
- ひとつのサーバで共通の機能（ログイン、プレイヤーデータ等）を一元管理するための基盤
- 共通故の制約が多く、ゲーム毎の拡張自由度が小さいのが課題
共通基盤あるある。しかし、ゲーム業界はタイトル毎の要求項目が細かく違いそうなモノだけど、かなり難しいのではなかろうか…
と思ったが、いわゆるガチャも共有の仕組みの一つのよう。収益の本流も共通なら、なるほど必要だろうなぁ。。
- 新サーバ基盤
- Webサーバフレームワークと、クライアントSDKとあわせて提供
- サーバはGo、クライアントはC#
- 1サーバ1クライアント構成
- サーバはGCP上にterraformで構築
- パッケージ管理ツールはdep(go modulesに移行中)
- サーバをGoにした理由は、学習コスト対効果が良いから。そして安定性があること。
具体的に他のどの言語やフレームワークとの比較で学習コストが低かったのかを聞きそびれてしまった。
構成もGCP特化でストレージはCloud Spannerとのことなので、このあたりはゲーム用基盤として最適化されていて便利そう。
ゲームユーザ向けならスケーラビリティも非常に重要であるし、データ量もさぞ膨大だろう、、
開発者はgo getして利用するあたりは、package単位で利用するGoの利便性が際立っているように思える。
このあたり、package設計は重要なポイントだろうと思う。
- コードの自動生成
- GAEでgRPCが使えないから辛い→独自実装しよう
- protobuf
- 拡張protocコマンドでサーバサイド、クライアントサイドのコードを自動生成
- go templateでコードテンプレート
- テストコード自体の自動生成
- できるかぎり自動化をがんばる
ProtocolBufferはなかなか良いとの推しを頂く。
インターフェースだけでなく、ドキュメント生成もできるらしい。なにそれ（無知）
gRPCの代替として使えるくらいのスキーマ言語らしいので十分だろうと思うが、RESTでも使えるだろうか？
ちなみにコードの自動生成の観点では、go generateを使う方向で検討していたが、今回の勉強会ではgenerateの話は一切無かった。
コード量が多いと言われるGoにあって、できる限りの自動化はやりたいところ。
## 2 次世代タクシー配車サービス「MOV」におけるテスト事例紹介
- テスト方針
- テスト全体に関わるfixtureを使わない
- マスタデータ以外をDBにロードしない
- 並列テストのために、bxcodec/faker v3でデータ生成
- 構造体にgoタグをつけてデータを自動生成する
- 本番用のコードにgoタグつけるのが嫌なので、テスト用に同じ構造体を自動生成してる
前者は順当な話。テストの実施に必要なデータは冪等性を担保すべきだ。
並列テストにおけるfakerはなかなか便利そう。テストデータを用意する上で省エネが図れるなら試す価値はあるかも。
本番用のコードにgoタグつけるのが嫌
このあたりは非常に意見が割れそうだが、そのテストだけのために同一構造体自体をテスト用に自動生成するのは気合入った話だと思う。
## 3 DeSCヘルスケアにおけるGo 活用事例紹介 #DeNAgo
- レイヤードアーキテクチャ + DI
- 依存性逆転の原則を守る
- ライフサイクルをレイヤード分離
- gomockを使って、テスト中はmockをDIする。
- ただでさえコード量、テスト対象が増えるため各レイヤーでは最小限
- DBデータ取得、保存はinfrastructure層
- gotestsコマンドでテストの雛形を生成
- エンベロープ暗号
- 会社のセキュリティポリシーとしてDBの暗号化＋カラムの暗号化
アーキテクチャのお話で、レイヤードアーキテクチャを採用しているとのこと。
ディレクトリは割と素直な名付けになっている。噂によるとメルカリさんもレイヤードアーキテクチャらしい。
ぼくのチームはクリーンアーキテクチャで進めているため、読み替えができれば大きな違いは無し。
導入メリットは、やはり変更時の影響分離が大きいところだそう。
エンベロープ暗号は聞いたことが無かったのでこれは別途調べる。
## そのほか
いろんな方面から耳にした内容。サンプル数の少ない情報として、あくまでメモ程度。
- Infrastructure層のテストは実際のFirestoreを叩きに行っているとのお話があり
ローカルシミュレータの挙動がちょっと…ということのようだが、テストを回す毎にお金がかかるのとパフォーマンス効率の面では厳しい部分がある。
ただし、本番の環境を叩きに行くテストのメリットはあり、悩ましいところのようだ。
Firestoreは複雑なクエリを書くことができないそうなので、テストケース自体が簡素なのだろうか？
- ネイティブアプリはSwift, Kotlinでそれぞれ作ることが多く、Flutterはまだちょっと…
そのうちFlutter勢力も増すかもしれないが、直近のGoogle I/OでもKotlin firstと言われている段階なので時期尚早なのかもしれない。
- エディタはみんな好きにやってる
最近になって、VSCodeはコード補完(LSP)が良い感じに向上してきたようで増えてきた模様。
JetBrainsは独自の補完を実装しており、それが爆速(らしい)。
- Goでテストの可読性を上げるためには
テーブルドリブンテストはおすすめ。
データや期待値は.golden拡張子で定義することができる。
- やはり、RDBMSのいい感じのデファクトORMはなさそう
が、黒魔術感がなく薄めのORMとして構造体の受け渡しができるsqlxは良さそう。
## まとめ
- もともとCやRubyを書いていた人がGoも触れているというところから、参入コストは低い。君でもやれる。
- Goはそもそもコード量は多い。そのため、チーム開発ではコードの自動生成をどうするか真面目に考える必要がある。猫も杓子もテストもドキュメントも自動化
- プロダクトやチーム規模によるが、サービスの改善を行うためにもドメインの分離をするためにもアーキテクチャは大事。コード量増加は辛く折れそうになるが自動化と気合で乗り切る。
- Goのテストはテーブルドリブンの導入やツール類を駆使することで可読性は随分違う。
- DeNAさんの勉強会は選べるお弁当、選べるドリンクが豊富であたまが下がる思い。ごちそうさまでした。
Kubernetesの初学者向けイベントに参加したはなし
仕事が一段落したこともあり、身も心も余裕ができたタイミングで良い巡り合わせだったので記録しておく。
「一晩でKubernetesを覚えて帰ろう。ワンナイトBootCamp! -- cndjp#10」
というイベントです。
最初にぼくのKubernetesとコンテナ技術との関わり具合をざっくりしたためておくと
- 3-4年ほど前にDockerを使ったサービス開発に携わる。
オーケストレーションツールなし。 - 直近は別案件で開発環境にDockerを利用。
ただしチーム全体での導入はせずチーム内の有志のみ。 - 業務でのマネージドサービスの利用経験なし。
- KubernetesはMinikubeを少し触った程度。
という初学者全開の状況。
まさに自分のためのイベント。
参加の目的
次はDockerもっとうまく使いたいなと思いつつも、Kubernetes知らずに走るのは流石に無謀じゃね？と気持ちと、業務で使う上での説明材料探し。
有用性をどれだけ熱く語れるようになるかは一番大事なポイント。
各発表について
イントロ
そもそも何故オーケストレーションが必要か？というところから。
Dockerを個々に管理するのは、数台のコンテナだけでも面倒さ具合は身に沁みてたので素直に腹落ちする。3年前に入門してたらいろいろ楽だったかなーと回想しつつ聞いた。
Kubernetesの基礎
全体像と用語の理解。Cluster内の構成、componentの役割について。API Serverの冗長構成の重要性を得る。
管理責務はざっくり以下の理解
Deployment
-> ReplicaSet
-> Pod
-> Container
特に、ReplicaSet, Podについては自分で動かして試したい。
動いているところを見てみよう
実際のターミナルをみんなで見る。
テスト用のREST APIは人それぞれで面白い。自分も少し個性を出して遊ぼうと自分で使いやすいように作ってみようと思えるデモだった。
内容的には、RollingUpdateとconfigureすることでのManifestと実態の同期はお作法としてまず覚えることにする。
Kubernetesのアーキテクチャと発展的な使い方
vtuber推しからAPI Serverを中心としたControl Loopのおはなし。発展的な使い方はどこへ。
kubectl runの裏で走るAuthenticationやAdmission Controlの挙動を掘っていくディープな内容。入門レベルの自分にはハイブローだったが、動作を知っておくに越したことはないので、また少し触ったタイミングでスライドを改めて見させて貰おうかと思う。
まとめ
これだけ初学者向けってのもあまり無いと思うので非常にありがたいイベントでした。
一方で、個人的にはここから具体的に利用するために課題を整理していかなくては。
- とりあえず試す
- k8s+DockerでのRDBMSサーバの扱いやユースケースorベストプラクティス
- オンプレ環境での活用方法
- チームメンバーの学習の流れ
- これらを踏まえたk8s導入メリデメ説明
- とりあえず試す
運営の皆様ありがとうございました。
