過度な断定で変にミスマッチを誘発するのも嫌だし。経営者の考えに自分が賛同できるか否かというのは、経営者の人の話を聞けば、経営メッセージとかこの会社のビジョンとか、そういうところから経営者の考え方というのが出てくるので、そこで合致していなかったら、たぶん会社に入ってどの部署に配属されてどんな上司がついても、合わないと思います。この辺は企業調査する時には調べておきたい。経営陣がどういうことを大事にしていて、それを浸透させる仕組みがあるか、とか。CTO・VPoEが語る「技術選定の自由度とガバナンス」https://logmi.jp/tech/articles/328627負債解消チームはかなり限定的にやっていて、全体的に負債を解消しましょうという感じではないんですよね。最初にお話ししたとおり、従業員の履歴管理機能がけっこうやばいです。「そこを集中して直そう」と言っていて、そこを直すことでどれぐらいの事業インパクトがあるのかみたいな話も、PMを立ててやっているので、ある種の機能開発に近いモチベーションでやれる返済業務に追われまくるとプロダクトエンジニアとしてはキツいよなあとは思うので、アドホックに作って事業インパクトを意識しながら解消していくのはモチベーション的にも良さそう。ここを解消すると、変更容易性によってユーザーにメリットがあるよねとか、本当にわりと全社的に注目を集めている負債なので、そんなにモチベーション管理に困ってはいないはずです。逆に本当に「何でもやります!」みたいな感じだと、モチベーション管理にすごく苦労するだろうなとは思います。ミッションがぼやけるほどモチベーションは維持しづらい。スタックがばらけると「学んでいけばいいじゃん」みたいな話がありますが、例えば、やっていた人が辞めちゃって保守しなきゃいけない場合、やったことがない人がやるとなると大変かなと思います仮に新しい技術をやるのであれば、CI/CDをきちんと組んでもらうのは絶対に言っていますまあですよね...(実際に出くわしてどうにもならなかった苦い記憶)。自分が新しいスタックを取り入れる時は(当たり前ではあるかもしれないけど)テスト細かく書いて色々自動化してドキュメントも残してというのは気をつけている。新しい技術を取り入れるハードルを高くしすぎて技術スタックが固定されてしまうと、それはそれで組織として探索的知見が得られずバッドな状況、環境になってしまうので攻守の塩梅が難しいところではあるなあとも思う。月)https://moneyforward-dev.jp/entry/2023/06/08/120000私たちは、テックジャイアントを目指しています。技術的な挑戦をつくるか?事業が拡大するにつれて、大量のデータや高いトラフィックに対応するため、そして複数のサービスを連携させるために、より大規模な分散システムを構築する必要が出てきました。トップがしっかりこういうことを発信しているのも組織としては良いなと思った。評価制度上はグレードが上がるほど技術的な挑戦やスケールの大きいアウトプットを求めらがちだけど、事業がスケールして保守運用するものが増えると単純作業の絶対量も増えるわけで、意識しないとそういう成果を出すチャンスの数が減っていってしまったりする。改善するのか?https://speakerdeck.com/lmi/productivity-con-link-and-motivation小さいリリースの回数が多いだけかも単に分割してマージしただけかもという問いかけができるのが良い。高いならハイパフォーマンスだというわかりやすい図式ができたけど、数字だけに気を取られるとやっぱ上手くいかないねという話。科学」でも因果の導出はどちらかというと逆で、ハイパフォーマーなチームは結果としてそういう部分に気を遣え、その結果数値が高くなる的なニュアンスのことが書いてあったようななかったような。Freeeks&Ubieの代表が「エンジニア向けの制度・待遇」にこだわる理由。環境を味方につけて成長できる技術者の特徴とは?https://type.jp/et/feature/23054/エンジニアが在籍するプロダクト開発組織では、職位を設けず、ロール(役割)を明確化するホラクラシー組織にしています。マネジメント業務よりも開発に専念したい人や、技術について上から命令されるのを嫌う人にとっては、評価をするのもされるのも時間がかかって「煩わしいもの」と感じてしまいかねません。プロダクト開発は不確実性が高く、本人の頑張りが成果には直結しないケースが多いので、フェアに評価をするのが難しいですよね。給与テーブルを設けず、評価も行わない仕組みにしています。前職の年収や市場価値を見て、入社時に決めます。その後は会社の業績と連動して昇給する評価を行わないの、かなり振り切った感じがしててすごい。評価期になると評価制度の表現に沿うような振り返りとかに無駄に時間がかかって本当にこれ意味があるのかと思うことはある。マネージャー陣やボードの時間をこんなに使ってまでやる意味があることなんだろうか、と。それにしても、これ人数と売上の規模がどの程度まで上手く回るのかな。ネトフリもそんな感じで言い値で報酬が決まる的なことが、以下の本に書いてあった気がする。https://www.amazon.co.jp/dp/4532323673常に右肩上がりで上昇する前提の強い気持ちなら成立しそうだけど中々クレイジーな気もする。ビッグテックのプロジェクトマネジメントとスクラム不在の謎https://t2y.hatenablog.jp/entry/2023/09/03/011023この記事は全体的に読み応えがあって面白かった。苦戦しているチームは、方法論とはあまり関係がないことが多い。うまくいかなかった理由として、ビジョンの欠如、優秀なエンジニアの離職、透明性の欠如、ツールの不備などが挙げられている。チームが選択できる方法論は関係なくて、マインドだったり環境不備だったりの方が要因としては大きい。なんか上手くいってないような気がするからスクラム導入してみようとか、モブプロやってみようとか、そういうのやりがちだけどそうじゃないんだという話。ビッグテックとその他の企業とのもうひとつの不思議な違いは、プロダクトマネージャーの役割であり、チームに専任のプロジェクトマネージャーやプロダクトオーナーがいないことです。多くの場合、大企業ではプロダクトマネージャーはプロジェクトマネジメントを担当しません。これを実現する責任を負います。して1年以上働いているが、チケットやタスクを作成したことはない。スプリントもやりません。ビジョン、戦略、パートナーシップにフォーカスしている。プロジェクトマネジメントやタスクはあまりやらない。エンジニアはプロジェクトマネジメントのほとんどの責任を担い、自分たちでタスクを作成する。