納品のない受託開発は設定より規約のRailsそのもの。
またですが、納品のない受託開発について再考してみました。
開発者はお客様の所に行きません。
- 移動時間や移動にかかるコストはかけません。
- 優秀な人材同士が社内で情報共有できる環境を作ります。
- オンラインを利用した情報共有
- オフラインを利用した情報共有
要件をまとめる作業、システムを構築する作業は1人でやります。
チームをまとめるコストはかけません。
DRYなコードを書く生産性の高い開発力を持った人材一人の生産性は、作ることを目的とした人材5人が集まったチームの生産性よりも高いです。
プログラマーは要望を抱え込みません。
- 量が増えることに関わる管理コストはかけません。
- 本当に必要なことに集中します。
納期は設定しません。
- 何をもって納品物なのか、何をもって納期に間に合ったのか?を検証するための管理コストはかけません。
- 納期を意識してがんばってしまい体が壊れると作業は進みません。そのようなリスクはとりません。
- 納期を従業員に意識してもらうための鼓舞する道具として利用しません。
- そんな理由がなくてもお客様の成功に全力を注ぎます。
- 頑張りすぎることにより、疲れ果ててやる気がなくなるなんて状況は作りたくありません。
- だいたいこれくらいで作れるという規模間はお客さんに伝えますが、約束はできません。
見積もりはしません。
- 毎月定額料金のサービスです。
- 見積書を作るためのコストはかけません。
- 見積書に付随する書類の作成コストもかけません。
ルールに対する例外オプションはありません。
- オプションを管理するコストはかけません。
こう考えてみると、設定より規約のRailsそのものかもしれない。
煩わしいオプションを無くし、規約を設けて 「早い、安い、うまい」のレールを敷く開発手法。
それはまさにRailsそのものかもしれない。