#builderscon 2019 参加レポート

今年もbuildersconに参加してきました。

builderscon.io

参加したセッション内容のメモと簡単な所感、全体所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。

昨年と一昨年の参加レポートのリンク。

本編1日目

Open SKT: メルペイ開発の裏側 - builderscon tokyo 2019

builderscon.io

資料: Open SKT: メルペイ開発の裏側 / builderscon tokyo 2019 Open SKT : Speaker Deck

内容

  • 決済はお金のトランザクション管理が難しい
  • SKTってなに?
    • Super Kazegusuri Time
    • オンボーディングも兼ねた社員研修
  • メルペイの開発で重視していること
    • インフラのように安定して信頼できるシステム
    • サービス開発をメインにしない
  • アーキテクチャ
    • GKE使ってる
    • 4階層のアーキテクチャ
      • Client
      • API Gateway
        • インターネットからのリクエストを安全に内部に届ける
      • API Service
        • クライアントとのメッセージに責任を持つ
      • Backend Service
  • 分散システムにおけるトランザクション
    • 難しい
    • 中央で一元管理する方向に
    • エラー処理も含めたモデルの一般化が必須
      • エラー処理を例外として扱わない
  • お金のモデルは全て状態遷移モデルを定義している
    • 引き算はいきなり確定させるとキャンセル時など不都合が生じる
    • いったん確保、その後に確定する
  • 不正検知
    • メルカリだけの時より本人確認、リアルタイム不正検知が重要に
    • AML/CFT
      • 金融庁からガイドラインがでている
      • 疑わしい人を見つけ出す、疑わしい取引を見つけ出す
      • ルールベースと機械学習の両方でやっている
        • ルールベースはSplunkを使っている
  • 開発フロー自体はメルカリと共通だが多少違いがある
    • メルペイでは各フェイズで追加のルールを設けている
    • Design Docはアーキテクチャ、SRE、関連チームからのレビュー必須
    • Testは第三者がテスト結果を検証可能な状態に
    • サービスの安定性の指標としてSLOを重視
      • まだ運用には課題がある
    • 本番環境にアクセスできるのはSERのみ
  • 業界全体のレベルをあげるために事例をどんどん公開していきたい

所感

メルペイのシステムアーキテクチャ、決済サービスの難しいところ、メルカリとの開発体制の違いなどが語られたセッションでした。
お金を扱うという特性から信頼できるインフラとなるようなシステムにするために、コストをかけてもより安全に開発していくという信念がとても伝わってくる内容でした。
サービスの安定性の指標としてSLOを重視するという話がありましたが値の設定とそれの運用はとても難しそうだと思いました。SLOをどのように設定し、どのようにアップデートしていくかの知見を今後是非聞いてみたいですね。

Android Architecture Componentを使って、改善・効率化するAndroidアプリ開発 - builderscon tokyo 2019

builderscon.io

資料: まだ未公開?

内容

  • AACの全体像
    • 便利に使える、公式、モダン、部分的に導入可能
    • Android Architecture Components  :  Android Developers
    • Data Binding
      • xmlからBindingクラスが生成される
    • Lifecycle-Aware Components
      • @OnLifecycleEvent(...)を使ってどのライフサイクルイベントでそれを実行するか書ける
      • ライフサイクルを外だしできる
    • Live Data
      • Lifecycleを考慮してくれるObservable
    • ViewModel
      • 画面が回転したとき画面は再生成されるがViewModelは変わらない
    • Room
      • SQLiteのオブジェクトマッパー
    • WorkManager
      • 少し長い処理や遅延できるものを実行するときに使える
      • 電力状態などデバイスの状態で実行するかどうか決められる
    • Paging
      • ページネーションに必要なPageのデータを持てるもの
    • Navigation
      • iOSでいうSegue
  • 既存プロダクト(Wantedly People)への導入とその変化
    • RealmからRoomへ
      • Roomの方がテスタビリティが高い
    • MVPからMVVMへ
      • ViewModel
    • WorkManagerの利用
      • 端末の連絡先と同期部分で利用。遅延実行することでUXの改善に繋がった

所感

Android Architecture Componentの概要とWontedly PeopleのAndroidアプリでどのように使っているのかが語られたセッションでした。
最近Android開発に関する情報はあまりちゃんと追っていなかったのでいろいろと知れました。公式でこれだけ用意されている状況なので、新規でAndroidアプリを開発するときはまずは公式のものを使ってどこまでできるかを考えて、それでまかないきれないものに対して他のライブラリを使うかどうか検討していくのが良さそうだと思いました。 Android Architecture Componentはいきなり全部入れないで自分たちに必要なものを徐々に入れていけるので、今回の発表の例のように既存の実装を置きかえていきやすいのもGoodですね。

WebAuthn/FIDOのUX徹底解説 ~実サービスへの導入イメージを添えて~ - builderscon tokyo 2019

builderscon.io

資料: WebAuthn/FIDOのUX徹底解説 ~実サービスへの導入イメージを添えて~ / builderscon tokyo 2019 ritou : Speaker Deck

内容

  • パスワード認証にはさまざまな問題がある
  • ワンタイムパスワード認証
    • 結局はユーザーが入力する必要がある
  • FIDO
  • FIDOのユースケース
    • パスワードレス認証として(所持+ローカル認証)
    • 追加認証として(所持)
  • FIDO 2
    • WebアプリからもFIDO
    • WebAuthn
      • FIDOを利用するサービス側が呼び出す
    • CTAP
      • セキュリティキーとやり取りするための仕様、ブラウザが実装
  • WebAuthnのフィッシング耐性
    • origin単位で鍵ペアを生成しているのでそもそもフィッシングサイトにログインできない
  • WebAuthnのUX
    • 追加の認証方式として利用しているユースケース(パスワード認証 + FIDO)
      • Dropbox
        • ソーシャルログイン後にも聞いてくる
      • GitHub
        • 重要な処理前のパスワード確認時にもセキュリティーキーを利用可能
      • Google
        • Android端末だと独自の方式を使っている(caBLE)
      • ポイント
        • 複数の認証方式を提供して「詰みにくい」仕組みが必要
    • メインの認証方式として利用しているユースケース(パスワード認証 or FIDO)
      • Yahoo!JAPAN
        • Android + Chrome環境に限定
        • ユーザー識別後に認証方式を出し分け
      • Microsoft
        • Windows Helloが動作する環境 + MS Edge限定
      • ヌーラボ
        • メインの認証方式としてパスワード認証と併用可能
      • ポイント
        • userVerificationは必須
        • サポート環境の制限
          • 制限ありだとメンテナンスが必要、制限なしならFIDO2対応環境なら勝手に対応可能
    • パスワードレスに向けて
      • 新規サービスではパスワード認証を導入しない
      • WebAuthn/FIDOが使えない環境のケア
      • 既存のサービスからパスワード認証を取り除く
        • 依存をなくす、強制もしくは任意で無効化する
  • Q&A: Authenticator自体が脆弱性を持っている場合もあるのでは?
    • どのデバイスで認証しているかを検証することは一応できるはず
    • これにより指定したデバイス以外は弾くこともできるかも

所感

WebAuthnの認証フローを実際に実装しているサービスの認証画面を元に説明してくれるセッションだったのでとても分かりやすかったです。
WebAuthnを使っているといっても思ったよりサービスごとにフローがバラバラで分かりづらい状況ということが理解できました。ITリテラシに疎い人からしたら現状この仕組みはかなり難しい気がします。今まではAuthenticatorの普及だけが問題だと思っていましたが、それだけでなくこのあたりのフローも業界内である程度統一できないとなかなか普及は難しそうだと感じました。

ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ - builderscon tokyo 2019

builderscon.io

資料: ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon : Speaker Deck

内容

  • SoRとSoEを各設計原則や設計パターンをベースに言語化したかった
  • モデルとは何か
    • SoRとSoEでは扱うモデルが違う
    • 解決した問題領域から必要と思われる情報を抽出して記号化、可視化したもの
    • どのようなモデルが有効化は対象とする領域に依存する
  • E-コマースサービスで考えると
    • SoRは事業者アクターを要求元とするドメインモデルをもとにしたアプリ
    • SoEは利用者アクターを容共元とするプレゼンテーションモデルをもとにしたアプリ
  • CQRSとの関係
    • SoR/SoEという分類とCommand、Queryの非対称性に着目した分離は共通している部分が多いのでは?
  • SoR/SoEの実践
    • バリデーション
      • バリデーションには種類がある
        • 入力値のチェック
        • その事業において必要な不変条件
      • 値のみでチェック可能なもの(入力チェックなど)はSoE側で可能
    • 整合性
      • SoR的にはシステム全体で不整合がないことが求められる
      • SoE的には利用者一人ひとりが自身の世界を持っている
    • 状態遷移
      • SoEのベースにあるのは特定の利用者アクターにとってのモデル
        • SoRが持つ全体の状態遷移モデルとは違う
      • SoRの状態遷移の一部だけが利用者にとっての関心領域
        • SoEにその複雑さを持ち込まないように
    • キャッシュ
      • 基本的にSoE側の関心
      • 戦略はいろいろある
        • 毎回、SoRに問い合わせる
        • Pub/Subによるリフレッシュ
        • Expireをもつ

所感

モール型のE-コマースサービスを例にして、アクターの分け方やSoRとSoEのシステム間連携をどのような考えで行うかが説明されたセッションでした。DDD本とClean Architecture本をあらためて読み直して考えたくなるような内容でした。
SoRとSoEって確かにバズワードっぽい感じになっている感じもするのでこうやってきちんと設計に落とし込んで考えられるようにするというのは非常に大事なことだと思います。
B2BがSoRで、B2CがSoEなのか?」のような質問があった気がしますが(うまく聞き取れなかったので違っていたらすいません)、そういう区分ではないと思っています。B2B、B2CのシステムそれぞれにSoE、SoRの分類があると考えます。今回の発表にもあったようにアクターで分けて考えればそれは自明だと思います。そういう意味でもこの発表の内容はとても分かりやすかったです。

本編2日目

レガシーサーバーを現代の技術で再構築する - builderscon tokyo 2019

builderscon.io

資料: レガシーサーバーを現代の技術で再構築する/builderscon2019 : Speaker Deck

内容

  • SVNとかRedmineなどがのった古いサーバーを何とかする話
    • やらないことを決める
    • URLは維持する
    • マネージドサービスを使っていく
  • 4年おきくらいに一応再構築はしていた
  • Redmineに気軽にモンキーパッチを当てるなどしてとりあえず便利にしてしまっていた
    • バーションアップが実質不可能に
    • Redmineにモンキーパッチを当てない、バージョンアップの障害になるのでプラグインは入れないという方針に変更
  • やらないことを決める
    • SVN
      • 今後移行してもらうことを前提に維持する
      • 新規作成はなし
    • Git
      • アクティブなものはGitHub
    • Redmine
      • バージョンアップも含め維持
  • EC2を分解しマネージドサービスで再構築
    • ALB導入
    • EBSをAmazon EFS/S3に置きかえ
      • ファイルじゃ無いといけないものはEFS、アプリを書き換えられるものはS3
    • アプリをECSを使ってコンテナ化、ALBから振り分け
    • ALBでルーティングし、URLを維持したまま段階移行が可能に
  • ファイルがディレクトリに大量にあるとlsコマンドが返ってこない
    • findを使いましょう
  • 認証どうするか
    • いろんなものにhtpasswdを使っていた
    • 最近のものはG Suite
    • htpasswdはどうにもできないのでGitHubでバージョン管理、Circle CIでworkflowを実行しサーバー上に配置
  • FargateからEFSは現状使えない
  • 定期的にシステムと業務を見直し、維持するもの切り捨てるものを決めることが大事

所感

歴史のあるサーバーをモダン化していくにあたっての取り組みやそこで得た知見が語られたセッションでした。
Redmineで使っていたプラグインが原因でバージョンアップが困難になったという話はあるあるだなと思いました。こういうプラグインって便利だからついつい入れちゃうんですよね。で、数年後もうメンテされて無くてどうしようというパターン。利便性との天秤がとても難しいので苦労が伝わってきました。
質疑応答で出ていた、使っているか使っていないのかよく分からないものはとりあえず黙って止めて文句がでるか様子を見るという方針は私もやったことがあるので皆やってるんだとちょっと安心しました。

htpasswdをGitHubで管理してることがちょっと気になってつぶやいていたらfujiwaraさんから返事を頂いたので貼っておきます。

スーパーカミオカンデの開発と運用 - builderscon tokyo 2019

builderscon.io

資料 : Introduction to Super-Kamiokande for geeks(?)

内容

所感

本当に初めて聞くような内容でした。まさに知らない世界。でも発表もテンポがよくとても楽しく聞かせていただきました。
前半は量子力学的な話、後半はデータ取得/保存のためのIT寄りの話でした。
こういう世界でもインフラ周りやソースコード管理などで考えないといけないことは割と同じ感じで「おーこういう分野の仕事や研究においても今やってる知識って使えるんだ」と思いました。まあでてくる単位の桁は違いましたけど。

入門サービスメッシュ - builderscon tokyo 2019

builderscon.io

資料 : builderscon Tokyo 2019: Intro Service Mesh : Speaker Deck

内容

  • サービスメッシュのような概念は今のコンテナブームの前からあった
    • マイクロサービス化により分散化し複雑なシステム構成に
    • 今までのツールデは対応できない運用課題が増加
      • Observability
      • Failure recover、fault isolation
    • Finagleに代表されるライブラリアプローチの興隆
      • 自前で作っている会社も多かった
      • 実装の一貫性の問題も
  • 歴史
    • 2016年にLinkerdがリリースされたときに初めてサービスメッシュって言葉が使われた
    • 2016年9月にEnvoyがPublic release
    • 2017年5月にIstioがPublic release
  • EnvoyはProxyの実装
    • Control Planeは自分で用意する必要がある
      • 自作
      • Istio
      • マネージドサービス: Traffic Director、AppApp MEsh
      • Consul
  • Linkerd v2はProxy、Control Plane両方持ってる
  • サービスメッシュ選球眼
    • 自分たちの規模を見据える
      • 大規模になるなら分散化が重要、高度に分散化した環境では通信層での仕事は必須
    • 自分たちの環境を分析してソフトウエアを選ぶ
      • 自分たちのやりたいこととIstioでできることの差分は?などを考える
  • Service Mesh is not for Kubernetes only
    • ただし、ハイブリッドクラウド環境などで使える製品はほとんどないし事例も少ないので頑張りが必要

