アジャイルと人月と
工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
これは逆で、アジャイル開発をサービスするんなら「人月」でしか契約できない。
なぜかというと、アジャイルは要件を作らない - 売り切れましたでも書いたようにアジャイル開発が約束するのは「変化への対応」であって「機能の納品」じゃないから。
結局コンサルタントと同様、スキルと人数に対してお金を払ってもらわざるを得ない。
通常、受託開発するなら成果物はシステム（とそれに付随する資料）になるんだけど、そもそも発注時に「どんなシステムを作ればいいか」分かってるならアジャイルである必要は無い。
わかんないからアジャイルしてもらうワケであって、その時点で「受託開発」的な契約はできない。
そりゃ相性悪いっしょ - 酒と煙草と○○の考え方が一番近いと思う。
だから
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
- 最終的なリリース日はいつになるの？
- 意思決定を延ばすってどういうことなの？
- ウチはこの予算でいつまでにやって欲しいんだけど、それ守れるの？
「あたえられた期日と予算」で「出来る限りのことをします」としか答えようが無い。
（実際にはそうは言わないけど）
意志決定とは「何を作るか？」を指す。
何を作れば良いかすべて分かっているならウォーターフォールでやればよい。
契約にかかる手間を見積に含めているか？
つい最近まで勘違いしていたけど、業務委託＝委任（準委任）ではない。
ぶっちゃけていうと"業務委託"という言葉は民法上には条文が無いので、単なるビジネス用語ということだった。
それはさておき、契約の小ネタ。
ソフトハウスとして独立して、小さくないSIerやユーザー企業と始めて取引を開始する場合、以下のような手順を踏むことになります。
- 信用調査（される）
- 基本契約
- なんやかんやヒアリング
- 個別契約（今回の案件ね！）
独立したエンジニアがかならずハマる落とし穴。これら契約にかかる手間を甘く見ると、あっという間にジリ貧になってしまいます。
必ずこれらの作業にかかる日数（手間）を見積に含めましょう。
信用調査
直近３年の決算書出せって言われるわけですよ。
メインバンクはどこか？資本はどこから出てるのか？
最近ではほとんど関係ないけど、昔はライバルメーカー（FだとかNだとかHだとか）の資本が関係してないかチェックされてたようです。
会社によっては資本金や従業員数などによって年間で発注できる上限額が設定されます。
というのは名目でして、R100人程度のSIerではほぼチェックしません。 形式です。
（逆にちゃんと見る会社はちゃんとした会社ってこと）
基本契約
「業務委託基本契約書」とかそれっぽいタイトルがつきます。 普通は印紙を貼りません印紙は４０００円が普通です。（金額を書かないので）。
今後の取引全般に影響する内容が書かれています。 ひな形を送りつけてくるのでちゃんと目を通しましょう。
すくなくとも、"取引形態"、"知的所有権"、"賠償"、"紛争の解決"には必ず目を通すこと。
NDAについては別契約になることが多いです。
契約形態は、今後の個別契約においてなされうる契約形態がすべて書かれます。
どういうことかというと、基本契約書で、弊社からの発注は"時間単価での準委任"か"価格と期間固定の準委任"ですと書かれていた場合、請負にてシステムを納品する契約を交わした場合はこの基本契約の"外"で契約を行ったことになります。
その場合はあらためて協議し、契約書を作成しなければなりません。
知的所有権は成果物の知的所有権についてです。
GPLなソフトウェアを利用する場合についての記載があるかどうかチェックしましょう。
準委任の場合は、成果物に対するすべての権利を譲渡することになります。 つまりクリエイティブな作業はすんな ってことです。
請負の場合は権利の譲渡が行われるタイミングに注意。 通常「検収が終わった時点」です。 それまではすべて受託側の所有です。
賠償は賠償。 遅延損害金とかです。
上限が決まってることを確認。
紛争の解決については裁判所がどこになるかをチェックしときましょう。
大体、ここまで。
会社の定款や決算書、あとは振り込み口座の通知書を送ったら口座開設（取引開始）です。
個別契約
で、やっと個別契約です。
金額の大きな場合、もしくは工期が長い場合を除き、"見積書"が個別契約書のかわりになります。
正式に契約書類として認められるのは"注文請書"なんですが、実質的には見積書の記載に強く縛られます。
ただし印紙を貼るのは見積書ではなく注文請書。
よく注文書と一緒に発注元フォーマットの注文請書が送られてきますが、必ずチェックすること。
見積もった内容と同等か（品名、納期、金額、契約方式）？ 付帯条件はついていないか？
こんだけやって、やっと作業に入れる…。
特に契約は古〜いひな形を何も考えずに押しつけて来ることもあります。 気をつけましょう。
契約のミスで会社が倒産！ ってのじゃぁないです。
独立したエンジニアにとって一番困ること、それは延々と時間をとられることです。
これはミスっててもなかなか自覚しづらいんですが、ボディーブローが如く確実に体力を奪います。
かなりの場合、契約の時点（作業の前）で気をつけることで防ぐことが出来ると思います。
外部の組織がSIとしてアジャイル開発を行うのは難しいかもしれません
これは、カンファレンスで最初の質問に答える中でのGuo氏による発言です。
これは以下の質問への回答の中でさらっと触れたはずです
開発をした人がシステムをメンテナンスするわけではないので開発に関するドキュメントも残しておきたい
http://www.publickey.jp/blog/09/post_77.html
Guo氏は外部組織がアジャイル開発を提供する際の難しさについて表題以上の事は発言していませんが、以下の発言を踏まえるならば明らかに運用チームや保守チームへの引渡に際して課題が多いことには間違いありません。
コードを書き始めた人は、なぜこのユーザーインターフェイスがそのようになっているのか分かりません。そして途中で機能が追加されるときも、なぜそのようなユーザーインターフェイスになるのか、元のユーザーインターフェイスを設計した人がいないと分からないでしょう。
http://www.publickey.jp/blog/09/post_77.html
だから、最後まで（ドキュメントが残るのではなく）デザイナーが人として開発に残っていることが大事です。
段階的に運用チームや保守チームが合流する方法が一般的かとは思いますが…。
やはりそこに立ちはだかるのは契約の壁。
商習慣とかそういうのじゃなくて、結局「何を約束するのか？」という意志決定は後回しにするほど面倒なことになるので、そこは可能な限り早い段階で決定したいもんです。
アジャイルは要件を作らない
Agile Conference tokyo 2009 … 技術評論社に行ってきました。
Guo氏はところどころで「アジャイルに対する誤解」について言及しておられましたが、その中で触れられなかった、かつ最も大きな誤解は
「要件決まらないなら作りながら考えよう」
だと思う。
外部のSIerとして顧客にアジャイル開発を提示するのであれば、欲しい物が分からないような場合や、システムに必要な要件が「決められない」場合にアジャイルを適用してはならない。
http://d.hatena.ne.jp/xmalloc/20091210/1260450691で上手いこと書いてるけど、変化を許容するってだけなら日本のSIerはばっちりアジャイルできてることになる。
結果がどうなるかは書くまでもないだろう。
変化とは？
アジャイルにおける「変化」は、主にシステムをリリースすることによる「変化」を指す。
アジャイルでは反復開発を前提としているため、顧客側では複数回システム導入が行われることになる。
システムはそもそもビジネスの制約（時間や人的リソースの制約）に影響を与えるために導入されるのだから、部分的とはいえシステムの利用が始まれば、それは要件の前提としてのビジネス環境が変わることになる。
だからこそ「要件は変化」し、変化への対応が重要になる。
このことを、目的や制約が認識できていないために起る要求の変化と混同してはならない。
システムリリースによる変化は許容できて、前提条件の変化はなぜ許容できないのか？
それは、前者が動的予測の難しさに起因するのに対し、後者が「能力の欠如」が原因である場合が多いからだ。
MVCのMんところ -2-
２ヶ月前のコメントに今更レス。
RailsのドキュメントやWikiPediaには堂々とMVCと書いてありますよ。
ですので、MVCについて誤った認識(少なくともMVCとしてはあまり良くない設計)を助長させているのは
Rails自身でもあるので「えせ」とDISられる理由はあると思いますが、その点はどう思われます？http://guides.rubyonrails.org/getting_started.html
http://ja.wikipedia.org/wiki/Ruby_on_Rails
この話って、たしかControllerをちゃんとテストできないような奴がModelを分厚くしたところで品質は保てねーだろボケが！ ってhigayasuoさんの意見が元だったと思います。
それはさておき、「その点」がどの点か分かりませんが、RailsのサイトにはActiveRecordこそがModelだとは書いてないですね。
「managing the rules of interaction with a corresponding database table」とは言っていますが、その前に「primarily」と前置きしています。
残念なことに「primarilyではない」Modelの役割とは何か？という事についてはココでも何処でも触れられてはいません。
たしかにデータの相互作用（や永続化）がロジックの主要な部分ではあるんですが、こういうドキュメントだけで勉強された方は、それ以外の部分はModelの役割であるとは思わないため、ロジックをcontrollerに書いてしまうんですよね…。
googleって広告屋だったっけ
いつまで「事業の柱は広告」って言い張る気だろうか？
広告ビジネスのために年間に８億ドル以上の投資って、ちょっとそりゃ無理があるだろう…。
一流のエンジニアを集めて、超高効率のデータセンターを作って、世界中のサイトをインデックス化して、地球規模のコンピューティング能力を持って… で、やることは「広告」？「検索」？
んなバカな。 のび太かよ。
11月
クリスマス（強制参加）
