$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト

自分の置かれた環境で問題意識を感じることってありますよね。例えば

  • 上司全然ちゃんとやってくれないじゃん!最悪!
  • 会社にこういう問題あるじゃん!なんで直らないの!最悪!

みたいな感じ。

昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。

昔に自分がよくやっていたアクション

問題意識を感じた時、昔に自分がよくやってしまっていたのは

  • 飲み会の場で愚痴る
  • 上司に詰め寄る
  • 問題意識だけを提起する

というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。

最近の意識の変化

しかし今から思い返してみると、上記したようなアクションでは、効率的に良い状況に変化させられない場合もあるなと思い直しました。そこで最近は問題意識を感じたときは、効率的に良い状況に変化させるために、問題意識だけを提起するよりも良いアクションはないかと吟味してから行動しようと考えるようになりました。

このように意識を変えてみたところ、昔と比べてより素早く/より質もよく問題を解決できるようになってきたなと手応えを感じることが増えました。意識を変えたのは非常に良かったです。

どんなアクションを取ってみているか

ここからは意識を変化させてから、どのようなアクションを取ってみたかについて書いてみます。例えば以下のようなことをするようになりました。

  • 提案先を考える
  • 解決の一案も含めて提案する
  • 自分が良いと思ったことをエイヤッてやってしまう
  • 頑張るんで自分に任せてくれ〜と言っちゃう
  • 自分の領域外のこともやる
  • 他の人にやってほしいと思う行動を、自分がやる

提案先を考える

まず問題意識を感じたときは、どこに相談しようかな?と考えるようになりました。

例えばオフィス環境を良くしたい!と思ったときに、これ辛いんすよねってマネージャとの1on1で提案してしまいがちでした。けれど意識を変えて、オフィス環境を良くしたいって一番思っているのは総務部だろうから、そこに直接相談してみよ〜と思うようになりました。

このように自分が感じる問題意識を、実は自分よりも強く問題意識を感じていそうなところに提案するようにしてみたら、親身に相談にのってくれることが増えたなと感じています。

解決の一案も含めて提案する

提案先を考えた次には、この問題意識を解決するためのアイデアは何かないかな?ということを考えるようにしてみました。例えばこの会議室リモートで使いづらい!と思った時には、テレビの配置をこう変えたら良くなりそうでは?というアイデアも含めて提案するようになりました。

イデアも含めて提案すると、そのアイデアを草案として、もっとこっちのほうが良いのではないかとか、この観点はどうかとか、建設的な会話をしやすくなったなと感じています。

自分が良いと思ったことをエイヤッてやってしまう

提案をするのではなく、自分がエイヤッて勢いよくやっちゃうという選択肢も考えるようになりました。自分が問題意識を持っているのだから、自分が責任持ってやるぞ〜という世界観です。

エイヤッてやることは、かなり早く物事が進む方法だなと思っています。問題意識を持っている自分は熱量も高いから、たぶん一番素早く問題の解決が進むんじゃないかな。

そのかわり怖いですし、失敗することだって結構あります。けど結構おすすめです。成功したらめっちゃ褒められるし、失敗したとしてもその失敗から非常に多くのことを学べます。自分が致命傷を負わない程度にがんがん失敗していきましょうと思っています。

ちなみに成功率をあげるために最近僕がやっているのは、周辺の人に話を聞いて違う視点を得ることです。視野が狭すぎると失敗しやすいと感じているので、いろいろな方向から意見を聞いて成功率を上げるようにしています。ただし視野を広げすぎると今度は動けなくなるので注意。

頑張るんで自分に任せてくれ〜と言っちゃう

結構重要な問題だなと思った上で、これやるためにまとまった時間や権限や深い思考が必要だなと思ったときは、頑張るんで自分に任せてくれ〜と言っちゃうようにしています。任せてもらって時間や権限をもらえると、自分が行動できる範囲は非常に広がるので、問題を解決しやすくなりました。

