IPAが公開する「安全なウェブサイトの作り方」第1章「ウェブアプリケーションのセキュリティ実装」を読んだ
徳丸本の中の御方も編集に加わられているとのこと。
構成は
- 第1章「ウェブアプリケーションのセキュリティ実装」
- 第2章「ウェブサイトの安全性向上のための取り組み」
- 第3章「失敗例」
このうち第1章を読んだので、要点とか気になったとことか別の参考サイトとかのメモを残す。
続きを読む「車窓からのTDD」をRubyで書き直してみる
やること
- 「車窓からのTDD」（後述）を読みながら、出てくるjavaのコードをRubyで書き直してみる
- TDDの雰囲気つかみつつ、Rubyのリハビリをする
- 『レガシーコードからの脱却』を読んでTDDちゃんとやりたい気持ちが本格化してきた
- ここ数ヶ月間対人の業務や別言語の仕事をしておりRubyほとんど書いていなかった
- 簡単なユニットテストだけなので初minitestで
seattlerb/minitest Rails テスティングガイド - Railsガイド
コード
TDDのステップをコミットに反映させたつもり
車窓からのTDD
http://objectclub.jp/technicaldoc/testing/stack_tdd.pdf
- 4ステップのサイクルを回す
- トライアンギュレーション（三角測量・方法論的複眼）
違う角度からの複数のテストを作り、全て通ることを確認していく- 一度 🚙 にした後、仕様をより正確に表現するようにテストを追加する 💚 🚗
- テストに通るように実装を修正する 🚙 ♻️
※ スマホから見ると絵文字が違うっぽい
- 🚗 は
:red_car:で赤い車 - 🚙 は
:blue_car:で青い車
考えたこと
- こんなシンプルなコードに30近いステップがある……
- 実務でほんとにやれるのか？
- 最後のほう曰く几帳面に全部fakeしていかなくてもいいらしい（「明白実装」）
- 実装に迷う部分はfakeで通して、そうでもないものはストレートに実装してもいいのかもしれない
- 実装の詳細に迷って途中で中身をばこばこ書き直すことが多いので、とりあえずハードコードでテストを通しておくというのよさそう
- 呼び出し元の視点でインタフェースを決められる、決めたインタフェースをぶれずに残し続けられる
- 開発のタイムプレッシャーを打ち負かすくらいスムーズにTDDしたい
- 涙無しには読めなかった『レガシーコードからの脱却』の生産性の話を信じる
- このPDFにも最後に品質について同じことが触れられていた
- 品質より納期を優先してしまうという開発、できればもうやりたくない
どっちも取れる""力""が欲しい。息を吸うようにテスト書くようになりたい
- テストケースが見慣れない感じだった
test_push_push_pop_top- テーマがやや低レイヤというかシンプルなデータ操作だったからかな
describe '#pop'の中にcontext '事前に1度pushされている場合'みたいなSpec式のほうが書き慣れてるかも
- 思ってた以上にRuby忘れてた 😢
次世代Webカンファレンス2019 聴講メモ #1 「SRE」
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容は後日配信される公式の動画をご覧ください。
（わかる範囲でしか書いてなくて、もっと面白いやり取りもたくさんあったのでぜひ動画でo( )o）
SRE
#nwc_sre
- @kani_b：クックパッド SRE・セキュリティ
- @deeeet：メルカリ マイクロサービスプラットフォーム
- @y_uuk1：先月まではてな（Mackerel） → 来月からさくらインターネット
聞きながらのメモなのもあってアカウントの頭文字を敬称略で書かせていただいています、すみません。。。
内容めも
SRE
kani_bさん（以下「k」） ：シスアドと違って、ソフトウェアエンジニアがインフラもやるようになってSREになっていくと思う。ソフトウェア開発の割合は？
- deeeetさん（以下「d」）
Googleのやり方を目指している。
全タスクをreactive/proactiveにラベリングして、半々の量になるように。
というか対応系タスクが増えてきたことで、ラベリングによって可視化（on github）してそれらが50ぱーを超えないようにしようとなった。
タスクはマネージャーが調整する。新規事業のリリース前後はreactiveなタスクの需要が上がるので、それを察知して、依頼が来る前にproactiveなタスクをやっちゃう。 reactive全てがtoilであるというわけではない。- reactive
アラート対応、開発者からの要望対応 - proactive
プラットフォーム構築 = より良いプラットフォームを作る
- reactive
- y_uuk1さん（以下「y」）
前職ではソフトウェア開発の割合は低かった。 - k
割り込み仕事の割合は、その人が持っているタスクによって変わってくる。複数人で1サービスを持ったりという工夫をする。
開発者との調整はいくらやっても割り込んでしまうので、SREチーム側のやり方を変える必要がある。もちろん自動化等の改善業務は進める。
タスクの可視化
d：どうやって可視化しているのか？
- k：
1つのチケットに書いてあるタスクの粒度が違っていて、単純にラベルを貼っても正確には可視化できない。
定期的に各人がどういうタスクをやっているか共有して、運用の仕事が多いメンバーをフォローする。 - y：
スクラムの手法で、タスクにポイントをつけてベロシティを計測している。差し込みの量はここでわかる。
toilを計測するのは難しかった（例えば一瞬で終わるものとかもあって）ので「本来やるべきタスクをどれだけやれたか」を可視化した。
オンコールの運用
- y：
振り返りは平日毎日。即時対応が必要なものはオンコール担当、その後対応が必要なものはみんなで。
週末は当番制。平日は起きてる人が対応していた。
ポストモーテムについて、クライアントに報告するかはフィルタリングされていた。
以前、過去2年分のインシデントを見直して、実現できていない対応をロードマップに組み込んだりしていた。 - d：
モノリス時代のオンコールは基本SREチーム。毎日primary, secondaryの担当が決まっていた（週一でまわってくる）。
ポストモーテムについては、アラートごとにインシデント内容・影響・対応をまとめて、週一でその1週間の全インシデントについて振り返りをやる。
議論はSlackで完結する。
SLI, SLO
- y：
SRE本のとおり策定しようとしてみたけど、結局時間で稼働率を測った。 - d：
両方ともとても大事だと考えていて、SLI, SLOが無いならSREを名乗れないと思っている。
プロダクトを出すときに必ずSLI, SLOを設定するようにしている。 （k：強く設定しようとすると「限りなく100％」ってなっちゃうと思うけど、そうはいかない。どう設定するのか）
決めるのはSREではなくデベロッパーになっている。本当はSLOのオーナーを決めないといけなくて、PMやCTOとか、その人達が数値の妥当性を検討するべき。
うちはまだできていない。
サービスによって、ツーナインでいいのかフォーナイン必要なのかが変わってくる。
k：プロダクトを作る側も、ある意味"あきらめる"ことが必要になってくる。ビジネス側にどう説明するのがいいんだろう。
- d：
100ぱーは無理だということをPMに理解してもらわないといけない。PMが理解しないならSLO設定の意味が無くなる。 - y：
求められる可用性に対して、その実現のために必要なタスクを洗い出してポイントをつけて「これをやるならこっちのタスクはできなくなります」と説明することになる。 - k：
SLIは持っていて、SRE自身がSLOも持っている。SRE本と同じようにエラー数/リクエスト数をベースにしている。
エラーバジェット
k：監視にはどういうもの使っていた？
- d：
モニタリングはdatadogで、重大なものはpagerdutyに飛ばしている。いまpagerdutyはほとんど全員が持っている、全体で170アカウントくらい。 - y：
サーバーサイドエンジニアもオンコールを持ちましょうという流れになっている。
監視はもともとインフラチームが設定していたけど、SLOをエンジニアが持つようになるとエンジニアが自発的に設定してくれるようになった。 - d：
オオカミ少年アラートが多すぎた。今後はアラートを設定するときは全員でレビューするようにしたい。
「これ設定すると俺たち朝に起こされるぞ、どっちをとる」みたいな。 - k：
最近prometheus + alertmanagerに移しつつある。アラート設定をテキストで書いてテストもやるようにしたい。
インフラのセルフサービス
- d：
せっかくマイクロサービス化して自立性の高い開発者チームを作っても、SREがボトルネックになっては意味が無い。
基本的にソフトウェア開発者チームに全権限を渡している。監視やインフラ基盤はできるだけGCPなどで使えるマネージドのものを使う。
オンコール含めて。
（k：そこにSREが入るタイミングは？）
それらを実行するCI等の仕組みを提供する。 - k：
うちももともと全権限をインフラチームが持っていて、何をするにもインフラチームにお伺いを立てる必要があった。
ソフトウェア開発者から見てもやりにくいし、なんとなくインフラチームって怖いし（笑）
DBのスキーマ変更も開発環境構築もセルフサービスでできるようになっている。
これからのSRE
k：セルフサービスが進むとこれからSREチームの役割はどうなっていくんでしょうか
- y：
みんながSREになっていって「SRE」という職種そのものは消滅する、みたいな流れでいいと思う。大きいところだと専門のチームが必要だと思うけど。
マネージドサービスも増えているし。 - d：
感覚的に、たとえばSLOがツーナインまでなら開発者だけでいいと思う。でもスリーナインを超えてくると専門のSRE人員が必要になることもある。
SREがいなくなるというより、SLOの高いクリティカルなサービスのチームにSREが入っていくことになると思う。
開発者チームにSREがembededしていくのは良いことだし、進めていくべき。 - y：
ML Opsみたいな、マネージドサービスがまだ無い分野をオペレーションする必要がでてきたときにSRE的な仕事が復活してくると思う。 - k：
SRE職人がやるんじゃなくて、開発者それぞれがSRE的な仕事をやっていく。 - y：
SREというのはDBとかの各分野のスペシャリストではなく、いろんな分野を「信頼性」っていう観点から体系化して「なんかよく知らんけどこれらを組み合わせてうまいことやる」っていうジェネラリストだと思う。SREは科学ではなく技芸である、という考え方を支持している。
どういう人がSREになっていくか
- k：
システムを理解してソフトウェアエンジニアや、科学的なアプローチにトライできる人かな - y：
いずれ失職すると思ってるけど、マネージドサービスとたたかうことになると思うので、創造的なことがやれるといいのかな - d：
組織として「SRE」をやっていって、それをリードする人がいる、ということになると思う
感想
用語からわからないところもあってぐぐりながら聞いてた。けどもともとインフラにも興味あったし考え方とか問題点とか聞けて面白かった。
SREチームが作ってくれたものにしろ自分で外のマネージドサービスを使うにしろ、わけもわからず使ったら結局サービス落としたりオオカミ少年アラートを増やしたりすることになるわけで、ソフトウェアエンジニアこそ今ちゃんと勉強しないといけないと思った。
「マネージドサービスとたたかってSREは失職する」という話はそのままソフトウェアエンジニア（狭義）にも言えることだなあ。。。
ワンオペ開発組織をどうにかしたかった駆け出しチームリーダーの話
レガシーもとい未熟もとい、まさにこれから新しい文化を作っていこうとしていたエンジニア組織の中で、小さいチームを持った駆け出しエンジニアが無い頭をしぼって行った取り組みを箇条書きにしてみた。
環境・経緯の詳細を書き始めると長くなるので、一部適当に書いてある。なぜこの記事を書いたかは最後に書く。
環境
- 会社
- 上場企業
- 社員数150人くらい、うちエンジニア職20人ほど
- 部長レベル以上にエンジニア経験者はいない
- 部署
- 自分
- 25歳♀
- 文系未経験エンジニア()
- 内定後、1年間のインターンを経て入社
- この記事に書いてあるのは正社員1年目の終わり〜2年目半ばまでの話
チームを持った経緯
チーム ①
- リーダー私：当時1 〜 2年目
- エンジニアAさん：中途入社2 〜 3年目。1児のママ。中国出身。日本語は9割方わかる。
- エンジニアBさん：当時3 〜 4年目。元メンター。社内で数少ない勉強熱心なエンジニア。
1年目の12月、当時だいたい7人が各自ワンオペ開発をしていたのが、突然マネージャーを除く6人を3人ずつ×2チームに分けると発表された。
各チームが追うべきKPI（？）も一応設定されていたものの、実情はただ事業サイドから要求された開発を空いてるリソースでやるだけだったので、さして話題にはならなかった（査定時にも特に言及されなかった気がする）。
なんのために分けたのか当時も今もよくわからないけど、部署内を細かく分けることで組織構造はこうなった↓↓
部署マネージャー（給与査定時の評価者） ↓ チームリーダー ↓ メンバー
（当時も自分でよく言っていたけど、この「チームリーダー」というのはただの名ばかり中間管理職である）
私が振り分けられたのは、部署内では技術・経験のある2人と同じチームだった。
当初、リーダーという立場にあったのは1児のママであるAさんだった。
年が明けて1月の終わり、Aさんがプライベートな事情で数カ月後に会社を離脱することが決まった。
Bさんが後任に乗り気でなかったこと、私が早く昇進したかったことの2点から、私がリーダーになった。
（このへんはマネージャーがさらに上を説得して回ってくれたんだと思う）
そういうわけで、2018年の2月からおおよそ7月までの6ヶ月間この3人のチームのリーダーとしてあれこれやっていた。
ここでの主な仕事は下記だった。
- リソースの調整
マネージャーに開発の候補を渡され、話し合いながらいつ誰に何を担当してもらうか考える - チーム内外のインタフェース
マネージャーとメンバーの間で情報のやり取りやスケジュール調整の仲介をする - レビュー全般
- 評価者へのアピール
半年に一度の供与査定時、評価者に対してメンバーそれぞれのアピールをする
チーム ②
- リーダー私：当時2年目。1ヶ月半後に退職予定
- エンジニアCさん：当時8年目くらい
- エンジニアDさん：当時3年目
これは2018年10月半ばから11月末までの話。
この少し前に、前述のチームにいたAさん・Bさんが会社から離脱した。他にも人員の入れ替わりがあり、チーム①結成時に存在していたチーム分けは空中分解していた。
私も離脱を決意して転職活動をしていたけど、うちにしては珍しくまとまった人数を要する開発があって、その一員をしているうちにリーダーになった。
（退職時期も決まってる中でのことだった、今思うと完全に失敗だったけどそれはまた別のお話。）
ここでの仕事は、とにかく開発をうまく進めることと、マネージャーとスケジュールを調整することだった。
本題
というわけで、上記2つのリーダー在任中、気をつけて実行していたことを箇条書きにしてみる。
要件レビュー
背景
当時、1つの開発が生まれて終わるまではこういう流れだった。（PDCAやリーン/アジャイルという概念は無い）
- マネージャーが開発案件を事業サイドと調整する
- マネージャーからリーダーに開発概要と目的が共有される
- リーダーがざっくりと要件精査＆影響範囲調査
- リーダーから担当メンバーに目的・要件・概要を共有する
- 担当メンバーが設計 → リーダーと設計レビュー
- 担当メンバーが開発、事業サイドの人と一緒にテスト → リーダーがコードレビュー
- リリース
見ての通りいくつかの伝言ゲームを経ているおかげで、次のような問題が起きていた。
- 設計レビュー時に、担当メンバーが要件を誤解していたことが発覚する → 設計手戻り
- 要件どおりに作ってみた後、ふと当初の目的を思い出すと要件に過不足があった → かなしい気持ち
特に1つ目の問題は大小の規模で多発していたように思う。
取り組み
私のチームでは4の後、設計に入る前に「要件レビュー」を新設した。確認するのは主にこういう点だった。
- 目的
- なぜこの開発・改修を行うのか？
- この開発・改修を行うことで期待される効果は何か？ その重要度は？
- 要件
- この開発・改修でクリアするべき要件は何か？
- 反対に、関連しそうなことがらでこの開発・改修で対応しないことは何か？
これらを担当メンバーがチケットに書いて口頭で説明し、リーダーや、必要に応じてマネージャーも参加してレビューする。
会議自体は20分ほどで終わる。
効果
この要件レビューで得られたのは次のような効果だった。
- 開発の目的および要件について、担当メンバーとリーダー・マネージャーの間で認識がそろう → 設計の手戻りが減る
- 担当メンバーが自分で要件を再構成することで、当初想定していたものに比べて必要十分な要件に洗練される
- 開発を振った側であるマネージャーやリーダーも、自分が気づいていなかった要件に気づける
- 担当メンバーが自分から能動的に開発案件にコミットしやすくなる
目的を明確に咀嚼することで、与えられた要件を淡々と実装するより自分ごとな感覚が強くなるっぽかった - 給与査定時、実績をアピールしやすくなる
担当した開発の重要度をマネージャーと確認しているため、どこをどうアピールすればいいかわかりやすい
開発規模によっては設計に入る前に1〜2日くらい時間をとったけど、設計が手戻るより全然良かった。
開発進捗の見える化
背景
もともと、部署内でのスケジュール共有にはbacklogのガントチャートを使っていた。
backlogはタスクの親子関係が設定できる（孫は作れない）ので、親タスクに案件自体を置いて、子タスクとして設計、開発、テスト、リリースを置いていくことが多かった。
ただこれだと「開発2週間」というだけひいてあって、その中で何が起きているのか、順調なのかヘルプやリスケが必要なのか、よくわからなかった。
心理的安全性の問題もあるのだけど、見た感じワンオペで担当していると特にヘルプやリスケは言い出しにくいようだった。
それで担当メンバーが誰にも言わずに無理をする、結果どうしようもなくなり、完了予定日の前日になって「間に合いません」と言い出す。数日のばす。また間に合わなくてのばす。
そういうことが過去によく起きていた。
一度ならまだしもこれが続くと本人のテンションも下がるし、中間管理職である私としてもマネージャーに事情を説明する必要があり面倒くさい。
別にリスケが悪いとは思っていない。問題なのは「どうしようもなくなるまで担当メンバーが一人で抱え込んでしまい、結果スケジュール調整がうまくいかない」ことにある。
取り組み
チーム内で動いている開発について、全てホワイトボードに進捗を書くようにした。我流カンバンみたいなもの。
形式は試行錯誤で良い点悪い点あったけど、ここではチーム②でやっていたものを取り上げる。（チーム②は3人で1プロジェクトの開発を分担して行っていた）
表はこんな感じ↓↓で、一般的なサイズのホワイトボードいっぱいに書いた。
表中の空欄部分には、タスクを書いた付箋（5cm四方）と、付随して担当者や完了予定日 が書いてある。
（表の構成に「担当者」という視点が無い点については後述する）
| 機能A | 機能B | 機能C | |
|---|---|---|---|
| 設計 | |||
| 開発 | |||
| テスト | |||
| リリース |
タスク付箋と附記には、たとえばこういうことが書いてある↓↓
- 設計：要件レビュー後、設計レビューでOKが出るまでのタスク
- 開発：設計レビュー後、コードレビューでOKが出るまでのタスク
- タスク付箋の例：「API叩く処理の開発」「レビューで付いたコメントの検討・修正」
コードレビューを経て生まれた修正タスクは付箋の色を変えてみる - 附記：担当者、コードレビュー依頼予定日
※ コードレビューは開発途中でも適当なタイミングではさむようにしていた
- タスク付箋の例：「API叩く処理の開発」「レビューで付いたコメントの検討・修正」
- テスト：コードレビュー依頼後、リリース準備完了までのタスク
- タスク付箋の例：「ステージング環境で疎通確認」「テストケース作成」「負荷確認」
※ リリースは開発ブランチからmasterに直接マージするというフロー。開発ブランチを都度ステージング環境に反映できるようになっていた。 - 附記：担当者、実施予定日、事業サイド待ち等のステータス
- タスク付箋の例：「ステージング環境で疎通確認」「テストケース作成」「負荷確認」
- リリース：リリース準備完了後、リリース後確認までのタスク
- タスク付箋の例：「事業サイドへのスケジュール共有」「リリース後負荷確認」
- 附記：担当者、実施予定日
付箋には自席からでも見えるようにホワイトボード用のマーカーで大きくタスクを書き、完了したら大きく☓印を付ける。
現在進行中のタスクについては、横に色付きのマーカーで担当者名を書き、完了予定日も書く。
担当者や完了予定日はホワイトボードに水性ペンで書いてあるので、いらなくなったら消すし変わったら書き直す。
「担当者」という情報の扱いが雑なのは「『誰がやるか』というのはさして重要でない、メンバー間のタスク分配は流動的であるべき」という空気を作りたかったことによる。
ただホワイトボードを眺めるとやたらと名前が書いてあるメンバーがいたりして、それを見つけると「タスク過多じゃないですか？」という話をしていた。
要件レビューを終えると、設計するべき点もほどよい粒度で見えているので設計の枠にタスクを貼る。
設計レビューでOKが出たら、開発タスクとテスト内容がおおよそfixするので開発とテストの枠にタスクを貼る。
……という感じでフェーズが進むにつれて表が付箋で埋まっていく。そして作業が進んでいくと☓印が増えていく。
タスクの粒度について「2日に1つは☓がつくように付箋を細分化する」ということをメンバーによく言っていた。
1枚の付箋に2週間かかるタスクを書かれては、もとの「開発2週間」と同じ状況になってしまう。
3日以上☓がつかないようだったら、付箋に書いたタスクの粒度が大きすぎると判断して、内容を一度口頭で表現してもらってタスクを分け直してもらった。
ホワイトボードにしたのは個人的な好みである。そこに物理的に置いてあると否が応でも目に入って良い。
Webサービスでもアプリでも、PCやスマホを使うものは自分で開かないと見えない。プッシュ通知が来ようが何をしようが、そこに置いてあるものには負ける。
最初は「担当者（行）×作業進捗（列）」で表を作って、タスク付箋が進捗によってTODO列→DOING列→DONE列へ移動していく式にしていた。
ただこれだと開発案件単位で進捗が追いにくく（このへんは開発の単位がちょっと特殊だったのかもしれない）、またワンオペの意識がさらに強くなってしまうような気がして途中でやめた。
効果
- リリースまでのタスクが常に、誰の目にも明らかであり続ける
- 担当メンバー自身だけでなくリーダーや他のメンバーがリスケやヘルプを提案できる
- レビュー依頼が飛んでくるタイミングをつかめる
それまではけっこう突然「これ今日中にレビューしてください」と来て焦ることもあったが、他のメンバーの進捗が把握できるので「来るぞ……」と内心で準備できた - タスクを細分化する癖がつく
- ☓のついた付箋がたまっていくことで達成感が得られる
当初解決したかった問題は上記の2番目にあたり、十分に解決された。
イメージだけど「API叩く処理のとこ明日いけそうですか？」「微妙そう」「じゃあ開発全体ちょっとスケジュール見直しますか」みたいな会話がしやすくなった。
加えて、リーダーである私が声をかけて回るのは当然として、他のメンバー同士でも「これ手伝おうか？」と言い合えていたのも良かった。
地味だけど想定していなかった効果として、4番目のタスク細分化がある。
「開発2週間」とガントチャートをひくだけだった頃に比べて、メンバー間で「それって具体的に何をするの？」「ちょっとみんなでタスク細かく洗い出してみよう」という会話が増えたように思う。
結果、担当者も自分がやるべきことを明確に理解できる → 工数見積もりの精度も作業スピードも上がる → 余計なリスケが起きにくい、という良い流れができた。
昼会
背景
チーム①が生まれた経緯で少し触れたように、リーダーの主な仕事に「チーム内のリソース調整」と「マネージャーとのスケジュール調整」があった。
ホワイトボード問題でも書いたように、そのためにはチーム内で適切なヘルプやリスケをスムーズに行える必要があり、もっと言うとメンバーの進捗状況を常に正しく把握する必要があった。
もともと週に1回1時間ミーティングをしてみたり、適当なタイミングで個別に進捗を聞いたりはしていた。でもなんだか効率悪いねーという話になっていた。
- たとえば毎週火曜日に進捗報告ミーティングをしても、水曜日に起きた問題についてキャッチアップするのが翌週火曜日になる
- 1週間あたためると問題が大きくなる
- リーダーと各メンバーで個別に話をすると、たとえばメンバーAの進捗についてメンバーBだけが知らないという状況になってしまう
取り組み
ミーティングを「週に1回1時間」から「毎日15分」に変更してみた。
実施の時間帯は、Bさんの提案で昼の12:00 〜 12:15になった（ゆえに「昼会」と呼んでいた。ちなみに定時は10:00 〜 19:00で昼休憩1時間は好きなタイミングで取れる）。
試行錯誤はあったけど、最終的には前述のホワイトボードの前で実施し、内容は↓↓に落ち着いた。
- 話すこと：
- 開発案件ごとのタスク状況
- いま困っていること
- レビュー依頼の予定
- 軽い愚痴
- やること：
- 小さい困りごとの相談
- リスケ
- 担当者変更
- タスク追加
- 会議設定
- やらないこと
- 10分以上かかる決めごと
必要になったら、決めるための会議設定だけ昼会で行う
- 10分以上かかる決めごと
効果
- 困りごとについてチームで気軽に相談できるようになった
「声かけるのは気が引ける、でも1週間は待てない」という問題でも、毎日軽く相談できる場ができた - 必要十分なリスケやヘルプができるようになった
- レビュアーの予定が立てやすくなった
- チーム内のコミュニケーションが活発になった
毎日おしゃべりしたおかげか、なんかちょっと仲良くなった気がした
2番目と3番目について、朝や帰りではなく昼にやるのが良い効果を生んでいたと思う。（ちなみに部署全体で朝会と夕会は存在していた）
当日2時間ほど仕事をした後に昼会をするため「今まで2時間やった進捗」をもとに「今日残り6時間で進められそうな作業」を確度高く見積もることができる。
すると「今日ここまでやろうと思っていたけど駄目そう」「予定通り今日の午後にレビュー依頼出せそう」という共有がしやすい。
聞く側（私）もだいたい自分の一日の余力が見えているので「じゃあこれ私が代わります」「手伝えなさそうなのでリスケしましょう」と返せる。
あと、声かけたりSlackに書いたりするほどでもない良いこと・悪いことを軽くしゃべれたおかげでちょっと仲良くなった。
こういうの地味に大事だったように思う。
Slack「決めなきゃチャンネル」
背景
自分の仕事をしている中で「これ決めておかなきゃ」と思いつきながらも後回しにすることがよくあった。他人とちょっと相談したほうがいいような内容だとことさら後回しにしがちだった、例えばみんな使いそうな定数の名前とか（もうチャンネルを見ることはできないので具体例がぱっと出てこない）。
いちおう小さい付箋に書いてデスクに貼ったりSlackにリマインダーを設定したりするものの、なんとなく後回しにし続けて数日後に「あそういえば」と慌てて相談するようなことが多発していた。
聞くところによると、私以外のメンバーも「後で相談しよう」と思ったまま忘れることがたまにあるらしかった。
必要な決めごとはいつか決めねばならないタイミングが訪れるから、致命的に困るようなことは無い。
でもプロジェクトとしてやらないといけないことが個人に閉じていること、個人に「いつかやるべき小タスク」が積まれてしまうことはチームとしても個人のメモリ管理としても良くないように思った。
取り組み
Slackに「決めなきゃチャンネル」を作った。
- 「必要だけどそこまで喫緊じゃない、小さい決めごと」に出会ったら、その場で決めなきゃチャンネルに一言で投稿する
- 昼会で担当者を設定し、担当者名のスタンプを押す。（発案者が自分で担当するときは投稿時に自分のスタンプを押す）
- 担当者は一人で決めごとを進めながら、調査過程や決めた結果について元投稿のスレッドに投稿する
- 他のメンバーも思うところがあればスレッドに投稿する
- 担当者が決め終えたと思ったら「済」スタンプを押す
- 昼会で決定内容を共有して、みんなが納得したら「完」スタンプを押す
チャンネルにはひたすら小さい決めごとが並んでいき、ひとつひとつにスタンプが押されていく。
「返信○件」と表示があったら担当者が何かしらの進捗を生んでいることになる。
効果
- 小さいタスクが個人のメモリで管理されるのではなくSlackに永続化されるので、気が楽になる
- プロジェクト内に存在する小さいタスクをメンバー全員が把握できる
- 個人が軸になって決めたものごとについて、議論や結論がテキストで残る
- スタンプわいわいして楽しい
結果、チーム全体のタスク管理は「大きいタスクはホワイトボードの付箋で公開」「小さいタスクはSlackで公開」という形になった。
TODOを即オープンにすることで個人のメモリが解放されていったのは間違いないように思う。
（ちなみに後日「やらなきゃチャンネル」という名前で決めごと以外の小タスクが同じように管理されていった。「情シスにこれ確認すること」とか）
ちなみにSlackのスレッド機能について、普段使いにくい印象だったけどこのチャンネルではちょうどよかった。
だいたい投稿されるのが小さい話題なので、流れていく分には別にかまわなかったというか、Slackスレッドの使いにくい部分は今回の用途だと無視された。
ふりかえって
4つの取り組みについて背景から効果をまとめてみたけど、チームを持つ上で一貫して目指していたのは「あらゆる情報をオープンにすること」だった。
最初にしれっと「ワンオペ開発」と書いたように、当時は1人が1案件を担当し、テスト含めて「案件はその人の責任」という考え方が強かった。
でもそれだとミスも起きやすいし疲れるし、何よりその人ができることしかできないというか、チームとしても個人としても成長しにくいのではないかと個人的に懸念していた。
加えてドキュメントを残す文化が無かった（ふざけてよく「ドキュメントインマイハート」と言っていた）ため、開発者本人しか手をつけられないコードも散見されていた。
そういう問題意識から、私のチームではできるだけ誰でも、すぐに、他のメンバーのタスクを肩代わりできる状態にしたかった。
そのためにはあらゆる情報に全メンバーが同じように触れ、かついつでも簡単にアクセスできるようにする必要があった。
なんだかんだ言ってずいぶん前のことなのでそれぞれの取り組みについて具体的な改善案は出てこないけど、全体を通してもっとちゃんと勉強すればよかったとちょっとだけ後悔している。
『エンジニアリング組織論への招待』（の特に↓↓のQiita記事のあたりとか）をもっと早く読んでおけば、いまだに未読の『カイゼン・ジャーニー』を読んでいれば、もっと体系だててチームや組織の問題点を整理して適切なアプローチを取れたかもしれない。
不安とストレスから解放される見積りとスケジュール方法 - Qiita
なぜこの記事を書いたのか
先に書いたとおり、ここに書いたあれこれのあった職場は昨年の11月にやめた。
12月から新しい職場で働いていて、そこではひたすらコードを書いている。
引き続きWebアプリケーションエンジニアではあるものの言語も開発文化も変わって、かなしいかな小さい開発すら手間取る始末だったりする。
事業やチームの戦力になるために今はとにかく数をこなして開発者としての力をつけるのが最優先だと考えている。
そんな中、1ヶ月経ってふと前職の頃のことを思い出して、当時は開発以外のことにばかり心を砕いていたなと懐かしくなった。
やったことやその効果が元の組織に残っているかは不明だけど（たぶん残ってない）、このまま私の中からも当時のことが消えてしまうと本当に無に帰してしまう気がして、せめて自分の成長の糧にしたくて、こうして文字に起こしてみた。
最後に
ここに書いたことを含めて、チーム①でやっていたことを部署内LTで話したことがあった。
当時のスライドが残っていたので貼っておく。
この記事では触れなかったけど「自分より給料が上の人たちに対して、リーダーとしてフォローして回る」というのはなかなかに難しいことだった。接し方とか、何より内心の葛藤とか。
あと、中間管理職の大事な仕事の一つに「自分の下にいるメンバーを守る」というのがあると個人的に思っている。私は給与査定には加われない立場だったから、評価者であるマネージャーにメンバーの成果や成長をアピールする必要があった。
これらも当時の私の中で重要なテーマだったから、気が向いたときにどこかでまた書こうと思う。
ちょっと恨み節っぽくなってしまったところがあるのはご愛嬌ということで。今年もよろしくお願いします。
『プロを目指す人のためのRuby入門』を読んだ
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ) | 伊藤 淳一 |本 | 通販 | Amazon
を読んだ。以下「チェリー本」と呼ぶ。
フル写経はせずに、初めて見たり自分でぱっと書けなかったりする書き方をかいつまんで、結果たぶん半分くらい写経した。
例題もできるだけ解説前に書いてみて、あと「ここをこう変えたらどうなるんだろう」的なことも自分で試しながら読んだ。写経よりこっちのほうが多かった気がする。
3日間かけてトータル10時間弱で読み終えた（時間/日が小さいのは集中力の無さゆえである）。
対象読者について、冒頭にこうある。Yesが多いほど向いているらしい。
Q1. すでにほかのプログラミング言語で3年以上の開発経験がある。もしくは「プログラミング歴 = Ruby歴」で、Rubyを始めてから半年以上経っている。
Q2. Rubyを学習する動機はRailsアプリケーションの開発に役立てるためだ。
Q3. すでに仕事でRubyを使っている。もしくはこれからRubyを使った仕事に就こうとしている。
（↑↑の含まれるまえがきは最初にリンクを貼った技術評論社のサイトで読むことができる）
私について言うと、Q2とQ3はYesで、Q1はNoになる。プログラミング歴はPHPの2年半、Ruby歴は2ヶ月くらい？
でも全然問題無かった。むしろ（私みたいに）プログラミング歴浅い人こそ、この本をベースに基本的な概念を学んでいってもいいと思った。
せっかく読んだので、良いなと思ったところを2つだけ。
説明が上手
（どこから目線だという。すみません）
とにかく話が上手い。
まえがきでも触れられているとおり、各章が「例題の紹介 → 基礎知識 → 例題の解説 → 応用知識」という構成になっている。
この章立てのおかげで、読んでいる側は素直に読み進めていくだけでRubyのいろんなテクニックについて↓↓を自然にのみこんでいくことができる。
- 解決したい問題
- 1に必要な知識
- 2を使った1の解決方法
- 1以外の様々な類題のための知識
最初から逆引き的に使うのは難しいけど（一読後ならできる）、私みたいな初学者がRubyを「ひとさらい」するにはとてもちょうどいい。
なんというか、読んでいて「作者が読者に理解してほしいこと」がわかる。私はこれを読んで何を理解しなければならないか、次コードを書くときいつどれを適用させていけばいいのか、そういったことがなんとなく腹落ちする。
まえがきに対象読者が明記されていることからも感じられるけど、すごく練って書かれたんだなと思う。
私もブログとか発表資料とか書いていく中で見習っていきたい。
同一著者の関連記事が豊富
Rubyをやる前から筆者の@jnchitoさんのことは知っていた。それくらいアウトプットがすさまじい方。
チェリー本の中で何度か「ここらへんよく知らない人はこの記事を読んでね！」と伊藤さんのQiita記事が紹介されていて、例えば正規表現のところは特に必読として下記のシリーズが挙げられている。
初心者歓迎！手と目で覚える正規表現入門・その１「さまざまな形式の電話番号を検索しよう」 - Qiita
これがとても良い。すごく良い。
同じ文体で関連事項も学べるというのは読む側にとって大きなメリットだと思う。
たいていの人には文体がある。
同じ内容を伝えようとしても、人によって話し始めも違うし、言葉選びももちろん違う。
反対に、同じ人が2つの記事で違う内容を伝えようとするとき、話し始めや言葉選びは記事間で似通っている。
読む側は多かれ少なかれ、筆者のそういう癖に合わせてテキストを読む必要がある。（SNSで知らない人の投稿を突然読んでもよくわからなかったりすぐ誤読したりするのはこれがうまくできないからだと思う）
そういう意味では、例えば「Progateをやりながら、関連事項を調べるためにRailsガイドを読む」というのは（私もよくやるし良いことだけど今の話の文脈で言うと）文体のパーサをスイッチングするコストが知らないうちにかかっている。
この点「チェリー本を読みながら、関連事項を調べるために伊藤さんのQiita記事を読む」というのは読者側のスイッチングコストがほとんど0になる。
だから読者は同じ本のコラムを読むような気分で、本文と同じくらい濃い解説記事を読むことができる。
結果、疲れず飽きずスムーズに周辺知識も取り込むことができる。と思う。
他にも、例題解答の設計が現実的だったり、伊藤さんご自身も推していたように開いたままにしやすい紙を使っていたりと良いところはあるけど、特に感じた2つを挙げてみた。
「ここはもっと良くなれる！」というのは今のところ別に無いけど、もし読み返したときに思うところがあったらまたどこかに書く。
年末の3日間で読めてよかった、Rubyがんばろって思えた。
PHP Conferenve2018 聴講メモ #3 「アーキテクチャ設計とUX設計は同じなのか!!??」by 弁護士ドットコムさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドをご覧ください。
アーキテクチャ設計とUX設計は同じなのか!!??
デザインマネージャー 金子 剛 / 弁護士ドットコム株式会社
テーマ
UXデザインとエンジニアリング
テイクホームメッセージ
- ユーザーとプロダクトが直接かかわりあうことで双方向なカイゼンが生まれる
間によくわからないものが入ると一方向のものになってしまう - UXデザインとアーキテクチャ設計は「複雑な現実を抽象化する」という意味では同じもの
- UXデザインはデザイナーだけのものではない。エンジニアこそUXデザインを！！
内容めも
- 共創：全職種でチーム組んでアジャイル開発している
「何を作るか、どう作るか」の両輪。 - スタイリスト → UXデザイナー へのキャリアチェンジが増えている
スタイリスト = 目に見えるグラフィックを作る人。
デザインするものがグラフィックからUX = 体験にシフトしている - 「UXデザイン」はデザイナーの専売ではない
エンジニアが体験をデザインする、なんてこともあっていい。 - UXデザイン？
- 例：スターバックス（コーヒーではなく体験を売る）
コーヒーではなく「笑顔の店員さんからコーヒーを受け取っておしゃれなソファでPCを開く」体験を売っている - 例：Slack
システムそのもの・機能そのものではなく「みんなでわいわいチャットする」体験を売っている
- 例：スターバックス（コーヒーではなく体験を売る）
UXデザイン
ユーザー → ？？？ → 実装
間に別の存在が入ると情報が落ちる。
エンジニアがUXデザインにも入ると、生により近い情報をつかって実装が行える。
→ エンジニアもUXデザインをやろう！
- ユーザーは何者か？
モデリング = 具体的な特徴を洗い出して抽象化する（例：擬人化） - 何を提供するのか？
- どう行動してほしいか？
- その行動をしてもらうには、何を満たせばいいか？
Issueに落とせる - どう作ればいいか？ ← エンジニアに一番馴染みがあるのはたぶんここ
ユーザーのモデリング
デザイン思考 → 「あの人は怒っている……『怒る』って何だ？」
現実の複雑なものを、特徴によって定義付けて抽象化する。
そういう意味で、UXデザインがやっていることはエンジニアと同じ。DDD本とか読むと「これデザイナーも考えてることだ！」と思う。
ユーザー中心設計 → 中間生成物（レポート）→ プロダクト
中間生成物はユーザーの情報からプロダクトへ一方に流れてくるもの。
それをはさまず、ユーザーとプロダクトが双方向にかかわりあうことでカイゼンが回せる。
参考図書
- 『エンジニアのためのデザイン思考入門』
- 『クリエイティブマインドセット』
- 『デザイン思考でゼロから1を作り出す』
質疑
- 普段エンジニアとどういう会話してるか
今はマネージャーだから直接現場に出てないけど、普通のスクラム体制だと思う。
KPIを軸に今必要なものやどう実現するかをみんなで話してる。ホワイトボードにいろいろ書いてわいわい話す。
やりたいことに対してエンジニアが技術を提案したりデザイナーがデザインを提案したり、といった感じ。
感想
発表内容自体が「複雑な現実を抽象化」を体現した議論ですごく面白かった。
デザイナーさんがDDD本読むって何事……と思ったけどだからこういう話ができるんだよなあ、周辺領域のインプットは人を深くする……。
個人的にいずれ企画サイドも手出したいと思ってたからちゃんと勉強しようと思った。
あとスライド、すごくおしゃれで素敵だった！！
PHP Conferenve2018 聴講メモ #2 「VOYAGEのエンジニア評価制度ってどんな感じなのか25分でミニ再演」by VOYAGE GROUPさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドやブログ等の公式資料をご覧ください。
VOYAGEのエンジニア評価制度ってどんな感じなのか25分でミニ再演
林 志嶺 / 株式会社VOYAGE GROUP
テーマ
VOYAGEの技術評価会
発表者・評価者が重視するポイント
PHPカンファレンス2018で技術力評価会を再演します！企業ブースでは評価資料の公開も！ - VOYAGE GROUP techlog
テイクホームメッセージ
- 技術評価会：地味かもしれないけどがんばったことを説明する
- 準備（非評価者 + アドバイザー） → 発表（評価者2名） → 評価すり合わせ → フィードバック → 昇格
- 評価者の総評は社内公開される。1日くらいかけて書く。
- 発表内容・評価
- 背景ややった内容について、理由を明確にする
- 評価者はやらなかったことも確認する → 意思決定全体を説明することになる
- 実際の設計やコードも評価に含める
- 前回からの成長も評価ポイント
- 評価は褒めるが基本。改善余地のあるところはアドバイスをつける
- 評価は本質ではない、評価を恐れずに本質的な仕事をしよう！
内容めも
VOYAGE GROUP
- 広告：SAP, SSP。月間数百億imp。ログは1日でテラバイト単位に。。。
- ポイントメディア：1,400万人の会員
- インキュベーション：いろんな分野
評価制度
地味にがんばったこと、そもそも評価されにくい
- ライブラリのアプデ、アラートの撲滅
- 仕様把握・要件定義のフェーズも、がんばっても理解されない
→ 「がんばったけど、実はたいしたことなかったのかな……？」へこむ
技術力評価会
準備 → 発表・評価（実演30分＆質疑60分。評価者2名）→ 評価すり合わせ → フィードバック → 昇格！
再演！
準備段階で、アドバイザーと一緒にマークダウン1枚で概要・背景・やったこと（進め方・実装）をまとめる。
背景は特に他の人には見えにくいので、力を入れて説明。評価者も重視する。
準備資料を元に、評価者の前で説明↓↓
- テーマ：ポイントメディアにおける運用タスクである「ポイント失効」の自動化
運用タスク全体は告知・減算処理・経理報告。間違えると大事故になる部分。 - 背景：減算処理、間違えられない作業かつ大変だったから自動化したかった
- 制約：スケジュール、人員の面での制約
評価者「なぜそういう制約が？」 - 解決スコープ
- 提案したこと、工夫したことのアピール
- 今回やること・その理由：○○までに〜をやる、その後☓☓までに〜をやる
評価者「ドキュメントはあったの？」「誰とどう進めたの？」 - 今回やらないこと・その理由：
評価者「この内容、やるとしたらどれくらいかかるの？」
やったことは見えるけど、やらなかったことは見えない。どういう案を出してどういう意思決定を行ったか、説明するし質問する。
- システム構築
- 設計、技術選定、コード
評価者「なんでこの言語を選んだの？ 別のこういう選択肢もあったと思うけど」
考え方だけでなく、コードも評価に含める。**
- 設計、技術選定、コード
- 評価してほしいポイント
評価者「新旧バッチで結果が異なっていたら一大事。どうやって一致を確認した？」
（被評価者「対象ユーザー数など集計値の確認、ランダムサンプルでいくつか個別チェック」
終わったら評価者が総評。社内に公開されるため1日くらいかけて書く。
ダメ出しではなく良いところの評価がメイン、加えて「こうできるともっと成長できるよ」をコメント。
評価を恐れず、本質的な仕事を！ それぞれの環境でがんばっていきましょう。
質疑
Twitter上で募集して、後日ブログで回答してくださるそうです！
感想
発表者の方が被評価者として話をして、評価者の方が質問しつつ、また別の方がオーディエンス向けに解説してくださるスタイルだった。
壇上の被評価者が答えに窮する場面もあって、これガチでやってるなと。すごい。
ちょっと前までまさに「外から見えない意思決定」にけっこうな労力割いてたから、それをきちんと説明できる場があってうれしい気持ちよくわかる。。。
自分のいた環境と違うのは「評価が全社に公開される」っていう点。給料が上がっても昇格しても、具体的にどこでどういう努力と成果を上げたのか外から見えなければ"席の離れた"人とポジティブな関係が作りにくい。
オープンな文化憧れるなー、1月のも聞いてみようかな。
