愚痴です🙇♂️
土台となるところが悪いので直すとしたらほぼ作り直し。
すでに遅延してるのでそんな時間はない。
機能性は担保できてそう(汚くて読みきれない)なので見なかったことにして小さな指摘だけしてmergeするしかないか🥲
やるせない。
設計の大枠相談まずしてね、とか、PRがなかなか上がってこないから突いてみたりしてたのですが…
結局相談なく遅延していざ上がってきたものが悲惨な状態でした。
こちらからミーティング設定して強制的に会話すべきでした、判断ミス。
今まで彼からそこまでひどいソースが上がってきてなかったので油断してました。
ちょっと彼には難しすぎたんだろうな…
いったんAIにソースを綺麗にしてもらいましょう。動作するかどうかは別
ポン出しで直せるほどシンプルではないんですよね。
pr-agentで最低限は直しますが些末なところしか直せないですね。
ちょっと落ち着いたら土台となるところから書き直すかなぁと諦めモード…
なるほど...それはコードの質とかじゃなくて根本的な設計思想や要件把握ができてないかもですね。早い（早くないかもしれませんが）うちに対症療法をやめた方がいいかもしれませんね...
ひどいコードを上げられないための秘策として構造を決めてからタスクを渡すというのがありますが…あ、これAIのための対策です
相手に依ってはやりますね。
というか、今まではそうやって渡してきたことが多いです。
今回は構造や土台から考えるようなタスクでした。
彼は審美眼がまだ全然身についてないんだなぁと実感しました。
審美眼がないとこの観点でもっとよくできないか？と人やAIに相談したりもできるわけもなく。
なるほど。マイクロマネジメントで主体性を奪う可能性も考えると匙加減が難しいところです。
まさにそれです🥲
マイクロマネジメントはやる方も得意な人？じゃないと疲れますしね。
ただ、質と生産性に対して相談や報告も少ないのでそろそろ発動しなきゃ行けないかもなぁと考え始めています。
コンサルとソースとかけまして、、、
その心は……
“レビューされると化けの皮が剥がれます”。
でしょうか。今回は。
その心は……
薄いとガッカリします。
（提案が薄い／ソースが薄い）
※料理のソース
すいません。おもしろいこと言えません。
何方も辛口が好まれることがある
みなさん、こういう経験ありませんかね？
どう気持ちを落ち着けてるんでしょう。
私もメンバーもよくなかった事象だと思うので受け入れつつ、どこかでお掃除しようとは考えています。が、ただただつらい。
書き直せるときでも全面書き換えはそれはそれでメンバーのモチベーション上よろしくない。
伝え方の問題なんですかね。
まずは保守性の観点で良くなかったと感じてもらいたいところ。(審美眼)
業務委託に任せた開発やってたときこんな感じ。
心が死ぬ。
そして動けばもういい。
許容せざるを得ない。
自分に権限があれば、業務委託をさっさとクビにした
> 心が死ぬ。
わかりみしかないです😢
残念ながら社員です。
まだ成長過程のジュニアメンバー。
今まで成長スピード早かったので完全に油断してました。
OpenAPI等のスキーマ、関数シグネチャやモジュール構成などの詳細を検討したDesign Docなどは作成されましたか？
あるいは実装着手前にそういったDesign Docを担当者に作成してもらって認識合わせするなど。
結局はSSOTとなるドキュメント作成なしに実装の着手に入ると、どんな人でもフルパワーは出せない気がします。
あなたがテックリード的な立ち位置なのであれば、それらのドキュメントを用意するか、作成してもらってそれをレビューするなど、仕組み化しないと属人性も高まるし再現性も落ちる気がします。
結局AIがうまくやってくれるかどうかも渡すコンテキスト次第なので、今後はこういったドキュメントをしっかり作る（もちろんアジャイルで）スキルが重要になってくると思います。
ありがとうございます。
ドキュメントはあるし参考になるソースもたくさんあります。
ちなみに、Webアプリではないです。
かなり低レイヤーでして…
上のレイヤーをずっと開発してた実績があるメンバーで、今回は下回りから上まで全部作るタスクでした。
ただ下回りが貧弱すぎて、上のレイヤーが悲惨になった感じです。
認識合わせのミーティング設定は依頼はしてたんですけど…開催されずいきなりPRが上がってきたという状況。
こちらからミーティング設定までしちゃえばよかったと反省中😢
なるほど。Webアプリかと早とちりしてしまいました。すみません🙇
Webアプリであれば上記のように設計時点で決めてしまえること（関数シグネチャやモジュール構成等）がありますが、低レイヤーだとどんな感じがいいんでしょうね。私もあまりわかっておらず。
クラウドインフラであればTerraform等を使うのであればコード云々の設計に近い方法は可能かもですが…
> Terraform
低レイヤーが物理まで行きましたね😅
いろいろやってるのでTerraformもWebアプリ開発も扱いはしますが…
Webアプリで雑に表現するとこんな感じ。
Webアプリ開発=上のレイヤー
アプリケーションフレームワーク(SpringBoot,Rails)=下のレイヤー(低レイヤー)
今回の低レイヤーは構文解析とかコンパイラーみたいな分野です。
教科書的な定石がいくつかあり、定石は対象言語によって変わる部分。
※もちろん定石だけで済むわけでないです。
つい先日少し似たような経験をしたものです。
結果としては、もう自分でやります、を発動して書き直しました。 （私の場合は問題があったメンバーは業務委託なのですが）
業務委託なら切りますね。
とりあえずmergeできるように最低限のレビューコメントだけ入れました。
落ち着いたら書き直しですね。
本人にやってもらうかはまだ決めきれてないですが。
外資IT営業の給与ガイド
#給料
#営業
外資IT営業の給与体系・株式報酬、期待できる年収値や上がり幅を、WorkCircleのユーザー様且つパートナー企業チャレンジャーベース社市川さんと、外資エンタプライズ向けソフトウェア(SaaS)営業の経歴を持つ西村さん共同で記事にしました。
RSU完全ガイド(確定申告用スプレッドシート付き)
#給料
外資企業で多く採用される給与の一つ、RSUの構造や仕組み、リスクや確定申告方法に関してWorkCircleのユーザー様、且つパートナー企業チャレンジャーベース社代表の市川さんと紹介します。
外資・日系IT企業のRTO(オフィス出社)状況リスト
各企業のRTO(オフィス出社)状況をリスト化しました。 提供元データは所属企業が証明されているWorkCircleユーザーによるものです。 希望する働き方や転職先を決める軸の一つとして、是非参考にしてください！