これも「エイヤッてやってしまう」と同じような意味でおすすめです。「エイヤッてやってしまう」よりもさらに怖いけど、でも成功したときのリターンはすごく大きいし、失敗からの学びもより大きいです。

自分の領域外のこともやる

自分の領域外のこともやっちゃうようになりました。これは上司の仕事とか、これは他部署の仕事とか、そういうことを考えすぎると、解決する手段の幅が狭まってしまいます。領域外のこともやることで、難しそうと思った問題もさらっと解決することが増えました。

ただし、自分よりその分野の専門性が高い人への敬意は忘れないように注意しています。領域外のことをやりつつ、その領域の専門家には敬意を払ってちゃんとサポートしてもらえるように相談する。このようにすると効率的に問題が解決することが多いです。

他の人にやってほしいと思う行動を、自分がやる

他の人にやってほしいと思う行動があれば、まずは自分がやってみるということも心がけるようになりました。例えばプロダクトオーナーにもっとサービスのビジョンを語ってほしいと思ったら、まず自分が自分なりの考えでサービスのビジョンを語ってみる。そして僕はこう思っているのですが、プロダクトオーナー的にはどう思ってますか?と聞いてみる。自分がまずやることで、他の人にもお願いしやすくなったと感じています。

他人の行動を変えるのって簡単にはできないし、時間もかかる。でも自分の行動は一瞬で変えられる。なのでやってほしいと思っているなら自分でまずやるというのは良い選択だなと思っています。

ひとつ注意点

ひとつ注意点があります。僕は最初に「昔に自分がよくやっていたアクション」を書き、そのアクションでは効率的に「良い状況」に変化させられない場合もあるなと書きました。しかしこのアクションをやるなと言っているわけではありません。むしろやっていきましょう。

僕がマネージャをやっている時は、詰め寄られる/問題意識を提起されることよりも、全く相談されない/何も反応がないことの方が辛いのです。そのためマネージャ視点の自分は、愚痴る/上司に詰め寄る/問題意識を提起するみたいな行動もどんどんやってくれという気持ちでいます。やっていきましょう。

まとめ

ここまで問題意識を感じたときに自分が最近やっているアクションについて書いてみました。少し意識を変えるだけで「効率的に良い状況に変える」ことができるようになったと感じるので、意識を変えて良かったと思っています。最近やってみているアクションも参考になれば幸いです。

今回はどちらかというと問題意識を感じたときのボトムアップ的な考え方です。僕はマネージャのロールもやっているのでトップダウン的な考え方もまた書きたいなと思います。

おすすめ書籍

少し論旨とは違うのですが、問題解決というテーマで昔読んだおすすめ書籍も紹介しておきます。

ある問題が本当に重要な問題かどうかを知りたければこの本。

問題をどう解決するかの参考にはこの本。

アプリケーションは全員で監視する - 「入門 監視」を読んだ

最近話題になっていた「入門 監視」を読んだ。アプリケーションの監視をするための実践的なノウハウが詰まっていて非常に参考になる書籍だった。

この本では、アプリケーションを監視するための骨格となる考え方や、様々な層(フロントエンドからOSのメトリックまで)での監視の入れ方の実践的なノウハウ、さらには障害対応をスムーズに行うためのフローや障害の根本対応をチームで行えるようにするためのやり方まで書かれている。実践的なすぐに取り入れられるような内容が多く、「アプリケーションをどう監視したら良いか分からない!」「障害対応をもっとうまくやる方法はないのだろうか?」と思う人には参考になる部分が多いと思う。


個人的にこの本の中で一番良いなと思ったのは、

  • SREだけでなくアプリケーションエンジニアも含めたアプリケーションに関わる人全員で監視を考えていくことが大事
  • むしろアプリケーションエンジニアはそのアプリケーションに誰よりも詳しいはずなので、アプリケーション監視のデザインのための知識を誰よりも持っているはず

