ウォーターフォールのメリットのエントリも事業会社のIT転生のエントリも契約のことを知らないと本質は見えてこない

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance

みなさんすごいなー「こんなにブクマつくほどの記事書いてみたいなー」と思ったか思わなかったかは棚に上げて。


さて、1つの目のエントリは昨日の午前中くらいだったかな、facebookのTLで流れてきたのを読んでブクマでコメントを残して、今朝、というか今もう一度読み直してみたんだけれど、書いているご自身はウォーターフォールがダメだと直接言っていないんですねぇ。サムがそう言っている、としか書いていない(ように読めたんだけど)。あとは最後にご自身が目指すビジョンで「技術やプロセスの導入スピードを同じにしたい」と言われているのは間接的にウォーターフォールではなくアジャイルを指しているのかな。


先ほど読み直したけれど、結局、「ご自身の決意表明なんだろう」と思ったです。はい。それ以上の情報はないような。


ところで、わたしもブクマしたのでわたしがブクマに何を残したかというと、いつも言っていることしか書いていないので進歩なさそう。>自分。

システム開発方法論はビジネス要求を実現できる手法かどうかで選ぶんだ。どっちにメリットがあるとかじゃない。ビジネスが高速リリースを望んでいなければ適用しない理由があるんだよ」


1つ目のブログエントリのタイトルが方法論について取り上げているなら、このコメントはあながち間違いではないだろう。ビジネスサイドが実現したい要求で生じるプロジェクトの特性を見定めて、実現性の高い方法論を選べばいい。好き嫌いは二の次。あなたがマネージャやプロジェクトマネージャなら。それこそ、プロジェクトを計画時のコストで終わらすために。念のために補足すると、計画時とかいて契約時としなかったのは、自社サービスのプロジェクトだってあるからなーと配慮したまでです。


2つ目のエントリに移ります。こちらは電車待ちの間に読んでツイートしたんだけれど、

「ソフトウエアを作ることがゴールになっている以上、スコープを破綻させることはできない。」


のくだりはちょっとどういう意味なんだろう。スコープが拡大する、ような意味合いかな。そのあとの終わらせて検収してはそうですよね、なんだけど。ただ、その次でわからなくなるんですよ。

「請負しないんだから、委任になります。顧客のIT部門に入り込んでその立場で仕事をするのが、主流となる。仮想的な内製部隊として機能していく。こうなりますわな。」


わからなくなってこんなツイートしたわけで。



請け負うとは、見積もりがきっちりできる、ということです。見積もれるから請け負える。別に、見積もれてもあえて準委任で契約してもいいけれど。で、気になるのはその次の顧客の立場で、となっているけれど、いや、そういうケースもありますね。


でも、別のケースもあるんですよ。それは、見積もりができるほど要件が明確でない場合、見積もれないから請け負えません。でも、その曖昧な要件をプロジェクトの中で一緒に明確にしていく作業を準委任でならやってもいいですよ、という内容の場合が。


このケースは実質人だしと同じですが、プロジェクトチームを受託側が編成して、持ち帰りでできるんですよ(実際、随分やってますよ)。あとですねぇ、

「「ウチは一切の請負はしなくて、業務委託でイケてるエンジニアを貸し出します。御社の事業にコミットして、モノも作れますから。毎月XX円お支払ください。」と言われて「なるほど、確かにそれがベストだね!アジャイルにやろう!」 ってなるのかなぁ。 顧客はそれについてこれるのか。 全ての舵取りを顧客に委ねるのが正しいのか。どう説明してご理解を頂くのかイメージが湧かないけど、それしか無いならしょうがないのかな。」


これ、普通の準委任契約じゃないのかな。契約の仕方の見せ方が新鮮に見える人がいるのかもしれないけれど、これ、本質は道幅ビジネスなんですよ。あとは諸条件でアウトプットのうち、ドキュメントを成果物にしていなかったりするんじゃないのかな。多分だけれど、内部で必要なドキュメントは内部用に作るんでしょう。そうしないと人の入れ替わりに対応できないから。


さいごに事業会社をIT企業に転生とあるけれど、武器にはなるだろうけれど事業会社が提供するサービスが物理だったら無理なケースもあるだろうねぇ。そういったケースはどう議論が展開されるのか興味があります。


関連があるような2つのエントリですが何か関連あったのかなぁ、というのが正直な感じなんだけれど、こうやって自分で2つのエントリを読んで、それぞれで言いたいことはなんだろうと考えてみてわかることもあるんだなぁ。


で、思ったのはシステムエンジニアは契約について、いよいよ知っていかないとこうした議論に参加もできないんじゃないか、ということです。はい。