  |
はてなキーワード:アジャイルとは
そもそものフレーミングとして、ワイは嫁をでかい猫だと思っとる（嫁には、ワイをでかい犬だと思えと言ってある）。
小細工としては、ぼんくらが使いたがるツボを突いた道具があるので、適宜導入しとる。
カーペットを掃除するコロコロとか、こじゃれたパンのトースターとか。
ああいうのを与えて、使わせる合図を決めとくと、素直に使っとる。
やっぱり猫や。
嫁家族との旅行やら○○式やらのめんどくさい準備は、タスク管理アプリを使ってこちらでバックログを作成して嫁や嫁の母をアジャイルマスターにすると、おもしろがって遊びながらまわしとる。
こんな感じでいろいろやるけど、基本はただの猫なので、役には立たん。
そういうもんだと思って愛するしかない。
お前らは、Windowsのアップデートの不具合に対して「マイクロソフトの怠慢だ」と思ってるんじゃないか。ああ、気持ちはわかる。毎月、毎月、何かしらの不具合が出てくる。その度に、お前らは「こんなんで、よく世界一のOSだと言えるな」と思うんだろう。でも、実は、その背景には、もっと複雑な現実がある。俺は、この業界で10年以上、ソフトウェア開発に携わってきた。その経験から、Windows11の不具合が多い、本当の理由を語ろうと思う。
最初に言っておくが、マイクロソフトは、別に怠けてるわけじゃない。むしろ、めちゃくちゃ頑張ってる。でも、その頑張りが、空回りしてる部分もあるんだ。その理由は、複数ある。
まず、一つ目は「スケーラビリティの問題」だ。Windows11は、世界中の何十億ものデバイスで動く必要がある。スマートフォンのように「数千万台」じゃなくて「数十億台」だ。その数十億台のデバイスは、全部、異なるハードウェアだ。異なるマザーボード、異なるCPU、異なるGPU、異なるネットワークカード。その全てのハードウェアの組み合わせで、Windowsが正常に動く必要があるんだ。
想像してみてほしい。お前が、ある薬を開発したとしよう。その薬を、世界中の何十億人もの人間に配布する。でも、その人間たちは、全員、異なる体質だ。異なる病歴を持ってる。異なる他の薬を飲んでる。その全ての組み合わせで、その薬が安全に効く必要がある。そして、毎月、その薬を新しいバージョンにアップデートする必要がある。できると思うか？それが、Windows開発の現実だ。
二つ目は「アジャイル開発の弊害」だ。昔のWindowsは「何年もかけて、完璧に完成させてからリリース」という戦略だった。だけど、今は違う。「毎月新しい機能をリリース」「ユーザーのフィードバックを即座に反映」という戦略だ。これは、確かに、ユーザーにとっては「常に新しい機能が使える」という利点がある。でも、開発側にとっては「地獄」だ。なぜなら、テストの時間が極端に短くなるからだ。
昔は「3ヶ月、テストに時間をかける」ことができた。だけど、今は「1ヶ月、いや、2週間でテストを終わらせて、リリースしろ」と言われるんだ。その2週間の中で、数十億台のデバイスの組み合わせを、全部テストすることはできない。だから、不具合が出るんだ。リリース後に。
三つ目は「レガシーコードの呪い」だ。Windowsは、80年代から続く、歴史あるOSだ。その歴史の中で、物凄い量の「レガシーコード」が蓄積されてる。つまり、古い時代に書かれたコードが、今も、Windowsの中に組み込まれてるんだ。そして、その古いコードは「絶対に消せない」。なぜなら、何十年も前のアプリケーションが、今も、Windowsで動いてる必要があるからだ。
想像してみてほしい。お前が、ビルの構造を変えたいと思ったとしよう。でも、そのビルの地下には「100年前に埋め込まれた、今も動いてる配管」がある。その配管は「絶対に壊すな」と言われてる。だから、新しい構造を作る時、その古い配管を避けながら作らなきゃいけない。その結果、新しい構造は「複雑で、歪んだ」ものになるんだ。それが、Windowsの現実だ。
四つ目は「組織の問題」だ。マイクロソフトは、今、めちゃくちゃでかい企業だ。Windowsチームだけでも、数千人の開発者がいる。その数千人が、全員、同じ方向を向いて、開発してるのか？違うんだ。複数のチームがあって、複数のマネージャーがいて、複数の優先事項がある。その結果「チームAが修正したバグを、チームBが、別のアップデートで、また復活させてしまう」みたいなことが起きるんだ。
さらに、「政治」がある。大企業にはね。「このチームの提案を通す」「あのチームの提案は通さない」みたいな、内部的な政治闘争がある。その結果「技術的には正しくない決断」が、されることもある。なぜなら「上司が気に入ったか」「社内での影響力」で判断されるから。
五つ目は「テスト環境の限界」だ。マイクロソフトは、物凄い数のテストマシンを持ってる。でも、それでも「全ての組み合わせをテストすること」は不可能だ。なぜなら、新しいハードウェアが、毎日、毎日、リリースされてるから。マザーボード、CPU、GPU。新しいハードウェアが出る度に、その組み合わせでテストする必要がある。でも、マイクロソフトは、新しいハードウェアが出た時点では「そのハードウェアを持ってない」。だから、テストできないんだ。リリース後に、ユーザーが使い始めてから、初めて「あ、このハードウェアでは、こんなバグが出る」と気付くんだ。
六つ目は「セキュリティアップデートの緊急性」だ。毎月、新しいセキュリティ脆弱性が発見される。その度に「至急、パッチを当てろ」と言われるんだ。でも、セキュリティパッチを当てる時に「別のバグが出ちゃった」みたいなことがある。なぜなら、セキュリティパッチって「システムの深い部分に手を入れる」から、予期しない影響が出ることがあるんだ。
七つ目は「ユーザー層の多様性」だ。Windowsを使ってるユーザーって、本当に多様だ。ゲーマー、企業のビジネスユーザー、クリエイティブプロフェッショナル。その全員のニーズを満たす必要があるんだ。でも、ゲーマー向けの最適化が、企業ユーザーの環境を壊すこともある。その度に「このアップデートは企業ユーザー向けにロールバックする」みたいな判断が必要になるんだ。
八つ目は「ドライバの問題」だ。Windowsのアップデートが原因で不具合が出た時「実は、ドライバの問題だった」なんてことが、よくある。なぜなら、GPUメーカー、ネットワークカードメーカー、その他、色々なハードウェアメーカーが「ドライバを提供してる」から。その全ての組み合わせで、Windowsが正常に動く必要がある。でも、ドライバメーカーは、Microsoftと同じペースでアップデートしないこともある。だから、Windowsアップデート後に「古いドライバとの相性問題」が出るんだ。
九つ目は「テストユーザーの不足」だ。Windowsアップデートは「InsiderPreviewプログラム」で、先行テストされる。でも、参加してるユーザーって、実は、そんなに多くない。だから「InsiderPreviewでは問題なかった不具合が、正式リリース後に、突然、大量に報告される」みたいなことがある。なぜなら「InsiderPreviewのユーザーが使ってなかった環境」で、不具合が出るから。
十番目は「時間がない」ことだ。つまり、全てはね。開発時間がない。テスト時間がない。修正時間がない。なぜなら「毎月、リリースしろ」と言われるから。修正できてない不具合でも「次のアップデートまで待つか」「このまま出すか」の選択を迫られるんだ。その結果「このまま出す」を選んでしまう。それが、不具合の連鎖につながる。
でも、ここで気付くべきことがある。それは「Windows11は、それでもすごい」ってことだ。数十億台のデバイスで、毎月、新しい機能をリリースして、その中でも「9割は正常に動く」ってことは、すごいことなんだ。100%完璧なOSなんて、この世に存在しない。特に、Windowsくらい複雑なシステムでは。
だから、お前らに言いたいことは、こういうことだ。「アップデートに不具合が出るのは、マイクロソフトの怠慢じゃなくて、技術的な現実なんだ」ってこと。それと「アップデートをインストールする時は、ちょっと待つ」ってこと。最初の2週間は、世界中のユーザーが使ってる。その2週間で「大きな不具合」が報告されたら「その時は、ロールバックする」って決断ができるんだ。でも「直後にアップデートする」と、その大きな不具合の被害を直で受けるんだ。
それと、企業ユーザーは「テレメトリデータを送らない設定」にしとくことをお勧めする。なぜなら「匿名データを送ってくる企業」の環境では、アップデートの相性問題がね、増えることがあるんだ。
最後に。Windows開発チームは、本当に、頑張ってるんだ。毎日、毎日、不具合を修正して。でも「完璧」を求めるなら、それは「無理」ってことだ。完璧を求めるなら「アップデートするな」が答えなんだ。でも「新しい機能が欲しい」「セキュリティアップデートが必要」なら、ある程度の「不具合との付き合い」は、覚悟する必要があるんだ。それが、OS運用の現実なんだ。
管理ツールで管理できるように論理的に計画しなきゃいけないのであって、適当行き当たりばったりで見た目だけ猿真似したデータを突っ込めば素晴らしい管理が実現できるわけじゃない。
どこぞのSIerから転職してきたPMが、「プロジェクトの8割は完了状態なので、オンスケです」とか言ってるのを聞いて仰天したことがある。
「どんな管理してんの？」
「8割完了って？」
「タスク数です」
ガント作ってるとは聞かされてなくて、管理者内でしか共有してないって言うから、見てみれば、確かにぱっと見、よく見る感じの情景が広がっていたのだが、
「このタスクとこのタスク、難易度天と地なんだけど、なんで人日同じなん？」
「詳しいこと読みきれないので、仮置きです」
「このタスク、これが完成しないと進められないんだけど、どうして平行してんの？」
「依存関係が、これを作ったときわからなかったので。依存関係があったとしても、影響しない部分は実装できるでしょう？」
「このタスク、外部とのにぎりが必要なんだけど、調整タスクとかは？」
「いるんですか？」
「タスクとして書き入れないとしても、前提条件だからそう言う条件があることの明記は必要だし、状態や見込みの管理は必須だろ？」
ってな感じで、簡単なタスクを8割、先にこなして、別部署との調整、技術的決定等々、管理ツールに書き込まれてない要素で週明けからラインが軒並み空き状態になるのにオンスケとか……。
OJTで雰囲気でやってきたから、肝腎要の部分はこれっぽっちも知らんのだな……。
「プロジェクトって、後になればなるほど進度が遅くなるもんですから」
いや違う。
いっぱしぶった口振りしても、口だけで中身がねぇ。
「そこはアジャイルで……」
コアな不動部分をドメイン分析で明らかにして、そこは確定するのがアジャイルだ。
それをしないから、アジャイルはいい加減で行き当たりばったりだ、ってクソ評価下されるんだ。
クソ評価を下されるべきはPM たちであって、アジャイルという手法じゃねぇってのに。
そもそも部分像の把握ですら怪しい。
こんなんでよく給料もらってるな。
マジかよ。
「今最先端の生成AIを導入して、遅れを一気に取り戻します！」
うん。
中堅以上のエンジニアからはアラートが上がっていたんだが、マネージャクラスは誰も理解できないどころか、反対しかしない消極的な人間とか悪しざまに罵り、圧力をかけてきやがった。
その後どうなったか？
知らん w
それもそっかあ
アジャイル開発であってアジャイルディベロップメントじゃないしなあ
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251113204213# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaRgtCgAKCRBwMdsubs4+SE1bAP4vVJu9yfjIdtI1TTfF/iq6D9cdX44u5wm1x9vq+BciMwEAhY60ilxwCOQTzLTE+pFIZw8udZVFUaoU3QJh6lQGbwg==4OP4-----ENDPGP SIGNATURE-----
俺もなんでもかんでも反論するわけじゃない。
「世界を壊した所で、常識や法則までは壊れない。神の領域よりも上の存在だからだ」って、「壊れた世界」で言われても、反論はしないよ。
壊された世界というものを広く世界の終焉まで含めて捉えると、そのときは宇宙の始まりへ巻き戻すようなことが起こるわけで、これに伴って全宇宙はブラックホールよりも(エネルギーの)密度が大きくなる。
ブラックホールですらその内部は今まで解明されている物理の常識には囚われないと推測されているのだから、宇宙の終焉にも常識は適用されないのではないかという推測も立てられる。
かといって実際に壊れた世界を目の当たりにしている状況でこのようなことを言われた場合、このような異常事態では、言ってることの中身が重要なのと、アジャイルな意思決定が重要だから、細かいことはあまり気にならないと思う。
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251021180556# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaPdM9AAKCRBwMdsubs4+SNclAQDu9C2MxMUxBcGXwQIrfgVSjjDT48U7fiaKh/yQ5/7IvwD+OrCWKioRixcIuGep032AjyAZGiYU0JSlXte2gvIuyQ8==C0ev-----ENDPGP SIGNATURE-----
手間が増えて、全然楽になってないのなら、それは正しく理解できていず、目的を見失い、手段を目的としているから。
速い話が、
間違えている
からだ。
DDDとかTDDとかDevOpsとかIaCとかクリーンアーキテクチャとかマイクロサービスとかアジャイルとか、とか、とか。
いろんな現場で、責任者は「うちは××を採用して云々」と胸を張って宣言してくれるんだが、「ならなんでそんな状態になってんの？」「なんでそんなにエンジニアがたくさん必要なん？」と聞きたくなる。
今時、SREがいるとか、QAが別にいてE2Eテストとかしてるとか。
まず間違いなく、
間違えている。
んだよね。
TDDをちゃんとしていれば専属QAは不要だし、DevOpsをちゃんとしていれば専属SREは不要。
いやでも「Googleならそうしている」っていうなら、大きな勘違いをしている点を指摘してあげよう。
「君たちはベアメタルサーバを管理していないし、Lanケーブルの取り回しもしていない。GoogleのSREエンジニアが頑張って運用してくれているシステムに乗っかって、アプリケーションに集中できる状態になっているはずだ」
ということ。
職業プログラマになって分かったことは、職業倫理なんてものは "人が死なない限り存在しない" というものだ。
僕らを取り巻くテーゼは、 "プログラムを事前に設計して考えて書くのはバカだ" というもの。
これは、インターネット環境で修正が用意になった結果として、「その場しのぎをすればいい」という場当たり的主義が起きた。
結局のところ、そんな対応をコンシューマも許容せざる得ないのだ。そんなテーマで書いてみる。
アジャイルだとかXPという方法論の理想は認めるし、とても共感する。顧客がソフトウェア開発のプロなら成り立つだろう。
だが、実際の運用はどうだろう。顧客に未完成品を準委任で売りつけて、保守で金をせびる方便になってしまった。
XP という主張も、アジャイルという運動も、未完成品を売りつけるための手法として使われている。
いざとなったら、可能な限り修正はしますよ、という触れ込みで。僕らが頑張ってこれだったんですといえば、故意ではないのだ。
だったら、自分たちのレベルを低くした方が、免責される幅も広がるし、安く人を調達できるし、うれしいことだらけ。わらっちゃうぜ。
TDDという手法がもてはやされたりするのも、やったもん勝ちみたいな精神性があるからなのだ。
そもそもの問題として、本当のテストの設計をするには、プログラムがどのような動作をすべきか考えなくてはならない。
V&Vの妥当性確認をするには、そもそも何をしたいかわかってなくてはならないし、そのためには、上流の設計は必要だ。
そのことを考えるに、TDD を設計しつつ行うことは、上流から下流までの見識を持って行わないといけないはずだ。
しかし、テストファーストといってる人たちは、このことを矮小化して、あらかじめ自分のわかってる範囲でテストを書いておけば問題ないと言っている。
現場で始めるTDDなんていうのは、そんなもんで、そういう場当たり的なことをを持てはやしているわけで、知れたもんだよね。
こいつらバカじゃねーのか、テスト書いてれば、見当違いのことしてもいいって言ってんのかよ、って思うわけだわな。
でも、何やっても、やってよかったと心底思える人達ばかりで、住む世界がちがうわけで。かなりお花畑な人達ばかりなのよ。残念なことに。
そもそもドメインモデリングなんて、いくらでも昔に提唱されていたのに、DDDに含めるのが間違ってるのだ。
そもそも、DDDの本はドメインモデリングについて、あまり語ってないし...。
どうせ、ユースケース層というものをドメインに入れて四苦八苦してるような輩には、なんもわかるまい。
ドメインとドメインがどう使われるかは、そもそも関係にないし、関係あったら問題だろう。
でも、ユースケースをドメイン内に表現したいとかいうのが後を立たないのは、なんもわかってないからだろうな。
わかってないならわかってないで黙っていてくれともうけど、DDDやってみましたっていうよくわからない記事ばかり出てくるし...
正直、AI に命令を出すリード、マネージャ、リーダーの能力が上がらないと、AI でコードを大量生産すると手に負えないスラムが根深く絡み合った構造で広がっていくことになるだろうというのが既に見えている。
というのも、AIほとんど影響ないちょい前の時点ですら「うちはDDD、TDD、クリーンアーキテクチャ、k8s、アジャイル、スクラム等々を採用して云々」ってプロダクトが、リリースから半年、1年で開発がスタックしている、という事例は一般が想像する以上に存在している。
リリース時は、CTOやマネージャが腕組みしてWebページで華々しい成果発表するものだが、その裏で手動運用のオンパレード、一箇所変更したらどこに影響が及ぶかわからない地雷原、不具合障害が発生するたびに増える監視サービス、手動運用マニュアル。
その前で、「圧倒的ではないか、我がプロダクトは」って悦に入る経営陣、の図。
それ見て「SaaS界のネズミー王国や〜」って妄想を迸らせる利用者側経営陣と、ブルシットな手数だけ増えて、業績給与はぴくりくらいしか動かないで悶絶する利用者側従業員。
この状態で、「いや〜、新技術の導入、失敗しましたわ〜。経費が5倍くらいに膨れ上がってます。ごめんちゃい」なんてリリース出せないでしょ。
それ見て教科書ガイドエンジニア、カタログショッピングエンジニアが「世界を変える！ 俺(の業務経歴書)が変わる！！」って初見手探りで導入して、連れション地獄。
これが現状よ。
ここにAI が入ってくると、ますます「中身も、他の処理との関係性もよくわからんけどプロダクトに組み込まれた謎プログラムの塊」が、「これ以上機能を載せるとバランスを崩して全体が倒れる」寸前のサイズまで育つわけよ。
ここまで行っちゃったら、どこをどうしたらどうなるか、「AI 使ってふふふふ〜ん」ってレベルのエンジニアでは太刀打ちできなくなってるだろう。
すっと
「動くな！」
となって、対策のための会議とドキュメントづくりが延々と半年とかいうオーダーで繰り広げられることになる。
その間やれること、というかやらなきゃならないことは、障害対応手動運用。
こういう状態に陥らせたリーダーやリードテック、CTOは「新しいことに挑戦したいので」と敵前逃亡、成果発表のWebページを担いで次の犠牲者の元へ。
ちゃんと設計したら、生成AIを駆使する必要、あまりないはずなんだよなー。
で、テストも書いてくれる、っていうけど、AI に全投げ似非エンジニアにその妥当性とか、判断できんのかな？
カバレッジを100％に近づけるためだけのテストを手動で大量に書くのを代替してくれるかもしれないけど、あのテストが品質保証、障害対策になってる現場が一つでもあるか？
今流行りらしい、業務ドメイン分割マイクロサービスだと、AI で辻褄合わせてテストとか、無理やぞ。
という地獄が、2、3年後訪れるだろう。
楽しみやなぁ〜w
という話をすると、AI使いこなせないオールドタイプの負け犬の遠吠え、みたいにいうてくるのがいるんだけど、むしろAI を効果的に活用するための構造、構成とか模索してんのよ。
てか、Web系って少なくとも「ウォーターフォール」じゃ無理な世界なんだよね
かといって「アジャイル」と呼ぶとちょっと違う気もするが、インクリメンタル・イテレーティブモデルではあるので、そういうのをざっくりと「アジャイル」と呼んではいる
ざっくりといえば、SIerと自社開発の差がここに出てくる
うちの部署に配属された新人の後輩女子がいる。22歳、名前は田中（仮名）。
第一印象は「うわ、めんどくさそうな子来たな」だった。
朝一でプロテイン飲んでる。昼休みにはサラダしか食べない。デスクには自己啓発本が3冊積まれてて、休憩時間にはKindleで読んでる。会話の端々に「アップデート」「アジャイル」「エンパワーメント」みたいな横文字が出てくる。
最初は正直、距離を置いていた。こういう子って、すぐに「先輩、もっと効率的なやり方があると思うんですが」とか言ってきそうじゃん？実際、1週間目にして「このExcelシート、もう少しマクロ組んだらもっと楽になりませんか？」って提案してきた時は、心の中で「はいはい、出た出た」って思った。
でも、その提案が的確すぎて。
私が手作業で2時間かけてやってた集計作業が、彼女のマクロで15分で終わるようになった。しかも、ミスもなくなった。
「田中すごいじゃん」って褒めたら、「いえいえ、まだまだです！もっと勉強しないと！」って言いながら、めっちゃ嬉しそうにニコニコしてる。
それからよく観察するようになった。
朝のプロテインは、実は朝食を取る時間がないから。一人暮らしで、朝は6時半に起きて、電車で1時間半かけて通勤してる。だから朝食代わりにプロテインを飲んでるだけだった。
昼のサラダも、お金がないからじゃなくて、単純に野菜が好きだから。「コンビニのサラダって、どれも美味しいんですよね！毎日違うの試してるんです！」って楽しそうに話してる。
自己啓発本も、「将来起業したくて」とか「キャリアアップのため」じゃなくて、「本を読んでる時が一番集中できるんです。通勤時間が長いので、有効活用したくて」という理由だった。
そして横文字も、別にカッコつけてるわけじゃなく、前の大学でそういう授業を受けてたから、自然と口に出るだけだった。
気づいたら、私の方が田中の話を聞くのが楽しみになってた。
「先輩、今度新しいカフェがオープンするらしいです！一緒に行きませんか？」
「先輩こそ、いつも優しく教えてくださってありがとうございます！」
こんな会話を交わしているうちに、ふと気づいた。
田中の「意識高い系」行動の全てが、別に誰かに見せつけるためじゃなく、彼女なりに一生懸命生きてる結果だったんだ。
そして、その一生懸命さが、なんだかとても愛おしく見えてきた。
「先輩、このプロジェクト、一緒にやりませんか？」
「いいよ」
「やったー！頑張ります！」
満面の笑顔でガッツポーズする田中を見ていると、私まで嬉しくなってくる。
最近、定時後に一緒にカフェに行くことが増えた。田中はいつも、今日あったことや、読んだ本の話や、将来の夢について熱心に話してくれる。
「先輩って、すごく聞き上手ですよね。話してると、なんだかすっきりするんです」
「そう？」
この前、田中が風邪で休んだ時、なんだかオフィスがすごく静かに感じた。田中のいない職場って、こんなにも物足りないものなのか。
「ご心配おかけしてすみません！明日には復活予定です！先輩に迷惑かけないよう、しっかり治します！」
こんな時でも、一生懸命で、健気で。
私、この子のこと、いつから「可愛い」って思うようになったんだろう。
最初は「意識高い系のめんどくさい後輩」だったはずなのに、今では「一生懸命で可愛い後輩」になってる。
でも、これって、単純に「後輩として可愛い」ってことだよね？
そうだよね？
そこそこ大企業に勤めてる
ソフトウェアエンジニアをしてるが、彼らはもうダメなのかもしれない。
OSが存在する時点で無駄なウィルススキャンソフトを入れさせられる。
いわゆるサーバーレスが大好きな人たちが集まって作ったゴミシステムの改修をさせられてる。
頭が沸いてるとしか思えない。。
当然NoSQLでは複雑な検索ができないので検索エンジンを使っている。。
彼ら自身が答えを出してるのに素直ではない。
なぜかgraphqlも採用している。
内部を見ても、普通にrestのコントローラーと同じ構造をしていてgraphqlのサービスに依存して返す値を変えてるだけである。。、
で、離職率が90%を超えている
擬似的にリレーションは再現できるであろうが、アプリケーション層での保証なのに問題ない顔している。
今わたしは外注を動かすためにシステムの仕様を作って、渡してる。
サーバーレスなアプリケーションでスマホアプリはそれらを呼び出している。
流石に工数見積もりができないのでスケジュール遅延する可能性が高いとPMに報告したが普通に怒られた。当たり散らされたがまあくだらないので放っておく。
上に相談したが耐えてくれとの話だった。
PMはSIer出身でこのプロジェクトはアジャイルと言い張るがガッツリウォーターフォールである。
このシステムはやばいからユーザー関連部分だけでもRDBMSに移行すべきと言ったが、工数が無いとしか言わない。
現代でソフトウェアを作る上ではもうdevops以前に協働するという基礎の方が大事である。
他社の機能をパクれと言ってもウチ独自の強みがないととか、そのアプリで出せる付加価値があると認められてから投資対象になると説明されるが、こいつらは何を食ってるんだろうか。
壊しやすく自分の手で扱える規模にアプリケーションを組んで激安で運用して当たるのを待てばいいのにそれも出来ない。
このシステムを冷静にレビューしても狂ってるのに誰一人疑問に思わない。。
上は無関心、PMは働かないでASDっぽいし人を詰める、同僚はASD
こんな魔境存在していいのか。。と疑問に思う。
人の入れ替わりも考えると3年ぐらいは同じチームでやってないと、ベロシティが全然読めなくて納期を大外しすると思う。アジャイルを導入してもうまくいかない期間があるから、JTCはそれに耐えられないんじゃないかな？
アジャイルはドキュメントより動くソフトウェア重視ではあるけど、開発者が顧客や営業より優位というわけではなく、動くソフトウェアを触ってもらうことで顧客の意見を取り入れていく手法なんだけどね
