簡単な指示、安い料金、早い結果

細かいルール - コ・ウェア・ライセンスのシステム開発

ルール、あるいはガイドライン

細かい仕様の指示がなくても、粗い要望だけで開発を始めます。

漠然としたアイデアを、仕様という目に見える形にまとめていくのも、エンジニアの仕事です。 最終的な意思決定より早い段階で、一度エンジニアにまかせてみませんか。 A案とB案で会議が紛糾するなら、両方のプロトタイプを作ってから、比較検討してみてはどうでしょう。 会議前の資料作りを、アウトソーシングするという考え方もあります。 お客様が会議にかけるコストと、間違った選択をするリスクを減らします。

既に細かい仕様ができている、既存のアプリケーションがある、という条件での開発も承ります。

支払済みの金額に見合うだけ、エンジニアは働きます。

支払いで得るものは、開発プロジェクトを始動させる点火であり、完成品を受け取る保証ではありません。 たとえるなら、ガソリンスタンドで金額指定の給油をするのに似ています。 定額で満タン保証はありえません。

どこまで完結したものが公開されるのかは、単純に予想できません。 お客様が発注時にサイズを上手に選び、使い分けることがポイントです。 小さい金額で少しずつ確認しながら進みたいこともあるでしょう。 ある程度は進まないと目に見えてこないという意味で、大き目のサイズを繰り返すのもありです。 サイズは、マイルストーン(チェックポイント)の距離を示すと考えれば、適切なサイズを選ぶヒントになるでしょう。

部分的に区切ったシステム開発は、通常のIT企業への依頼では考えられません。 オープンソースだからこそ、途中で業者を変えることができるのです。 ガソリンスタンドを選ぶように気軽に。

膨大な要求、金額に見合わない依頼でなければ、初回で完成度の高い成果が手に入るはずです。

テキストによってコードを公開します。

インターネットへの接続さえあれば、テキストの取得は簡単です。 追加のアプリケーションが必要なこともなく、使用するブラウザに制約が加わることもありません。 マクロ付きエクセルブックが通過できないといった厳しいセキュリティを設けているような企業のファイアーウォールでも、 テキストの取得に制限がかかることは、まずありません。 容量が許せば携帯でも見れます。 最後の手段として、印刷したものを打ち込むことだってできます。

テキストのソースコードなら、OSの種類や、エクセルなどのバージョン、国や言語への依存を避けられます。 テキストのソースコードなら、バグ修正の差分を簡単に確認できます。 テキストのソースコードなら、バイナリファイルを開くようなリスクを犯さずに中身を確認できます。 セキュリティの規定が厳しい企業でも、管轄者によるコードの品質チェックが容易なため、企業内で安心して利用できます。

納期は即日から1ヶ月ぐらいが標準です。

要望やタイミング(繁忙期など)に依存します。 小さいサイズほど早いことが期待できます。 Sサイズ案件なら、即日や翌日公開可能なことが多いでしょう。

公開プロジェクトです。

仕様段階から公開し、誰でも読めるURLを利用します。

要望としてエンジニアに渡したメールがそのまま公開されるわけではありませんが、 公開したくない情報についてはお客様がエンジニアに渡す段階で注意を促しておくべきです。 動作確認に利用するデータ、 企業内のシステムや事務フローについての情報、 といったものが考えられます。

依頼主の個人、法人、部署、担当者などについては、個人情報の範疇として非公開が原則です。 担当するエンジニアの属性も個人情報として非公開です。 エンジニアがウェブ上で使用している名称などは公開されます。

機械的に作業量を決めません。

作成にかけた時間、 作成したコードの行数、 作成した関数の数、 などの数字で機械的に作業量を決めるようなことはしません。 受け取った金額に見合う開発を終えたかどうかは、総合的に判断します。

たとえば関数1個程度の開発、といった場合に、 厳密に1個の関数で終わりということもなければ、 1個を維持するために、何でも詰め込んだ巨大関数を作ることもありません。 関数1個程度の内容を記述するために、 16個の補助関数に分割した方が良いコードになると判断した場合、 エンジニアは後者を選ぶでしょう。

見積もりにかけるコストを節約します。

ちゃんと見積もりしたらもっと安くできるのではないか?

仮に5,000円程度で作成可能なものを、 正確に見積もるのに、どれだけ追加コストがかかるでしょう。 見積もり時間も加算して、 結局、12,000円の請求でした、というのでは、 本末転倒です。 最初からMサイズを頼んだ方が安く済んだことになります。

見積もりの正確さを追求すればするだけ、 見積もりそのもののコストを加算しなければいけません。 それを避けるために、緻密な見積もりを排除した、固定料金方式を採用しました。

完成品を受け取る保証が無いのに金を払う。

完成する保証も無いのに金が払えるか。と考えるかもしれません。

支払うお金を着手金と考えてはどうでしょう。 製品保証、完成保証をするシステム開発というのは、 「最初から」3回程度作り直す程度の金額を請求しています。 うまく1回で完成する可能性もあるのです。

最初に投下する金額を小額に限定することで、 失敗したときのリスクも、小さく限定できます。

coming soon

/ja/shop/may.html 2010-12-17