Konifar's ZATSU

私はのび太の味方じゃないわ、悪の敵よ

ドキュメントが更新されない問題

むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。

実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。

  • 使う
    • 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい
    • いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも
  • 詳細に書きすぎない
    • 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい
  • 管理者を置く
    • ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要
    • 個人的にはあんまり管理者は置きたくはない
  • 目線を合わせる
    • ドキュメントに対する感度は人によって違う。例えばドキュメントは気づいた時に皆で更新するものというような目線合わせは必要
  • 掃除をする
    • 何やっても必ず古くなるんだから、半年に1回くらいはみんなで大掃除するようなイベントを作る
    • そもそも整理できていないから気づかれず更新されないというのもあるのでこういうのは必要

書き出してみたけれどたぶんこれらはわりと細かい話で、一番大事なのはドキュメントが更新されやすくなるような最初の設計なんだと思う。

たとえばフローとストックをうまく分ける指針だとかディレクトリ構成だとか、適切なグループ分けや権限設定、ルールが守られていない時に自動検知してワーニングを出す仕組みなど、根っこの設計がないといたちごっこになりがち。

こういう設計を考えたりツール選定したりあるいは作ったり、社内に浸透させたりするのって、ある規模よりでかいと片手間ではできなくなる気がする。そういう専門チームが社内に必要になるのかもしれない。

自分の経験だと設計は途中から変えるのはわりとエネルギーがいる。途中から変えることに躊躇のない決断力や、そういうもんだよねと順応できる組織が結局のところ強いのだ。

なんかドキュメントが更新されない話からはだいぶ外れてきた。他の森の知見吸いたい。

共通認識を揃えて前置きの謝罪を減らす

不要な摩擦を減らすために、一言謝罪を入れてしまいそうになることがある。特にテキストコミュニケーションで多い。たとえば以下のような一言である。

  • 「横からすみません」
  • 「忙しいところすみませんが」
  • 「休日にメンション失礼します」
  • 「もう認識されていたらすみません」
  • 「行き違いだったら申し訳ないんですが」
  • 「自分の認識違いだったらすみません」

こういうちょっとした気遣いはとても重要で、それ自体を否定することはない。ただしやりすぎは健全ではないと思っていて、こういった謝罪による前置きは減らせるようにしていきたい。たとえば有休や育休を取る時には、ただの前置きだとしても謝罪はしない方がよいと思う。過度な気遣いは文化の形成においてマイナスに働くこともありうる。

これをどう解決するかというと、共通認識を揃えておくことが必要だと思う。

例えばSlackで「深夜にメンションすみません」という謝罪は、Slackの運用ルールで「メンションはいつでもOK。受け取る側が設定で工夫する」という話を決めて浸透させておけばよい。「横からすみません」という謝罪は、「気になったことはどんどん発言していくことを推奨する」といった指針を決めて皆が文化として受け入れられればよい。

とはいえ、こういう前置きの謝罪をしたくなる気持ちはすごくわかるし、「謝罪はやめましょう」というコミュニケーションもそれはそれで萎縮させてしまうことになりうる。関係性を築いた上で伝え方に気をつけて「遠慮はいらんですよ」と伝えていくのがいいのかもしれない。あるいは、この前置きの謝罪は不要ということ自体も共通認識として最初に揃えておくとよいのかもしれない。

Simple Bankを#10までやった感想

TECH SCHOOLが提供しているBackend master classの題材であるSimple Bankをやってみた感想を書いておく。最後までやってから書こうかと考えていたが、思ったより内容が濃くて忘れちゃいそうなので途中経過を書くことにした。

github.com

全31回分のYouTubeの動画を見ながら残高管理、送金を行える簡易銀行サービスを作成する形式で、いま10回分やってみたが結構よさそう。10回でどのくらいまでいくかというと、DBスキーマの設計・作成、CRUD制御のGoのコード/テストコード作成、Postgresのデッドロックや同時実行制御の理解、GitHub ActionsによるCIの設定ができる。