所感

サービスメッシュ登場の背景や考え方をざっと学べるセッションでした。
コンテナ技術の流行から出てきた概念だと思っていたのですがそんなことはなくそれより前からあった概念だということに驚きました。「Service Mesh is not for Kubernetes only」という言葉は今まではサービスメッシュ=コンテナで使うものという思考しかなかったので考えを柔軟にするいいきっかけになりました。

もしもハッカーの「サイバー攻撃日誌」が読めたら - builderscon tokyo 2019

builderscon.io

資料 : 公開なし

内容

  • Red Teamサービスとは
    • サイバー攻撃シミュレーションサービス
    • サイバー攻撃に備えたい企業や組織がお客様
    • 特徴
      • 攻撃目標の設定
        • 1番守りたいものを設定。それを狙う
      • 事前通知はしない
      • 攻撃対象は組織全体
    • あらゆる手段を駆使して攻撃する
  • 攻撃例のケーススタディ
    • SNS使って従業員の情報集めてメール送信
      • ターゲットに大学の後輩からOB訪問お願いしますという形のメール送付
        • 社員数が多いと数名は必ずひっかかる
      • 添付で履歴書付ける。VBAでマルウエア仕込んでおく
    • 権限昇格させる
      • SYSTEM権限で動作するサービスのEXEを置きかえ
    • パスワードハッシュの取得
      • ローカルアカウントのハッシュダンプを取得し解析
      • IT管理者の特定
        • 座先表や社員番号、機器番号等が載っているファイル等を探して推測
    • 横断的侵害
      • 取得済みアカウントによるリモートコマンドの実行
    • ドメイン管理者アカウントの取得
      • Mimikatz: メモリ上の認証情報を取得
    • ドメインコントローラーに侵入
      • 全ユーザーのパスワードハッシュを取得、解析
      • これを使ってWebメールにアクセス、システム構成図などを探す
      • 2要素認証が設定されているとここで詰まるので対応策を考える
        • ユーザーの端末はもうのっとっているので2要素を突破しているユーザーの端末経由で入り込む
        • ユーザーがお昼などで席を外している間にRDPで入り込んで操作
  • 防御側が理解しておくべき事
    • 検知の仕組み
    • 後から分析できる仕組み
    • 危険度を判断できるスキル
    • 初動、情報共有が早いと侵入に苦労する
  • Hardening projectで練習できる
    • 各チームにECサイトが与えられ主催者がひたすら攻撃、それを守る
  • わざわざそこまでやるやつはいないだろうと誰かが言うたびにわざわざそこまでやるやつが現れる
  • QA: Macの場合はやはり大変なのか?
    • ADに参加していない場合も多く、マシン単体で動作していることが多いので他のマシンに攻撃を展開していきづらい
  • QA : 秘密の質問とかがあるだけでも侵入しづらいって思ったりするのか?
    • たいがいマイドキュメントとかにメモがあるので侵入が難しくなることはない。2要素認証だと本当にやりづらい。

所感

ここまで詳細な攻撃方法を聞けるとは思っていなかったのでとても面白かったです。個人的には今年のベストセッションでした。攻撃のケーススタディはずっとなるほどー!という声を口に出してしまっていました。
やはり2要素認証は使える場合は使うべきってことがはっきりしました。なぜか使わないという謎の選択を過去実際に見てきたのでこのセッションをそのときの関係者に見せたくて仕方なくなりました。
あとは、検知の仕組みをきちんと整えて対応できるようにすることもあらためて大事だと思い知らされました。本気で攻撃されたらやられるときはやられるので、いかに早く反応できるかが勝負になってきますからね。

全体所感

3年連続で参加していますが、本当に毎回知らないことを聞くことができるカンファレンスです。
特に今回は、スーパーカミオカンデのセッションともしもハッカーの「サイバー攻撃日誌」が読めたらのセッションの2つに感銘を受けました。まだまだ自分の知らない世界はたくさんありますな。
会場はいつもの慶応日吉キャンパスではなく北千住の東京電機大学のキャンパスでの開催でしたが、ベンチなども割と多くてちょっと休憩することも日吉よりはできたので快適でした。

運営の皆様、発表者の皆様、参加者の皆様、楽しいカンファレンスをありがとうございました!今年も本当に刺激を受けました!

(おまけ)運営フィードバック

最後に運営面で気づいた点をメモ。

  • 受付がすべてQRコードで済むのは体験としてとてもよい
  • アンケートへの誘導が参加者証の裏のQRコードからいけるの便利
  • 最後に余ったノベルティや水を無理矢理渡している感が少し出てしまっていた
    • さばききりたい気持ちは十分に分かるのですが
  • 質疑応答時にマイクを持っている人が一人であっち行ったりこっち行ったりで大変そうだった
    • もう一名くらい入れて手分けした方がスムーズかも

Regional Scrum Gathering Tokyo 2019参加レポート

Regional Scrum Gathering Tokyo 2019に参加してきました。
昨年に続けて2度目の参加です。

2019.scrumgatheringtokyo.org

去年の参加報告はこちらです。

braitom.hatenablog.com

参加したセッションで印象に残ったことと簡単な所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。

3日分まとめて書いたらなかなかの分量になってしまったので以下の目次から気になるものをピックアップしてご覧下さい。

Day1

Outcome Delivery: delivering what matters

confengine.com

資料 : なし

印象に残ったこと

  • Whyがはっきりしていないと問題が生じる
  • たくさんのフレームワークやプラクティスがある
  • 私たちは本当に早くより多くの機能が欲しいのか?それても重要な成果が欲しいのか?
  • メビウスループ
    • Outcome Delivery | Outcomes over Outputs
    • 発見とデリバリーのバランス
    • 左側はデザイン思考的なループでWhyを求めるもの、右側のループはアジャイル思考的なループで素早く機能を作っていくループ
      • すべてはバランス
    • ディスカバリーバランス、オプションピボット、デリバリーループ
    • Whyを定義し、オプション(手段)を選択し、デリバリーして計測して学ぶ、オプション(手段)を選択し...これを回す
    • 選択するプラクティスは何でもよい、成果を出すのが大事
    • オプション(手段)はやってみないと分からない → だからこと計測が大事
  • 計測が我々の行動をドライブする
    • 計測するのが難しくても計測できるような仕組みを時間をかけて作っていくのが大事

所感

最初に最高のコーヒーとは何か?最高のコーヒー体験とは何か?なぜコーヒーを朝飲んだのか?を突き詰めるワークショップを行ってWhyを掘り下げることを体感させてからのセッションだったので内容がすんなりと入ってきました。

ラクティスは確かにいろいろありますが、効果や使い方を理解して正しく使うことが大事だなと思いました。プラクティスをただやってみたいだけな人にはならないようにしないとですね。
今、目の前にある問題へ対応するために最善のプラクティスを選べるように引き出しは増やしたいものです。

Whyを意識して問題を正しく理解する、解決のためのプラクティスを選択する、実行して計測する。ダメなら別のプラクティスを選択〜とループを回していく。このサイクルを意識していきたいです。

また、問題を定義するときに使っていた、「Frame the Problem」のフォーマットは使ってみたいなと思いました。Problem、Context、Impact、Causeを書くフォーマットで問題がうまく整理されそうでした。

Coaching resilient Scrum teams

confengine.com

資料 : なし

印象に残ったこと

  • Vodafoneでの大規模アジャイル導入的な話
  • 変化には時間がかかる
  • アジャイル推進組織を人事部の下においた
  • 最初の1か月はつらかった
  • Coaching Compass
    • 会社にどれだけインパクトを与えられるかを示す
    • インパクトと学びの2軸のマトリックス
    • 組織の中にはスクラムに向いているチームもあるし、ウオーターフォールが向いているチームもある
    • 影響度の大きさによりマッピングする○の大きさ、Tribeによる色で分けてマッピングする
    • それにより優先度をつけて、常にアジャイルコーチを張り付かせるか、質問されたら対応するだけ、など対応を分ける
    • エグゼクティブ組織には実践よりも原理を理解してもらうなどの対応も
  • Resilience
    • 弾力性のある、適応性のあるみたないこと
    • これを実現するには精神的に安全な環境でなければならない
      • これができるとfailファースト、実験的なことができるマインドセットがうまれる
  • ラクティスMap
  • 土壌を作る
    • 最初から何か理想のモデルを与えるのではなく、自分たちから自分たちに合ったものが産まれるようにする
  • 会社はエコシステム
    • プロセスと文化によってできている
  • 非公式なネットワークを作る
    • インフォーマルなミーティングを大事にしている
    • よいアイデアなどはたいていここからうまれる
  • 組織は生き物
    • アジャイルは組織からうまれる
    • どのようにコミュニケーションするのかが大事

所感

Vodafoneでの組織的なアジャイル導入の話でした。
Coaching Compassで社内のチームをマッピングして、それにより対応方法を分けるという考えはなかなか面白かったです。今まさに全社規模でのアジャイルの普及的なことを少し考え始めているのでこうやってうまく社内のプロジェクトをマッピングして対応方法を分けて考えていくというのは使えそうだと思いました。

さらっとお話しされていましたがこれめちゃくちゃ大変で根気がいる取り組みだったろうなと感じました。組織という生き物とうまく向き合っていくための希望をもらった気がします。Resilienceな組織作りを意識していきたいですね。

行動分析学に基づくScrumの導入

confengine.com

資料 : 行動分析学に基づくScrumの導入

印象に残ったこと

  • 行動分析学をもとにスクラムの習得さの困難さのヒントになれば的な話
  • スクラムの習得が困難な理由
    • It dependsだから(状況によるものが多いから)
      • 個人、組織、プロダクト、プロダクトの状態はそれぞれ異なるから
    • 状況を考慮して理想を探索する手法として行動分析学が使えるかも
  • 行動分析学とは
    • 行動 = 死人にはできないこと
    • ABC分析
      • Antecedent(先行事象)→ Behavior(行動)→ Consequence(後続事象)
    • 好子と嫌子
      • 嫌子を使ったマネジメントは即時性があるが継続性はない
    • 行動に注目する、標的行動を特定する、標的行動を強化/弱化する
  • 行動分析学を使ったスクラム

所感

スクラム関係なく、チームや組織をよくしていきたいと思っている人は行動分析学を学んだ方がよさそうだと強く思いました。きちんと学問になっているものはやっぱちゃんと抑えておかないとダメですね。行動分析学に関する本をひとまずいくつか読んでみようと思います。

ひとまずこれを買いました。

行動分析学マネジメント-人と組織を変える方法論

行動分析学マネジメント-人と組織を変える方法論

ちゃんとやってるのになんかうまくいかないスクラムからの脱出

confengine.com

資料 : #RSGT2019 ちゃんとやってるのに なんかうまくいかないスクラム からの脱出 - Speaker Deck

印象に残ったこと

  • ちゃんとやっているのになんかうまくいかない
    • 増えるミーティング、終わらないタスク、ギクシャクする関係性
  • このチームに対してやったこと
    • エンジンに再点火
      • レトロスペクティブが形骸化していたので感謝と対話を中心にした
        • Webツールで事前に書いておくことをやめて付箋を使って本人の言葉で意見を出すように
    • 一本道
      • 全員バラバラに動いていたのでタスクを一本に並べた
        • 重要さに順位付け、アサインしない。個人の課題からチームの課題に
    • パーティを組む
      • 知識に隔たりがあるなどの理由からコードレビューにかかる時間が読めない
        • モブワークして全員で取り組むように
    • だったならつかってもいい
      • 突発対応があると後半がくるしくなっていた
        • 前回こうだったかた計画をつくる。突発があったことを前提に
    • 立て看板
      • スプリントの目標を立てることで現在地の共通認識をもつように
        • ユーザー登録機能の実装完了、みたいにプロデューサーでも分かる名前にした
    • 荷下ろし
      • テックリードが1人で抱えすぎていたので大丈夫だよと伝えた
        • できていないことを数えるのではなくできていることを一緒に数えた
        • できるだけメンバーを頼るように
    • 3段階の地図
      • グランドスケジュール、プロダクトバックログ中、プロダクトバックログ小を用意して全体を見れるようにした
  • 期待はスクラムと相性が悪い
    • 期待と違う現実を見せてくれるのがスクラム
    • 期待を土台にしていると現実から目をそらしてしまう
  • スクラムを現実の上で回し始めた
    • 現実を受け入れて乗り越えていくチームに
    • 油断せずに変わり続ける現実を受け止め続ける
  • スクラムと違う部分に注意が必要
    • その部分にこれまでの経験(期待)が入り込みやすい
  • ちゃんとやっているのになんかうまくいっていないのはよい状態
    • ちゃんとやっているから、ちゃんと失敗して、ちゃんと悩んでいる

所感

当たり前のことを当たり前にやることの大切さとその難しさを改めて実感できるセッションでした。セオリーは分かっていてもいざやろうとすると難しくて心が折れそうになることが多々あります。それを1つずつ着実に適応していったんだなあ、すごいなあと思いました。

特に荷下ろしの部分はすぐにでも真似したいなと思いました。抱え込みすぎているメンバーのできていないことを数えるのではなくできていることを一緒に数えるというやつです。自分がこの対応してもらったら絶対嬉しいのでメンバーにもやってあげたいです。

超Scrum入門〜未完成フラクタルと15minSprint〜

confengine.com

資料 : 超Scrum入門〜未完成フラクタルと15minSprint〜 #RSGT2019 - Speaker Deck

