Masteries

技術的なことや仕事に関することを書いていきます.

「仕事の問題地図」読んだ

仕事の問題地図 ~「で、どこから変える?」進捗しない、ムリ・ムダだらけの働き方

仕事の問題地図 ~「で、どこから変える?」進捗しない、ムリ・ムダだらけの働き方

会社のSlackで id:onk さんが推薦されていて, 面白そうと思ったのでさくっと読んでいました. チームで仕事をするにあたって現れる様々な問題点, 例えば「計画がない」, 「進捗がわからない」, 「モチベーション不足」, 「意見が出てこない」... それらに対して, どのようにアプローチしていくかについてのアイデアがまとめられた本です.

個人的には, 最初の「計画不在」の章が良かったと思っています. 昨今いろいろな計画を建てる機会が増えてきていて, どのように計画を作るか... というところで試行錯誤していたので, 良いアイデアを幾つか見つけることができました.

  • 構造化してみる
  • 計画表を書いて相談してみる
  • 未知か既知かを皆で判断する
  • 情報共有の旗振り役を置く

「構造化してみる」では, 仕事(タスク)を複数の段階に分けて構造化するアイデアが紹介されていました. 第1段階では命題(テーマ)を書き, 第2段階には目的を, 第3段階に目的達成のためのアクションを, 第4段階以降はそのアクションを成し遂げるために必要な細かな作業項目を, それぞれ"モレなくダブりなく"書き出していく... という形で構造化していく方法です. そこそこの規模のプロジェクトを開始するときは「インセプションデッキ」などのテンプレートが使えますが, 小規模〜中規模なタスクの計画であれば, この構造化を使った計画作りをうまく使えそうな気がします.

やはりチームで仕事をやっていくにあたって, 「銀の弾丸」と言えるものはなくて, 本書でも仕事をするにあたっての問題を文章化して図示して(地図にして)理解しやすいようにして, それに対する地道な解決案を示していく... という感じになっていて, 分析すること/それを元に手を打っていくことが重要そう, という気持ちになりました. とはいえ, そういう時に分析の助けとして, あるいは分析結果から次に打つアクションを考える種として, 本書があると「そういえば, 似たような内容が...」という感じにヒントとして使えそうです. また, 「はじめに」に書かれているように, チームでこの「問題地図」を眺めて, いま自分たちのチームにはどの辺に問題点がありそうか? と発見する目的で使うのも良さそうです.

そういう意味で言えば, 社会人になって2〜3年目くらい, 徐々に業務に慣れてきたタイミングでこの本を読めると, 視点が個人からチームに広がって良い影響があるのではないかと思います. 個人的には, ここ数年で視野が広がった感覚があるので, 「視野が広がった!」というよりは, 「視野が広がって見えてきた問題点に対して, こういう向き合い方ができるかな...?」と考えながら読むことができました. サックリ読めますし, 良い本だと思いました.

「Gotanda.pm #19」でJSONの話をしました

「Gotanda.pm #19」でJSONの話をしました. 普段何気なく使っているJSONですが, JSON, JSON::PP, JSON::XS, Cpanel::JSON::XS, JSON::MaybeXSとかたくさんのモジュールがあったりするので, それらの紹介や各種Tipsの紹介などをしました.

boolean_values でJSONのture/falseをPerlでどのように表現するかを変更出来る...という話をしたのですが, id:karupanerura さんからその実用例を教えてもらったり(受け取ったJSONを更にMessagePackに変更するとき, MessagePackのture/falseに対応したものをセットしておくと便利)とか, あとは id:kfly8 さんがCpanel::JSON::XSの特徴を話してくれたりとか, いろいろ学びがありました. あとは今更dualvalueのことを知ったりとか...

金曜日ということもあって(?)疲れがたまっていたのか, 懇親会はちょっとぐったりしていたのですが, 総じてPerlの話題が盛りだくさんで楽しい勉強会でした. また次回も参加したいと思います!!!

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

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

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

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

SQLアンチパターン

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日で解決せず,数日〜数週間の規模で障害が続くこともあり得ます.

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

休憩するのも仕事のうち

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

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

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

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

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

最後に

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

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