｢失敗から学ぶRDBの正しい歩き方｣読んでた

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

id:Soudai さんこと曽根壮大さんの｢失敗から学ぶRDBの正しい歩き方｣, ちまちまと読んでいました. 結論から言えばめちゃくちゃ良い本という感想で, これまでMySQLなどデータベースのアンチパターンについて本で学ぶ時には, ｢SQLアンチパターン｣が最良の選択肢といった感じでしたが, ｢失敗から学ぶRDBの正しい歩き方｣は, それと並ぶ立ち位置にある本だと思います.

SQLアンチパターン

｢SQLアンチパターン｣, 非常に良い本なのですが, どちらかというと初心者向けではなく, ある程度データベースを使ったプロダクト開発の経験を積んだ上で読んで, ｢こういうアンチパターンがあるのか...｣とか, ｢これってあの時踏み抜いたやつだ...｣みたいな感じで, 知識を整理する時に役立つ... という感想を持っています. それに対して｢失敗から学ぶRDBの正しい歩き方｣は, さまざまなアンチパターンに対して, どういう経緯で陥っていくのか...? という部分が物語っぽく紹介されていたりするので, 新卒入社のエンジニアとか, これからデータベースを学んでいくぞ! という人も, アンチパターンのイメージがしやすくなっているように思います. データベースのアンチパターンと向き合う最初の一歩として最適ですし, ｢SQLアンチパターン｣を読んで, まだとっつきにくいな... という感想を持った方は必読でしょう.

一方で, ｢SQLアンチパターン｣を既に読了した方からすれば, ｢失敗から学ぶRDBの正しい歩き方｣は若干の物足りなさはあるかもしれません. とはいえ, だからといって購入する価値が一切ないのか? といえばそうでもなくて, とはいえ新人教育などの場面で教本として｢失敗から学ぶRDBの正しい歩き方｣を渡し, アンチパターンを踏んだ時に｢これは"失敗から学ぶRDBの正しい歩き方"にある, ○○というアンチパターンで...｣と紹介する, みたいな使い方ができると非常に有用なので, そういう機会がありそうな方は一通り目を通しておく価値はあると思います(自分の場合は, ｢こういうのあったなー｣とか, ｢あるある〜｣みたいな気持ちで読み進めていました).

以下個人的な感想ですが, 著者の id:Soudai さんはかつて同僚で, とてもお世話になっていた(本当に頼りになる兄貴みたいな人で, 最近もちょっといろいろ相談させてもらう機会があったりしました)のですが, 違うチームで働いていた事もあり, 技術的な話題をみっしり伝授してもらう... という機会を作れないまま転職されてしまったのが, 個人的な心残りでした. 今回, この本を通して, id:Soudai さんからデータベースに関する知見を伝授してもらう事が出来て, 若干念が晴れたような気持ちを持っています. 会社は違いますが, これからも本や勉強会を通して, いろいろな知見を伝授頂きたいですね. 次の本も楽しみにしています!!!

｢小さな習慣｣を読んだ

小さな習慣

...どこかでオススメされたのか, Kindleに入っていたので最近ちまちまと読んでいました. 個人的な課題として, 例えば本を読んだり, コンスタントに(業務外で)コードを書いたり, そういうポジティブな習慣があまり身につかないので, その辺りのヒントにならないかな...? と思って読んだのですが, なかなか面白かったです.

この本では, 例えば｢本を読みたい｣, ｢文章を書きたい｣といった目標を叶えるため, タイトルの通り｢小さな習慣｣を続けることで, そういった活動を定着させるとよい... と紹介されています. ｢小さな目標｣とは, 例えば, ｢運動して痩せたい｣であれば, ｢毎日1回腕立て伏せをする｣みたいな感じです.

とにかく, 馬鹿らしい程に目標を小さくすることで, ｢面倒...｣, ｢大変...｣という気持ちではなく, ｢まあ, それくらいなら...｣と思えるようにする. そうして腕立て伏せを1回やってみると, 時と場合によっては調子が出てきて, 2回, 3回... と続いていったりする. そうやって, ある程度の成果を毎日出しつつ, 毎日繰り返すことで習慣にする... という感じでしょうか. 毎日継続できると, ｢やれている!!!｣という気持ちになって, 自己肯定感を得られそうなのも良さそうです.

何かしら, 新しいことを始めよう! という時は, 結構｢大きな目標｣を作りがちで, だからこそ理想と現実のギャップとかが生まれて, 最終的に心が折れる... みたいな事がありがちに思います(自分自身の過去の経験も踏まえて...). そうならないように, ｢小さくはじめて, 継続し, 結果としてたくさんの成果を得る｣ことを目指すわけですね. ...そういえば, 仕事をするとき, ｢なんとなく元気が出ない時は, 簡単なタスクに取り掛かってみて, それでエンジンをかける｣みたいな事をするのですが, これもまた｢小さく始める｣という意味で似ているところがあるなあ, と思ったりしました.

