B-Teck!

お仕事からゲームまで幅広く

【ふりかえり】2023年1月

ふりかえり

前回のふりかえり
【ふりかえり】2022年8月 - B-Teck!

夏頃以降気力がなくて何もできていなかったけど、回復してきたので色々再開し始めています。
とりあえず毎月ふりかえりを書けるくらい何かをしたい。

Input・Output

ブログ

本

勉強会

趣味とかその他

本

所感

仕事

12月から作業し始めたタスクが年末年始にかけてようやく動く形になってきて、まずは一安心という感じ。
10月半ばくらいから現在までフロントエンドのタスクに関わることが多く、毎日わかんねーって言いながらどうにか倒しています。
なんとなく最近課題に思っているのは、未知に対してどれだけ精度高く見積もることができるかと、見積もりを外れたときにどうリカバリするかというところ。
意思決定者がどういう情報を求めているのか、どういう進め方をすれば納得してもらえるのか、みたいな部分がまだまだ弱いなーと感じています。

プライベート

プライベートではだいぶ気力がなくなっていたのですが、12月頃からちょっと元気になってきました。
腰を据えてやる娯楽(長編のゲームとか)も様子見つつやっていきたいなーという感じ。 文字を書く元気も出てきたし、久しぶりにKotlin触りたいなーという気持ちで Kotlin サーバーサイドプログラミング実践開発 を読んだり触ったりしてみています。
継続して勉強できる姿勢を続けていきたいなあ。

仕様書について考えてる

ドキュメント 仕事

継続して提供されるサービスであれば、仕様や意思決定の経緯を残したい。
どういう形ならあとからそれらを辿れるかなあというのを考えてるメモです。中身はあまりない。

イメージしてるのはこんな感じ。

要求仕様・機能要件

開発アイテムが発生した際に書くドキュメント。
ステークホルダーと合意した要件やその案件で満たすべき仕様を記述する。
対外的に機能紹介をするときにここだけ読めば伝わる状態だと良い。

親ページにはおおまかに下記が書いてあって、関連する小ページへのリンクを貼る。

  • ペルソナ
  • やること・やらないことのスコープ
  • デザイン
  • 開発範囲の外部仕様
    • 画面上の挙動や制約、注意点など

設計ドキュメント

内部的な設計資料がぶらさがってるイメージ。
テーブル設計や各種リソースの構成図、APIのIFなど。
議論が発生した場合は議事録側にメモを残し、リンクされているとよい。
文字数とか操作の制約とかがあればなぜなのか書いてあるとうれしい。

調査ドキュメント

機能開発や設計において調査した結果のメモ。
行った調査や意図が記録されていてほしい。

議事録

部署間のMTGからチーム内の議論まで、「案件に関わる意思決定」に関連する会話のメモ。
参加者、会話内容、意思決定、もしあれば次のアクションアイテムが書かれていると良い。

仕様書

機能が開発されたあと継続してメンテされていくドキュメント。
追加開発や改修が発生した際は開発完了時にこのドキュメントに反映される。
文言や分岐、各種バリデーションとかエラーとかが網羅されていてほしい。

更新フロー

開発中は常時意思決定や設計ドキュメントが更新され、開発完了時にそれらの差分が機能ドキュメントに反映されてほしい。
更新時は相互にリンクされてると最高。

ここまで書いて思うこと

自分はドキュメントを書くのが苦ではない方なので困らないけど、あんまりドキュメント書かないタイプの人に全部書いてっていうと嫌がられる。
仕様として残す範囲の挙動も個人に依存しそうで、かといってガチガチにすると多分メンテされなくなる。
そもそも単機能が肥大化してしまっている場合、この形ではおそらく記述しきれないし、複数ラインで同じ機能の開発が走ったときに開発中機能の仕様記述がコンフリクトしそう。
細かい仕様はどこまで残すのかとかも含めて何もわからん。
そもそもすでに機能があるけどドキュメントがないみたいなときどうする問題もある。
こういうドキュメンテーションがうまくいってる事例をもっと知りたい。

【本】人事と採用のセオリーを読んだ

本

人事と採用のセオリー

人事と採用のセオリー

Amazon

人事・採用業務のつながりを知りたくて買った本。
採用業務部分はすでに知っていることが多かったが、下記に挙げるような人事領域はあまり考えたことがなかったので勉強になった。

以下メモとか感想とか。

人事の役割

本書の最初で語られるのは人事組織とはどういう役割を持っているのかということだった。
具体的には 「採用」「育成」「配置」「評価」「報酬」「代謝」。
これらの一貫性を保ちつつ、会社の理想とする人材のポートフォリオを構築するというのが目的としている。
人材ポートフォリオというのは、事業要件などに合わせた職種・等級や能力ごとの人口比のこと。

フェーズごとの組織要件の違い

これは著者の方が登壇されたイベントの記事が非常にわかりやすかった。
logmi.jp

ざっくりいうと認識の限界を超えたときに組織が階層化し、階層化によって組織の統制方針が変化し、フェーズごとにマネジメントの方針や構成員に求める振る舞いが変わるというもの。
グライナーモデルと呼ばれているらしい。
Stepの境界と、なぜそれが必要になるか、というのがしっかり語られていて納得感があった。

社内の人口フローを考慮した入社・退職率マネジメント

人事の役割のところでも書いたように、人事には社内の人材ポートフォリオの構築が求められている。
ここには採用計画や、退職率マネジメントなども含まれる。
配置・評価・報酬などの制度設計で組織の風土を定義し、形作っていく。

自分が読んだ感じでは大きく育成型と即戦力型の2つに分けられそうなイメージ。

育成型では

  • 時間をかけて総合的な能力を育成し昇進
  • 年功序列的な報酬システム
  • 積み上げ式で功績を評価する
  • 社内スキルの向上を重視

即戦力型では

  • 優秀層を即戦力として採用
  • 現時点の評価が反映される時価的な報酬システム
  • 直近の成果に応じた評価
  • ポータブルスキルを重視

という感じ。

育成型は退職率を抑え、即戦力型では適切なキャリアチェンジを促す。

感想

冒頭にも書いたように、人事業務についてほぼ何も知らない状態から読んだので面白かった。
正直、1メンバーとしてはあまり考えたことのない社員の「代謝」、つまり退職率のマネジメントの話はどきりとさせられる。
なんとなく企業は退職率を抑え、社員を育成し、配置していくものだと思っていたのだけれど、そうでない場合もあるよねと。
自分の所属してる組織や、求人などで制度を公開している企業がどのStepなのか、どういうタイプの制度設計をしてるのか考えたりすると面白そうだよなーと思った。