対象レベル

  • ある程度開発経験のある人が対象
    • Databaseとは？Dockerとは？Git/GitHubとは？といった説明はない
    • GoはTour of GoをやっておけばOK
  • Backendの開発経験はなくてもたぶん大丈夫
    • 写経とエラーメッセージを読むことに慣れていれば、YouTubeの内容をもとにキャッチアップできる構成になっている
  • 英語はゆっくりで聞きやすいのでカンファレンス動画とか見れる人ならたぶん大丈夫
    • 英語字幕をつけてくれているのでリスニングに自信がなくても理解しやすい

よかったところ

  • 動画の長さが10~30分くらいで短め
  • ひととおり必要なツールやサービスを体験できる
    • 単にGoでコードを書きましょうではなく、DockerやPostgres、GitHub Actionsなども順番に触れる
    • 11回以降のタイトルを見ると、DBのモックやAWSへのデプロイなどもカバーされているっぽい
  • チームで働く前提の構成になっている
    • 第1回がDBスキーマを設計してdbdiagramでドキュメントとして残すという内容
    • マイグレーションスクリプトや、Makefileの書き方なども丁寧に説明している
    • 第5回がCRUD操作まわりのGoのコードのテスト、第10回がGitHub ActionsによるCIの設定
  • エラーを起こしてそれを解決するという構成になっている
    • 動画内で原因や解決方法を説明するだけではなく、そのプロセスを学べる
      • トランザクションの同時実行制御に問題のあるコードを書いておいて、次の回でテストを書く時に修正する流れとか
      • GitHub Actionsでのテスト実行も、最初にPostgres DBのセットアップがない状態でエラーにしてから、ドキュメントを見てymlに設定を追加して試して、また違うエラーが出たら調べて、という流れだった
    • エラーを解決する時に、公式のドキュメントをブラウザで調べるところを動画で見れるのはよい
  • 毎回「公式のドキュメントを見ろ」と繰り返し言ってる
    • 説明をした後で、大事なのは公式のドキュメントを読むこと、と言っている回が何回かあった
    • これは自分の経験でもとても大事なことだと思う
  • 実際に動かして体験して理解する構成になっている
    • 第9回のTransaction Isolation Levelの説明では、 READ UNCOMMITTED、 READ COMMITTED、 REPEATABLE READ、 SERIALIZABLE をそれぞれセットした上で2つのターミナルからSelectやUpdateを流して結果を確認した

注意が必要なところ

  • ちょっと古い部分もある
    • 大きな問題はないが、ツールのバージョンが古いところがある
    • 動画内でも何度も言われているとおり、公式のドキュメントをちゃんと見ることが重要
  • 技術選定はわりとさらっと話されている
    • 第4回のdb/sqlかgormかsqlxかsqlcかという話は、簡単なPros/Consが話された上でsqlcを使うことにしている
    • gormなどと比べて、その後の回でトランザクション同時制御の話を説明しやすいという観点の選定でもありそう
    • 一から作らなくてももっと楽なやり方もありそうだが、まずはそういうことは考えず言われたとおりに触って体験するのがよい

こんなコンテンツが無料で受けられるなんていい時代ですなあ。

なかなか面白いので、時間を見つけて最後まで完走したい。こういうの毎回ブクマだけしてやらずに放置するので、まずはやってみた自分を褒めたい。えらい！！

採用活動におけるモジュール化と公開

最近、制度やカルチャーをCompany Deckとして公開したり、Podcastやブログで現在の状況や社内の雰囲気を発信したりする会社がすごく増えた。

Company Deckでいうと、10X や Ubie、Autify の資料はとてもよくまとまっていて素晴らしい。

こういった活動は、ソフトウェア開発においてモジュールを切り出してOSSとして公開するのと似ていると思う。