まあとりあえずやってみよう... ということで, ｢本を1日2ページ読む｣とか, ｢業務以外で1 commit or 技術/読書エントリを50文字書く｣とか, 早速｢小さな習慣｣を考えて, やっていってみることにしました. 自分の場合, コンプリート欲(= 毎日続けたい! 埋めたい! と思う気持ち, 有る種の収集欲?)が強いように思うので, それもうまく働いて, ここ1週間くらい｢小さな習慣｣を毎日続けられています(これからどうなるかはわかりませんが...). 今日も｢なんとなくだるいな... 早く寝たい...｣という気持ちが強かったものの, いざ｢技術/読書エントリを50文字書く｣ため, ブログの編集画面を開いて｢小さな習慣｣の感想をちょこっと下書きしよう... と思ったのですが, 予想以上にスラスラと書き続けるが出来て, 最終的にはだいたい仕上げることができました.

そんなに分量も多くなく, また｢小さな習慣｣がなぜ有効なのかについて, 研究成果を元に考察されていたりして, そういう意味でも読み応えのある本でした. とはいえまあ, 個人的にはこの本に書かれている事が本当に価値のあるものだったのか? という判断は, 1ヶ月後とか半年後とか, あるいは1年後に, 今のところ続いている｢小さな習慣｣がどうなっているか...? というところでやっと判断できると思っているので, 無理のない範囲で引き続きやっていきたいと思っています. 果たしてどうなることやら...

障害対応五訓

※このエントリは, 技術書典6で頒布された｢Hatena Tech Book｣に寄稿した, ｢障害対応五訓｣をブログに掲載したものです.

papix.hatenablog.com

Webサービスを運用していると，さまざまな障害と出会います．当然，そんな障害とは一切出会わずに済むのが一番ではあるのですが……．とはいえ，どうしても立ち向かわなければならないときがあります． これまで5年ほど，業務としてWebサービスの開発や運用に携わってきて，さまざまな障害と直面し，たくさんの成功や失敗を経験してきました． その中で，障害に立ち向かう際に求められる振る舞いや，解決に至るために必要なアクションについて，いくつかの気付きを得ることができました． そのような知見を，「障害対応五訓」としてまとめてみたので，紹介します．

障害とは非日常である

鳴り響くアラート，騒がしくなるオフィス，ターミナルには大量の文字が流れ，エンジニアの額には汗が浮かぶ……． 障害対応は，日々Webサービスを開発し運用している人たちにとっては切っても切り離せない存在ではありますが，日常の開発とは異なり，予測不可能で，臨機応変な対応が求められ，それゆえに緊張感が高まる状況と言えます．

自分の場合，障害が起きるとどうしても慌ててしまいます．自分が心をこめて開発しているプロダクトを早く復帰させて，利用するユーザーへの影響を最小限に抑えたい． そしてその焦りは，得てして障害対応の場面において本来は不要なはずの，過剰な高揚感に繋がりかねません． そんな焦り，異様な高揚感といった感情をきっかけとして，障害対応に取り組む中でオペレーションミスをしてしまったり，コミュニケーションが粗雑になって雰囲気が悪くなってしまったり，伝えるべき情報が然るべき人に伝わらなかったりといった二次被害が発生することもあります．

このような二次被害を防ぐには，障害に陥ったプロダクトの状況を正しく理解し，必要な手を打ち，チームメンバーがそれぞれの役割を果たして冷静に行動することが重要です．そのためにも，会社やチームによって障害対応時のマニュアルやワークフローを定め，それに則って行動することが重要です．特に，障害が発生したと伝える必要がある人たち（ステークホルダー）や，障害対応時によく陥る落とし穴などの情報がまとまっていると，慌てがちな障害対応の初動において，非常に便利な道標となります．

加えて，当然ではありますが平常心を持って障害に望むのも重要です．とはいえ先にも述べたように，障害は予測不可能で突然訪れるので，何も準備のない状態で完全な平常心を保つのは難しいところがあります．

そこで，せめて「障害対応の時，平常心を保てなくても，ここだけは抑えておきたい」というポイントを「障害対応五訓」として選び，会社やチームの定めるマニュアルやワークフローとは別に、個人としての心がけとして思い出せるようにしました．

障害対応五訓

心は熱く，頭は冷静に