印象に残ったこと

  • 人間であることをやめる、人間だと思っているからうまくいかない
  • 30minスプリントは簡単、15minでもできるのでは?
  • 短時間スプリントはモブ/ペア/ソロの強制切り替えタイミング
  • 生き生きとしたチームとは?
  • うまくいったらどうなるの?
  • シロアリの蟻塚には設計図はない、小さいルールだけで成り立っている
  • 進化としての余地を残した未完成なフラクタルがもっとも強いのでは?
    • まだ見つからない
  • Krebs Cycle of Creativity
  • 目的のない行動もあるから美しく生き生きしている
    • 基盤チームはスプリントという目的だけをしていた
  • フラクタルスプリント
    • ビジネス目的のスプリントを3回やったら、非ビジネス目的のスプリントを1回やる、みたいな
    • 自然な改善、自然なチームに
    • 人間をやめようとしたはずが人間らしく生き生きしてきた
  • 学生や新人はこういうことを最初からできる
    • 玄人はUnlearnしなければならない
    • 学生は1Dayスプリントを5日でできる、チームが習得するには180日かかった
  • Unlearnする時間をそもそも短くするような組織作りが大事
  • 生物の歴史をチームや組織で仕組み化する → これが行きついた何か
  • 楽しくうまくできるまで突き詰めるのが大事

所感

自分では絶対にたどり着かない考えをいろいろと聞けて時間が一瞬で過ぎたセッションでした。きょんさんすごいなあ。
楽しくうまくできるまで突き詰めるという気持ちは他の何ものよりも大事にしていきたいです。楽しければつらいと感じることも少なく継続できますからね。

あと、Unlearnのところも印象に残りました。Unlearnしなければいけないことはやはりどうしても出てきてしまうものだと思います。
つまり、逃げることはできないものです。これを起きないようにするのではなく起きて必然のものと捉え、Unlearnする時間をそもそも短くするような組織作りする必要があると私は捉えました。
速くUnlearnできる組織って何?そういった組織になるため必要なことは何?ということを考えていきたいと思います。

Day2

Learning to Experiment

confengine.com

資料 : なし

印象に残ったこと

  • 緊急事態や大事故が起こるまでプロセス改善などの変化が起きない
    • 茹でガエルになってしまう
    • なぜ緊急事態が起こるまでやらないのか?
  • どうやって実験を学ぶか?
    • 心理的安全性を確保するのが大事
  • 失敗するリスクの高い実験こそが学習を最大化する
    • 実験が成功すると思い込むような状況になってはいけない
    • 実験が必ず上手くいくと思い込む人がいるが、そうではない。実験が失敗せず成功ばかりの場合、自己満足に陥っている可能性がある
  • レトロスペクティブ
    • 反復するループができる
    • 継続的な改善のプロセス
    • マイクロレトロスペクティブを45分に1回やるチームもある
  • モブプログラミングの始まり
    • 助けて下さいのひと言から始まった
  • フラットな組織構造
    • マネージャーがいない
    • 階層構造の問題無くコミュニケーションができるように
  • 悪い習慣を取り除くには?
    • この仕組みを見つけることが大事
    • 始めるよりやめることの方が難しい
  • 目標に対する反復実験
  • 想定外の実験
    • 4人のプロダクトオーナーの話
      • いつも一緒、1日1回は顔を出す、週に1回は顔を出す、月に1回は顔を出す
      • ミーティングにかける時間数を出した
        • 1か月に1回のPOのチームはミーティングの時間が長かった
          • POが来ないからメンバーで議論する時間が多くなった
      • サティアの変化モデルは無視される
  • ビジネス全体のレトロスペクティブ
    • 経営陣もレトロスペクティブを回すようになった
    • よいプラクティスを拡散したいなら一貫性がないといけない
    • よいプラクティスを広めたいのであれば、透明性、結果、一貫性が必要。ビジネスのふりかえりを広める場合とくに有用
  • 隣の芝生は青くみえるだけ
  • 大きな変化をいきなりやらないように小さくやる
    • 自己満足に陥らないようにする
  • 全員参加と共同責任
    • 手柄を皆で分ける
    • 同僚が手柄を盗まないという信頼感が大事
  • イノベーション普及理論
  • やさしさ、気遣い、尊敬
    • これをグランドルールとした
  • Vulnerability、Trust、Appreciation
  • コードと本番の間に人を入れない
  • 誰でもいつでも休暇を取れる状況は心理的安全性が高いと言える
  • 開発者がコミュニケーション能力を高めるのは意味がある
    • それにより避けられる問題も多々ある
  • 見積もりをやめる
    • 見積もりをなくすことを経営陣からどう理解してもらうか
      • うまく見積もりを行おうと思ったらそれは過去やってきたものでしかあり得ない
    • 見積もりに本当にかかるコスト、副次的なコスト
      • 再見積が必要になる、ズレを管理したくなる、心理的負担、決められたことなのでよりよいやり方を考えなくなる など
      • パーキンソンの法則
      • 見積もりには隠れたコストがたくさんある
    • 見積もりは納期では無い
    • ラクティスを透明性高く進めることで見積もりなしにできる

所感

実験を繰り返そう!を強く訴え、それが組織にとってどう影響を与えるかというセッションでした。正直内容盛りだくさんでちょっと消化不良気味になりました...
ということで、上記の印象に残ったことはぶっちゃけ取ったメモを整形せずほぼそのまま貼り付けていますw キーワードだけでも後で振り返れると思うので。

とはいえ、学びが非常に多かったです。
何かを試すときは上手くいくと思い込む人が出てくるというのは確かになあと。失敗することもあるから実験なわけで、毎回うまくいっているならそれは単なる自己満足であると。おっしゃるとおりでございます。これは陥りがちなので注意していきたいです。

見積もりが必要ないという話は衝撃的でしたが、結局は見積もりがなくてもうまく回るような組織作りが実験を繰り返すことでできたからこそなんでしょうね。それなしにいきなり見積もりなしはうまくいかないと思うので、「よし、うちも次から見積もりなしでいくぞ!」なんて間違っても思ってはいけないと思います。

手柄を皆で分け同僚が手柄を盗まないという信頼感があるチームというのはどう考えても強いチームなのでこういう状態にするにはどうしたらよいかを考え続けていきたいです。これがないと実験を繰り返しても効果が出ないことになってしまうと思いますので。

Effective Retrospective / とにかく楽しいふりかえり

confengine.com

資料 : Effective Retrospective とにかく楽しいふりかえり - Speaker Deck

印象に残ったこと

  • 振り返りは楽しく感じると効果的と感じやすい
  • 今日は振り返りのWhy、Whatを中心に話す。Howはうまくいけば何でもよいと考えている
  • ふりかえりとは
    • 前向きな活動
    • 楽しい気持ちの方がよいアイデアがでる
  • ふりかえりの3ステップ
    1. 立ち止まる
      • 走り続けると視野が狭くなる、そのために立ち止まって視野を広げる
      • みんなで立ち止まる必要がある
      • 忙しいからふりかえりをスキップしようってなったら立ち止まることの意義をちゃんと伝える
    2. チームを成長させる
      • 部分最適全体最適
      • コミュニケーションの質、関係性の質がよくないと全体最適はできず部分最適になってしまう
      • 関係の質を高めるには
        • 感謝を伝える、個人の月間目標を立てて共有する、など
        • Mutual Respectが大事
    3. プロセスの改善
      • 失敗は繰り返さないように、成功を何度も続けられるように
      • 改善・・・問題点を直す
      • カイゼン・・・問題がなかったとしても仕事のやり方を継続的によくしていく
      • 問題をすべて解消する必要は無い
        • コアの問題を探す
        • 関係の質が高まっていれば問題を共有するだけでコミュニケーションにより解決することも
      • 自己承認と他己承認
        • 自己承認がうまくなると他己承認につながる
        • 他己承認しあうのは正のループ
  • 楽しいふりかえりを構成する3つの要素
    • 場づくり
      • 対話の準備
      • 心理的な場づくり
        • 前向きスイッチを入れる
        • 議論と対話
          • 議論はA or B、対話はA + B = X
      • 物理的な場づくり
        • 空間を最大限活用する
        • 音楽や飲食によるリラックス効果を使いアイデアを生む
    • 学び
      • 学びがあると成長したという実感を得られる
      • 失敗すらも学びに変える
      • ふりかえりは失敗できる恰好の場
    • 成長
      • 自己効力感、集団効力感が大事

所感

ふりかえりに必要なことが網羅的にまとめて説明されていてとても学びのあるセッションでした。ふりかえりを行う前にこの資料は定期的に読み直したいです。
そしてプレゼンがめちゃくちゃうまいと思いました。話す速度、ふるまいなど場づくりってこうやるんだなあというのがプレゼンする姿からも学べました。

説明されていたことをいろいろ実践していくのはもちろんのこと、ふりかえり時の自分の振る舞いも意識するようにしていくようにしようと思います。楽しい気持ちでふりかえりしたいのに、ファシリテーターが楽しくなさそうなのでは元も子もないですからね。あとは議論と対話の違いは意識していきたいです。

全部SCRUM!~SIerで大切だったもの、サービサーで大切だったもの~

confengine.com

資料 : [RSGT2019]全部スクラム!~SIerで大切だったこと、サービサーで大切だったこと~

印象に残ったこと

  • SIerでのスクラム
    • SIerは発注先のスクラムチームに入れない
      • お客側にPO Proxyをたててもらいその人と客先などに同行
      • Scrum Teamには口を出さない
    • よかったこと
      • 無駄なものを作らないで済んだ
      • 仕様変更に耐えやすいもの作りができた
    • できなかったこと
      • 作りたいもの、納品物も最初から決まっている
      • 新しい価値の創造はできなかった。お客様もSIerにはそこを求めていなかった
    • 写像駆動ベース、守りのScrum
  • サービサーでのScrum
    • よかったこと
      • 自分たちで決めたから施策がみんなのものになった
    • 価値駆動ベース、攻めのScrum
  • SIerでもScrumはできる
    • SIerじゃできないというのはウソ
    • ただし、攻めのScrumではなく守りのScrumになる
    • Scrumの適用はものづくり部分だけといった限定的なものではない

所感

SIerサービサー、両方とも実際に経験した話をベースに話されていて興味深かったです。
SIerだからScrumは難しい、できないと決めつけるのは本当に良くないことだなあと思いました。それこそ思考停止です。
できる範囲の中で、守りのScrumという定義をしてしっかり道を切り開いていくという考えはとても参考になりました。

そのときサーバントリーダーはどう振る舞うか

confengine.com

資料 : そのときサーバントリーダーはどう振る舞うか - Speaker Deck

印象に残ったこと

  • サーバントリーダーシップの実践を始めるまでにやったこと
    • いろいろ本を読んだ
    • 印象に残ったフレーズと自身のふりかえり
      • あなたは何をしようとしているのですか?
        • 何の組織?に答えられない
      • 耳を澄まし、理解すること
        • 立場を越えた本音を聞けている気がしない
      • 信頼し、信頼されること
        • 信頼が伝わっているか分からない
        • 信頼されているだけのアウトプットを見せられているのか?
      • 会社組織の上下はしたがうものの信任で得られるわけでは無い
        • なぜ自分が部長の立場を受けたか伝えていない、自分でも整理できていない
    • 読みながら何が大事か書き出すのが大事
    • 正直に自分を分析するのが大事
  • やってみたこと
    • ビジョンづくりと提示
    • 感謝を言葉に
      • 日本人は言葉で言わない人が多い
    • ちょっといいですか?をいいやすく
    • トラブル解決と社内調整を率先する
  • 理解と信頼
    • 傾聴、共感、癒やし、納得
    • 繰り返して関係性の深度を高めること
  • ビジョン作成のポイント
    • 概念化、先見力
    • 言いたいことを並べるのではない、分かりやすくて過去から未来を導くものを
  • やってみたV2(繰り返し、繰り返し以下を行った)
    • ビジョンを分かりやすく
    • 挨拶と雑談は自分から
    • やりたいことの把握と後押し
    • わかりやすいKPIで握る、こまめに報告する
    • トラブル解決と社内調整に同席してもらう
  • 変わってきたこと
    • 上司
      • 心配が減り細かいことを言わないようになった
      • 上司が期待する組織のイメージを共有できた
    • 配下のマネージャー
      • 1on1などでメンバーの話が増えた
      • 成長したいポイントを理解できるようになった
    • メンバー
      • プロジェクトの目的と結果、成果を語れるように
      • あいさつが増えた、個人的な話の報告も増えた
    • 全体的に安心感がお互いに生まれた
  • 組織成果
    • トラブル削減
    • リリース数が増加
    • 採用数が増加
    • 成果をチームで出してくれるようになった、帰属意識が高まった、組織を考えて動いてくれるようになった
  • 課題
    • 主体性をどうしても持てないメンバーがまだいる
      • さらに会話をする
    • 組織の色がでて、合う、合わないが出てきてしまう
      • 大きな問題では無い、合わない人が自分の意思で出て行くのはよいこと
  • 思いはシンプル、ブレないことを繰り返す
  • ふりかえるとただの人間関係構築の話でしかない

所感

サーバントリーダーとは何か?という話はとてもよく見ますが、実践した経験とそこから出た課題を聞くのは初めてだったのでとても参考になりました。
実際に、帰属意識が高まって組織を考えて動いてくれるメンバーが増えたなどの成果に繋がっているようで本当に素晴らしいです。

あと印象に残ったのは組織に色が出てくるとどうしても合わない人もでてきてしまうという話です。これを問題と捉えずに、合わない人が出てくるのはしょうがないことだと考える発想はなるほどなと思いました。
合わない人が出るとどうやって馴染んでもらおうと考え胃が痛くなる経験をしたことがあるのでかなりはっとさせられました。
確かにそういう人に無理に順応してもらうより、自分で今の組織には合わないと悟ってもらってより活躍できる場所を探す方が本人の為になりますからね。

学習する/Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー

confengine.com

資料 : 学習する/Unlearnするチームへ #RSGT2019 / Learning and Unlearning Team - Speaker Deck

