文化シヤツターとIBMのIT裁判のニュースに関するネットの反応

atsuizo @atsuizo

「RFPを委託先に書かせるのが信じられない」みたいなブコメが多くて驚き。コンサルファームなんてその辺ずーっとやってきたじゃん。最近は「開発以降を取りやすい」というメリットからSIerも積極的に進出してるけど。あと、あくまで「委託＝準委任」だぞ。

atsuizo @atsuizo

要件そのものはクライアント自身が出さなきゃいけないけど、ごちゃごちゃした情報（要件の元）を吸い上げて整理して、ロジカルなドキュメントにまとめるのは、コンサルが得意とするところであり、そうした外部の力を頼ること自体は間違ってない。出来上がったRFPを承認するのはクライアント自身。

atsuizo @atsuizo

RFP作成フェーズから関与すると、内部事情とかリスク要因とかも事前に知ることが出来るし、自分らが受けるとしたら・・・、といった観点から要件にバイアスかけることができるので、提案時点で圧倒的に有利ということもあり、設計開発以降を主力とするSIerも食い込もうと必死になってる。

atsuizo @atsuizo

案件が美味しそうなら「流石RFPから入ってただけあって、ウチのことをわかってる」って言わせる提案をすればいいし、ヤバそうなら「やはりRFP作成に入ったところは、開発請負ではなく、チェックする側に入りましょう（≒PMO支援）」という提案をすることも出来る。

atsuizo @atsuizo

なので、今回の件の印象として、発注者がどんなに残念ユーザだったとしても、受けた側の残念さが上回るんだよね。パッケージのプラットフォーム借りるだけのほぼアドオン・スクラッチとか、かつてERPパッケージブームのときにアドオン量産して死屍累々だった歴史を全く見てないのかと。

atsuizo @atsuizo

あんな大きな金額になる案件を「アジャイル開発とウォータフォール開発の併用」とかいう、どっちもちゃんとマネージできないヤツの言い訳みたいなスタイルってのも痛々しい。後任PMはそこがおかしいと思って軌道修正の提案をしたつもりなんだろうけど、経緯が経緯なので逆鱗に触れたんだろうな。

atsuizo @atsuizo

以上、今や案件の先頭に立ってマネジメントしたり業務要件を整理したりする機会も責任の一切ない安全なポジションから、得意な技術領域の支援に特化したお仕事にシフトして、非常に快適なエンジニアライフを謳歌している人の戯言でした。

Yoi @Yoi

提案依頼書や要件定義書はユーザが全部書くと思い込んでいる人に言いたい、「下手に素人が提案依頼書や要件定義書を書くとそれこそ漏れ漏れや論理破綻してデスマーチになるよ」と。提案依頼書や要件定義書を書くのは専門家に任せてその内容のレビューをしっかりやってユーザが責任もって発行する良い

atsuizo @atsuizo

DBスキルに良い意味で偏った（ステ全振りな）人たちばかり集まっていて、正直、プロジェクトの計画や管理は苦手な人が多い印象の弊社ですので、DBの実行計画は読めても、プロジェクトについては実行計画読むの苦手だしオプティマイザとしても弱い感じ。

Yoi @Yoi

専門知識がないから専門家の書いた提案依頼書や要件定義書が理解できないと言うなら、そういうユーザは勉強するまでシステム調達するなとは言いたい。システム屋向けの基本設計書は読めなくても要件定義書は業務用語で書いてあるはずなので必ず読めるはず

atsuizo @atsuizo

RFPを見れば、外部が入って書いたか客が自力で書いたか、だいたい見分けがつくし、それで外したときは、大抵ヤメコンがお客の中にいるケース。それくらい、ドキュメントとしての品質が違うんだよね。

Yoi @Yoi

@atsuizo 全く同感です。例の件はＩＢＭのほうが悪い気がしますが、ＲＦＰの発行を許した時点で文化シャッター側にもその内容に責任がありますよね。レビューしないユーザも悪い

atsuizo @atsuizo

誤字脱字なんて可愛いもので、いわゆるMECEとかロジックの整合性もそうだし、社内や業界でしか通用しない言葉（システム名、業務名、略称）を何の説明もなく入れたり、本当にそれで相手に伝わると思っているのかね。相手に正確に伝わらなかったら欲しいものが出てこないんだぜ。っていう話。

Yoi @Yoi

@atsuizo あと良くあるのは、なにも考えずに24Ｈ365Ｄ稼働とか稼働率99.999%とか全システムを冗長化しろとか書いておいて、それで見積もりが高かったらなじるユーザー。正直笑うしかないｗ

atsuizo @atsuizo

@Yoi 非機能要件は売る側からしても相場観がわかりにくい世界でもあるので、揉めやすいポイントですね。もう少し業務機能よりでも、画面要素詰め込みまくり、データモデルがぐちゃぐちゃな旧システムを引きずりつつ「全画面、応答速度1秒」とか。ボトルネックが「DCとの回線ケチって遅い」というオチも。

Yoi @Yoi

@atsuizo 非機能要件とかマジ素人が書けない代表要件ですよね。たちの悪いベンダーだとそういうの判っていて、「要件はユーザ側で出してください」と言っておいて、「システム止まらないほうが良いですよね」とか「画面遷移は早いほうが良いですよね」とかいって高額のハードを組み入れる誘導をしてきますｗ

atsuizo @atsuizo

@Yoi そうやってハード側で確保しておいた利益が、一筋縄ではいかない開発のプロジェクトバッファだったりして、要件変更の無償吸収にもうまく使われていた古き良き時代？の記憶。細分化して買い叩く風潮が激化して、小さなトラブルが大きなもつれにつながりやすくなっている気がします。

Yoi @Yoi

@atsuizo なるほど。そういう面もありますね。

atsuizo @atsuizo

質の悪いｗハードメーカーSE出身。営業力が強すぎて、SEから見ても無駄に高いサーバー入ってたなあ。なんて酷い営業なんだ、と思ってたけど、それで救われている部分もあったなと思う。

atsuizo @atsuizo

ていうか、請けるベンダ側も会計を細分化しすぎてハードの利益を開発の方に振り向けられなくなって現場の首を絞めてないか。（進行基準のアレ絡みで完全に分けなきゃいけないんだっけ？

to_su @to___su

なぜ顧客が要件だけでなく非機能要件までを定義し、私がその帳尻を合わせるためのパラメータ探しに奔走し、弊社のPMが顧客の提示した非機能要件との擦り合わせに駆り出され、無駄に複雑なシステムに成り果ててしまうのか・・・いい加減、腹立たしいので一度先方と直接お話をしてみたい。