障害が起きたとき，自分は慌てがちであると同時に，心が熱くなるタイプの人間です．そういった感情が，障害の解決へ至るまでの力に繋がる部分もあるのですが，とはいえ頭まで熱くなると，視野が狭くなり，最適な選択肢や情報を見逃してしまいがちです． 心は熱く煮えたぎらせて力に変えつつ，一方で頭は冷静になって，起きている出来事に対して視野を広く保つことが大事だと思いました．

まずは深呼吸，そして役割分担から

障害が発生すると，急激に気持ちが高ぶります．特に，自分のコードやオペレーションが原因で障害が発生した場合などは，「早く回復しないと！」という気持ちや，「やってしまった……！」という気持ちがごちゃ混ぜになって，冷静に振る舞うこと難しい場合があります． 結果として，そのまま勢いでなし崩し的に障害対応に向かってしまいがちです．

そうならないように，障害が起きたらまずは深呼吸をして，一呼吸置くことが大事だと思いました．高ぶった感情とそれに伴って熱くなっている頭を，いったん通常の状態に戻すイメージです． また可能なら，チームみんなでいったん深呼吸してリズムを合わせ，会社やチームで定めたマニュアルなどを参照しながら，「役割分担」の確認から障害対応を始めていくのが良いと思います．

チームで障害に立ち向かうときは，「考えるリソース」を原因の調査や対応に割けるように，それ以外の部分はなるべく考えなくても進むように準備することが大事です．対応の指揮者は誰が担うのか，記録を残すのは誰か，実際にオペレーションをするのは誰か，プロデューサー・ディレクターや営業といった他職種のメンバーとコミュニケーションを取るのは誰か……． 最初に役割分担を丁寧に確認することで，障害対応の途中に「このタスクは誰がやる？」で右往左往する事態を大幅に減らせるはずです．

プランB，プランCまで考える

障害に立ち向かっているとき，特に原因が明らかでない場合には，計測と調査，原因の推測を繰り返し，その結果見つかった対応策に片っ端から取り組んでみて，その結果どれかが当たって沈静化する……，というパターンが多いように思います． とはいえ，時と場合によっては1日で解決せず，数日〜数週間の規模で障害が続くこともあり得ます．

障害対応が長期化したときには，サービスへの影響を考慮しつつ，「現在の段階ではここまで」といった最低限のラインを定め，そこを目指して行動するという意思決定も求められます． 目先の問題だけに捕らわれず，それが効かなかった場合の次の一手や，サービスとして必ず死守したいラインについても，平行して考慮していくことが大事だと思いました．

休憩するのも仕事のうち

障害が長期化したときはもちろんのこと，すぐに解決できることが見込めるときも，「動く人」と「休む人」をきちんとアサインするのは大事だと思いました． 長期化したときには，きちんと稼働と休暇の管理をしないと最終的には誰も動けなくなるという事態に陥るかもしれません．また障害が幸いにも長期化しなかった場合でも，障害に立ち向かった人はどうしても消耗しがちです． そのため，例えば障害の恒久的な対策や，影響範囲の調査を担えるメンバーを温存しておく（そのため障害対応中にしっかり休んでおいてもらう）ことは重要です．

仲間が苦労して障害に立ち向かっている中で休むのは罪悪感がかなりありますが，とはいえ「休憩するのも仕事のうち」です．その休憩が，障害対応の次の一手に必要不可欠と思って，しっかり休むようにしたいものです．

広く意見を募り，謙虚に受け止め，解決への糸口を掴む

一緒に障害に立ち向かう仲間は，それぞれ違う経験やスキルを持っています．さらに，はてなにはさまざまな経験・スキルを積んだエンジニアが他チームにもたくさんいます． 障害に立ち向かうにあたっては，その障害をさまざまな視点で眺め，解決のためのアクションを見つけることが重要です．そのため，仲間の力をうまく引き出すことは，障害を解決する近道だと言えます．

障害に対応しているとき，普段以上の情報が脳内を，チームを，そして社内を駆け巡ります．そういうときに，仲間の意見を受け取ったり引き出したりするアクションへの優先順序が下がったり，あるいは仲間が出してくれた意見を受け取る余裕がなくなってしまうことがあるように思います．障害対応のときはもちろんのこと，常日頃から謙虚な気持ちを忘れず，仲間の意見をうまく引き出してインプットし，視点を増やして障害解決へ至るきっかけを探していくことが大事だと思いました．

最後に

実際に障害へ対応する中で自分なりに気付いた，障害対応における大事なことを「障害対応五訓」として紹介しました． この五訓を一言でまとめると，なんとなく「まずは落ち着く」という言葉に集約される気がします． 障害対応の中で落ち着くためにどうするか？ そして落ち着いた上でどういうアクションするか？ ということがまとまっているように思います．