印象に残ったこと

  • 2018年から楽天ではエンジニア以外もプログラミング研修必須になった
  • 研修を受けた彼らの成長の加速度から何を学ぶべきか
  • 研修
    • リアルプロダクト開発
      • 実際に事業が抱えている課題を解決する
    • リアルチーム開発
      • チームで方針を決める
      • 最低限のルールは存在するが自分たちで仕事をハックする
    • レトロスペクティブツアーを実施
      • 他のチームのふりかえりを聞きに行く
      • 学習する機会を多くする
  • 配属されてからも研修で作ったアプリのバージョンアップを続けた
    • なぜなら楽しかったから
    • それを通して色々なことが学べた
  • Yattah KPI
    • 小さな課題達成をチームで共有、課題達成したらやったーと言い合う
    • チームとしての連帯感が生まれた
    • 簡単なコミュニケーションでもチームの雰囲気が改善する
  • ラクティスを当たり前に使いこなし、動くプロダクトをつくりあげた
    • ビジネスメンバーに驚きと感動を与えた、想像を遙かに上回るものだった
  • 学習するUnlearn
    • 学習棄却、学習を捨てる
    • 学びほぐし
  • Learn → Unlearn → Relearn
  • 新人はUnlearnを高速に回していた
  • 経験していないという強み
    • 経験がないのは弱みでは無くて強みという考え
    • 積み上げたものが邪魔をする
  • メンタルモデル
    • 新しいインプット→とりあえずやってみよう
    • うまくいかなかった→変えてみよう、捨てるものが小さい
  • 学習を積み重ねることで成長は鈍化するという事実
  • Unlearnしても忘れるわけでは無い、前よりも早くきれいに積むことができる
  • 戦略的にUnlearnする
    • KPTにUnlearnの項目を加えるなど
  • 積み重ねていく活動とUnlearnする活動は別のサイクルで回す
  • 俺たちを越えていけという研修だった

所感

ハッとさせられることだらけだし、楽天の新人の皆さんの成長速度すごいしものすごいセッションでした。

新人研修ってどうしても決まったルールでやって、ありきたりなものになってしまうんですよね。それはつまり新人を子供扱いしていることが原因だと思います。新人だから色々決めてあげないといけないとできないとかそういう理由を付けて。そういうことをしないで新人に全面的に任せるスタイルの研修を実施し、そこから得た知見が存分に語られていました。

「配属されてからも研修で作ったアプリのバージョンアップを続けた、なぜなら楽しかったから」って発言すごくないですか?こういう気持ちを持てる新人研修なんて最高過ぎませんか?

で、ポイントはUnlearn。経験が色々と邪魔をするのはほんとそのとおりだと思いますが、積み上げた経験が役にたつことも多々あります。要はこれもOutcome Deliveryの話であったようにバランスの話なのかなと個人的には感じました。
Unlearnする機会を定期的に設け、捨てるもの、学びほぐす必要があるものをきちんと認識、分類できるようにするということを意識しないといけないのかなと。つまり、積み上げた経験をそのまま適用した方がよいものとUnlearnした方がよいものを正しく判断するということです。
そしてきょんさんの話にもあったようにUnlearnすべきものがあったらそれを素早く回すことができるようにするのが目指すべきことだと感じました。

いやーしかし本当に最高のセッションでした。パシフィック・リムを初めて見たときのような興奮がしばらく続きました。

Day3

OST(Open Space Technology)

去年は家庭都合により参加できなかったので初参加です。OSTについては以下をみるとどんなものか把握できます。色々な立場やバックグラウンドの方といろいろな意見ができてとても刺激的でした。

kawaguti.hateblo.jp

心理的安全性あるとき~ないとき~

会議で上司が何もしゃべらないとき、なんかテンションが低いなどいくつか心理的安全性がないなーと感じる場面について議論がありました。
しゃべらない上司にはあえて「どう思いますか?」みたいな質問しちゃうのはどうですか?という意見を出しましたが、その発言をするための心理的安全性がそもそもない!となり「確かにそうだよねー」みたいな話をしました。

一番掘り下げたディスカッションが起きたのはスクラムが失敗し続けていると指摘されたときという話題でした。上司はスクラムの成功体験はあるのか?何と比べて失敗していると言っているのか?などなどいろいろな意見が飛び交いました。残業が常態化しているという話にも繋がってとても面白かったです。

関西の方なら必ず知っているという「あるとき~ないとき~」の元ネタ知らなくてすんませんでした。

f:id:braitom:20190111142146j:plain
成果物

業務委託さんにプロダクト思考を持ってもらうには?

大きく分けて契約によるもの、愛着や主体性によるもの、マインドによるものという観点で色々な意見交換をしました。業務委託する側、される側どちらの意見も出たことでよいディスカッションができたと思います。

愛着や主体性、マインドなんかもよくよく考えると全部契約に起因するんじゃないかと個人的には思いました。契約条件やNDAになんかうまいこと書いて業務委託する側もされる側も対等な関係作りができるようなハックがないか考えたいなと思いました。

f:id:braitom:20190111141838j:plain
成果物

よなよなエール流 熱狂を生むチームづくり ~8年連続赤字から13年連続増収増益までの軌跡~

confengine.com

資料 : なし

f:id:braitom:20190111142534j:plain

印象に残ったこと

  • どん底を見て思った
    • ファンや残った社員を見捨てることはできない
    • この会社に人生をかける決意
  • 差別化戦略〜プロモーション〜
    • 戦略
      • トレードオフを伴う・・・何かを取ったら何かを捨てなければいけない
      • 活動間のフィット感を出す・・・何かをやったら何かにもよい影響がある。相乗効果がある
    • 超宴
      • やると赤字、しかし参加者は盛り上がる
      • 短期の売り上げを捨てて、そのときのお客さんの熱狂をとるというトレードオフ
        • 最初は少人数でやって小さな経験を積み上げる
        • 中長期的に見れば参加してくれた人はきっとファンになって売り上げにつながるだろうという考え
    • 突き抜けた個性は賛否両論を生み出し熱狂的ファンを生む
  • チーム作りの話
    • チームビルディングプログラム(TBP)というセミナーを受講し刺激を受ける
      • トップが変わらなきゃダメ
        • 相手を変えるのではない、相手はコントロールできないが自分はコントロールできる
        • 理想を諦めちゃダメ
      • 人には個性があり、それをお互いに理解することが重要
      • 目標を定め、共有し、合意する
    • 社内TBPをやった
      • 自由参加
      • チーム作りが大事だと賛同してくれた人が参加
        • 全員を一気に無理矢理受けさせても意味がない
        • 変われる人からはじめて、広めて全体をかえることにした → 急がば回れ
    • チーム作りにはコミュニケーションが重要
    • ヤッホー流コミュニケーションマップの作成
      • 人数の違い、質や量の違いでコミュニケーション手段の分類をプロット
    • 1日30分朝会で雑談をする
  • 一見売り上げに繋がらないような取り組みは顧客の心に入りやすい
    • 最初から売ろうと思っていない、顧客に楽しんでもらおうと思っている
    • 後から売り上げがついてくる
    • この勇気をもてるか?
  • 変わり者でもよい

所感

RSGT 2019の最後にふさわしいセッションでした。アツかった。
会社が楽しい、社員が楽しんでいるという状態をここまで社長自らが表している企業が他にあるでしょうか。

トレードオフの話がとても刺さりました。極端なトレードオフを選択し続けるということが果たして自分にできるだろうか?一報の選択を捨て続けることが果たしてできるだろうか?これは今年の自分のテーマの1つとして考え続けていきたいです。

チームの作り方も全員を無理矢理引きずり込むのではなく、熱意のある人から広げ徐々に浸透させていくという方法も素敵でした。当たり前といえば当たり前なのですがやはり成功の裏にはこういうった当たり前のことを地道に続けるしか無いということを再認識できました。

本当に力をもらえるセッションでした。

ちなみに、ヤッホーブルーイング再生の話はこの本に詳しく書いてあるそうですのでぜひ。

ぷしゅ よなよなエールがお世話になります

ぷしゅ よなよなエールがお世話になります

全体所感

去年に引き続いての参加ですが相変わらず最高のイベントでした。参加することで1年頑張れる力がもらえます。そういう意味でも年明けすぐにあるのは最高ですね。
誰とでも気軽に話せて意見交換できる雰囲気のイベントって本当になかなかないので普通のイベントの何十倍も学びがあります。その分、疲労もハンパないですが...もちろんよい意味での疲労です。
この雰囲気を作れる運営の皆様は本当にすごいと思います。

学びがたくさんありましたがその中でも今年は以下を意識していきたいと思います。この辺りの経験で何か得たらどこかで還元したいですね。

  • 計測は大事、必ず計測できる方法を考える
  • 何をやるにも心理的安全性は大前提
    • つまり組織の成功循環モデルでいう、関係の質を高めることがとても重要
  • 実験を繰り返すのは大事、それができる状態をいかにつくるか考える
  • Unlearnすべきもの、積み重ねた経験を活かした方がよいものを判断できるようになる
    • UnlearnするときはUnlearnする速度を上げられる状態を作れるようにする
  • 当たり前を当たり前に地道に繰り返す、続ける

運営の皆様、発表者の皆様、参加者の皆様、本当にありがとうございました!来年も参加します!

参考

builderscon 2018に参加してきた

今年もbuildersconに参加してきました。

builderscon.io

参加したセッション内容のメモと簡単な所感、全体所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。

去年の感想。

braitom.hatenablog.com

braitom.hatenablog.com

全体所感

メモが長いので全体所感を先に。

今年も「知らなかった、を聞く」が実現されている素晴らしいカンファレンスでした。色んな文化の人が出会える素敵な場です。
本当に色んな内容の話がありどのコマもどれを聞こうかという悩みが発生します。ゲストスピーカーも豪華ですしまさにフェスだと思います。

ここのところ業務であまり技術的なことができていないということもあり、気分をリフレッシュさせる気持ちで今回は参加しました。今回参加したことで技術の楽しさを再認識できましたし、自分はやはり何かをエンジニアリングで解決することが好きなんだなーということも再認識できました。何かを作りたいという気持ちも高まりました。とてもよい機会をいただき感謝の気持ちでいっぱいです。

最後に、運営で気になる点があったので改善の余地がある点を書いておきます。

  • 去年に比べ記念ホール以外の各部屋が満席になるのが早かったように感じました。セッション終わってトイレへ行って次の部屋に行くとすでに立ち見であったり満席で入れないことが何度かありました。この辺りの調整は難しいとは思うのですがちょっと残念でした。もう一部屋くらい確保して溢れた人が休憩できる部屋とか用意できるとよいかもしれません。そこで新たな交流もうまれるでしょうし。
  • セッション内で質問した時に、初めの方から手を挙げてるのに後から手を挙げた人に先にマイクを渡してどんどんスルーされ、なかなか質問できないということがありました。手を誰が挙げてたなのかを覚えておくのはなかなか難しいとは思うので立ってもらっておくなどの工夫が必要だと思いました。
  • クロージング時のじゃんけん大会からベストスピーカー発表まで身内感がかなり出ていて参加者を置いていけぼりにしていたように感じました。その後、コミュニティのあり方についての素晴らしい話があったのに説得性が欠けるものになってしまっていました。ワイワイしている時は身内感が出てしまうのはしょうがないと思うので運営の一人一人が意識するしかないように思います。

色々書きましたがこれだけのカンファレンスを毎年続けているということは大変ありがたいですし、素晴らしいことだと思います。今後も楽しいカンファレンスを期待しています!
運営の皆様、発表者の皆様、参加者の皆様、楽しいカンファレンスをありがとうございました!

本編1日目

Electronによるアプリケーション開発事情2018

builderscon.io

資料 : builderscon2018.pdf - Speaker Deck

内容

  • MastdonクライアントをElectronで作った
  • リリースに関して
  • なぜMastodonアプリを作ったのか
    • デスクトップ向けのクライアントが少なかったから
  • Whalebirdのコンセプト
    • Slackに慣れてるのでそれっぽい感じに
  • Mediumに英語で記事書いたら海外から反応が
    • いいアプリだけどElectronだから減点、みたいな意見が
    • Electronが嫌いな理由
      • メモリ消費が多いという意見が多い
  • メモリ消費をなんとかしよう
    • 1GB以上メモリを消費することもあった
    • タイムラインの流速が早い方がメモリ消費が多いことが分かる
      • Streamingされたものをすべて表示していたのが原因
      • iOSのUITableViewは画面に表示されている部分しかレンダリングしていない、この方針を真似する
      • 古い部分を捨てていく方針に
    • Vue.js部分のパフォーマンスも意識
      • v-ifとv-showを意識
      • v-ifの切り替え時のレンダリングコストはバカにならない
    • Electronのバージョンを上げるだけでメモリ消費量が少なくなることも
  • megalodonというmastdon APIクライアントライブラリも作った
    • TypeScriptで実装
    • TypeScript最高
    • ElectronアプリもTypescriptで書けば良かった...
  • Electronのセルフアップデート機能使うとAppleの審査に弾かれるので使っていない

所感

個人でプロダクトを作ってそこから普段の仕事では使っていないいろいろな技術を学んでいく姿勢が素晴らしいと思いました。英語で記事を書いて海外ユーザーを引き込むスタンスも素晴らしいです。あと、vue-cliでVueを使うElectronアプリの雛形を作れることは知りませんでした。

electron-builderが相当便利なことが分かったので、Electron使う機会があったら使っていきたいです。

パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと

builderscon.io

資料 : ritou_user_authn_builderscon_tokyo_2018 - Speaker Deck

内容

  • パスワード認証
    • 特定デバイス不要の最強の認証方式、のはずだった
    • 現実には使い回し、サービス側の運用方針にユーザーが振り回されるという現実
    • やめるべき理由
      • ユーザーへの負担(ユーザーのスペック不足www)、サービス側のリスク/コスト
  • 現状
    • よくある実装
      • パスワード、多要素認証、リカバリー、リカバリーコード
        • いざ実装しようとすると複雑になりがち
      • ソーシャルログイン
        • パスワード認証とセットで使われることが多い
          • IdP上のアカウントに問題が発生した時への準備
  • 最新動向
    • FIDO2.0
      • UAF + U2F
      • FIDO1.0までバラバラの仕様だった
    • Web Authn API
      • FIDO2.0のWeb API仕様
      • ここで試せる → WebAuthn demo
      • 定着するまでに必要なこと
        • ブラウザの対応、Authenticatorの普及、ユーザーへの啓蒙
  • 課題と対策
    • どのようにしてパスワードレスを実現できるか
      • 新規サービス
        • パスワード認証を使わない
      • 既存サービス
        • パスワード認証を使うのをやめる
          • 新たな認証方式の提供、新たな認証方式への移行、パスワード認証の撤廃
    • 課題
      • どの認証方式を使うか
      • UXが変化する
        • 登録フローが変化する、ログインフローが変化する
      • パスワード確認相当の処理をどうするか
        • どの認証方式で代替するかの決めが必要
  • まとめ
    • パスワード認証を安全に運用するのは困難
    • WebAuthnによる新しい認証方式はすぐそこまで来ている
  • #idcon - Identity Conferenceというコミュニティがあるので興味がある人はぜひ

