2020年買ってよかったもの
早いもので2020年ももう終わりですね。
今年のふりかえりとしてまとめておきます。
電動スタンディングデスク FlexiSpot E6
もともとそれなりにちゃんとしたデスクがあったので悩みましたがFlexiSpot E6を結局買いました。
天板も選べるE3にしようか迷ったのですが、組み立ての時間を節約したかったのである程度組み立てられているE6を選びました。
先日まで売っていたような気がしたのですがもう廃盤みたいですね。
やはり電動で昇降できるのは本当に便利です。高さのメモリ機能も便利です。おそらく手動昇降型だったら面倒くさくて上げたり下げたりしないでずっと座りっぱなしになっていたと思います。
なお、椅子はアーロンチェアを使っています。7年くらい使っていますがまだ全然問題無く使えているので椅子は早めにそれなりのものに投資することをお勧めします。
足踏みマット DM1
固い床の上に立ちっぱなしだと足に負担が掛かります、また冬だと床の冷たさが直撃し足が冷えます。 調べたところ皆さん下にマットを敷いているらしいことが分かったので買うことにしました。
買ったのはスタンディングデスクと同じメーカーであるFlexiSpotの「足踏みマット DM1」です。
足裏を刺激するための仕組みがあったのが購入の決め手です。
ガチな足裏の刺激を求める人には物足りないレベルのものですが、足踏みしたり、傾斜があるのでそこを使ってふくらはぎを伸ばしたりできます。ちょっとした刺激ですが割とリラックス効果があるので気に入ってます。
もちろんそれなりの厚さもあるので床の冷たさの直撃が防げます。クッション性も固すぎず柔らかすぎずでちょうどよいです。
モニター LG 35WN75C-B
モニターも増設しました。
元々、このPhillipsの32インチの4Kディスプレイをずっと使っていたのですが(2016年から使っている)、ウルトラワイドディスプレイのよい評判をだいぶ聞くようになったので買ってしまいました。
www.philips.co.jp
もっと大きいサイズを買おうかと悩みましたが、手持ちのディスプレイと共存させようと思いこの35インチを選択しました。もう少し欲張って49インチのウルトラワイドディスプレイにするとそれだけで机の幅いっぱいになりそうだったので。
端的に言って、ウルトラワイドディスプレイは最高ですね。視線の移動距離が少なくなるのがこんなに疲労削減に効果があるとは思ってもいませんでした。
解像度、ppiが元の4Kディスプレイよりは下がるものの慣れてしまえばどうということはありません。確かに、最初はちょっと文字がかすむなーと気になったのでこのあたりにシビアな人だと厳しいかもしれません。
またUSB-Cケーブル一本でMacbook Proに繋ぎ、ディスプレイ投影、充電ができるのがとても便利です。しかも90Wで充電できます。Macbook Proの16インチもこれで問題無く充電できます。
あと、思いのほかディスプレイ内蔵のスピーカーの音がよいのも嬉しいおまけでした。リフレッシュレート100HzというのもGoodです。
ちなみに両ディスプレイとも「エルゴトロン LX デスクマウント モニターアーム」で支えています。
エルゴトロン LX デスクマウント モニターアーム マットブラック 45-241-224
- 発売日: 2019/06/20
- メディア: Personal Computers
こんな感じのダブルディスプレイ構成となり快適です。
BenQ ScreenBar Plus
モニターに掛けて使うデスクライトです。
これは本当にお勧めです。いい感じに角度の調整もでき本当にディスプレイに光が反射しません。そのためディスプレイは見やすく手元は明るいという環境が作れます。
明るさはもちろんのこと色味も白色~暖色と調整できます。これで手元で本を読むのもだいぶ快適になりました。
なお、このPlusというモデルは手元で明るさを調整できるちょっとしたリモコンの様なものがついてくるので手を伸ばすとすぐに明るさの調整ができるので便利です。
SONYヘッドホン WH-1000XM4
正統進化という感じでとてもよいヘッドホンです。
実はあまりオーバーヘッド型は好きではないのですが、この機種は長時間付けていてもそこまで頭への締め付け等の負担が少なく気に入っています。ノイズキャンセル性能も申し分ないです。充電がUSB-Cというのもポイントが高いです。
が、実は仕事中はこのヘッドホンは使っていなくて、iPhoneについてくるApple純正のイヤホンを使っています。なんやかんやでマイク性能もよくリモートミーティングに最適だと思っています。充電の心配もないですし。
このSONYのヘッドホンはプライベートで、仕事中はAppleのイヤホンで、という使い分けをすることでオンオフを切り替えています。
あまり聞きませんがオンとオフでヘッドホンを使い分けるのはこのリモートワーク環境下では割とお勧めなのでぜひお試し下さい。
パナソニック 電気ひざかけ「くるけっと」
パナソニック 電気ひざかけ「くるけっと」 洗える 125×93cm DC-H5-T
- 発売日: 2020/09/01
- メディア: -
冬場のデスク周りで最高のパフォーマンスを発揮しています。座っているときはひざ掛けとして、スタンディング時は腰回りに巻いて使っています。
電源を入れるとすぐに暖かくなり、しかもかなり暖かいです。これを導入してから本当に暖房を付ける頻度が下がりました。
しかも丸洗いできるので衛生面も安心です。
THE NORTH FACE 室内用シューズ Compact Moc
防寒用品ばかり続きます。なぜなら冷え性だからです。足先は本当に信じられないくらい冷たくなります。
登山用の靴下も導入しているのですがそれでも冷えるので試しに買ってみたらこれが大正解でした。
元々この製品は、テントや山小屋用のルームシューズなので保温性に優れています。そのため履いてしばらくたつとぽかぽかしてきます。
足下はこのシューズ、足下より上は電気ひざかけでカバーすることでだいぶ冬でも快適になりました。
Oura Ring
リング型のヘルストラッカーデバイスです。
もともとFitbitを使っていたのですが手首がかぶれるようになってしまいました。そこでリング型のOura Ringに切り替えました。
Fitbitに比べると見られる項目が少ないので若干不満はありますが、睡眠計測の精度も高く満足しています。また、防水なのもポイント高いです。
バルミューダ 電気ケトル
バルミューダ 電気ケトル ザ・ポット ブラック BALMUDA The Pot K02A-BK
- 発売日: 2016/10/21
- メディア:
家でコーヒーを飲む回数が上がったので購入しました。 私は、コーヒーマシンは使わずハンドドリップで入れる派なので、細口のケトルを使ってガスでお湯を沸かしてコーヒーをいれていました。このケトルは銅製でそれなりのいい値段がするものだったので愛着をもって使っていましたが、家で仕事しているとうっかり火をつけたままちょっとSlackのメッセージを返すつもりがそのまま集中してしまい火を消し忘れるといったことが何度か起きたりもしました。
いい加減いちいち火を止めるのがめんどくさくなり、もういっそ電気ケトルを買えばよいという結論に至りました。スイッチ入れておけば勝手にお湯が沸いてくれるので万が一そのまま仕事に集中してしまっても問題無いですからね。
ということで細口でデザインのよいこれを買いました。温度調整機能などはありませんがただスイッチを入れるという非常にシンプルな構造なので便利です。
ちなみにドリッパーはこれを使っています。
【Amazon.co.jp 限定】HARIO (ハリオ) コーヒードリッパー V60セラミック クラシックブラック 1~4杯用 VDC-02AZ-CB
- 発売日: 2019/06/03
- メディア: ホーム&キッチン
デジタル 温湿度計
dretec(ドリテック) 温湿度計 デジタル 温度計 湿度計 大画面 コンパクト O-271WT(ホワイト)
- メディア: ホーム&キッチン
ただ、温度と湿度を表示するだけのデバイスです。
家で仕事をする以上、環境の管理はしっかりしたいなと思い導入しました。
NETATMO ウェザーステーションも使っているのですがいちいちアプリで見るのも面倒なのでぱっと見で分かるこちらの商品を見える位置に置くようにしました。
りんご酢
会社の同僚に勧められて買ったらおいしかったのでリピートしています。
炭酸水で割って1日1杯飲むようにしています。健康になったような気になります。
なお、健康飲料という意味だと養命酒もお勧めします。りんご酢と養命酒のおかげかどうかはしりませんが、この1年風邪をひいていません。家族全員がインフルエンザにかかる中も生き延びました。
まとめ
今年はほぼWFHだったこともありふりかえるとやはりデスク周り系へ投資が多い1年でした。
私は前職から週2でリモートで働くという生活をそれなりに長く続けていたので割とデスク周りの装備は整っていましたが、本当に毎日家で仕事するとなるとちょっとアップデートさせたくなったのでそこに投資した形です。
なおガジェット系は他にも、iPhone 12 Pro MaxやApple Watch Series 5などを買っていますが惰性で毎年買い換えているので特に大きな感動はなかったです。
来年も経済を回していきたいと思います。
お題「#買って良かった2020 」
備忘録 : 意志決定関連情報メモ
ここのところ意志決定がうまくいっているのかいっていないのかよく分からなくなることが多くなってきたので基本に立ち返ろうと思ってWeb上でちょっと調べてみた。
参考になりそうな記事のリンクをまとめておく。
・人間の思考プロセスはしばしば過ちを導く、という事実を踏まえた上での意志決定の制度を高めるための7つのステップが紹介されている。
・サイモンの意志決定論関連
・意志決定をする際に気をつけるべきポイントが9つ書かれている。
・組織での意志決定のプロセスにおいて問題になりやすいポイントが書かれている。
・ひとまず読んでみようと思っている書籍
- 作者:長瀬 勝彦
- 発売日: 2008/09/05
- メディア: 単行本
ハーバード・ビジネス・レビュー意思決定論文ベスト10 意思決定の教科書
- 発売日: 2019/03/28
- メディア: 単行本(ソフトカバー)
- 作者:籠屋 邦夫
- 発売日: 1997/06/01
- メディア: 単行本
- 作者:ハーバート・A. サイモン
- 発売日: 2016/01/07
- メディア: 文庫
#builderscon 2019 参加レポート
今年もbuildersconに参加してきました。
参加したセッション内容のメモと簡単な所感、全体所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。
※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。
昨年と一昨年の参加レポートのリンク。
本編1日目
Open SKT: メルペイ開発の裏側 - builderscon tokyo 2019
資料: Open SKT: メルペイ開発の裏側 / builderscon tokyo 2019 Open SKT : Speaker Deck
内容
- 決済はお金のトランザクション管理が難しい
- SKTってなに?
- Super Kazegusuri Time
- オンボーディングも兼ねた社員研修
- 目標やポリシー、アーキテクチャ、開発体制、開発手法を伝える場
- メルペイの開発で重視していること
- インフラのように安定して信頼できるシステム
- サービス開発をメインにしない
- アーキテクチャ
- 分散システムにおけるトランザクション
- 難しい
- 中央で一元管理する方向に
- エラー処理も含めたモデルの一般化が必須
- エラー処理を例外として扱わない
- お金のモデルは全て状態遷移モデルを定義している
- 引き算はいきなり確定させるとキャンセル時など不都合が生じる
- いったん確保、その後に確定する
- 不正検知
- 開発フロー自体はメルカリと共通だが多少違いがある
- 業界全体のレベルをあげるために事例をどんどん公開していきたい
所感
メルペイのシステムアーキテクチャ、決済サービスの難しいところ、メルカリとの開発体制の違いなどが語られたセッションでした。
お金を扱うという特性から信頼できるインフラとなるようなシステムにするために、コストをかけてもより安全に開発していくという信念がとても伝わってくる内容でした。
サービスの安定性の指標としてSLOを重視するという話がありましたが値の設定とそれの運用はとても難しそうだと思いました。SLOをどのように設定し、どのようにアップデートしていくかの知見を今後是非聞いてみたいですね。
Android Architecture Componentを使って、改善・効率化するAndroidアプリ開発 - builderscon tokyo 2019
資料: まだ未公開?
内容
- 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の改善に繋がった
- RealmからRoomへ
所感
Android Architecture Componentの概要とWontedly PeopleのAndroidアプリでどのように使っているのかが語られたセッションでした。
最近Android開発に関する情報はあまりちゃんと追っていなかったのでいろいろと知れました。公式でこれだけ用意されている状況なので、新規でAndroidアプリを開発するときはまずは公式のものを使ってどこまでできるかを考えて、それでまかないきれないものに対して他のライブラリを使うかどうか検討していくのが良さそうだと思いました。
Android Architecture Componentはいきなり全部入れないで自分たちに必要なものを徐々に入れていけるので、今回の発表の例のように既存の実装を置きかえていきやすいのもGoodですね。
WebAuthn/FIDOのUX徹底解説 ~実サービスへの導入イメージを添えて~ - builderscon tokyo 2019
資料: WebAuthn/FIDOのUX徹底解説 ~実サービスへの導入イメージを添えて~ / builderscon tokyo 2019 ritou : Speaker Deck
内容
- パスワード認証にはさまざまな問題がある
- ワンタイムパスワード認証
- 結局はユーザーが入力する必要がある
- FIDO
- ローカル認証を利用
- 公開鍵暗号方式を用いた登録と認証
- FIDOのユースケース
- パスワードレス認証として(所持+ローカル認証)
- 追加認証として(所持)
- FIDO 2
- WebアプリからもFIDO
- WebAuthn
- FIDOを利用するサービス側が呼び出す
- CTAP
- セキュリティキーとやり取りするための仕様、ブラウザが実装
- WebAuthnのフィッシング耐性
- origin単位で鍵ペアを生成しているのでそもそもフィッシングサイトにログインできない
- WebAuthnのUX
- Q&A: Authenticator自体が脆弱性を持っている場合もあるのでは?
所感
WebAuthnの認証フローを実際に実装しているサービスの認証画面を元に説明してくれるセッションだったのでとても分かりやすかったです。
WebAuthnを使っているといっても思ったよりサービスごとにフローがバラバラで分かりづらい状況ということが理解できました。ITリテラシに疎い人からしたら現状この仕組みはかなり難しい気がします。今まではAuthenticatorの普及だけが問題だと思っていましたが、それだけでなくこのあたりのフローも業界内である程度統一できないとなかなか普及は難しそうだと感じました。
ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ - builderscon tokyo 2019
資料: ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon : Speaker Deck
内容
- SoRとSoEを各設計原則や設計パターンをベースに言語化したかった
- モデルとは何か
- SoRとSoEでは扱うモデルが違う
- 解決した問題領域から必要と思われる情報を抽出して記号化、可視化したもの
- どのようなモデルが有効化は対象とする領域に依存する
- E-コマースサービスで考えると
- CQRSとの関係
- SoR/SoEという分類とCommand、Queryの非対称性に着目した分離は共通している部分が多いのでは?
- SoR/SoEの実践
所感
モール型のE-コマースサービスを例にして、アクターの分け方やSoRとSoEのシステム間連携をどのような考えで行うかが説明されたセッションでした。DDD本とClean Architecture本をあらためて読み直して考えたくなるような内容でした。
SoRとSoEって確かにバズワードっぽい感じになっている感じもするのでこうやってきちんと設計に落とし込んで考えられるようにするというのは非常に大事なことだと思います。
「B2BがSoRで、B2CがSoEなのか?」のような質問があった気がしますが(うまく聞き取れなかったので違っていたらすいません)、そういう区分ではないと思っています。B2B、B2CのシステムそれぞれにSoE、SoRの分類があると考えます。今回の発表にもあったようにアクターで分けて考えればそれは自明だと思います。そういう意味でもこの発表の内容はとても分かりやすかったです。
本編2日目
レガシーサーバーを現代の技術で再構築する - builderscon tokyo 2019
資料: レガシーサーバーを現代の技術で再構築する/builderscon2019 : Speaker Deck
内容
- SVNとかRedmineなどがのった古いサーバーを何とかする話
- やらないことを決める
- URLは維持する
- マネージドサービスを使っていく
- 4年おきくらいに一応再構築はしていた
- レンタルサーバー → オンプレ → EC2
- 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さんから返事を頂いたので貼っておきます。
hash化はされているのと、リポジトリやS3の権限を絞ってるのでEC2にログインして見られるのと同等の公開範囲にはなってます。ランダム発行したパスワードしか付与してない(ユーザに決めさせてない)というのもあり、許容範囲かなと思ってはいます(が、なくしたいですね
— fujiwara (@fujiwara) August 31, 2019
スーパーカミオカンデの開発と運用 - builderscon tokyo 2019
資料 : Introduction to Super-Kamiokande for geeks(?)
内容
- クオークはアップクオークとダウンクオークがある
- こいつらがいると世の中のもの全部作れちゃう
- クオークとレプトンはそれぞれ3世代ある
- なぜ3世代かは誰も分からない
- 陽子は10の80乗年後に壊れると言われている
- ニュートリノはありふれた粒子、重さはほぼない
- 太陽はたくさんニュートリノを作っている
- 地球の中心からもニュートリノは来ている
- チェレンコフ光の輪っかを見るとどこから来ているか分かる
- チェレンコフ光は一瞬しかでない
- スーパーノバでニュートリノが大量の放出される
- ベテルギウスがスーパーノバになったらヤバい量のニュートリノが放出される
- スーパーカミオカンデの光電子倍増管(デカい電球みたいなやつ)は機械で作れないから人が作っている
- データ取得のためのシステムのインフラ
- スイッチはQoSが切れるものを選ぶ
- ケーブルの長さが1m違うと5ns変わっちゃう
- 全てのデータを取っておかないといけない
- CPUはTotal2212コア
- 計算にはFortran使っている、新しいのはC/C++
- ソースコード管理はSubversion
- ハイパーカミオカンデを建設予定。2027年には観測開始できる予定
所感
本当に初めて聞くような内容でした。まさに知らない世界。でも発表もテンポがよくとても楽しく聞かせていただきました。
前半は量子力学的な話、後半はデータ取得/保存のためのIT寄りの話でした。
こういう世界でもインフラ周りやソースコード管理などで考えないといけないことは割と同じ感じで「おーこういう分野の仕事や研究においても今やってる知識って使えるんだ」と思いました。まあでてくる単位の桁は違いましたけど。
入門サービスメッシュ - builderscon tokyo 2019
資料 : 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
- Control Planeは自分で用意する必要がある
- Linkerd v2はProxy、Control Plane両方持ってる
- サービスメッシュ選球眼
- 自分たちの規模を見据える
- 大規模になるなら分散化が重要、高度に分散化した環境では通信層での仕事は必須
- 自分たちの環境を分析してソフトウエアを選ぶ
- 自分たちのやりたいこととIstioでできることの差分は?などを考える
- 自分たちの規模を見据える
- Service Mesh is not for Kubernetes only
- ただし、ハイブリッドクラウド環境などで使える製品はほとんどないし事例も少ないので頑張りが必要
所感
サービスメッシュ登場の背景や考え方をざっと学べるセッションでした。
コンテナ技術の流行から出てきた概念だと思っていたのですがそんなことはなくそれより前からあった概念だということに驚きました。「Service Mesh is not for Kubernetes only」という言葉は今まではサービスメッシュ=コンテナで使うものという思考しかなかったので考えを柔軟にするいいきっかけになりました。
もしもハッカーの「サイバー攻撃日誌」が読めたら - builderscon tokyo 2019
資料 : 公開なし
内容
- Red Teamサービスとは
- 攻撃例のケーススタディ
- SNS使って従業員の情報集めてメール送信
- 権限昇格させる
- SYSTEM権限で動作するサービスのEXEを置きかえ
- パスワードハッシュの取得
- ローカルアカウントのハッシュダンプを取得し解析
- IT管理者の特定
- 座先表や社員番号、機器番号等が載っているファイル等を探して推測
- 横断的侵害
- 取得済みアカウントによるリモートコマンドの実行
- ドメイン管理者アカウントの取得
- Mimikatz: メモリ上の認証情報を取得
- ドメインコントローラーに侵入
- 全ユーザーのパスワードハッシュを取得、解析
- これを使ってWebメールにアクセス、システム構成図などを探す
- 2要素認証が設定されているとここで詰まるので対応策を考える
- ユーザーの端末はもうのっとっているので2要素を突破しているユーザーの端末経由で入り込む
- ユーザーがお昼などで席を外している間にRDPで入り込んで操作
- 防御側が理解しておくべき事
- 検知の仕組み
- 後から分析できる仕組み
- 危険度を判断できるスキル
- 初動、情報共有が早いと侵入に苦労する
- Hardening projectで練習できる
- 各チームにECサイトが与えられ主催者がひたすら攻撃、それを守る
- わざわざそこまでやるやつはいないだろうと誰かが言うたびにわざわざそこまでやるやつが現れる
- QA: Macの場合はやはり大変なのか?
- ADに参加していない場合も多く、マシン単体で動作していることが多いので他のマシンに攻撃を展開していきづらい
- QA : 秘密の質問とかがあるだけでも侵入しづらいって思ったりするのか?
- たいがいマイドキュメントとかにメモがあるので侵入が難しくなることはない。2要素認証だと本当にやりづらい。
所感
ここまで詳細な攻撃方法を聞けるとは思っていなかったのでとても面白かったです。個人的には今年のベストセッションでした。攻撃のケーススタディはずっとなるほどー!という声を口に出してしまっていました。
やはり2要素認証は使える場合は使うべきってことがはっきりしました。なぜか使わないという謎の選択を過去実際に見てきたのでこのセッションをそのときの関係者に見せたくて仕方なくなりました。
あとは、検知の仕組みをきちんと整えて対応できるようにすることもあらためて大事だと思い知らされました。本気で攻撃されたらやられるときはやられるので、いかに早く反応できるかが勝負になってきますからね。
全体所感
3年連続で参加していますが、本当に毎回知らないことを聞くことができるカンファレンスです。
特に今回は、スーパーカミオカンデのセッションともしもハッカーの「サイバー攻撃日誌」が読めたらのセッションの2つに感銘を受けました。まだまだ自分の知らない世界はたくさんありますな。
会場はいつもの慶応日吉キャンパスではなく北千住の東京電機大学のキャンパスでの開催でしたが、ベンチなども割と多くてちょっと休憩することも日吉よりはできたので快適でした。
運営の皆様、発表者の皆様、参加者の皆様、楽しいカンファレンスをありがとうございました!今年も本当に刺激を受けました!
(おまけ)運営フィードバック
最後に運営面で気づいた点をメモ。
Regional Scrum Gathering Tokyo 2019参加レポート
Regional Scrum Gathering Tokyo 2019に参加してきました。
昨年に続けて2度目の参加です。
去年の参加報告はこちらです。
参加したセッションで印象に残ったことと簡単な所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。
※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。
3日分まとめて書いたらなかなかの分量になってしまったので以下の目次から気になるものをピックアップしてご覧下さい。
Day1
Outcome Delivery: delivering what matters
資料 : なし
印象に残ったこと
- Whyがはっきりしていないと問題が生じる
- たくさんのフレームワークやプラクティスがある
- Deloit The Agile Landscape v3
- 全然シンプルじゃない...
- 私たちは本当に早くより多くの機能が欲しいのか?それても重要な成果が欲しいのか?
- メビウスループ
- Outcome Delivery | Outcomes over Outputs
- 発見とデリバリーのバランス
- 左側はデザイン思考的なループでWhyを求めるもの、右側のループはアジャイル思考的なループで素早く機能を作っていくループ
- すべてはバランス
- ディスカバリーバランス、オプションピボット、デリバリーループ
- Whyを定義し、オプション(手段)を選択し、デリバリーして計測して学ぶ、オプション(手段)を選択し...これを回す
- 選択するプラクティスは何でもよい、成果を出すのが大事
- オプション(手段)はやってみないと分からない → だからこと計測が大事
- 計測が我々の行動をドライブする
- 計測するのが難しくても計測できるような仕組みを時間をかけて作っていくのが大事
所感
最初に最高のコーヒーとは何か?最高のコーヒー体験とは何か?なぜコーヒーを朝飲んだのか?を突き詰めるワークショップを行ってWhyを掘り下げることを体感させてからのセッションだったので内容がすんなりと入ってきました。
プラクティスは確かにいろいろありますが、効果や使い方を理解して正しく使うことが大事だなと思いました。プラクティスをただやってみたいだけな人にはならないようにしないとですね。
今、目の前にある問題へ対応するために最善のプラクティスを選べるように引き出しは増やしたいものです。
Whyを意識して問題を正しく理解する、解決のためのプラクティスを選択する、実行して計測する。ダメなら別のプラクティスを選択〜とループを回していく。このサイクルを意識していきたいです。
また、問題を定義するときに使っていた、「Frame the Problem」のフォーマットは使ってみたいなと思いました。Problem、Context、Impact、Causeを書くフォーマットで問題がうまく整理されそうでした。
Coaching resilient Scrum teams
資料 : なし
印象に残ったこと
- Vodafoneでの大規模アジャイル導入的な話
- 変化には時間がかかる
- アジャイル推進組織を人事部の下においた
- 最初の1か月はつらかった
- Coaching Compass
- Resilience
- 弾力性のある、適応性のあるみたないこと
- これを実現するには精神的に安全な環境でなければならない
- これができるとfailファースト、実験的なことができるマインドセットがうまれる
- プラクティスMap
- 土壌を作る
- 最初から何か理想のモデルを与えるのではなく、自分たちから自分たちに合ったものが産まれるようにする
- 会社はエコシステム
- プロセスと文化によってできている
- 非公式なネットワークを作る
- インフォーマルなミーティングを大事にしている
- よいアイデアなどはたいていここからうまれる
- 組織は生き物
- アジャイルは組織からうまれる
- どのようにコミュニケーションするのかが大事
所感
Vodafoneでの組織的なアジャイル導入の話でした。
Coaching Compassで社内のチームをマッピングして、それにより対応方法を分けるという考えはなかなか面白かったです。今まさに全社規模でのアジャイルの普及的なことを少し考え始めているのでこうやってうまく社内のプロジェクトをマッピングして対応方法を分けて考えていくというのは使えそうだと思いました。
さらっとお話しされていましたがこれめちゃくちゃ大変で根気がいる取り組みだったろうなと感じました。組織という生き物とうまく向き合っていくための希望をもらった気がします。Resilienceな組織作りを意識していきたいですね。
行動分析学に基づくScrumの導入
資料 : 行動分析学に基づくScrumの導入
印象に残ったこと
- 行動分析学をもとにスクラムの習得さの困難さのヒントになれば的な話
- スクラムの習得が困難な理由
- It dependsだから(状況によるものが多いから)
- 個人、組織、プロダクト、プロダクトの状態はそれぞれ異なるから
- 状況を考慮して理想を探索する手法として行動分析学が使えるかも
- It dependsだから(状況によるものが多いから)
- 行動分析学とは
- 行動分析学を使ったスクラム
所感
スクラム関係なく、チームや組織をよくしていきたいと思っている人は行動分析学を学んだ方がよさそうだと強く思いました。きちんと学問になっているものはやっぱちゃんと抑えておかないとダメですね。行動分析学に関する本をひとまずいくつか読んでみようと思います。
ひとまずこれを買いました。
- 作者: 舞田竜宣,杉山尚子
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2008/12/17
- メディア: 単行本
- 購入: 4人 クリック: 57回
- この商品を含むブログ (25件) を見る
ちゃんとやってるのになんかうまくいかないスクラムからの脱出
資料 : #RSGT2019 ちゃんとやってるのに なんかうまくいかないスクラム からの脱出 - Speaker Deck
印象に残ったこと
- ちゃんとやっているのになんかうまくいかない
- 増えるミーティング、終わらないタスク、ギクシャクする関係性
- このチームに対してやったこと
- エンジンに再点火
- レトロスペクティブが形骸化していたので感謝と対話を中心にした
- Webツールで事前に書いておくことをやめて付箋を使って本人の言葉で意見を出すように
- レトロスペクティブが形骸化していたので感謝と対話を中心にした
- 一本道
- 全員バラバラに動いていたのでタスクを一本に並べた
- 重要さに順位付け、アサインしない。個人の課題からチームの課題に
- 全員バラバラに動いていたのでタスクを一本に並べた
- パーティを組む
- 知識に隔たりがあるなどの理由からコードレビューにかかる時間が読めない
- モブワークして全員で取り組むように
- 知識に隔たりがあるなどの理由からコードレビューにかかる時間が読めない
- だったならつかってもいい
- 突発対応があると後半がくるしくなっていた
- 前回こうだったかた計画をつくる。突発があったことを前提に
- 突発対応があると後半がくるしくなっていた
- 立て看板
- スプリントの目標を立てることで現在地の共通認識をもつように
- ユーザー登録機能の実装完了、みたいにプロデューサーでも分かる名前にした
- スプリントの目標を立てることで現在地の共通認識をもつように
- 荷下ろし
- テックリードが1人で抱えすぎていたので大丈夫だよと伝えた
- できていないことを数えるのではなくできていることを一緒に数えた
- できるだけメンバーを頼るように
- テックリードが1人で抱えすぎていたので大丈夫だよと伝えた
- 3段階の地図
- エンジンに再点火
- 期待はスクラムと相性が悪い
- 期待と違う現実を見せてくれるのがスクラム
- 期待を土台にしていると現実から目をそらしてしまう
- スクラムを現実の上で回し始めた
- 現実を受け入れて乗り越えていくチームに
- 油断せずに変わり続ける現実を受け止め続ける
- スクラムと違う部分に注意が必要
- その部分にこれまでの経験(期待)が入り込みやすい
- ちゃんとやっているのになんかうまくいっていないのはよい状態
- ちゃんとやっているから、ちゃんと失敗して、ちゃんと悩んでいる
所感
当たり前のことを当たり前にやることの大切さとその難しさを改めて実感できるセッションでした。セオリーは分かっていてもいざやろうとすると難しくて心が折れそうになることが多々あります。それを1つずつ着実に適応していったんだなあ、すごいなあと思いました。
特に荷下ろしの部分はすぐにでも真似したいなと思いました。抱え込みすぎているメンバーのできていないことを数えるのではなくできていることを一緒に数えるというやつです。自分がこの対応してもらったら絶対嬉しいのでメンバーにもやってあげたいです。
超Scrum入門〜未完成フラクタルと15minSprint〜
資料 : 超Scrum入門〜未完成フラクタルと15minSprint〜 #RSGT2019 - Speaker Deck
印象に残ったこと
- 人間であることをやめる、人間だと思っているからうまくいかない
- 30minスプリントは簡単、15minでもできるのでは?
- 短時間スプリントはモブ/ペア/ソロの強制切り替えタイミング
- 生き生きとしたチームとは?
- うまくいったらどうなるの?
- シロアリの蟻塚には設計図はない、小さいルールだけで成り立っている
- 進化としての余地を残した未完成なフラクタルがもっとも強いのでは?
- まだ見つからない
- Krebs Cycle of Creativity
- Art、Design、Science、Engineering
- Neri Oxman’s Krebs Cycle of Creativity – MIT Spectrum
- 目的のない行動もあるから美しく生き生きしている
- 基盤チームはスプリントという目的だけをしていた
- フラクタルスプリント
- ビジネス目的のスプリントを3回やったら、非ビジネス目的のスプリントを1回やる、みたいな
- 自然な改善、自然なチームに
- 人間をやめようとしたはずが人間らしく生き生きしてきた
- 学生や新人はこういうことを最初からできる
- 玄人はUnlearnしなければならない
- 学生は1Dayスプリントを5日でできる、チームが習得するには180日かかった
- Unlearnする時間をそもそも短くするような組織作りが大事
- 生物の歴史をチームや組織で仕組み化する → これが行きついた何か
- 楽しくうまくできるまで突き詰めるのが大事
所感
自分では絶対にたどり着かない考えをいろいろと聞けて時間が一瞬で過ぎたセッションでした。きょんさんすごいなあ。
楽しくうまくできるまで突き詰めるという気持ちは他の何ものよりも大事にしていきたいです。楽しければつらいと感じることも少なく継続できますからね。
あと、Unlearnのところも印象に残りました。Unlearnしなければいけないことはやはりどうしても出てきてしまうものだと思います。
つまり、逃げることはできないものです。これを起きないようにするのではなく起きて必然のものと捉え、Unlearnする時間をそもそも短くするような組織作りする必要があると私は捉えました。
速くUnlearnできる組織って何?そういった組織になるため必要なことは何?ということを考えていきたいと思います。
Day2
Learning to Experiment
資料 : なし
印象に残ったこと
- 緊急事態や大事故が起こるまでプロセス改善などの変化が起きない
- 茹でガエルになってしまう
- なぜ緊急事態が起こるまでやらないのか?
- どうやって実験を学ぶか?
- 心理的安全性を確保するのが大事
- 失敗するリスクの高い実験こそが学習を最大化する
- 実験が成功すると思い込むような状況になってはいけない
- 実験が必ず上手くいくと思い込む人がいるが、そうではない。実験が失敗せず成功ばかりの場合、自己満足に陥っている可能性がある
- レトロスペクティブ
- 反復するループができる
- 継続的な改善のプロセス
- マイクロレトロスペクティブを45分に1回やるチームもある
- モブプログラミングの始まり
- 助けて下さいのひと言から始まった
- フラットな組織構造
- マネージャーがいない
- 階層構造の問題無くコミュニケーションができるように
- 悪い習慣を取り除くには?
- この仕組みを見つけることが大事
- 始めるよりやめることの方が難しい
- 目標に対する反復実験
- 想定外の実験
- 4人のプロダクトオーナーの話
- いつも一緒、1日1回は顔を出す、週に1回は顔を出す、月に1回は顔を出す
- ミーティングにかける時間数を出した
- 1か月に1回のPOのチームはミーティングの時間が長かった
- POが来ないからメンバーで議論する時間が多くなった
- 1か月に1回のPOのチームはミーティングの時間が長かった
- サティアの変化モデルは無視される
- 4人のプロダクトオーナーの話
- ビジネス全体のレトロスペクティブ
- 隣の芝生は青くみえるだけ
- 大きな変化をいきなりやらないように小さくやる
- 自己満足に陥らないようにする
- 全員参加と共同責任
- 手柄を皆で分ける
- 同僚が手柄を盗まないという信頼感が大事
- イノベーション普及理論
- やさしさ、気遣い、尊敬
- これをグランドルールとした
- Vulnerability、Trust、Appreciation
- コードと本番の間に人を入れない
- 誰でもいつでも休暇を取れる状況は心理的安全性が高いと言える
- 開発者がコミュニケーション能力を高めるのは意味がある
- それにより避けられる問題も多々ある
- 見積もりをやめる
所感
実験を繰り返そう!を強く訴え、それが組織にとってどう影響を与えるかというセッションでした。正直内容盛りだくさんでちょっと消化不良気味になりました...
ということで、上記の印象に残ったことはぶっちゃけ取ったメモを整形せずほぼそのまま貼り付けていますw キーワードだけでも後で振り返れると思うので。
とはいえ、学びが非常に多かったです。
何かを試すときは上手くいくと思い込む人が出てくるというのは確かになあと。失敗することもあるから実験なわけで、毎回うまくいっているならそれは単なる自己満足であると。おっしゃるとおりでございます。これは陥りがちなので注意していきたいです。
見積もりが必要ないという話は衝撃的でしたが、結局は見積もりがなくてもうまく回るような組織作りが実験を繰り返すことでできたからこそなんでしょうね。それなしにいきなり見積もりなしはうまくいかないと思うので、「よし、うちも次から見積もりなしでいくぞ!」なんて間違っても思ってはいけないと思います。
手柄を皆で分け同僚が手柄を盗まないという信頼感があるチームというのはどう考えても強いチームなのでこういう状態にするにはどうしたらよいかを考え続けていきたいです。これがないと実験を繰り返しても効果が出ないことになってしまうと思いますので。
Effective Retrospective / とにかく楽しいふりかえり
資料 : Effective Retrospective とにかく楽しいふりかえり - Speaker Deck
印象に残ったこと
- 振り返りは楽しく感じると効果的と感じやすい
- 今日は振り返りのWhy、Whatを中心に話す。Howはうまくいけば何でもよいと考えている
- ふりかえりとは
- 前向きな活動
- 楽しい気持ちの方がよいアイデアがでる
- ふりかえりの3ステップ
- 立ち止まる
- 走り続けると視野が狭くなる、そのために立ち止まって視野を広げる
- みんなで立ち止まる必要がある
- 忙しいからふりかえりをスキップしようってなったら立ち止まることの意義をちゃんと伝える
- チームを成長させる
- プロセスの改善
- 失敗は繰り返さないように、成功を何度も続けられるように
- 改善・・・問題点を直す
- カイゼン・・・問題がなかったとしても仕事のやり方を継続的によくしていく
- 問題をすべて解消する必要は無い
- コアの問題を探す
- 関係の質が高まっていれば問題を共有するだけでコミュニケーションにより解決することも
- 自己承認と他己承認
- 自己承認がうまくなると他己承認につながる
- 他己承認しあうのは正のループ
- 立ち止まる
- 楽しいふりかえりを構成する3つの要素
所感
ふりかえりに必要なことが網羅的にまとめて説明されていてとても学びのあるセッションでした。ふりかえりを行う前にこの資料は定期的に読み直したいです。
そしてプレゼンがめちゃくちゃうまいと思いました。話す速度、ふるまいなど場づくりってこうやるんだなあというのがプレゼンする姿からも学べました。
説明されていたことをいろいろ実践していくのはもちろんのこと、ふりかえり時の自分の振る舞いも意識するようにしていくようにしようと思います。楽しい気持ちでふりかえりしたいのに、ファシリテーターが楽しくなさそうなのでは元も子もないですからね。あとは議論と対話の違いは意識していきたいです。
全部SCRUM!~SIerで大切だったもの、サービサーで大切だったもの~
資料 : [RSGT2019]全部スクラム!~SIerで大切だったこと、サービサーで大切だったこと~
印象に残ったこと
- SIerでのスクラム
- サービサーでのScrum
- よかったこと
- 自分たちで決めたから施策がみんなのものになった
- 価値駆動ベース、攻めのScrum
- よかったこと
- SIerでもScrumはできる
- SIerじゃできないというのはウソ
- ただし、攻めのScrumではなく守りのScrumになる
- Scrumの適用はものづくり部分だけといった限定的なものではない
所感
SIerとサービサー、両方とも実際に経験した話をベースに話されていて興味深かったです。
SIerだからScrumは難しい、できないと決めつけるのは本当に良くないことだなあと思いました。それこそ思考停止です。
できる範囲の中で、守りのScrumという定義をしてしっかり道を切り開いていくという考えはとても参考になりました。
そのときサーバントリーダーはどう振る舞うか
資料 : そのときサーバントリーダーはどう振る舞うか - Speaker Deck
印象に残ったこと
- サーバントリーダーシップの実践を始めるまでにやったこと
- いろいろ本を読んだ
- 印象に残ったフレーズと自身のふりかえり
- あなたは何をしようとしているのですか?
- 何の組織?に答えられない
- 耳を澄まし、理解すること
- 立場を越えた本音を聞けている気がしない
- 信頼し、信頼されること
- 信頼が伝わっているか分からない
- 信頼されているだけのアウトプットを見せられているのか?
- 会社組織の上下はしたがうものの信任で得られるわけでは無い
- なぜ自分が部長の立場を受けたか伝えていない、自分でも整理できていない
- あなたは何をしようとしているのですか?
- 読みながら何が大事か書き出すのが大事
- 正直に自分を分析するのが大事
- やってみたこと
- ビジョンづくりと提示
- 感謝を言葉に
- 日本人は言葉で言わない人が多い
- ちょっといいですか?をいいやすく
- トラブル解決と社内調整を率先する
- 理解と信頼
- 傾聴、共感、癒やし、納得
- 繰り返して関係性の深度を高めること
- ビジョン作成のポイント
- 概念化、先見力
- 言いたいことを並べるのではない、分かりやすくて過去から未来を導くものを
- やってみたV2(繰り返し、繰り返し以下を行った)
- ビジョンを分かりやすく
- 挨拶と雑談は自分から
- やりたいことの把握と後押し
- わかりやすいKPIで握る、こまめに報告する
- トラブル解決と社内調整に同席してもらう
- 変わってきたこと
- 上司
- 心配が減り細かいことを言わないようになった
- 上司が期待する組織のイメージを共有できた
- 配下のマネージャー
- 1on1などでメンバーの話が増えた
- 成長したいポイントを理解できるようになった
- メンバー
- プロジェクトの目的と結果、成果を語れるように
- あいさつが増えた、個人的な話の報告も増えた
- 全体的に安心感がお互いに生まれた
- 上司
- 組織成果
- トラブル削減
- リリース数が増加
- 採用数が増加
- 成果をチームで出してくれるようになった、帰属意識が高まった、組織を考えて動いてくれるようになった
- 課題
- 主体性をどうしても持てないメンバーがまだいる
- さらに会話をする
- 組織の色がでて、合う、合わないが出てきてしまう
- 大きな問題では無い、合わない人が自分の意思で出て行くのはよいこと
- 主体性をどうしても持てないメンバーがまだいる
- 思いはシンプル、ブレないことを繰り返す
- ふりかえるとただの人間関係構築の話でしかない
所感
サーバントリーダーとは何か?という話はとてもよく見ますが、実践した経験とそこから出た課題を聞くのは初めてだったのでとても参考になりました。
実際に、帰属意識が高まって組織を考えて動いてくれるメンバーが増えたなどの成果に繋がっているようで本当に素晴らしいです。
あと印象に残ったのは組織に色が出てくるとどうしても合わない人もでてきてしまうという話です。これを問題と捉えずに、合わない人が出てくるのはしょうがないことだと考える発想はなるほどなと思いました。
合わない人が出るとどうやって馴染んでもらおうと考え胃が痛くなる経験をしたことがあるのでかなりはっとさせられました。
確かにそういう人に無理に順応してもらうより、自分で今の組織には合わないと悟ってもらってより活躍できる場所を探す方が本人の為になりますからね。
学習する/Unlearnするチームへ ー 新卒研修とスクラムとモブプログラミング ー
資料 : 学習する/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については以下をみるとどんなものか把握できます。色々な立場やバックグラウンドの方といろいろな意見ができてとても刺激的でした。
心理的安全性あるとき~ないとき~
会議で上司が何もしゃべらないとき、なんかテンションが低いなどいくつか心理的安全性がないなーと感じる場面について議論がありました。
しゃべらない上司にはあえて「どう思いますか?」みたいな質問しちゃうのはどうですか?という意見を出しましたが、その発言をするための心理的安全性がそもそもない!となり「確かにそうだよねー」みたいな話をしました。
一番掘り下げたディスカッションが起きたのはスクラムが失敗し続けていると指摘されたときという話題でした。上司はスクラムの成功体験はあるのか?何と比べて失敗していると言っているのか?などなどいろいろな意見が飛び交いました。残業が常態化しているという話にも繋がってとても面白かったです。
関西の方なら必ず知っているという「あるとき~ないとき~」の元ネタ知らなくてすんませんでした。
業務委託さんにプロダクト思考を持ってもらうには?
大きく分けて契約によるもの、愛着や主体性によるもの、マインドによるものという観点で色々な意見交換をしました。業務委託する側、される側どちらの意見も出たことでよいディスカッションができたと思います。
愛着や主体性、マインドなんかもよくよく考えると全部契約に起因するんじゃないかと個人的には思いました。契約条件やNDAになんかうまいこと書いて業務委託する側もされる側も対等な関係作りができるようなハックがないか考えたいなと思いました。
よなよなエール流 熱狂を生むチームづくり ~8年連続赤字から13年連続増収増益までの軌跡~
資料 : なし
印象に残ったこと
- どん底を見て思った
- ファンや残った社員を見捨てることはできない
- この会社に人生をかける決意
- 差別化戦略〜プロモーション〜
- 戦略
- 超宴
- やると赤字、しかし参加者は盛り上がる
- 短期の売り上げを捨てて、そのときのお客さんの熱狂をとるというトレードオフ
- 最初は少人数でやって小さな経験を積み上げる
- 中長期的に見れば参加してくれた人はきっとファンになって売り上げにつながるだろうという考え
- 突き抜けた個性は賛否両論を生み出し熱狂的ファンを生む
- チーム作りの話
- 一見売り上げに繋がらないような取り組みは顧客の心に入りやすい
- 最初から売ろうと思っていない、顧客に楽しんでもらおうと思っている
- 後から売り上げがついてくる
- この勇気をもてるか?
- 変わり者でもよい
所感
RSGT 2019の最後にふさわしいセッションでした。アツかった。
会社が楽しい、社員が楽しんでいるという状態をここまで社長自らが表している企業が他にあるでしょうか。
トレードオフの話がとても刺さりました。極端なトレードオフを選択し続けるということが果たして自分にできるだろうか?一報の選択を捨て続けることが果たしてできるだろうか?これは今年の自分のテーマの1つとして考え続けていきたいです。
チームの作り方も全員を無理矢理引きずり込むのではなく、熱意のある人から広げ徐々に浸透させていくという方法も素敵でした。当たり前といえば当たり前なのですがやはり成功の裏にはこういうった当たり前のことを地道に続けるしか無いということを再認識できました。
本当に力をもらえるセッションでした。
ちなみに、ヤッホーブルーイング再生の話はこの本に詳しく書いてあるそうですのでぜひ。
- 作者: 井手直行
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2016/04/08
- メディア: 単行本
- この商品を含むブログを見る
全体所感
去年に引き続いての参加ですが相変わらず最高のイベントでした。参加することで1年頑張れる力がもらえます。そういう意味でも年明けすぐにあるのは最高ですね。
誰とでも気軽に話せて意見交換できる雰囲気のイベントって本当になかなかないので普通のイベントの何十倍も学びがあります。その分、疲労もハンパないですが...もちろんよい意味での疲労です。
この雰囲気を作れる運営の皆様は本当にすごいと思います。
学びがたくさんありましたがその中でも今年は以下を意識していきたいと思います。この辺りの経験で何か得たらどこかで還元したいですね。
- 計測は大事、必ず計測できる方法を考える
- 何をやるにも心理的安全性は大前提
- つまり組織の成功循環モデルでいう、関係の質を高めることがとても重要
- 実験を繰り返すのは大事、それができる状態をいかにつくるか考える
- Unlearnすべきもの、積み重ねた経験を活かした方がよいものを判断できるようになる
- UnlearnするときはUnlearnする速度を上げられる状態を作れるようにする
- 当たり前を当たり前に地道に繰り返す、続ける
運営の皆様、発表者の皆様、参加者の皆様、本当にありがとうございました!来年も参加します!
参考
builderscon 2018に参加してきた
今年もbuildersconに参加してきました。
参加したセッション内容のメモと簡単な所感、全体所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。
※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。
去年の感想。
- 全体所感
- 本編1日目
- 本編2日目
- 「Web とは何か?」 - あるいは「Web を Web たらしめるものは何か?」 - Idea of Web
- 証券トレーディング業務におけるExcel依存を脱却するプロジェクトで直面した技術的選択とプロジェクト運営の失敗
- なぜエンジニアはパフォーマンス計測しないのか
- 業務時間で書いたパッチは誰のもの? OSS 活動にまつわる罠
- なぜ私はキーボードを作るのか
- LT
- キーボードをカスタムしてプログラミング環境を良くした話
- スーパーファミコン開発ことはじめ
- Micorservices-friendly data pipeline
- WebReplayから見るWeb開発の未来
- チームでテストを書くために
- capanfileがRubyパースできることに気づいた俺たちは
- こんな現場でやってられるか
- 5分でフォトブース
- Development Tools for Next Generation
- アップデートばかりしている言い訳をさせてくれ
- 登壇やLTを始めてみたい」方の背中を押してみたい
- iOSDC Japanを本物のインターネットを提供した話
- Node.jsでCloudFormationのテンプレートを分割して管理する
- ネットワーク障害を支配したい話
全体所感
メモが長いので全体所感を先に。
今年も「知らなかった、を聞く」が実現されている素晴らしいカンファレンスでした。色んな文化の人が出会える素敵な場です。
本当に色んな内容の話がありどのコマもどれを聞こうかという悩みが発生します。ゲストスピーカーも豪華ですしまさにフェスだと思います。
ここのところ業務であまり技術的なことができていないということもあり、気分をリフレッシュさせる気持ちで今回は参加しました。今回参加したことで技術の楽しさを再認識できましたし、自分はやはり何かをエンジニアリングで解決することが好きなんだなーということも再認識できました。何かを作りたいという気持ちも高まりました。とてもよい機会をいただき感謝の気持ちでいっぱいです。
最後に、運営で気になる点があったので改善の余地がある点を書いておきます。
- 去年に比べ記念ホール以外の各部屋が満席になるのが早かったように感じました。セッション終わってトイレへ行って次の部屋に行くとすでに立ち見であったり満席で入れないことが何度かありました。この辺りの調整は難しいとは思うのですがちょっと残念でした。もう一部屋くらい確保して溢れた人が休憩できる部屋とか用意できるとよいかもしれません。そこで新たな交流もうまれるでしょうし。
- セッション内で質問した時に、初めの方から手を挙げてるのに後から手を挙げた人に先にマイクを渡してどんどんスルーされ、なかなか質問できないということがありました。手を誰が挙げてたなのかを覚えておくのはなかなか難しいとは思うので立ってもらっておくなどの工夫が必要だと思いました。
- クロージング時のじゃんけん大会からベストスピーカー発表まで身内感がかなり出ていて参加者を置いていけぼりにしていたように感じました。その後、コミュニティのあり方についての素晴らしい話があったのに説得性が欠けるものになってしまっていました。ワイワイしている時は身内感が出てしまうのはしょうがないと思うので運営の一人一人が意識するしかないように思います。
色々書きましたがこれだけのカンファレンスを毎年続けているということは大変ありがたいですし、素晴らしいことだと思います。今後も楽しいカンファレンスを期待しています!
運営の皆様、発表者の皆様、参加者の皆様、楽しいカンファレンスをありがとうございました!
本編1日目
Electronによるアプリケーション開発事情2018
資料 : builderscon2018.pdf - Speaker Deck
内容
- MastdonクライアントをElectronで作った
- リリースに関して
- electron-builderがあればだいたいのことは解決する、マジ便利
- electron-userland/electron-builder: A complete solution to package and build a ready for distribution Electron app with “auto update” support out of the box
- electron-packagerというのもあるがそれよりelectron-builderがお勧め
- アプリのパッケージ、証明書の追加、各種インストール形式に圧縮、設定がpackage.jsonで書ける
- Mac App Store用にパッケージングするにはいろいろ大変...
- electron-builderがあればだいたいのことは解決する、マジ便利
- なぜMastodonアプリを作ったのか
- デスクトップ向けのクライアントが少なかったから
- Whalebirdのコンセプト
- Slackに慣れてるのでそれっぽい感じに
- Mediumに英語で記事書いたら海外から反応が
- いいアプリだけどElectronだから減点、みたいな意見が
- Electronが嫌いな理由
- メモリ消費が多いという意見が多い
- メモリ消費をなんとかしよう
- megalodonというmastdon APIクライアントライブラリも作った
- TypeScriptで実装
- TypeScript最高
- ElectronアプリもTypescriptで書けば良かった...
- Electronのセルフアップデート機能使うとAppleの審査に弾かれるので使っていない
所感
個人でプロダクトを作ってそこから普段の仕事では使っていないいろいろな技術を学んでいく姿勢が素晴らしいと思いました。英語で記事を書いて海外ユーザーを引き込むスタンスも素晴らしいです。あと、vue-cliでVueを使うElectronアプリの雛形を作れることは知りませんでした。
electron-builderが相当便利なことが分かったので、Electron使う機会があったら使っていきたいです。
パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと
資料 : ritou_user_authn_builderscon_tokyo_2018 - Speaker Deck
内容
- パスワード認証
- 特定デバイス不要の最強の認証方式、のはずだった
- 現実には使い回し、サービス側の運用方針にユーザーが振り回されるという現実
- やめるべき理由
- ユーザーへの負担(ユーザーのスペック不足www)、サービス側のリスク/コスト
- 現状
- 最新動向
- FIDO2.0
- UAF + U2F
- FIDO1.0までバラバラの仕様だった
- Web Authn API
- FIDO2.0のWeb API仕様
- ここで試せる → WebAuthn demo
- 定着するまでに必要なこと
- ブラウザの対応、Authenticatorの普及、ユーザーへの啓蒙
- FIDO2.0
- 課題と対策
- どのようにしてパスワードレスを実現できるか
- 新規サービス
- パスワード認証を使わない
- 既存サービス
- パスワード認証を使うのをやめる
- 新たな認証方式の提供、新たな認証方式への移行、パスワード認証の撤廃
- パスワード認証を使うのをやめる
- 新規サービス
- 課題
- どの認証方式を使うか
- UXが変化する
- 登録フローが変化する、ログインフローが変化する
- パスワード確認相当の処理をどうするか
- どの認証方式で代替するかの決めが必要
- どのようにしてパスワードレスを実現できるか
- まとめ
- パスワード認証を安全に運用するのは困難
- WebAuthnによる新しい認証方式はすぐそこまで来ている
- #idcon - Identity Conferenceというコミュニティがあるので興味がある人はぜひ
所感
パスワードレスな認証の現状や関連技術のさわりについて丁寧に説明されていました。話を聞いているとパスワード認証をなくすのは技術的な話よりも人々のマインドを変えることの方が難しそうだなと思いました。
また、UXが変化するというのはあまり意識したことなかったですが確かにそのとおりですよね。
Authenticatorは果たしてあとどれくらいで普及してくるのだろうか?エンジニアが多い身の回りでもyubikey使っている人少ないのでまだ相当かかるだろうなあ。
Webサービスにて200週連続で新機能をリリースする舞台裏
資料 : Webサービスにて200週連続で新機能をリリースする舞台裏 / builderscon tokyo 2018 - Speaker Deck
内容
- Mackerelを200週連続でリリースしてきた話
- 連続リリースの定義
- ユーザーにとって価値のある機能をリリースする
- バグフィックスやメンテナンスリリースは含めない
- 何のためにやっているのか?
- 機能開発のスピード感が価値のひとつであり優位性だった
- 最初は連続リリースを意識していなかった、気づいたら50週いってた
- 毎週連続リリースをアピールしたら顧客獲得の大きな武器となった
- どうやって維持したか
- 続けるコツ
- 毎週告知をチームの最重要コミットメントと位置づけ、チーム全員がそれを目指す
- 毎週リリースをやめた理由
- 主な機能が出そろった
- スピード感より腰を据えた機能開発の方が顧客にとって大きな価値となるフェーズになったと判断。スタートアップ機の終了
- 毎週リリースを終えてみて
- 足回りの改善がやりやすくなった
- Playframweork、Scala、sbtのバージョンが一気に新しくなった
- 足回りの改善がやりやすくなった
所感
バグフィックスやメンテナンスリリースは含めずに、ユーザーに価値のある機能だけをこれだけの期間毎週リリースしてきたのは本当にすごいと思います。チーム作りもいろいろと試行錯誤があったかと思いますが工夫したんだろうなあと。
バックログに対してエンジニアの100%稼働を求めないで20~30%は余力が残るように計画するというのは本当に大事だと思います。(そうしようと思いつつなかなかできないのですが...)
あと、プレゼン資料の構成がとてもうまいと思いました。
daiksyさんのプレゼン構成はいつもとてもうまいなあと思う。内容がすっと入ってくる。何について話しているのか分かりやすい構成なんだろうな。
— uenot (@braitom) September 7, 2018
イノベーションを止めずに、端末管理と運用を行う方法
資料 : イノベーションを止めずに、端末管理と運用を行う方法 - Speaker Deck
内容
- なぜ端末管理するのか?
- ライセンス管理
- 稼働状況の確認、棚卸しなどコスト削減につなげるため
- 情報セキュリティ対策
- 不正利用対策
- 端末管理するからには目的を明確にする必要がある
- 念頭に置くこと
- 管理方針
- 懸念における対応が未定義ならきつめに設定
- 端末はなくしてしまう前提で設計
- macOSの管理
- プロファイルマネージャーというものがある
- auditログが読みづらいのでosqueryで取得してElasticSearchに入れる
- google/santa: A binary whitelisting/blacklisting system for macOS を使うなど
- Windowsの管理
- Azure ADとIntune
- Winlogbeatとosqueryで監査ログ取得してElasticSearchに入れる
- iOSの管理
- Androidの管理
- managed Googly Play
- ビジネス部門と管理部門のバランスが大事
- 要望をちゃんと受けていくスタイル、代替案を提示していくスタイル
- 一方的に締め作るのはダメ
- お互い歩み寄っていく姿勢が大事
- 要望をちゃんと受けていくスタイル、代替案を提示していくスタイル
所感
知見が共有されることが少ないデバイス管理系の話ということでとても参考になりました。端末管理をするにしても目的が大事で、何のためにその設定をするのかを忘れないようにすることがとても大切ということが伝わってきました。人はミスを犯すという前提で設計しないといけないこともなるほどなあと思いました。
Macの管理はとてもツラそう...でも色々なサービスやOSSを組み合わせて仕組みを作る感じはエンジニアリング感があってちょっと楽しそうかも。
また、気になったので以下の質問をしてみました。
- Q: 今後人数が増えていってもこの方法で運用が回るか?ライセンス費などもかさんでくると思うがペイできるか?
- A: できると思う。なるべく工数をかけない方向で努力している。人数増えてきたら外部の会社にお願いすることも検討すると思う。本当に必要なのはみんなの要望に対応するための時間を確保しておくこと
この質問をした意図としては人数が増えると運用負荷とライセンス費用がどかっと上がると思っているからです。また、ビジネス部門と管理部門のバランスの話をされていたのですが、人数が増えると色々な考えを持った人がどんどん増えていくということなのでこのバランスを保つためのコストもどんどん高くなってきます。そんな中でこの仕組みを続けていけるのだろうか?と疑問に思った次第です。
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
内容
- lldの紹介
- リンカとは
- オブジェクトファイルを1つの実行ファイルやDSO(DLL)にまとめるプログラム
- 開発のきっかけ
- どうやったか
- 何かが間違っていても全くヒントがない
- バイナリをプリントアウトして考える、バイナリを理解できるよう。とりあえずOSにロードされるように頑張った
- Hello Worldがリンクできるようになるまで数ヶ月、大きなプログラムがリンクできるまで1年くらいかかった
- リデザインのポイント
- 難しくし過ぎない
- 不自然な最適化はしない。自然と性能が出るように書く
- データ構造こそが重要
- 速くてシンプルなコードを書くために
- 良いデータ構造にするのが重要、データが先、コードは後
- 2回書く。1度目の経験を2度目に生かす
- 最適化する箇所を最小にとどめる
- 終わりに
- 問題についてよく考えて自分がよいと思うやり方を勇気を持って試してみる
- 存在しない問題を作りだしてそれを解決しようとするのではなく、元々の問題を直接解決できないのかよく考える
- カーゴ・カルト・プログラミングしない
- 理不尽なものは受け付けない
所感
まさに自分にとって「知らなかった、を聞く」セッションでした。
リンカを使うことはあってもそれを実際に作ることなんて考えたこともなかったのでどういう考えでつくるのか、どういう苦労があるのかが分かりこういう世界があるのかーと思いました。プログラマとしての生き方、考え方をあらためて考えさせられました。
あと、なんというか考え方とかすごいなーと聞いていて終始思っていました。
いやー面白かった。スーパーエンジニアがどう考えながらものごとを設計していくのか、解決していくのかが伝わってきた。考え方すごいなー。所々、勘でやったとか天才感はかなりあったけど。
— uenot (@braitom) September 7, 2018
このtweetがまさにこのセッションのすごさを表しているなーと。
るいさんのセッション大変良かった。伝説のロックバンドのライブを見た気分。ライブビデオを発売して欲しい。10年後、若者に「おじさんこのセッション生で見たんだぜ」て自慢したい。#builderscon
— ぎゃばん@並列プログラミング (@ledsun) September 7, 2018
本編2日目
「Web とは何か?」 - あるいは「Web を Web たらしめるものは何か?」 - Idea of Web
内容
- Webは進化しているが本当に正しい方向に進化しているのか?それを誰がバリデーションできるのか?
- Webに関わる視点
- Webを使う人たち、Webで作る人たち、Webを作る人たち
- 最初はティムバーナーズリーが論文を共有したいということから始まった
- HTML,HTTP,URL
- WebのApp化
- Cookie,Form,JS,iframe など
- Ajaxの登場
- Originの登場
- HTML5の登場
- アプリケーションを作るには貧弱すぎた
- データ保存できない、動画も音声も再生できない、線すら引けない etc
- Webは文章を共有するものではなくなった
- それはWebに本当に必要か?
- Contents Use Caseで議論すると失敗する
- 自分にとって必要/不要みたいな議論になる
- Functional Use Caseでの議論に移りつつある
- 互換性とセキュリティモデルが議論できるか
- Contents Use Caseで議論すると失敗する
- それはWebに本当に必要か?
- Extensible Webの話に
- アプリケーションを作るには貧弱すぎた
- アプリケーションプラットフォームの限界
- WebのOS化
- ここもFunctional Use Caseで議論
- OSのセキュリティモデルがWebにはない
- 安全なデバイスアクセスを実現するセキュリティモデルが必要
- Permissionの導入
- Hyper Media System → Application Platform → Operating System と変化
- Webは時代の要求に応じて変化する
- WebがWebとして壊れないために必要なモノを模索
- 今はWebにとって重要な過渡期
所感
WebのはじまりからAjax、HTML5、Deviceアクセス系のAPIがどういう経緯で登場してきたのかがセキュリティモデルの考えを絡めて丁寧に説明されていてとても勉強になりました。 「Hyper Media System → Application Platform → Operating System」という流れで進化してきており、これによりWebを支える技術で書かれている以上のことが必要な時代になってきていることがよく理解できました。個人的にはベストセッションでした。
「WebがOSに近づくという流れはOSがWebでいいじゃんって話とも言える。GoogleがChrome OSやってるのはその流れ」というのもなるほどなーと思いました。それを聞いてあらためて考えるとやっぱGoogleってすごいなという気持ちになってきました。ブラウザもOSも持っているわけで。WebとモバイルアプリとOSの境目をユーザーが分からないような世界を作れるのはやっぱGoogleなんだろうなーと。
証券トレーディング業務におけるExcel依存を脱却するプロジェクトで直面した技術的選択とプロジェクト運営の失敗
資料 : 公開なし
内容
- Excelはツラい、脱却しようとしてもツラかった
- 証券トレーディング業務とExcelの関係
- Excel脱却プロジェクト
- プロジェクトアンチパターン
- 上から降ってくる技術的選択、大きめの選択
- 政治力の及ばない相手との共同作業
- 短すぎる納期
- 既存ワークフローのいいところを無視
- 後から明らかになる要求に対応できない体制
所感
これは確かに資料公開もビデオ撮影もできないよな、というとても香ばしい内容でした。こんなにツラい案件をやっている人もいるんだと元気をもらいました。
やはり、こういった失敗プロジェクトの事例の共有はありがたいですね。とても参考になりますし、色々と考えさせられます。政治的な話はどうにもならないと逃げずにできる限りのことはやって、大爆死せずにいかに怪我を少なくできるかを考えていくのが大事だと思っています。
また、プロジェクトの進め方をもうちょい工夫すれば大爆死は避けられたのではないかと思いました。
結局マネージャーがいろいろサボったってだけの話に見えてきた。そもそ何で作るの?含めメンバー含め考えた方が良かっただろうし、社内政治やステークホルダーとの調整をサボったのも原因のように見える。 #builderscon #buildersconC
— uenot (@braitom) September 8, 2018
なぜエンジニアはパフォーマンス計測しないのか
資料 : why_dont_you_measure_your_performance - Speaker Deck
内容
- これと結構かぶっているとのこと
- ガジェットを駆使して自分を測る
- 結果を言うと体重減ったり、体脂肪減ったりで効果が出たことは出た
- プライベートでコードを書くようになったのも1つの成果
- 7年のログからみる自分の傾向
- 仕事が忙しくなると太る
- プライベートが不安定になると太る
- やる気がでないという問題も科学的アプローチで解決できるのでは?
- ありとあらゆるものを測定することに
- Withings Wifi body Scale
- Withings Activate
- Withings Sleep
- GoBe2
- Spire
- ZOZOスーツ
- キーボードのタイプ数
- 取ったデータを全てFirebaseに集約していく
- グラフを色々表示するUIも作成
- 睡眠時間と集中度の関係見たが相関あるのかないのかよく分からなかった...
- 人体ABテスト
- 朝ごはん食べる/食べない、カフェイン制限、朝運動してみる、満員電車に乗る、断酒
- どれもあまり数字に出なかった...
- 改善策
- 睡眠
- 食事
- 16時間断食
- 栄養を考える
- お勧めの間食
- 欲しいも、ナッツ、ブルーベリーなど
- 運動
- ジム通い、パーソナルトレーニング、歩く
- タバタトレーニング
- 脳機能改善にはトレイルランニングとクロスフィット
- 開発環境
- 立って開発
- Ergodox導入
- 机の下にステッパー導入。歩きながらコードを書く
- そんなに計測する必要あるの?
- ぶっちゃけ指標に関する数値は1つでよいと思う
- 自分の体のことは自分から学ぶしかない
- 自分の人生を自分で決める
- やる気を出すのではなくやる気が出る状態を作る
所感
これはネタ枠だから!、本当に立ち見してまで聞くこと?と心配そうな感じでしたがきちんと自分の問題を解決するためにエンジニアリングしていて素晴らしい発表だったと思います。
私もいろんなガジェットを買ってデータだけは集めているのですがほとんど分析できていないので見習おうと思いました。
これだけデータが貯まっているのでデータ分析系の話と組み合わせた何かをすると、昨今の機械学習ブームもあるのでもっと色々な人にアプローチできるかも。
業務時間で書いたパッチは誰のもの? OSS 活動にまつわる罠
内容
- 業務で書いたパッチ投稿に潜む罠
- このパッチは社外公開してよいのか?
- 誰に許可を取ればいい?
- 何名義で公開すればいいの?
- CLAへの署名を求められたら?
- 趣味で書いたOSSを業務で改善するときの罠
- 業務時間を趣味OSSに使っていい?
- パッチの著作者は誰のもの?
- 会社のコードを混ぜたくない
- サイボウズのポリシー
- 策定の背景
- 著作権
- 極秘情報を含むもの、上長の明示的な指示または承認のもと作成されたものは会社に帰属する
- その他は社員個人のものとなる
- 趣味OSSへのパッチも自分のもの
- 業務で書いたときは会社のもの、本体に取り込まれたら個人のもの。
- 新規OSSは許可不要
- CLA同意を求められたら会社を代表して署名してよい
- 参考にした企業
所感
こういうポリシーを策定できるのはさすがサイボウズさんだなと思いました。 OSSに関する方針を会社としてしっかりと考えてポリシー作っているということは以下のような利点があると思います。
- 働いているエンジニアからしたら自分たちのことをきちんと理解してくれていてありがたいと
- 外から見たらエンジニアの取り組みを支援している素晴らしい会社、かつライセンス周りについてもきちんと理解している会社であると感じる
利点しかないですよねほんと。このポリシーを決めるにあたってきっと内部的にはいろいろと揉めたこととは思いますが、却下とならずにきちんとこうやって成果として出てくるのはさすがだなと思います。
これをきっかけに日本の企業も自社のOSSポリシーを持つのが当たり前になるとよいですね。セッション聞いた後、以下のようなことをモヤモヤと考えていました。
会社のOSSポリシー絶対必要だよなー。自分のところでやるとしたら、OSSは無料で使えるものでしよ?みたいな変な考えの層がそこそこいそうなのでそこから変えないとだなーとボンヤリ考えている #builderscon
— uenot (@braitom) September 8, 2018
なぜ私はキーボードを作るのか
資料 : なぜ私はキーボードを作るのか_builderscon2018 - Speaker Deck
内容
- キーボードを作るまで
- 肩こりがひどい
- Helixが社内で流行っていた
- HHKB2台使いに
- メリット: 何も自作しなくて良い
- デメリット: でかい、キー設定いじらないと無力
- キーキャップ選べるの楽しそう
- 自作キーボードについて
- 2種類ある
- 誰かが販売するPCBを用いて組み立てるもの
- ErgoDoxとかHelixはこっち
- PCBから自作するもの
- 誰かが販売するPCBを用いて組み立てるもの
- PCBとは
- プリント回路基板
- 2種類ある
- パーツ選定について
- 自作キーボードやらかし集
- 失敗はつきもの
- 失敗をおそれず色んなキーボードを自作してほしい
- 一歩先へ
- フットペダルつけてキースイッチを割り当てる
- なぜキーボードを自作するのか?
- 自分に道具を合わせるという考え方
- 既製品は自分を道具に合わせることになる
- 自分に道具を合わせるという考え方
所感
自作キーボード愛を感じるセッションでした。自作キーボードは一度やってみたかったので色々と参考になりました。 特に失敗事例の紹介はとても参考になると同時に、ハンダ付けのワザがやっぱ要求されるのかーとやはりちょっと尻込んでしまう自分が...
Helix買ってみようかなー。
LT
キーボードをカスタムしてプログラミング環境を良くした話
- Elixir好き
- 特にパイプ演算子が大好き
- パイプ演算子は格好いいけど最高に打ちにくい
- よし、キーマップ書き換えよう
- GitHub - qmk/qmk_firmware: keyboard controller firmware for Atmel AVR and ARM USB families で書き換える
- 3回入力が必要だったのが1回に!
スーパーファミコン開発ことはじめ
- なんかゲーム作りたい
- 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パースできることに気づいた俺たちは
こんな現場でやってられるか
5分でフォトブース
Development Tools for Next Generation
資料 : Development Tools for Next Generation - Speaker Deck
- ChromeBookで使えるエディタがない
- ないから自分で作ってる
- Next Editor
- Editor with Git
- 目標
- Git for Everyone
アップデートばかりしている言い訳をさせてくれ
登壇やLTを始めてみたい」方の背中を押してみたい
資料: 「登壇やLTを始めてみたい」方の 背中を押してみたい - Speaker Deck
- 自分も社内外の人から背中を押してもらってきた
- 背中を押して上げる
- アウトプットで学べることを教えてあげる
iOSDC Japanを本物のインターネットを提供した話
- 会場からdwangoのデータセンタへ雑に繋いだ
- 設計をどうするか?構築をどうするか?機材をどうするか?
- 牧さんの会社endeworksでネットワーク機器レンタルしている!
Node.jsでCloudFormationのテンプレートを分割して管理する
資料 : Node.jsでCloudFormation_のテンプレートを分割して管理する.pdf - Speaker Deck
- CloudFormationはテンプレートが大きくなりやすい
- 分割して管理したい
- S3にテンプレートを置く方法があるがめんどう
- 作った
- 見通しが良くなってめんどくささがなくなった
- honoka-api-base
ネットワーク障害を支配したい話
資料 : ネットワーク障害を支配したい話
- システム監視のリプレイス中にテストしたい
- 受け身じゃなく先手をうてるようになりたい
- iptableやtcで素振りできる
- もっと便利なものは?
- Chaos Engineering的な話
- 色々なツールがあるので素振りしていこう
HBFavが使えなくなったので代替策を考える
はてなより、お気に入りフィードRSSの継続および仕様変更についてというアナウンスがありました。
これによりHBFavというお気に入りユーザーのブクマを閲覧するのに便利なアプリが動かなくなってしまいました。
今回の仕様変更にともない提供終了のアナウンスも出されています。
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
したらローカル環境で実行時にエラーが発生した ibcurl4-openssl-dev
をUbuntuにインストールすることで解消した
ことの始まり
先日こんなメールがGitHubから届きました。
「これが噂の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便利ですね。もっと色んな言語に対応してくれるとありがたいものです。