カジュアル面談や面接の中で何度も聞かれる質問を共通化して公開することで、都度説明するコストが下がり、直接話す場ではより深い話ができる。ライブラリを利用することで本来の実装に集中できるのと同じである。これは候補者にとっても企業にとってもよい体験となる。

また、公開前提で進めることで制度自体が自然とブラッシュアップされるという利点もある。例えば、給与レンジやグレードを考えるとわかりやすい。こういった分野は公開するのが難しい。ある程度の矛盾がなく納得感のある制度設計でなければ逆効果になりかねないからである。自前のツールをOSSとして公開する時、コードを見返して完成度が上がっていくのと似ている。個人的には、もっとライトに公開していく流れになるといいなと思うけれど、レピュテーションリスクもあるのでなかなか難しい。

エンジニアリングのメタファーで考えてみると、欲を言えばPull RequestやIssueが送れる形で公開してもらえるとさらにありがたいなと思ったりもする。色々な会社がこういった取り組みを公開してお互いにブラッシュアップしていくことで、採用におけるベストプラクティスが見えてきて候補者にとってもよい体験が提供できるとよいなと思う。

自分も過去に採用プロセスをまとめた採用面接ガイドなどを公開してきたけれど、先に挙げたCompany Deckの公開は何度かチャレンジしようとして未だにできていない。なので他の会社が公開しているモジュールをみると、素晴らしいなーと思う反面、嫉妬や焦燥に近い感覚を覚えたりもする。要するに「クソーかっこいいなー自分もやるぞ」という感覚である。採用活動において切り出せる部分はどんどん切り出して、実装プロセスも含めて公開していきたいものである。

成果が出ていても変化がないと飽きる

幸せについて本気出して考えていたら「組織の成果と幸福を高めるには信頼の文化が大事」という研究の話をGLOBISの動画で知ることになった。

発表者が言うには、コミュニケーションの中で信頼を生みやすい3つの質問があるとのこと。そのうちのひとつが「日々の仕事で学びや変化はありますか？」というもので、「人間は好成績を納めていても変化がないと飽きる」という言及があり、これはすごいわかるなーと思った。

成果を出しているとある程度は満たされていくが、それは必要条件であって十分ではない。成果を出しつつ、自分の経験やスキルの切り売りをしている感覚でこのままでいいのか悩んでいるという人も意外と多いと思う。成果が出ないと萎えてくるので成果を意識することは必要だが、同じくらい変化し続けることにも目を向けなければならない。

一方で、変化は疲れるから今のままでいいよという人もいると思う。そういう人はそのままで全く問題はない。周りから押し付けられる変化はたいていつらい。

ただ、自分から変化のきっかけを作るのもそれはそれで結構難しいというか、できる人は意外と少ない。僕がかつて小僧の頃通っていた学校の席替えや年間行事のように、ある程度の半強制的な変化を設計しておいた方がいいのだと思う。

たとえば部署を変えてみたりプロジェクトを変えてみたり、そういうことができる組織は変化を感じやすいのかもしれない。3ヶ月ごとくらいで環境を変えられるような組織の設計だと、「日々の仕事で学びや変化はありますか？」に対してYesと答えやすくなる気がする。

組織において最近変化ないなーと思ったら、自分の望む変化について同僚やパートナーに相談してみるといいかもしれない。自分に関して言うと、直近3ヶ月はマネージャーをやめてQAのいちメンバーとなり、あまりやったことのないキャッチアップを色々としたので変化はしている。成果が期待の30%くらいしか出せていないことにもちろん焦りはあるが、こういう変化の要望の相談を聞き入れ調整してくれた同僚には感謝をしている。

問題解決ブルドーザー

視座の可視化というこの記事がめちゃくちゃ好きで、たまに読み返している。

note.com

ここに書いてある、課題があった時のアクションのレベルみたいな話がわかる~~~って感じで好き。

具体的には何らかの課題があったときに下記のどのアクションをするか判断できそうです。
・ そもそも気づいていない
・ 認知してる（けど言語化できない）
・ 問題指摘する
・ 解決策を提示する
・ 解決する

