いないわけではないけど開発チーム内には不要というか、役割としているのがおかしいという。いうものに求める役割というか、出してほしいアウトカムへの定義がしっかりしている気がする。単なる役割分担の話で終わらせられるかどうか。スクラムが日々のリリースの邪魔になったのでした。スクラムの全体的な考え方は、スプリントを中心に展開され、スプリントの最初にタスクにコミットし、スプリント中にそれらに取り組み、最後にやったことをデモするというものです。このプロセスは不自然で、動きの速いウェブチームからは押し付けられたかのように感じられました。プロダクトオーナーへのデモ、作業の承認、そしてリリースといったスクラムのセレモニーは、いくつかのことを前提としています。プロダクトオーナーは、作業が仕様通りに行われたことを確実に検証できる人であることプロダクトオーナーが仕様書を書いていること承認を行わずに成果物が本番環境にリリースされることありません一回スクラムとか始めると、それをやめると言い出すの結構ハードル高い気がする。なんとなくスプリント回ってベロシティとか見えてきて上手くいっているようにも見えると、これやめていいんだっけ、みたいな。スクラムイベントは儀式で、削れない制約、みたいな。スクラムがマッチする類のタスクやフェーズと、そうでないタスクがあると思うので、柔軟にやっていけると良さそう。同様の組織のエンジニアと話すと、彼らのほとんどはスクラムを実践したことがありません。?それにはいくつかの理由があります。有能で自律的な人材は、信頼できる質の高いアウトプットを生み出すために、より少ない構造しか必要としません。大手テック企業は、このような人材を惹きつけ、余裕をもたせ、雇用できます。有能なチームを活用するには、彼らに働き方を選択する自由を与えることが必要です。自分もチームの仕事を構造化するよりも「全員が全速力で走るのが一番速い」と思う派閥ではあるけど、それは全員がプロフェッショナルであり、阿吽の呼吸で動けるという前提が必要なので、そういう状況じゃないならやっぱある程度の構造化は必要かなあ。ビッグテックに入ってくるような人はみんなプロフェッショナルなんだろうけど。重要性に拍車がかかったような気がする。ポストするようにしている。頻繁に投稿する人と全く投稿しない人で二分化されがちなので、その辺は「それは単なる思考様式ではなくスキルだから、言って3秒で即実践はできない。実践を繰り返して習熟する必要がある」と、文化の醸成が大事なんだろうなあと。情報の整理と標準化4割の共通プラットフォームは生まれながらに死んでいる4割の共通プラットフォームはうまく運用できずに死んでいくプラットフォームにもプロダクトマネジメントが必要。誰に、何を、どうやって、価値を届けるか。認知負荷が多いか少ないかは相対的なものだから定義が難しいけど、全部をプロの水準でこなす、はやっぱ現実問題難しいというか非効率だから分業が必要になっていくんだけど、どこでその舵を切るか、どうやって分担していくか、が難しい。多くの場合は「タスクが生まれた理由」のみが残されており、個々人が思いをぶつけ合うと空中戦を生む理由になります。書いた人以外の誰かが見たときに「このタスクのほうが先にやったほうがいいよね」というのがわかるような情報を共有しましょう。以下3つがおすすめです。売上へのインパクト他社との差別化コスト削減こんなん無理やろと思うかもしれないが、このレベルで明文化しないと一生空中戦のままということなんだろうなきっと。ユーザーベネフィットと直接結びつかないようなタスクだとより一層。モラルを崩壊させない「目的ベースの目標設定」のやり方https://logmi.jp/tech/articles/328778「企業の目的が顧客の創造だということはわかりました」ということで、じゃあそれを自分の部門とか、部とか、課とか、チームとかにどうやって反映させるのかというと、これはまた難しい話それぞれの目標、個人とか組織とかの目標が、その価値交換システムにどう関係あるのかを説明できないといけないわけですSMARTのSはSpecific(具体的)です。Measurable(計測可能)。これがやたらとフォーカスされている。3つ目がAchievable(達成可能)です。夢物語じゃなくて現実的に達成可能じゃないといけない。次がRelated(関連性がある)。ここですよここですよ。Measurable(計測可能)ばかり強調されますが、大事なのはRelatedです。関連性があるほうが重要で、上位の目的、部門とかチームの目的とどう関連性があるかが切れているとまずいということになります個人の目標も会社、部門、チームの目標とのアライメントが取れていることが大事。アウトプットがどう事業インパクトを生み出したかというアウトカムをしっかり計測していきたい。この導出どうやるのがいいんだろうなあは結構模索中というか全然わからんって感じがしたりもする。目標を管理や報酬と結びつけるとモラルが崩壊する関連性がないとどうなるかという話をしたいんですが、関連性がないとビルドトラップと呼ばれるものに陥ります。そもそもの個人的な感覚として、目標管理と評価制度は、利益の再分配と個人の成長という二つの目的を一つのツールで同時に満たそうとしているので難しいんじゃないかと思う。プロダクトと事業を無限にスケールするための最強のロードマップの作り方https://speakerdeck.com/yamamuteki/the-greatest-roadmap-for-unlimited-scaling-your-business-and-productsこれはだいぶ刺さった。中で一番沸いていたんじゃなかろうか。ロードマップ欲しくなるんだよな...目標管理と評価制度の考え方https://kakehashi-dev.hatenablog.com/entry/2023/12/11/090000ここで重要なのは、非連続な成長を期待しているということは不確実性の高い挑戦を行うことでもあり、つまり、必ずしもうまくいくかどうかはわからないということだから成果を評価するような評価制度だとチャレンジが少なくなってしまう。失敗を許容する文化、みたいなのは口で言うのは簡単なんだけど制度上もしっかりそこが組み込まれていないと誰もチャレンジしなくなっちゃうだろうなとは思う。新卒で入った会社は新人に難しい仕事をこれでもかというほど振って、どれだけチャレンジできたかをしっかり評価する風土があったので、そういう環境が合う合わないはもちろんあるけど、合う人には成長できる環境が整っていたなと思う。従って、評価面談で目標設定のときにこれを立てていましたが・・・のようなコミュニケーションは不要です。目標設定のときに立てたことをやれていないときは、普段の1on1で話せていれば良いですが、逆に頻度が多いと話すタイミングを失ってしまうというパターンが多い気がします。いうときは、月1回の頻度で目標を見直す場を1on1とは別に設けてみるというのも良いです。やって予め目標をメンテ出来ていれば、堂々と評価面談に望めるようになります。不確実性の高い環境であればあるほど、期初と期末で全然状況が違うなんてことは往々にして起こりうるし。上にも書いたけど目標管理と評価制度を密結合させて二兎を追うのではなく、個人の成長は目標管理で、利益の再分配は評価制度で、と棲み分けつつも、それをいい感じに結合していくのが良さそう。プロダクトマネージャーの評価のやり方https://logmi.jp/tech/articles/329832エムスリーはグレード制を導入していないので、基本的にキャリアラダーという考え方は使っていませんなるほど。グレード制を取ってないとこって結構あるのかな、あんまり聞いたことない気もする。私がグレード制を導入していない一番の理由が、中途採用でメチャクチャ困るんですよ。中途採用はどうしても前職給与の考慮が必要これは確かにそう思う。グレード間のオーバーラップがある程度あればいいんだろうけど、ない場合は給与に合わせてグレード決めると整合性取れなくなっちゃうパターンは起こりがち。降格がしやすい環境なら深く考えなくてもいいような気もするけど、日本だと降格の人事考課は中々難しそう...。ソフトウェアアーキテクチャ入門https://speakerdeck.com/snoozer05/20230727-software-architecture-is-a-tool-to-enhance-our-humanity大変よくまとまっていてソフトウェアアーキテクチャという曖昧なものを改めて復習できた。自分が年度初めに書いた技術ブログの稚拙な内容と似通っている部分もあり、自分の理解が大枠そこまで外してなかったかなというのが再確認できてよかった。Ladderの活用と改善https://engineering.mercari.com/blog/entry/20230908-048dd4c0ab/こういうふうに定期的にしっかりと効果測定と振り返りができてるのが強い組織という感じがする。「うちら最強!」メチャいいマインド。ネガティブになりがちだから意識していきたい。ギャルネス、ギャルマインド。「“良くないコード”に腹を立てても意味はない」新しい事業・新しいプロダクト・新しいコードに触れる時に意識したいことエンジニア採用・組織づくりのトレンド予測2023〜開発生産性がエンジニア採用の鍵に。DX内製化や外国人採用なども〜受託開発とか自社開発とか言うけれど、会社のカルチャー違いや個人差の方が大きい。テックリードはキャリアの分岐点。改善するのか?Freeeks&Ubieの代表が「エンジニア向けの制度・待遇」にこだわる理由。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。