所感

パスワードレスな認証の現状や関連技術のさわりについて丁寧に説明されていました。話を聞いているとパスワード認証をなくすのは技術的な話よりも人々のマインドを変えることの方が難しそうだなと思いました。
また、UXが変化するというのはあまり意識したことなかったですが確かにそのとおりですよね。

Authenticatorは果たしてあとどれくらいで普及してくるのだろうか?エンジニアが多い身の回りでもyubikey使っている人少ないのでまだ相当かかるだろうなあ。

Webサービスにて200週連続で新機能をリリースする舞台裏

builderscon.io

資料 : Webサービスにて200週連続で新機能をリリースする舞台裏 / builderscon tokyo 2018 - Speaker Deck

内容

  • Mackerelを200週連続でリリースしてきた話
  • 連続リリースの定義
    • ユーザーにとって価値のある機能をリリースする
    • バグフィックスやメンテナンスリリースは含めない
  • 何のためにやっているのか?
    • 機能開発のスピード感が価値のひとつであり優位性だった
    • 最初は連続リリースを意識していなかった、気づいたら50週いってた
    • 毎週連続リリースをアピールしたら顧客獲得の大きな武器となった
  • どうやって維持したか
    • 定期リリースは週2回(火・木)、祝日の場合は調整
    • 週次当番(ローテーション)
      • リリース担当、サポート担当、OSS係、控え
    • リリース全体の所要時間は1〜2時間ほど
    • 2週間スプリントで開発している
      • そのスプリントの中に火・木のリリースも含めている
      • 長期タスクと短期タスクにタスクを分類して管理
      • バックログに対してエンジニアの100%稼働を求めない
        • 20~30%は余力が残るように計画する
      • マイクロマネジメントをしない
  • 続けるコツ
    • 毎週告知をチームの最重要コミットメントと位置づけ、チーム全員がそれを目指す
  • 毎週リリースをやめた理由
    • 主な機能が出そろった
    • スピード感より腰を据えた機能開発の方が顧客にとって大きな価値となるフェーズになったと判断。スタートアップ機の終了
  • 毎週リリースを終えてみて
    • 足回りの改善がやりやすくなった
      • Playframweork、Scala、sbtのバージョンが一気に新しくなった

所感

バグフィックスやメンテナンスリリースは含めずに、ユーザーに価値のある機能だけをこれだけの期間毎週リリースしてきたのは本当にすごいと思います。チーム作りもいろいろと試行錯誤があったかと思いますが工夫したんだろうなあと。
バックログに対してエンジニアの100%稼働を求めないで20~30%は余力が残るように計画するというのは本当に大事だと思います。(そうしようと思いつつなかなかできないのですが...)

あと、プレゼン資料の構成がとてもうまいと思いました。

イノベーションを止めずに、端末管理と運用を行う方法

builderscon.io

資料 : イノベーションを止めずに、端末管理と運用を行う方法 - Speaker Deck

内容

  • なぜ端末管理するのか?
    • ライセンス管理
    • 稼働状況の確認、棚卸しなどコスト削減につなげるため
    • 情報セキュリティ対策
    • 不正利用対策
  • 端末管理するからには目的を明確にする必要がある
  • 念頭に置くこと
    • 目的を見失わない
    • 性善説はなりたたない
  • 管理方針
    • 懸念における対応が未定義ならきつめに設定
    • 端末はなくしてしまう前提で設計
  • macOSの管理
  • Windowsの管理
    • Azure ADとIntune
    • Winlogbeatとosqueryで監査ログ取得してElasticSearchに入れる
  • iOSの管理
  • Androidの管理
    • managed Googly Play
  • ビジネス部門と管理部門のバランスが大事
    • 要望をちゃんと受けていくスタイル、代替案を提示していくスタイル
      • 一方的に締め作るのはダメ
    • お互い歩み寄っていく姿勢が大事

所感

知見が共有されることが少ないデバイス管理系の話ということでとても参考になりました。端末管理をするにしても目的が大事で、何のためにその設定をするのかを忘れないようにすることがとても大切ということが伝わってきました。人はミスを犯すという前提で設計しないといけないこともなるほどなあと思いました。

Macの管理はとてもツラそう...でも色々なサービスやOSSを組み合わせて仕組みを作る感じはエンジニアリング感があってちょっと楽しそうかも。

また、気になったので以下の質問をしてみました。

  • Q: 今後人数が増えていってもこの方法で運用が回るか?ライセンス費などもかさんでくると思うがペイできるか?
  • A: できると思う。なるべく工数をかけない方向で努力している。人数増えてきたら外部の会社にお願いすることも検討すると思う。本当に必要なのはみんなの要望に対応するための時間を確保しておくこと

この質問をした意図としては人数が増えると運用負荷とライセンス費用がどかっと上がると思っているからです。また、ビジネス部門と管理部門のバランスの話をされていたのですが、人数が増えると色々な考えを持った人がどんどん増えていくということなのでこのバランスを保つためのコストもどんどん高くなってきます。そんな中でこの仕組みを続けていけるのだろうか?と疑問に思った次第です。

lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話

builderscon.io

内容

  • lldの紹介
    • LLVMのサブプロジェクト
    • とにかく高速
    • 採用事例
  • リンカとは
    • オブジェクトファイルを1つの実行ファイルやDSO(DLL)にまとめるプログラム
  • 開発のきっかけ
    • 会社で「コンパイラとリンカを作らないといけないけどどちらがいい?」→ Windowsのリンカを作ることになった
  • どうやったか
    • 何かが間違っていても全くヒントがない
    • バイナリをプリントアウトして考える、バイナリを理解できるよう。とりあえずOSにロードされるように頑張った
    • Hello Worldがリンクできるようになるまで数ヶ月、大きなプログラムがリンクできるまで1年くらいかかった
  • リデザインのポイント
    • 難しくし過ぎない
    • 不自然な最適化はしない。自然と性能が出るように書く
    • データ構造こそが重要
  • 速くてシンプルなコードを書くために
    • 良いデータ構造にするのが重要、データが先、コードは後
    • 2回書く。1度目の経験を2度目に生かす
    • 最適化する箇所を最小にとどめる
  • 終わりに
    • 問題についてよく考えて自分がよいと思うやり方を勇気を持って試してみる
    • 存在しない問題を作りだしてそれを解決しようとするのではなく、元々の問題を直接解決できないのかよく考える
    • カーゴ・カルト・プログラミングしない
    • 理不尽なものは受け付けない

所感

まさに自分にとって「知らなかった、を聞く」セッションでした。
リンカを使うことはあってもそれを実際に作ることなんて考えたこともなかったのでどういう考えでつくるのか、どういう苦労があるのかが分かりこういう世界があるのかーと思いました。プログラマとしての生き方、考え方をあらためて考えさせられました。

あと、なんというか考え方とかすごいなーと聞いていて終始思っていました。

このtweetがまさにこのセッションのすごさを表しているなーと。

本編2日目

「Web とは何か?」 - あるいは「Web を Web たらしめるものは何か?」 - Idea of Web

builderscon.io