という話。最近僕のチームではSREがチーム内に所属するようになったためアプリケーションエンジニアにいろんな運用知見が伝えられた。それにより以前よりアプリケーションエンジニアも監視に詳しくなり自分たちで監視ルールを積極的に入れられるようになった。結果として、これまでアプリケーションの監視で漏れがあった部分が埋まってきていると感じている。この経験からこの本で書かれているような、アプリケーションエンジニアも含めて全員で監視を考えていくことに対する重要性に非常に共感できた

最近、監視はみんなでやろうという話を色んな場所で見かける一方、監視にアプリケーションエンジニアも携わるのが当たり前という認識が広まっているという状況にはまだまだなっていないなと感じている。そのためこの本をきっかけに、アプリケーションエンジニアとSREの監視に対する意識が統一され、監視を全員でやるのが当たり前という文化が広まると良いなと思った。


その他自分にとって参考になったのは以下のようなポイントだった。

  • 監視というとサーバのOSのメトリクスなどからやってしまいがちだが、できるだけユーザーに近いところから監視を始めるのが最適
    • HTTPのレスポンスコードやリクエスト時間など
  • 3章のインシデントの対応フローとインシデント対応の際に必要なロール。またアラートからその根本対応をするためのやり方


とにかく実践的な内容ですぐに取り入れられるので一読してみると良さそうです!

読書ノート

* 問題を解決するための適切なツールを組み合わせて使うのは良い。連携して使えないたくさんのツールを持つのはアンチパターン(例: ネットワークのレイテンシとアプリケーションのレスポンスの悪化を関連付けられない)。連携できて役割が異なるなら良い 343
* ツールは誰かが使っている、使っていたからという理由では選ばず、現在の状況で試し、評価することが重要 373
* オペレーションチームだけでなく全員が本番環境全体に責任を持つことが大事。ソフトウェアエンジニアはアプリケーションに誰よりも詳しいので、アプリケーション監視の仕組みをデザインするのには最高の場所にいる 426
	* 良い。実際にSREがチームに所属して、それによりアプリケーションエンジニアも監視を意識するようになった。それによりアプリケーションの監視の仕組み構築がもっと良くなったと感じる
* 監視サービスのコンポーネント: データ収集、データストレージ、可視化、分析とレポート、アラート 572
* データ収集の手法として、メトリクスとステータス情報を/healthに出力し、その出力を監視する手法がある 595
* まず監視を追加すべきなのは、ユーザがあなたのアプリケーションとやり取りをするところ 824
* 監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力を観察しチェックし続ける行為。アラートは、この目的を達成するための1つの方法でしかない 938
* 誤報はとにかく減らそう。アラートをチューニングする簡単な方法が1つある。 1080
	* オンコール担当は前日に送られたすべてのアラートの一覧を作る
	* 一覧にひととおり目を通しながら、各アラートはどのように改善できるか、あるいはアラートを削除してしまえないか自問自答する
* 監視自体は何も修復してくれないので、基礎にあるシステムを改善する時間を持たなければならない 1107
	* オンコールシフト中、場当たり的対応をしていない時間は、システムの回復力や安定性に対して取り組むのをオンコール担当の役割にする
	* 前週のオンコールの際に収集した情報を元に、次の週のスプリント計画にシステムの回復性や安定性について取り上げる計画を立てる
* オンコールローテーションは出勤日に始めると、チーム内で引き継ぎがやりやすくなる 1107
* ソフトウェアエンジニアもオンコールのローテーションに入れる 1157
* インシデント管理のプロセス
	* 1. インシデントの認識(監視が問題を認識)
	* 2. インシデントの記録(インシデントに対して監視の仕組みが自動でチケットを作成)
	* 3. インシデントの診断、分類、解決、クローズ(オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みとする)
	* 4. 必要に応じて問題発生中にコミュニケーションを取る
	* 5. インシデント解決後、回復力を高めるための改善策を考える
	* s: 簡潔によくまとまっている
