なんとか管理ツールの使い方

管理ツールで管理できるように論理的に計画しなきゃいけないのであって、適当行き当たりばったりで見た目だけ猿真似したデータを突っ込めば素晴らしい管理が実現できるわけじゃない。

どこぞのSIerから転職してきたPMが、「プロジェクトの8割は完了状態なので、オンスケです」とか言ってるのを聞いて仰天したことがある。

こちらの目算では4割に達してなかったから。

「どんな管理してんの？」

「タスクブレイクダウンして、ガント作ってます」

「8割完了って？」

「タスク数です」

ガント作ってるとは聞かされてなくて、管理者内でしか共有してないって言うから、見てみれば、確かにぱっと見、よく見る感じの情景が広がっていたのだが、

「このタスクとこのタスク、難易度天と地なんだけど、なんで人日同じなん？」

「詳しいこと読みきれないので、仮置きです」

「このタスク、これが完成しないと進められないんだけど、どうして平行してんの？」

「依存関係が、これを作ったときわからなかったので。依存関係があったとしても、影響しない部分は実装できるでしょう？」

「このタスク、外部とのにぎりが必要なんだけど、調整タスクとかは？」

「いるんですか？」

「タスクとして書き入れないとしても、前提条件だからそう言う条件があることの明記は必要だし、状態や見込みの管理は必須だろ？」

ってな感じで、簡単なタスクを8割、先にこなして、別部署との調整、技術的決定等々、管理ツールに書き込まれてない要素で週明けからラインが軒並み空き状態になるのにオンスケとか……。

お前、マジでPMやってきたんか？

OJTで雰囲気でやってきたから、肝腎要の部分はこれっぽっちも知らんのだな……。

「プロジェクトって、後になればなるほど進度が遅くなるもんですから」

いや違う。

いっぱしぶった口振りしても、口だけで中身がねぇ。

お前がプロジェクトの全体像の把握に失敗しただけだ。

「そこはアジャイルで……」

アジャイルはそう言う意味じゃねぇ。

コアな不動部分をドメイン分析で明らかにして、そこは確定するのがアジャイルだ。

それをしないから、アジャイルはいい加減で行き当たりばったりだ、ってクソ評価下されるんだ。

クソ評価を下されるべきは PM たちであって、アジャイルという手法じゃねぇってのに。

そもそも部分像の把握ですら怪しい。

こんなんでよく給料もらってるな。

でも、社内的にはできる、期待のPMって評価？

マジかよ。

そのあと、なんか会議やった結論が、

「今最先端の生成AIを導入して、遅れを一気に取り戻します！」

うん。

そのAIを利用する前段階が全然終わらんのだが。

中堅以上のエンジニアからはアラートが上がっていたんだが、マネージャクラスは誰も理解できないどころか、反対しかしない消極的な人間とか悪しざまに罵り、圧力をかけてきやがった。

その後どうなったか？

知らん w

平和っていうのは

戦争前夜が続いているだけのこと。

生成 AI でボロボロになった自社サービスを立て直す方法

システム開発で生成AIを有効に使おうとしたら、生成AIが生成するコードを鼻歌混じりで完璧に仕上げられるだけのプログラミング力と、システム全体の最適な設計ができる技術力が必須の最低ラインとなる。

プログラミング力がなければ、生成AIが仕込む地雷に気付けないからシステムを地雷原にしてしまう。

そのレベルのエンジニアでは地雷除去は100%不可能なので、ぶっ壊れたまま走る暴走列車になるだろう。

その状態になったら、エンジニアたちは100%飛ぶ。

経営者の手の中に残るのは、ぶっ壊れて部品を撒き散らすサービスと、逃げ出さなきゃいけない状況なのにそれを認識できないほど低レベルの「バナナ」エンジニアの集団だ ( 大枚叩いて「世界をひっくり返す画期的なサービスを作ってる！」って思ってたらこれとか、まじウケる w )。

システム全体の最適な設計ができなければ、適切なプロンプトを捻り出せないので、整合性を保ったままサービスを成長させることは不可能だ。

現状、どこかで誰かが作ったような小さなツールなら、なんとかなりそうだと思う。

プログラミングレベルなら。

けど、成長させる前提のプロダクトに使うとか、正気の沙汰とは思えない。

小さなツールは AI のフレームの中でこなせるとしても、自社サービス、特に今までなかった類のサービスとなったら、フレームの外、現実に開いたものだからAI が扱える対象ではない。

だから合理的なものは出てこない。

具体的な指示を出してくれるように見えてるだろうが、過不足なく正しいかと聞かれたら、AI推しエンジニアにホルホルされたものを見た限りでは、ないわー、としか言いようがない。

AIの絵とかと似ていて、ぱっと見イケてそうで、よく見たら変。

絵のように、縦横の制限があって、各ドットの色の幅の制限もあって、多少色ずれがあっても大勢に影響がないものじゃなく、プログラムは一箇所+と-間違えただけでも致命的なものだから。

「テストも自動で生成できるんです！」

って、やたら本プログラムに迎合的なテストが生成されていたりするんだが、実装ベッタリの境界値テストとかより大事なテストが丸っと抜け落ちてたりするんだよね。

で、その重要性というか危険性を、エンジニアは理解も認識もできないままになったりする。

意味のないテストを延々と繰り返して、実環境で不具合障害が発生するたびに、場当たり的な対策をフジツボのように追加しまくってやった気になるのを運用だとか勘違いしたまま炎上地獄への坂道を転げ落ちていくんだよな。

大規模なサービスの設計は抽象度の高い部分を先に詰めないと、辻褄が合わなくなって破綻する。

初期リリースにはブーストが必要なのは確かだが、使いこなせない生成AIを使うと、書き初めで最初に筆を置く場所を適当にするのと同じくらい、取り返しのつかない事態に陥るだろう。

初期リリースこそ、全体設計と、サービスを支える基本モジュールを抽象的に、丁寧に作る必要がある。

「一旦リリースしてシェアを獲得してから作り直す」という選択肢も、一昔前ならあったけど、AI で嵩増ししたサービスの作り直しは、多分すでに合理的ではない。

再設計再実装の手間もそうだが、補助輪(AI)エンジニアに、移行作業の戦略策定設計実施ができるわけがないから。

AIを絶賛するエンジニアには2種類いる。

最低限のプログラミング力とシステム設計能力があって使いこなせるエンジニアと、ないけど称賛していれば自分もすごいエンジニアと思ってもらえると思ってる意識高い系(笑)エンジニアだ。

おいら自身、たまーに使うけど、チームメンバー全員に積極的に活用しろとは死んでも指示できない。

むしろ使用禁止を言い渡すだろう。

というか言い渡した。

どのレベルのエンジニアが書いたプログラムかという情報なしに、レビューとかしてたら時間がいくらあっても足りん。

特にプログラムを書けないことを誤魔化すためにAIを駆使する奴は、発覚したら即銃殺でも構わないと思ってる。

でも、ドキュメントをAIに食わせてナレッジ共有させるのは構わないですよねって？

ゴミドキュメントを大量生成させてAIに食わせても、結果はゴミ。

"Garbage in, garbage out"くらい知らんか？ w

まずちゃんとしたドキュメントを書いて、ちゃんと整理して、ちゃんと更新しろ。

それ以上のナレッジ共有はない。

そういうことができない人間が書くドキュメントが、有用なドキュメントなわけがないだろ w

で、表題の件。

自社サービスをボロボロにした張本人たちに建て直せるわけがない。

以上 w