内容

  • Webは進化しているが本当に正しい方向に進化しているのか?それを誰がバリデーションできるのか?
  • Webに関わる視点
    • Webを使う人たち、Webで作る人たち、Webを作る人たち
  • 最初はティムバーナーズリーが論文を共有したいということから始まった
    • HTML,HTTP,URL
  • WebのApp化
    • Cookie,Form,JS,iframe など
  • Ajaxの登場
    • 単に表示するだけの時代にはなかった問題に直面することに
      • サーバはそんなリクエストがくるとは思っていない
      • Cookieや認証で守られたリソースG奪われる など
  • Originの登場
    • Same Origin Policy
      • Webのセキュリティモデルを整備
    • Cross Origin
      • Originを正しく超える手順の定義
      • CORSがやぶられることの重大性
      • Cookieがやばい → Originの上で焼き直し中
    • OriginのあたりからWebを支える技術に書かれている内容を超え始める
      • Originの登場でHyper Media PlatformからApplication Platformに
  • HTML5の登場
    • アプリケーションを作るには貧弱すぎた
      • データ保存できない、動画も音声も再生できない、線すら引けない etc
    • Webは文章を共有するものではなくなった
      • それはWebに本当に必要か?
        • Contents Use Caseで議論すると失敗する
          • 自分にとって必要/不要みたいな議論になる
        • Functional Use Caseでの議論に移りつつある
          • 互換性とセキュリティモデルが議論できるか
    • Extensible Webの話に
  • アプリケーションプラットフォームの限界
    • 他のプラットフォームと比較される、今はモバイル
    • 低レベルAPIへ(Device Access
  • WebのOS化
    • ここもFunctional Use Caseで議論
    • OSのセキュリティモデルがWebにはない
      • 安全なデバイスアクセスを実現するセキュリティモデルが必要
    • Permissionの導入
  • Hyper Media System → Application Platform → Operating System と変化
  • Webは時代の要求に応じて変化する
  • WebがWebとして壊れないために必要なモノを模索
  • 今はWebにとって重要な過渡期

所感

WebのはじまりからAjaxHTML5、Deviceアクセス系のAPIがどういう経緯で登場してきたのかがセキュリティモデルの考えを絡めて丁寧に説明されていてとても勉強になりました。 「Hyper Media System → Application Platform → Operating System」という流れで進化してきており、これによりWebを支える技術で書かれている以上のことが必要な時代になってきていることがよく理解できました。個人的にはベストセッションでした。

「WebがOSに近づくという流れはOSがWebでいいじゃんって話とも言える。GoogleChrome OSやってるのはその流れ」というのもなるほどなーと思いました。それを聞いてあらためて考えるとやっぱGoogleってすごいなという気持ちになってきました。ブラウザもOSも持っているわけで。WebとモバイルアプリとOSの境目をユーザーが分からないような世界を作れるのはやっぱGoogleなんだろうなーと。

証券トレーディング業務におけるExcel依存を脱却するプロジェクトで直面した技術的選択とプロジェクト運営の失敗

builderscon.io

資料 : 公開なし

内容

  • Excelはツラい、脱却しようとしてもツラかった
  • 証券トレーディング業務とExcelの関係
    • 取引の大部分は伝統的なものが多く、Excel依存のものが多い
    • 店頭取引の取引入力前にExcelを多用
      • VBA
        • メンテが大変、人の入れ替えが多い
      • トレーダー同士は同じ社内でもライバル
      • 属人化しやすい、各々の秘伝のVBA
  • Excel脱却プロジェクト
    • Webアプリ作れ、4ヶ月以内に作れ
    • もちろん激しく失敗
    • ExcelっぽいWebアプリ作った
      • Excelとショートカットが違う、Excelにあった機能が使えないなどの声が...
    • 営業が3人クビに、自分の作ったシステムで他人が死ぬ...
    • どうすればよかったか?
      • 既存のExcel資産を活用して、手作業のマージ作業を軽減するだけでよかった?
      • Excelの良いところをもっと考えるべきだった
  • プロジェクトアンチパターン
    • 上から降ってくる技術的選択、大きめの選択
    • 政治力の及ばない相手との共同作業
    • 短すぎる納期
    • 既存ワークフローのいいところを無視
    • 後から明らかになる要求に対応できない体制

所感

これは確かに資料公開もビデオ撮影もできないよな、というとても香ばしい内容でした。こんなにツラい案件をやっている人もいるんだと元気をもらいました。

やはり、こういった失敗プロジェクトの事例の共有はありがたいですね。とても参考になりますし、色々と考えさせられます。政治的な話はどうにもならないと逃げずにできる限りのことはやって、大爆死せずにいかに怪我を少なくできるかを考えていくのが大事だと思っています。

また、プロジェクトの進め方をもうちょい工夫すれば大爆死は避けられたのではないかと思いました。

なぜエンジニアはパフォーマンス計測しないのか

builderscon.io

資料 : why_dont_you_measure_your_performance - Speaker Deck

内容

  • これと結構かぶっているとのこと
  • ガジェットを駆使して自分を測る
  • 結果を言うと体重減ったり、体脂肪減ったりで効果が出たことは出た
    • プライベートでコードを書くようになったのも1つの成果
  • 7年のログからみる自分の傾向
    • 仕事が忙しくなると太る
    • プライベートが不安定になると太る
  • やる気がでないという問題も科学的アプローチで解決できるのでは?
  • ありとあらゆるものを測定することに
  • 取ったデータを全てFirebaseに集約していく
    • グラフを色々表示するUIも作成
  • 睡眠時間と集中度の関係見たが相関あるのかないのかよく分からなかった...
  • 人体ABテスト
    • 朝ごはん食べる/食べない、カフェイン制限、朝運動してみる、満員電車に乗る、断酒
    • どれもあまり数字に出なかった...
  • 改善策
    • 睡眠
    • 食事
      • 16時間断食
      • 栄養を考える
      • お勧めの間食
        • 欲しいも、ナッツ、ブルーベリーなど
    • 運動
    • 開発環境
      • 立って開発
      • Ergodox導入
      • 机の下にステッパー導入。歩きながらコードを書く
  • そんなに計測する必要あるの?
    • ぶっちゃけ指標に関する数値は1つでよいと思う
    • 自分の体のことは自分から学ぶしかない
    • 自分の人生を自分で決める
    • やる気を出すのではなくやる気が出る状態を作る

所感

これはネタ枠だから!、本当に立ち見してまで聞くこと?と心配そうな感じでしたがきちんと自分の問題を解決するためにエンジニアリングしていて素晴らしい発表だったと思います。
私もいろんなガジェットを買ってデータだけは集めているのですがほとんど分析できていないので見習おうと思いました。

これだけデータが貯まっているのでデータ分析系の話と組み合わせた何かをすると、昨今の機械学習ブームもあるのでもっと色々な人にアプローチできるかも。

業務時間で書いたパッチは誰のもの? OSS 活動にまつわる罠

builderscon.io

内容

所感

こういうポリシーを策定できるのはさすがサイボウズさんだなと思いました。 OSSに関する方針を会社としてしっかりと考えてポリシー作っているということは以下のような利点があると思います。

  • 働いているエンジニアからしたら自分たちのことをきちんと理解してくれていてありがたいと
  • 外から見たらエンジニアの取り組みを支援している素晴らしい会社、かつライセンス周りについてもきちんと理解している会社であると感じる

利点しかないですよねほんと。このポリシーを決めるにあたってきっと内部的にはいろいろと揉めたこととは思いますが、却下とならずにきちんとこうやって成果として出てくるのはさすがだなと思います。

これをきっかけに日本の企業も自社のOSSポリシーを持つのが当たり前になるとよいですね。セッション聞いた後、以下のようなことをモヤモヤと考えていました。

なぜ私はキーボードを作るのか

builderscon.io

資料 : なぜ私はキーボードを作るのか_builderscon2018 - Speaker Deck

内容

  • キーボードを作るまで
    • 肩こりがひどい
    • Helixが社内で流行っていた
    • HHKB2台使いに
      • メリット: 何も自作しなくて良い
      • デメリット: でかい、キー設定いじらないと無力
    • キーキャップ選べるの楽しそう
  • 自作キーボードについて
    • 2種類ある
      • 誰かが販売するPCBを用いて組み立てるもの
        • ErgoDoxとかHelixはこっち
      • PCBから自作するもの
    • PCBとは
      • プリント回路基板
  • パーツ選定について
    • キースイッチ
      • 高さを選ぶ、軸を選ぶ
      • 自作だと小指だけ赤軸、他は茶軸などできる
    • キーキャップ
    • ケース
      • キットに付属しているものが多い
      • 3Dプリンタなどで自作して自分で作るパターンも
  • 自作キーボードやらかし集
    • 失敗はつきもの
    • 失敗をおそれず色んなキーボードを自作してほしい
  • 一歩先へ
    • フットペダルつけてキースイッチを割り当てる
  • なぜキーボードを自作するのか?
    • 自分に道具を合わせるという考え方
      • 既製品は自分を道具に合わせることになる

所感

自作キーボード愛を感じるセッションでした。自作キーボードは一度やってみたかったので色々と参考になりました。 特に失敗事例の紹介はとても参考になると同時に、ハンダ付けのワザがやっぱ要求されるのかーとやはりちょっと尻込んでしまう自分が...

Helix買ってみようかなー。

LT

キーボードをカスタムしてプログラミング環境を良くした話

資料 : キーボードをカスタムしてプログラミング環境を良くした話 / Improved programming environment with customizing keybords - Speaker Deck

スーパーファミコン開発ことはじめ

  • なんかゲーム作りたい
  • 25年以上前のもだし今ならなんとかなるでしょ → ならなかった
  • いろいろ頑張ったけどツラい
  • コンパイラか言語を自分で作るしかない!
  • To Be Continue

Micorservices-friendly data pipeline

  • マイクロサービス化が進むとデータが多くなってくる
  • 中間層にデータパイプライン作ろうと試みている
  • バッチとストリームのパスを用意
  • まだプロトレベルでいろいろ考えているところ
  • 中間層がモノリスになってしまうのでは?という不安も

WebReplayから見るWeb開発の未来

WebReplayから見るWeb開発の未来 #builderscon - Speaker Deck

  • いわゆるTimeTravelDebugging(TTD)
  • 最近Firefoxのnightlyに入った
  • クライアントサイドのバグ再現のためにある
  • 現状まだ使うには厳しい...
  • Web開発の未来がある機能な気がする!戻りたかったあの頃に戻れる!

チームでテストを書くために

資料 : チームでテストを書くために / To write test code with team members - Speaker Deck

  • テストがない状態からテストを導入した話
  • まずは経験を積んでもらった
    • 先導する
    • 敷居を下げる
    • 効果を実感する
  • 現在ではチーム全員がテストを書くように
  • 知識と経験を付けるの大事

capanfileがRubyパースできることに気づいた俺たちは

  • cpanfileをRubyでパースした
  • なんでPerlじゃないの?
    • ダメなわけない

こんな現場でやってられるか

  • PMを知ること大事
  • 手始めにPMBOK読むのお勧め
  • 銀の弾丸はない、しかしベストプラクティスはある

5分でフォトブース

  • 会場にあった写真撮って加工してインスタに自動でアップするやつの話
  • 材料はIntel NCUとRealSenseとLCD
  • Vimチョットできる
    • あのkaoriyaさんだった...

Development Tools for Next Generation

資料 : Development Tools for Next Generation - Speaker Deck

  • ChromeBookで使えるエディタがない
  • ないから自分で作ってる
  • Next Editor
    • Editor with Git
  • 目標
    • Git for Everyone

アップデートばかりしている言い訳をさせてくれ

  • Swiftの歴史
    • バージョンアップのされ方
    • Appleは破壊的変更してくる
  • OSS化によりマシになってきている?

登壇やLTを始めてみたい」方の背中を押してみたい

資料: 「登壇やLTを始めてみたい」方の 背中を押してみたい - Speaker Deck

  • 自分も社内外の人から背中を押してもらってきた
  • 背中を押して上げる
  • アウトプットで学べることを教えてあげる

iOSDC Japanを本物のインターネットを提供した話

  • 会場からdwangoのデータセンタへ雑に繋いだ
  • 設計をどうするか?構築をどうするか?機材をどうするか?
  • 牧さんの会社endeworksでネットワーク機器レンタルしている!

Node.jsでCloudFormationのテンプレートを分割して管理する

資料 : Node.jsCloudFormation_のテンプレートを分割して管理する.pdf - Speaker Deck

  • CloudFormationはテンプレートが大きくなりやすい
  • 分割して管理したい
    • S3にテンプレートを置く方法があるがめんどう
  • 作った
  • 見通しが良くなってめんどくささがなくなった
  • honoka-api-base

ネットワーク障害を支配したい話

資料 : ネットワーク障害を支配したい話

HBFavが使えなくなったので代替策を考える

はてなより、お気に入りフィードRSSの継続および仕様変更についてというアナウンスがありました。

bookmark.hatenastaff.com

これによりHBFavというお気に入りユーザーのブクマを閲覧するのに便利なアプリが動かなくなってしまいました。

hbfav.bloghackers.net

今回の仕様変更にともない提供終了のアナウンスも出されています。

HBFav の提供終了について · Issue #160 · naoya/HBFav2 · GitHub

しかし、諦めるのはまだ早いです。
お気に入りフィードの仕様変更があっただけで廃止になったわけではありません。
いくつかのパラメーターは使えなくなりましたが、一覧をフィードで取得することは可能です。それをとりあえずRSSリーダーに突っ込んでおけばなんとかなりそうです。
はてなさん、フィードを継続してくれて本当にありがとうございます。

というわけでその方法です。といっても以下の仕様のページに全て書いてあります。

はてなブックマークお気に入りフィード仕様 - Hatena Developer Center

link[rel=altenate] にURLがあるのでそれを取得すればOKです。

以下、簡単な解説。

1.お気に入りフィードのページに行きソースコードを表示します。

2.該当箇所を探します。altenateでページ内検索すれば1発です。
こんな感じのものが見つかるはず。

<link rel="alternate" type="application/rss+xml" href="/braitom/favorite.rss?key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" />

3.私の場合だと以下がフィードのURLになります。

http://b.hatena.ne.jp//braitom/favorite.rss?key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

あとはこのURLをRSSリーダーに登録しておけばとりあえず確認することができます。
ひとまずお気に入りフィードを確認するだけの用途ならこれで個人的には事足りる状態になりました。

GitHub PagesのJekyllでError: jekyll-remote-theme が発生した

GitHub PagesのJekyllで公開しているサイトがあるのですがbundle updateしたら若干はまったのでメモ。

Summary

  • GitHub PagesのJekyllを使っているプロジェクトでbundle updateしたらローカル環境で実行時にエラーが発生した
    • 発生したエラーはError: jekyll-remote-theme
    • 環境はUbuntu 16.04.3 LTS、Ruby 2.4.3
  • ibcurl4-openssl-devUbuntuにインストールすることで解消した

ことの始まり

先日こんなメールがGitHubから届きました。

f:id:braitom:20180118164740p:plain

「これが噂のDependency graphの機能で脆弱性のあるライブラリを通知してくれているのかー最高に便利だな」と思いました。

ということでアップデートを開始。

環境

今回問題が発生した環境は以下です。

やったこと

Gemfileの確認

GitHub Pagesのgemはこんな感じになっていると思います。

source "https://rubygems.org"

gem 'github-pages', group: :jekyll_plugins

bundle updateの実施

アップデートします。

$ > bundle update

何のエラーもなくアップデートできました。Gemfile.lock もきちんと更新され、中を見ると問題のnokogiri もアップデートされていることを確認しました。

動作確認、エラー発生

ローカルで動作確認をします。

$ > bundle exec jekyll serve
Configuration file: /mnt/c/Users/xxx/xxx/_config.yml
  Dependency Error: Yikes! It looks like you don't have jekyll-remote-theme or one of its dependencies installed. In order
to use Jekyll as currently configured, you'll need to install this gem. The full error message from Ruby is: 'Could not open library 'libcurl': libcurl: cannot open shared object file: No such file or directory. Could not open library 'libcurl.so': libcurl.so: cannot open shared object file: No such file or directory. Could not open library 'libcurl.so.4': libcurl.so.4: cannot open shared object file: No such file or directory' If you run into trouble, you can find helpful resources at https://jekyllrb.com/help/!
jekyll 3.6.2 | Error:  jekyll-remote-theme

おや、なんかエラーが出てる。Error: jekyll-remote-theme ってやつですね。

対応策

調べたところjekyllのリポジトリにそれっぽいIssueが上がっているのを見つけました。

Dependency Error: jekyll-remote-theme is not installed · Issue #6660 · jekyll/jekyll

まさにこれですね。

いろいろ書かれていますが、私の環境では下の方にあるようにibcurl4-openssl-devを入れることで解決しました。

$ > sudo apt install libcurl4-openssl-dev

これでもう一度、bundle exec jekyll serve を実行したところエラーが解消されました。

さいごに

あとはPushすれば無事にGitHubが出しているセキュリティアラートも消えていると思います。
しかし、Dependency graph便利ですね。もっと色んな言語に対応してくれるとありがたいものです。

Regional Scrum Gathering Tokyo 2018参加レポート #RSGT2018

Regional Scrum Gathering Tokyo 2018に参加してきました。

2018.scrumgatheringtokyo.org

参加したセッションで印象に残ったことと簡単な所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。

Day1

Build a Workplace People Love – Just add Joy

資料 : Richard Sheridan - Build a Workplace People Love – Just add Joy // Speaker Deck

印象に残ったこと

  • エンジニアの喜びとは「自分の作ったものが、世に出て、誰かに使われること」
    • 混沌→PMO導入→官僚主義に→シャドーITが始まる→Agileだ!→でも何もスタートできない...
    • ソフトウエア開発における喜びがなくなっていく
      • Joy Incに書かれてる仕組み作りをはじめることに
  • 喜びとは何か?どうなると喜びが悲しみなるのか?
  • 柔軟なオフィスレイアウト
    • 上司の許可はいらない。好き勝手移動できる
  • 騒音も受け入れる
  • 赤ちゃんを連れてきてもOK。もともとガヤガヤしているのでたいした問題ではない
    • 赤ちゃんのおかげで顧客がやさしくなるという効果も
  • チケットは手書き
    • 手で書くとコピーペーストしないから自分の言葉で書くし絶対読む
  • 学習とは
    • 本を読むことではない
    • 人から学ぶ、一緒に作業しながら学ぶ
  • コミュニケーション
    • Slackなどのチャットツールは使わない
    • 声が一番、直接会話
    • 全社ミーティングはHey Menlow!Hey Rich!のかけ声でさっと実施
  • 恐怖と戦い、変化を受け入れるために実験してみよう
    • それはうちではうまくいかないといった反応には「実験しましょう」と促す
  • 「今日話したことは簡単にできるものではない、しかし必要なことである」

所感

Joy, Inc.の原作者リチャードさんの生講演ということでとても楽しかったです。この本3回くらい読んだので。
内容的には本に書かれていることが多かったのですが本人の口から聞くとまたあらためていろいろと考えさせられました。

仕事する上で「喜びとは何か?どうなると喜びが悲しみなるのか?」については、やはりきちんと定義できていないといけないなと思いました。インセプションデッキで近いことができそうですがあえて「喜び、悲しみ」みたいな項目を入れてもよいかもと思いました。

文化を形成するのにオフィスレイアウトってやっぱ重要だよなとあらためて思いました。柔軟なオフィスレイアウトができるからこそチャットツールを使わないで直接会話が成り立つし、全社ミーティングも成り立つんだろうなあと。

変化を嫌う人、それはうちではうまくいくはずがないという人には「実験しましょう!」と伝え続け、何かを変えていけたらと思いました。

心が折れてもソシキ・カイゼンを続けられるたった一滴の魔法

資料 : 心が折れてもソシキカイゼンを続けられるたった一滴の魔法 // Speaker Deck

印象に残ったこと

  • やってきたこと
    • アジャイルワーク(社内へのアジャイルの浸透)
      • 組織改善、組織変革に有効なのでは?
      • 見える化が大事
      • 総務部でもアジャイル
      • 手法を採用するというよりも、考え方やプラクティスを取り入れていってる
    • 越境ワーク(社内見学ツアー)
      • メンローがやってるやつ
      • 半年先くらいまで予約で埋まっている
  • 価値観
    • 知的好奇心、学び=良いこと
    • 少年サッカーのコーチ経験
      • 「大きい相手でも怖くないよ、そこを気にしたところで何も変わらないから 大変だけどね」 by 小学6年生のキャプテン
    • オーストラリアでの留学経験
  • 続けられるわけ
    • 社内の仲間
      • QCサークル(公式組織)とコミュニティオブプラクティス(非公式コミュニティ)
      • カイゼンの取り組みを少し賞与へ反映させる仕組み
    • コミュニティの仲間
  • 越境なのでボーダーがない
  • ギャザリングの場
  • 人を喜ばせるために、笑顔にさせるためにわれわれの仕事があるのではないか?
  • 見返りを求めずGive&Giveしている人はいるんじゃないかな?好きな人を増やそう
  • 何ごとも自分の選択
    • 義務でも犠牲でもない
  • 子供の「いいこと考えた。聞きたい?どーしよっかなー」ということを大人になってもやっていいんじゃないの?

所感

私は普通の人ですってことを強調されていましたが相当すごい方だと思います。ここまでめげずに成し遂げられるのは普通の人ではできませんよ。本当に。
心が折れそうなときにこの資料を読み直したいと思います。しかし、仲間を作っていくことってほんと大事ですよね。
本買います。

www.shoeisha.co.jp

サーバント・リーダーシップを掘り下げて考えましょう

資料 : サーバント・リーダーシップを掘り下げて考えましょう

印象に残ったこと

  • なぜ必要か?
    • セルフマネジメントチームを可能にする
    • 日本企業への解毒剤となる
      • 縦社会、お偉い様への過剰反応など
  • 世界を変えたいのであればまずは自分自身が変わることからはじめなさい by ガンジー
  • スクラムマスターとサーバントリーダーシップ
    • スクラムマスターという役割には権力、肩書きのパワーが付いていない
    • チームのパフォーマンスをあげてプロダクトを出すために何でもする
  • サーバントリーダーシップは究極のソフトスキル
    • スクラムマスターだけでなくメンバー全員にとって役に立つ
  • 単に命令するだけなら誰でもできる、説得してやってもらうにはスキルが必要
  • チームメンバーから自分の役割に対してフィードバックをもらう

所感

サーバントリーダーシップの話は至るところで出てくるのですが毎回もやもやします。というか、その時々の状況によって常にリーダーシップのあり方は変わり続けるものなので正解なんてないのだと思います。だからもやもやするのかなと。
講演や本などからいろいろな考え方やパターンをインプットしていってその時々の状況に応じてベストな振る舞いができるようになることを目指していきたいと思いました。

以下は雑なメモ。

  • タックマンモデルの段階によってはサーバントリーダーシップだけではうまく回らないこともあると思う
  • 出来たての組織とかメンバーが大きく変更した組織の場合は最初のうちはトップダウン型のリーダーシップでよいのでは?
    • ある程度、組織がレベルアップしたらサーバント型に移ればいいのでは?
  • このあたりエラスティックリーダーシップに書いてあったはずなのでまた読もう

ゲーム開発現場の中心で心理的安全性を叫ぶ

資料 : ゲーム開発現場の中心で心理的安全性を叫ぶ [RSGT2018]

印象に残ったこと

前半
  • 社内勉強会に参加しづらいと感じる
    • 隣の席の先輩が忙しそうだから...
  • 社内勉強会を開催したいが
    • 業務時間内にやっていいの?
    • いちいち報告しないといけないの?
  • こんな状態が続くとモチベーションが下がって何やるにも億劫になるという負の循環が起きてしまう
  • 勝手にできないと決めつけて言わずに諦めていた
    • RSGTへの参加なども言ってみたら会社から許可おりた
    • 研修費用もお願いしたら会社から出してもらえた
  • 組織の空気を少しずつ変えていく
  • LT大会の実施
    • 勉強会のハードルを下げる
    • コミュニケーションの活性化
  • 起きた変化
    • イベント参加報告をレポートからLTに
    • 自由参加できる勉強会が増えた
  • 継続させるために
    • スタート前に協力者を探す
    • スペシャル会を開催する(大御所を呼ぶなど)
    • 地道な宣伝活動
  • Chatwork社員雑談部屋
    • 退室自由、避難禁止
    • 時期を見て情報の発信量をコントロール
    • バカなふりする
      • 間違っていても雑に発言してよい空気を作る
      • もやっとしてることでも言っていいんだ
      • やりたいこと、熱量を吐き出していいんだ
    • 言える化
      • 思い込みを取り除き気軽に発信できる → 相談したり助けてと言える → 問題や間違いを指摘し合える
  • 全員を巻き込めずイライラするよりも今一緒に活動している人達で楽しむにはどうすればよいかに集中する
後半
  • チームを潰した話
    • 透明性を重視していろいろ見える化した
    • リーダークラスの人が辞めてしまった
    • 見えないものを見えるようにして何が悪いんだろうと思っていた。しかし何も考えずに全てを見えるようにするのも良くないことに気づいた
      • 隠したいスケジュールとかがあった?
    • そもそもなぜ隠さないといけなかったのか?隠さないとイケない雰囲気のチームがいけなかった
    • このようなチームにいきなりスクラムを適用は厳しいことを知った
    • 心理的安全性があるチーム作りが必要
  • 心理的安全性とは
    • 仲間に背中を預けチャレンジできる状態・状況
    • 個人が安心して本気で取り組める
  • 話し合える場を作る
    • 対等な立場でプロダクトやチームについて話し合える場
  • 話すきっかけ、雰囲気作り
    • ムードメーカー(この人だったら多少のことを言っても許されるって人)に期待
  • 個人との対話も重要
    • 個人の不安はふりかえりでは拾えない
    • 人への不満は時間の無駄
    • チームVS問題という構図になるようにする
  • ふりかえりで感謝の言葉が増えてくると良いチームになってくる

所感

前半のお話は今自分が取り組んでいることに近い話だったのでとても共感できましたし参考になりました。イベント参加報告がレポートからLTになったというのはとてもよいですね。言える化という言葉もしっくりきました。言える化の状態作ってもメンバーの入れ替えがあるとまたちょっと戻った感じになるのでその辺どうしているのかどなたかと意見交換したいなあと思いました。

後半のお話からはとにかく対話が大事ということがビシバシと伝わってきました。やはりなんやかんやで対話大事ですよね。がんがん対話していきましょう。

Scrum プロジェクト開始のベストプラクティス

資料 : 【資料公開】Scrumプロジェクト開始のベストプラクティス | Ryuzee.com

印象に残ったこと

  • ベストプラクティスはない
  • 自分たちで考える
  • インセプションデッキも単なるフレームワーク
    • 書けば終わりではない
    • 目的は共通理解の形成
  • 対象領域によって開発手法を選ぶ必要性
    • プロジェクトの特性によって本当にスクラムでやるのか考える
    • ウオーターフォールの方がうまくいく場合もあることをきちんと考える
  • プロダクトオーナーとスクラムマスターは外部とのインターフェイス。外部パートナーをアサインするというのは好ましくない
  • リスクが高いチーム体制
    • パートナー比率が高い
    • 既存チームが強力な指示型で運営されている
  • プロジェクトは初期で決まる。人が大事。兼任辞めさせる、経験がある人を集めるなど
    • プロジェクトを成功させたかったら、十分条件を満たしなさい。開発の初期で成否が決まることが多い
    • スクラムは不十分な状態からプロジェクトを成功させられるフレームワークではない。成功させるためには十分な状態で開始する必要がある
  • ワーキングアグリーメントを設定する。みなで話し合って働き方を合意しておく
  • スクラムの知識レベルを揃える
  • 非機能要件はアーキテクチャ、コスト、開発期間に影響を与える
  • 技術検証はキリがないので、タイムボックスを設定する。全てを検証するのは無理。結果によってはプロジェクト中止もあり得る
  • ラクティスの選択は最初から盛り込みすぎない
    • 学習コストが高すぎる
    • 後で変えてもよい
  • バージョン管理システムの使い方が分からない人に本番コードは書かせない。まずは教育をしっかり行う
  • スプリントの期間はスプリントが長い方が難しい。最初は1週間が楽
  • 最初のスプリントの開始までに必要な準備期間のお勧めは1か月。最初のスプリントができるかどうかで判断
  • 社歴の長い人がスクラムマスターすると社内に知り合いが多いので調整がスムーズにいくことも多い
  • Q:スクラムマスターの評価どうすればいいの?
    • A:評価いらなくない?個人の成果よりビジネスとしての成果が大事なのでは?それが許されないならチームメンバーにフィードバックしてもらう

所感

最高でした。学びしかないセッションでした。 冒頭でも述べられていたのですがベストプラクティスなんてなく、その時々の状況応じて自分たちで考えていけないということを忘れてはいけません。
質疑応答で出ていたスクラムマスターの評価の話も印象深かったです。個人の評価よりもビジネスとしての成果が大事なのでは?って話はほんとそうだよなあと思いました。

Day2

敢えて属人化せよ!エキスパートの集団こそが最強のチーム

印象に残ったこと

資料が公開されていないのでここはセッション内容のメモをそのまま貼っておきます。

  • 環境は大事
    • 超人の同僚といつでも議論、協力できる
    • よいマネージャーがいる
    • 健全な勤務時間
    • いつでもリモート作業、会議
    • 広い机と速いマシン
      • スペックのよいマシンが使えなければ会社に行く意味なくないですか?
  • 楽しく作れる条件
    • 大きな裁量、権限
    • 頼れる仲間
    • 上がる給料
      • お金大事
  • 始めてアメリカに移ったとき
    • 今までの習慣でプランニングドキュメント書きますといったらやってもいいけどコード書けっていわれた
    • そのドキュメントを作った1週間を無駄にしていることを身をもって知った
    • コードが知識の履歴そのもの
    • バックログが常にあるのは最初ツラいことだと思っていた → 常にやること(改善出来ること)があるということは良いことだと思えるようになった
  • 最初の数回のスプリントをとにかくやってみる
    • 口で聞いても分からない、体験することが大事
  • App Servicesの開発プロセスの変遷
    • DevOps → NoOps → Dev + Support
    • お客様からの意見をいかに反映させるか
    • お客様が実際にどう使っているか知ることは非常に学びがある
  • よいマネージャーを探すのは難しい
    • 自分からよいマネージャーを探してそのチームに入るという考え方
  • 評価システム
    • 5段階評価だったがなくなった
    • どうしてもチームがギクシャクする
      • こんなに頑張ったのに...なんであいつの方が...とか
    • 無くすことで心理的に楽になり働きやすくなった
      • 何かに追われている感がなくなった
    • 評価基準はimpact
      • マネージャーの力量が問われる
      • 同僚をどれくらい助けたかなど
      • 評価しあう仕組みはとても大事、チームの雰囲気を良くする
        • 自分がいい仕事ができたとき、それを助けてくれた人に感謝したくなる
      • マネージャのこともレビュー、その上司が評価するのに使う
        • マネージャが悪いと部下が逃げる
  • ハッカソンの力
    • ハッカソンからいくつもの本番提供しているサービスが生まれた
    • 業務と直接関係ない場所でも自分のアイデアを活かせる場
    • 組織的に支援できる環境が必要
      • MSではハッカソンの期間1週間くらい取ってくれる、表彰もしてくれる
  • マネージメントの力
    • 本当にそんなことやって意味あるの?って人に対して継続的にメッセージを発信していくのが大事
    • トップは大きなビジョンをきちんと伝えることが大事
      • MSはそれでだいぶ変わった
      • ただし時間はかかる。バルマーのときから変わり始めていた
  • スイッチを切り替える
    • 上司は使うもの
    • バグはあって当たり前
    • 内部向けの議事録不要
      • 意思決定に参加してない人に対してアピールすることはない
    • 積極的に発言しないミーティングは出席不要、途中退席可
      • 逆に自分が貢献できそうなミーティングには積極的にアプローチする
        • スケジュールがもし合わなかったらリスケしてもらう、同じミーティングをもう1度開いてもらうなど
    • 属人化したExport集団こそ最強
      • 特定の人しかできない作業があるとその人が休んだり辞めると業務が止まってしまう
      • それぞれの分野で尖っている人がいてそれをまとめる人、サポートする人がいる
      • サッカーチームと一緒
        • 尖っている人たちを集めて最強のチームをつくる(属人化を許容。FW、GKと役割が完全に分かれているってこと)
        • 彼らがいなくならないような最高の労働環境を整える
        • サッカーだと試合に勝つことがゴール、我々はよいプロダクトをつくることがゴール

所感

なんというか本当に素晴らしかったです。会場もスタンディングオベーションが出るんじゃないかくらいの雰囲気でした。
最高の環境で、自分が本当に好きなことに取り組んでいて毎日楽しいんだ!って気持ちが伝わってきました。そんな状態を支えているのがマネージャーであり評価制度であるわけで。これらをまずはしっかりしないと働き方改革なんてうまくいくはずないよね?と改めて思いました。

リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく

資料 : リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく // Speaker Deck

印象に残ったこと

  • 何が難しいのか?
    • サボる人がいるのでは?
      • サボる人は会社にいてもサボっている
    • 労務管理の難しさ
      • 仕事とプライベートの境界が曖昧
      • 真の裁量労働でないと多分成り立たない
    • メンバーに自主性が求められる
      • 自主性が必要、個人の裁量も必要
  • 突き詰めるとコミュニケーションの難しさ
  • つまり、コミュニケーションが難しいということ
  • お客様と一緒に仕事するときってオフィス離れて働いてますよね?リモートワークは突き詰めるとそれと一緒なのでは
  • コミュニケーション
    • メインはSlack
      • 仕事も雑談も。雑談重要
      • テキストだけに頼らない
      • 必要員応じて音声、音声のログはwikiなどに共有
  • テキストコミュニケーションの難しさ
    • 情報が少ない
      • 情報とは: 声の抑揚、表情/仕草、空気感
      • 感情が分からない
      • 良質なコミュニケーションと感情は切り離せない
    • フラットな感情はやや不機嫌気味に伝わる
      • 大げさに絵文字や感嘆符を入れる
  • 雑談
    • 情報の欠如を補うもの
    • 毛づくろいのためのコミュニケーション

所感

自分とだいたい同じ考えだったのでとてもよく理解できました。リモートワークが難しいのではなく結局はコミュニケーションが難しいのですよね、やっぱり。リモートでうまくいかないチームは同じ場所にいても結局うまくいかないと思っています。ただ、オンラインでの議論については工夫と前提条件が必要だとおもっていてその辺りは以下に以前書きました。

braitom.hatenablog.com

スクラムチームとして、妨害リスト(Impediments List ) を運用して見えてきた課題解決方法

資料 : 妨害リストを運用して見えてきた課題解決方法 // Speaker Deck

印象に残ったこと

  • 妨害リスト
    • 開発チームの進捗を妨げるものを排除する
    • 明確に定義されているものではない
    • Trelloのボードで運用
      • まずはFactに入れる
  • 登録される例
    • 人やスキルの話
    • 環境に関する話
    • プロダクトに関する話
    • 品質やスタンスの話
  • 何が妨げになるのかを俯瞰できる
    • チームで共通の課題認識を持てる
    • 問題 VS 私たちの構図になる
  • いつも出てくる問題の多くはチームの外にある
    • 前提を変えない限り大きな改善にならない
  • 妨害リストにも透明性
    • 誰でも見えるように
    • チームの外の人にも見えるようにすることで相談しやすくなる
    • 相談するときには経緯が伝わっている
  • 更新されなくなる問題
    • デイリースプリントで聞いてみる
    • 定期的に棚卸しする時間を取る
    • ミーティングで出た課題を追加する
    • Slackなどで妨害っぽいものがあったら追加を促す

所感

梶原さんの話は以前にも聞いたことがありその時も妨害リストの考えいいなーと思いつつ行動に移せていませんでいた...これを機に今度こそ実際に試してみようと思いました。確かに前提となるような問題ってチームの外にあること多いですよね。そのため透明性を保って誰にでも見られる状態にしておくのは大事ですよね。

「ふりかえり」の始め方と続け方

資料 : 「ふりかえり」の始め方と続け方 // Speaker Deck

印象に残ったこと

  • ふりかえりの大前提
    • 心理的安全性があること
    • 時には参加者を選ぶことも必要
  • 状況にあったやり方を選ぶ
    • 何でも感でもKPT使えばよいというものではない
    • チームの状況は?
    • 参加人数は?
    • 何にフォーカスする?
  • 点ではなく戦でふりかえる
    • メトリクスを取る
  • アクションを日々の活動に組み入れる
    • タスクボードに見える化する
    • タスクをする時間を見積もり確保する

所感

ふりかえりってやっぱ難しいなあとつくづく感じました。いろいろ試行錯誤してパターンを増やしてその時のチームや状況に合うものを選択できるようになりたいです。

モヤモヤ女子大生がプロダクトオーナーになったら!

資料なし

印象に残ったこと

  • 専門用語はあえて使う必要は無い。分かりやすいものに変える
    • 非エンジニアからすると横文字ばかり使われるのは何言ってるか分からなくて怖い
  • 自信をつけてもらう
    • 開発者との知識差を負い目と感じてしまう
    • 勉強会などを開催して武器を持たせる

所感

軽い気持ちで参加したのですが学びが多かったです。自信がない状態だとやはり引け目を感じてなかなか自分の意見も言えず前に出て行けないものです。それを打開するために勉強会をするなどして何かしら武器を持たせてあげるということはとても大事だと思いました。飛び抜けている武器を身につけられなくても言っていることが分かるくらいの知識レベルを持たせてあげるだけでも十分なこともあります。若手の成長を考える上ではこのことはとても役にたちそうです。
あと、エンジニア以外の人と話すときに横文字を連呼するのは本当にやめようと思いました。

Panel - 実感駆動でものづくり ー 協調学習過程としてのスクラム。欲しいものを、どうやって知るか。

資料 :

印象に残ったこと

  • 社内政治を攻略する
    • うまく組織をハックできるなら組織にとっても良いこと
  • 金とアジャイル
    • エンタープライズだと年次の予算計画が多い
    • 新規事業なのに計画駆動になる
    • 1年先を予想して予算作る
      • 不確実な情報をもとに
      • 軌道修正が不可能に
    • アジャイルを選択しても
    • 資金調達のタイミング
      • 説明責任単位で資金調達できるとよい
  • 金の話
    • 決裁権限ある人はやっちゃえばいい
      • グレーゾーンわざわざ聞くから黒になる
  • 政治の話
    • 経営層での支援者は必要
    • 角を立てずに波風を立てる
    • 偉い人くらい手玉に取れなければいけない

所感

いやー世の中けっきょく何をやるにも結局は金と政治だよねーと改めて思いました。いくらうまくプロセス回せたとしてもお金がなければ何もできませんし、お金を得るためには政治が必要なわけですしね。

さいごに

はじめてRSGTに参加しましたがとてもよいイベントでした。
なんというかこのイベント自体が心理的安全性が確保されているというかなんというか。多少の失敗があっても笑って許し合える雰囲気がある感じがしました。議論も至る所で起きますし、初参加者でも違和感なく参加できる感じでした。

内容も意識が高まるものが多く、同じ悩みを抱えている人がどのように課題に取り組んでいるのか、工夫しているのかが知れて勉強になると同時に元気がもらえました。
失敗しても死ぬわけではないのでとりあえずやってみる、実験してみるの精神で今年もやっていこうという気持ちでいっぱいです。

運営の皆様、発表者の皆様、参加者の皆様、本当にありがとうございました!来年も参加したいです!

2017年買って満足度が高かったもの

2017年も早いものでもう終わりですね。
皆さんがやっているのを見て自分もまとめておこうと思ったので今年買って満足度が高かったものをつらつらと残しておこうと思います。

iPhone X

www.apple.com

なんやかんやで満足度高いです。ホームボタンがなくなることでどれくらい影響があるのか心配でしたがすぐ慣れました。 今となってはホームボタンがなぜ存在していたのか分かりません。

一番懸念していたのはApple Payの支払時にTouch IDが使えなくなることだったのですが、Face IDでの認証が思った以上に速いので杞憂に終わりました。
Face IDはマスクをしていると認証しないからイケていないと思う方もいるかもしれませんが、マスクをちょっとずらせば認証できますし、そもそもマスクしているときにそんなに頻繁にロックを解除することがないので私は全く問題ありません。

カメラの性能も本当に素晴らしいです。何も考えずにシャッター切ればきれいな写真が撮れます。過去、カメラに定評のある端末をいろいろと試してきましたが間違いなく最高の出来だと思います。

唯一の不満は、ずっとPlus系の端末を使ってきたので画面サイズがとても小さく感じることです。これも慣れればどうということは無いのですが、たまに妻のiPhone 7 Plusを見ると画面の大きさが恋しくなります。

iPhone 8 Plus

www.apple.com

新しいiPhoneを9月に使えないというのが私には耐えがたかったのでiPhone X発売までの繋ぎに買いました。iPhone Xを入手したのですでに手元にはありませんが...
1か月ちょいの利用でしたが本当に満足度が高かったです。

今までのiPhoneの延長で最新型を使いたい方には間違いなくお勧めです。画面の見やすさ、動作のヌルヌルさどれをとってもiPhone 7系から進化していて素晴らしかったです。
カメラの性能も格段に進化していました。子供の幼稚園の運動会はこれだけで挑みましたが全然問題無かったです。

Apple Watch Series 3

www.apple.com

Apple Watchもなんやかんやで全シリーズ使っていますがこのSeries 3はやっとまともなApple Watchになったと感じさせてくれるものでした。

性能がアップしたことでアプリの起動、Apple Payの起動が格段に速くなっています。
Series 2も初代に比べれば格段に動画が速くなっていたのですがまだストレスが残るものでした。それがSeries 3では本当にスムーズに使えるのでストレスがなくなりました。

ただ、デジタルクラウンの赤ぽっちがちょっとダサく感じるのが残念です。今となってはもう慣れましたが。

ちなみに目玉機能であると思われるCellular通信については契約はしたものの一度も使ったことがありません。

Apple Watch Hermès - 38mmケース用ヴォー・スウィフト(エトゥープ)シンプルトゥールレザーストラップ

www.apple.com

Apple Watchのバンドはいろいろと買ってきたのですがちょっと冒険してみようと思い買ってみました。

つけた瞬間に、これがHermèsのレザーか!と感動しました。滑らかさが全然違います。今まで私がレザーだと思っていたものはいったい何だったのでしょうか。それくらいの衝撃。気持ちよすぎてついつい触ってしまいます。

Apple Watchの安いモデルと同じくらいのお値段ですが、今後も長く使えるものなので興味のある方は買ってみるとよいと思います。

Galaxy S8+

www.galaxymobile.jp

私は日本市場で人気のあるAndroid端末の現状を把握するという意味で、毎年GalaxyかXperiaどちらかの最新モデルを買うことにしています。
今回はこのGalaxy S8+を買いました。

画面が大きいのに手に収まるちょうどいいサイズ感、ベゼルレスのかっこよさ、スペックどれをとっても間違いなく今まで使ってきたAndroid端末の中で最高峰のものでした。

ただ、期待していたアシスタント機能である「Bixby」がゴミのような出来だったのが非常に残念です。

iPad Pro 10.5

www.apple.com

久々に大きな進歩を遂げたと感じさせてくれるiPadでした。
120Hzのリフレッシュレートは伊達じゃないです。

Apple Pencilでメモを取りながらの資料読みや技術書読みがとてもはかどります。

Kindle Oasis (Newモデル) 32GB

Kindle Oasis (Newモデル) 32GB、Wi-Fi、電子書籍リーダー

間違いなく過去最高のKindleです。毎日の通勤時の読書ライフの質が格段にあがりました。

防水、ページ送りができる物理ボタン、7インチになった画面サイズ、どれをとっても素晴らしいです。
私は気になった部分をハイライトしながら読むことが多いのですが、このハイライトするときの動作が速くなっていることも嬉しいところです。数秒の差かもしれませんが積み重ねると結構な時間の節約になっていると思います。

Nintendo Switch

www.nintendo.co.jp

言わずもがなSwitchです。
ただ、私はそこまでSwitchのゲームはしていません。

Switchの満足度が高い理由は、子供と一緒にTVゲームができるという機会を与えてくれたことです。

5才と3才の子供も細かいことが分からなくても一緒に遊べます。さすがNintendoさんです。
自分が子供のころにさんざんやったマリオシリーズを大人になってから自分の子供と一緒にできるということはとても感慨深いものです。

Logicool MX ERGO Wireless Trackball

www.logicool.co.jp

ロジクールから久々にでた新型のトラックボールです。M570tを愛用していたので迷わず飛びつきました。

最初はちょっと大きいなと思っていたのですが慣れてくるととても手にフィットします。電池ではなくて充電式になったこともありがたいです。
あと、傾斜を変えられるのがとてもよいです。基本は20度に傾けて楽な体勢で使うようにしていますが、ちょっと気合いを入れたいときは0度にして使っています。これが自分にとっての気合いスイッチとなっています。

Beoplay E8 - B&O PLAY

kanjitsu-boplay.jp

完全ワイヤレスイヤホンです。
昔、EARINが出たときに完全ワイヤレスイヤホンは体験していて残念な気持ちになったので敬遠していたのですが、まわりで買う人も多く、各種メーカーがこぞって出してきたので何か買っておこうということで買いました。結果、買って大正解でした。ケーブルがないってやはり素晴らしいです。

私が完全ワイヤレスイヤホンを使うのは主に通勤時とジムにいったときだけなので音質は捨てました。音質や防水を求めるなら間違いなくBoseSoundSport Free wireless headphonesを買った方がよいと思います。

私が大事にしたのは操作のしやすさと音漏れしないかの2点です。

この機種は横をタップするだけで操作できます。また、外の音が聞こえるようになるTransparencyモードも地味に便利です。話しかけられたときなどに左側をワンタップするだけでイヤホンを外すことなく外の音を聞くことができます。

音漏れについては入念に確認しましたがそこそこ大きな音にしても漏れません。個人的に電車の中での音漏れはけっこう許しがたいのでイヤホンを買うときはこのチェックがかかせません。

ちなみに、イヤーチップを変えるだけで音質やつけ心地、音漏れの印象はだいぶ変わってきます。私はComplyのものをいつも買っています。お持ちのイヤホン用のものを探して買ってみて下さい。

www.comply.jp

なお、長時間の移動時や普段はBose QC 30を使っています。これは去年の発売と同時に買いましたが本当に素晴らしいです。

bbs.kakaku.com

ThinkPad X1 Carbon 2017モデル

www3.lenovo.com

MacメインからWindowsメインに変えようとした年だったのでWindowsノートが必要になったので買いました。勉強会やセミナーなど外に行くときの相棒です。

安定のThinkPadでした。本当に何の不満もありません。この軽さでこの性能、そして何よりこのお値段で買えることがすごいです。特盛りにしてもMacBook Proよりも全然安かったので買うときに本当にこの値段でいいの?と不安になりました。

Apple Watch Series 3の赤ぽっちは許しがたいですがThinkPadの赤ぽっちはやはり最高です。

ヘアードライヤー ナノケア EH-NA99

kakaku.com

Panasonicのドライヤーです。ドライヤーが壊れたのを機に買いました。

髪の毛を乾かす速さが段違いに早くなりました。寝癖がすごいので毎朝頭を洗っているのでかなり時短できるようになりました。

また、我が家は私以外は女性(妻と子供2人)なので、彼女たちは髪の毛がさらさらになると喜んでいました。

常盤珈琲焙煎所のコーヒー豆

tokiwacoffee.com

最後にいきなりガジェットではなくてコーヒー豆です。

家では豆を自分でひいてドリップする派なのですが今年はここのコーヒー豆にはまりました。
浅煎り〜中煎りが好みなので大宮ブレンド常磐ブレンドをメインで、気分次第でその時々のシングル豆を買っていました。

店舗はさいたま市周辺に数店舗しかないのですが通販もやっているようなので興味がある方はぜひ。


最後に

他にもGoogle HomeAmazon Echo、Clova WAVE、HoloLensなどなどいろいろと買いましたが満足度が高いというよりは技術的な興味で買ったものなのでここには載せませんでした。

今年はあまりモノを買わないようにしたつもりなのですが無駄にApple製品を買ってることが分かりました。

来年も経済を回していきたいと思います。良いお年を。