自分の経験だと、「問題指摘する」と「解決策を提示する」の間に結構隔たりがあって、指摘したら物事が前に進むと感じている人が意外と多い気がする。

また、問題を指摘してるつもりで、実は問題を把握できてなかったり適切に指摘できてないケースも多い。例えばあまり理にかなっていないと感じる制度に対して「これなんでずっとこうなってるのか謎」「こう変えればいいのに」とコメントしたとして、これは問題の指摘と言えるだろうか。これは認知してるだけで、問題の指摘にはなっていないと自分は思う。

自分が物事をうまく動かせない憤りが、半ば愚痴のような指摘もどきとして表層に出ていると言ってもいい。自分もそうなりそうなことはあるが、たいてい物事を前に動かせないと思い込んでいるだけで、頭を使って人を巻き込めば自分がコントロール可能な状態にできることも多い。

自分が関わってきた中で、「解決する」の領域まで一気に持っていくめちゃくちゃすごい人が何人かいた。自分ができないと思っていたことや、問題の指摘、解決策の提示で止まっていたことを、ブルドーザーのようになぎ倒して解決していくのである。こういう人を、自分は「問題解決ブルドーザー」と呼んでいる。

自分が認知や問題指摘、解決策の提示で止まりそうになった時は、これまで見てきたブルドーザーのことを思い出すようにしている。自分も早く自他ともに認められるブルドーザーになりたいものである。

組織の透明性を高めるための情報を受け取る側のスタンス

組織の透明性を高めるためには発信側の工夫が不可欠だが、情報を受け取る側のスタンスも認識を揃えておいた方がよい。

自分の経験上、こういうスタンスでいるとよいんじゃないかという話をざっとまとめておく。

情報は常に100点ではないもの

  • オープンになった情報は常に完璧な状態というわけではないという姿勢でいた方がよい
  • たとえばSlackでシュッと投げ込まれたタスクや事業の方針に対して、背景がわからずモヤッとしたみたいな経験はあるかもしれない
    • 複雑な話ではこういうことが起きがちで、わからないことがあると人は不安になる
  • とはいえ、完璧を目指して情報が公開されるのが遅れたり公開されなくなったりするのはよくない
    • 情報を公開する側は、実は結構緊張していたりする
  • そのため、情報を受け取る立場としては、「情報は常に100点な状態ではなくむしろ100点に近づけていく部分も皆でやるんだ」くらいのスタンスでいた方がよい
    • もちろん発信側に対するフィードバックは適切に行うべきだが、そういうスタンスでいた方がお互いに楽

情報は自分から取りにいくもの

  • 情報はオープンにするだけで浸透するわけではない。各人の情報のキャッチアップが必要
    • もちろん浸透させるためにドキュメントやレポートライン、会議体、役割の設計は不可欠だが、前提として自分で取りに行く意識を持っておいた方がよい
  • 人に聞くでもSlackや社内ドキュメントを検索するでも、どんなやり方でもよい
  • 「取りにいけない」、あるいは「取りに行くのが大変」という場合に声をあげるのも自分の役割と思っておくとよい
    • 例えばSlackのチャネルが多すぎるとかKibelaのフォルダがカオスとか
    • このへんは組織の雰囲気や体制にもよるが、そういうスタンスでいた方が自分でコントロールできるので楽

なんでそんなことを受け取る側がやらなきゃいけねえんだ、発信する側がなんとかしろよという意見は当然あると思う。責務の多くは発信する側にある場合が多いけれど、実際にはお互いに歩み寄っていく方が気持ちが楽になるというか、建設的だと思う。発信側になった経験や、透明性を高めるための組織設計の経験があるかどうかで感じ方は違うかもしれない。

情報を渡す側も受け取る側も、お互いへのリスペクトを忘れずに。そして、次の曲が始まるのです。

あわせてよみたい