* 数分以上かかる本当のサービス停止には明確に定義された役割が重要 1157
	* 現場指揮官、書紀、コミュニケーション調整役、インシデント対応役(作業員)
	* s: 現場指揮官は最もアプリケーションに詳しい人(例えばテックリード)が適切、コミュニケーション調整役はマネージャ(例エンジニアリングマネージャ)が適切、書紀はだれでも、対応役は全員でやる
* フロントエンド監視にはリアルユーザ監視とシンセティック監視の2つのアプローチがある 1693
	* リアルユーザ監視とは実際のユーザトラフィックを監視のデータとして使うこと(Google Analyticsでのフロントエンド計測とか)
	* WebpageTest.orgのようなものはシンセティック監視
* Navigation Timing APIのタイムライン 1791
	* s: ブラウザのライフサイクルを知るのに非常に良い図
* フロントエンド監視では 1871
	* 実際のユーザが見ているページのロード時間を監視しよう
	* JavaScriptの例外を監視しよう
	* ページのロード時間をCIシステムから計測し続け、ロード時間が許容時間内に収まるようにしよう
* 分散トレーシングとは。リクエストに一意なリクエストIDを「タグ付け」することで、そのリクエストがどのサービスにアクセスしたか、各サービスでどのくらいの時間を過ごしたかが分かる 2290
* OS標準メトリクスから監視を始めるのはアプリケーションが動いているかどうかという重要事項と関連が弱いシグナルから始めることになるため、おすすめしない 2330
    * ただしトラブルシューティングの味方になるので、全システムで自動的に記録しアラートは設定しないくらいが良い
* 8章にはOSのメトリクスや他のよくあるコンポーネントのメトリクスの説明があるので、知りたかったら読むと良い 2330

「実践Scala入門」読んだ

[asin:4297101416:detail]

読んだ。この本は「コンパクトなコップ本」を目指したと最初に書かれているとおり、この本を読めばひとまずScalaを書けるようになるなと思った。これからScalaを始めたくなったらまずはこの本を読んでおけば十分だと思う。

また、「コンパクトなコップ本」だけに留まらず、実践ではよく使うがコップ本ではあまり言及されていないような機能についても解説されていたことが非常に良かった。例えばコップ本ではOptionやEither、Tryなどを使ったエラー処理についてあまり書かれておらず、昔Scalaを始める時にエラー処理のやり方で詰まったことがあった。その時にこの本を読んでいたらもっとスタートダッシュが速かっただろうと思う。他にも実践ではほとんどの場合利用するsbtについても解説されているのも良かった。

こんな感じでScala入門するには最適な一冊だと感じました。

読書ノート

- javaでscalaのコンパイル後jarを動かす方法。scala標準ライブラリにクラスパスが通ってれば良い 20
- scalatestのscaladocは品質が高いらしい、あとで調べる 34
- オプションにnull渡すとnoneになるのでjavaライブラリをラップも出来る 104
- ジェネリックな型をサブタイプにする 109
- :で終わると右結合 130
- updateという関数は、代入で置き換えられる 140
- future周り教えてくれるのがいい。コップ本だとなかった? 158
- print:namer試したい 172
- partialfunctionにはマッチしないかもしれないパターンマッチを渡しても大丈夫 172
- sbtのビルドのスコープにはプロジェクト軸、コンフィグレーション軸、タスク軸があり、それらすべてでキーごとの値を変更可能 200
- sbtの設定できるキーの一覧は https://github.com/sbt/sbt/blob/develop/main/src/main/scala/sbt/Keys.scala で確認可能 204
- privateめそっどのテストに使えるtrait便利そう、ただパッケージプライベートで問題ないらしい 223
- AsyncFunSuite 226
- partial functionでcaseを全部書かなくて済む。isDefinedAtで呼び出しが成功するか確認可能 241
- extends AnyValして値クラスを作るとJVMレベルのオブジェクト生成が可能な限り行われないようになる 244
- メソッドから無名関数への変換処理をη-expansionというのは知らなかった 251