最初にも述べたように，障害は遭遇しないに越したことはありません．とはいえ，突然皆さんの前に立ちはだかるものなのです． そういった事態に備えて，皆さんも「ここだけは押さえておきたいポイント」を常日頃から考えて，備えておくのはいかがでしょうか．

｢ハーバード流交渉術｣を読んだ

最近社内でいろいろなミーティングに参加する機会が増えてきて, その中で自分達の意見を伝えたり, うまい着地点を一緒に探っていく機会が少しずつ増えてきました. 一方で, そういう時の振る舞いや注意点など, 結構模索しながらやっていたので, 会社の同僚に教えてもらった｢ハーバード流交渉術｣という本を読んでみることにしました.

ハーバード流交渉術 (知的生きかた文庫)

なんとなく, ｢ハーバード流｣とか強そうな(?)タイトルがついているので, ｢えっ, そんな方法で!?｣みたいな, 突拍子もない飛び道具的な方法が紹介されそう... とか想像していたのですが, その予想と反して素朴というか, 手堅いというか, ｢確かにここは抑えるべきだな...｣と腹落ちの行く内容が紹介されていて, 良かったです. 具体的には, 以下の4点が基本点として紹介されています:

• 人と問題を分離せよ
• 立場ではなく利害に焦点を合わせよ
• 行動について決定する前に多くの可能性を考えだせ
• 結果はあくまでも客観的基準によるべきことを強調せよ

個人的には, 以下のような内容が意識に残りました:

• 交渉に入る前に, 交渉相手と雑談したりして関係を持つと良い
• 圧力や混乱を防ぎ, より良いコミュニケーションを実施するため, 交渉に参加する人数を制限した方が良い時もある
• 可能なら, 交渉の前の検討段階から相手に参加してもらって, その成果についてお互い責任を持てるようにすると良い
• 向き合っている問題や, 現れた意見に対して相手の気持ちになって考え, 真に欲していることを導かないといけない(利害関係を明らかにする)
• 合意形成を急ぐ前に, 視野を広げて, 双方が利害に満足出来る選択肢を考え出さないといけない
• 交渉を助けるために, 客観的な意見や数値, 慣習といったお互いにとって公平な基準を用いるべき

...これまで何度か, ミーティングに望むにあたって｢自分の意図をきちんと相手に伝えられるよう, しっかり準備しよう...｣と時間をかけて案を練って共有したところ, 相手からすると｢突然, 案(意見)が降ってきた｣ように見えてしまって, 結果として議論が紛糾するという事が少なからずあったように思っています. なので最近は, ある程度20%〜30%くらいの完成度の素案が完成した段階でステークホルダーに共有し, 意見を求めながら一緒に進めていく... というやり方を意識していて, 今のところ以前よりうまくいっているように思っています(加えて, 意見を求めて一緒に取り組むステークホルダーも, なるべく少人数になるよう配慮してみています).

会社やチームの規模が一定以上になってくると, どうしても社外はもちろんのこと, 社内のステークホルダーとも交渉する機会が増えてくると思います. そういう時に, お互い後腐れなく(特に社内のコミュニケーションで, 議論が紛糾して険悪な関係になる... というのはやっぱり避けたいですし...), 交渉する原因となった問題をうまく解決出来るようにするには, やっぱり行き当たりばったりでは乗り越えられないので, ある程度の工夫(意識)が必要だと思います. その上で, 本書は道標になってくれる本だと感じました. ミーティングに出る機会が増えて, 自分の意見を伝えたり, ステークホルダーと意識のすり合わせをする機会が増えてきた... という方におすすめです.

JPAの理事に就任することになりました

...というわけで, JPAのブログでお知らせがありましたように, 一般社団法人Japan Perl Associationの理事に就任することとなりました.

blog.perlassociation.org

Perlは自分にとって, まさに｢青春の言語｣という立ち位置だと思っていて, Perlを通じて多くの人と出会うことが出来ましたし, そこから多くのことを教えてもらって, 育ててもらったと思っています.

昨今, Perlを取り巻く状況は年々厳しくなっていると思っていますが, とはいえプロダクト開発の中でガッツリと, あるいは日々の業務を支えるスイスアーミーナイフとしてPerlを仕事で使っている方, 更に趣味としてPerlを楽しんでいる方もまだまだいらっしゃると思っています.

JPAの理事として, そういった方々と, そのコアとなるコミュニティを引き続き支えていけたらいいと思います. 新体制となるJPAを, これからもどうぞよろしくお願いいたします.