2018年10月アーカイブ

「反省文を書く」は個人攻撃たるか

この記事は私自身の過去の反省文です。

技術的な問題やミスがあった場合に、その原因を掘り下げ、同じことが起きないよう仕組みそのものを見直す、なんていうのは今さら言うまでもなく当たり前のことだと思っている。もちろん過去も思っていた。これを行うためには、ミスや問題に直面した人にそもそも何があったのかを詳細にまとめて報告してもらわないといけない。そのことを指して少し揶揄してのつもりで「反省文書いて」という表現を私は過去に使っていた。でもそれは良くないことだと今さら反省している。

反省文と聞くと、本来の意味はともかく、普通の人はどう思うか。小学校や中学校のときになにか教師に怒られるようなことをしたあとに書かされる「私が悪かったです、すみません。」な文章を思い浮かべる人が多いと思う。本来の意味でもやはりなにか悪いことをしたという前提が置かれることが多いように思う。このため「反省文」と聞くとその悪いことを責められるというイメージを持つ人が多いと思う。

でも私はそんな「悪かったです、すみません」な謝罪が欲しかったわけじゃない。どうしておけばそういうミスや問題が起こらなかったかをはっきりさせたい、場合によっては対策もしておきたい、と思っていた。

とはいえ、「反省文」という言葉を使う限りはそうとは捉えない人が多かったんじゃないかと思っている。むしろミスを積極的に責め立てようとしているという印象を与えてしまったんじゃないかと思っている。個人攻撃に走ると課題解決には悪影響しか与えないのは言うまでもない。個人攻撃をしようとしてるんじゃないかと疑われることもやはり課題解決には悪影響しか与えない。

「The DevOpsハンドブック」読んだ

DevOps的な考え方・業務の回し方を、DevOpsがもてはやされる前から実践してきた人たちが、今一度立ち戻りDevOpsとは何なのかを、これから実践する人向けに解説した本。具体的な会社での導入事例を豊富に取り入れて解説に付け加えているのが特徴になっている。

手放しに喜べるような万能の手法ではない、と前置きをしながらも、どうしてもこのアメリカ的な文章のせいで、手放しに喜ぶようなノリの文章になってしまっているのが少し気がかりだった。そもそもこの本の解説から理解するなら、DevOpsって手法のことじゃなくて、単に業務の回し方に対する考え方でしかないように思えてしまう。そう、技術の話じゃなくて、業務プロセスの話。

変更を反映させるまでのデプロイのチェーンに問題があった場合はその解決にみなで協力して当たる、というのが正しい方法だという記載がある。ただ実際には、現場は作業の細分化が進んでいて各々は自分の担当の業務に手いっぱい、直接は担当じゃないとこの問題にまで手を伸ばせる余裕のある人は少なく、結局いつも臨機応変に手を伸ばせる器用で全体もよく見えている人ばかりが対処する。そういう役回りの人が消耗していき、特に上から評価もされない場合は成果とみなされず給与にも反映されず、そして去っていく、というような姿になってしまうというのが欧米では多くなるんじゃないかと思う。

本を読んでいて気に止まった点をいくつか

11.3 まとめより、「燃え尽き症候群になる率は低いのだ。」アメリカでも燃え尽き症候群みたいな話はあるのね。まぁあっちだと離職して少し休みその後転職というのはよくある話なのに対し、日本だと一度ドロップしてしまうとなかなか戻れないという違いはありそう。

17.2 機能テストにはA/Bテストを組み込むより、「価値を産まない機能を機能を1つ作るよりも、チーム全体に休暇を与えたほうが会社や顧客のためになる」、お、おう。そこまで割り切れる会社は日本にはほとんどないだろうなぁ。

19.6 回復力と学習を生み出すために本番環境にエラーを注入するより、Netflixが意図的に本番環境に擬似的な障害を起こして訓練にする話は今は結構有名になったのかな。Chaos Monkeyでググるとたしかに結構ヒットする。本番環境に手を加えるなんて、日本の大企業じゃ絶対にやらないよねぇ。

20.1 チャットルームとチャットボットで組織的な知識を自動的にキャッチするより。チャットルームにオペレーション状況をリアルタイムに全員に流す話と特定の人にだけ情報を届ける電子メールとの対比がある。チーム規模にもよるけど、情報をあえて一部の人にのみ開示してコントロールするのがマネジメントだと信じる人も少なくないので、やっぱこういう話は大企業ほど抵抗があるだろうなぁ。

個人的な意見かもしれないけど、やっぱDevOpsって技術の話じゃないと思う。コードを変更してからそれを反映した本番環境を作るとこまでを自動化・効率化・高速化する、なんて話は当たり前にしか感じない。組み込みの世界だと、ビルド用PCのセットアップ・各種ツールのインストール・ソースコードのチェックアウト・ワンストップなビルドシステム・ターゲットイメージの生成・ターゲット実機への確実なイメージの書き込み・標準化された自動テスト、あたりはソフトウェ開発者ならワンストップでとまでは言わないまでも手順化・自動化しているのは当たり前だと思う。

と、DevOpsそのものに否定的な意見の内容になってしまったけど、DevOpsを知るという意味では丁寧にかつ全体を追って書かれた本なので安心して読める。

このアーカイブについて

このページには、2018年10月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2018年9月です。

次のアーカイブは2019年1月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

月別 アーカイブ

ウェブページ

Powered by Movable Type 5.2.13