このエントリーをはてなブックマークに追加

読みました。

SonicGarden社にはもともとリモート勤務のところに惹かれており、このあとフリーランスになる上で参考になるだろうと思いまして。

以下は読みながら考えたことです。

簡単に言うと...

  • 「納品のない受託開発」はアジャイル開発にもっともフィットしたビジネスモデルの一つ
  • 一括請負の問題の解決。すなわち...
    • 瑕疵担保責任　→　元々は完成品を約束する工事関係の用語。バグの無いシステムはありえないので、一括請負とそれについてまわる瑕疵担保責任はシステム開発とそもそもマッチしない
    • 余分なバッファを積むことでの顧客への不利益。バッファは瑕疵担保責任での問題を見込んでいる側面も
    • 納品して終わりなのは開発会社にとって。顧客にとっては納品してからがスタート

開発者目線で考える

  • バッファを積まないことによる不安　→　「納期を約束できない」ことで解決
  • アジャイル開発がやりたい！
    • どんなアジャイル開発がやりたいのか 参考 : アジャイルソフトウェア開発宣言
    • 個人（顧客）と対話したい　→　できるよ！
    • 動くソフトウェアに注力したい　→　できるよ！
    • 与えられた仕様ではなく、顧客の変化する要望に対応したい　→　できるよ！
  • のれんわけ、ギルドのシステム
    • 開発者→起業の流れを考えている人にとって、こういう新しいビジネスモデルを経験できるというのは価値が高い

顧客目線で考える

  • 向いてないお客さん

    • がつっと人を充てたい
      • がつっと人を充てたからといって、スピード感が出るとは限らない
      • アジャイルで人を充てられるのがベスト
      • ただしこの会社のサービス提供方式とは違う
      • ？人を充てて欲しい＆スピード感が欲しいというお客さんに対してはどう対応しているのか？
    • 一括請負でお願いしたい
      • 予算が決まっているから
        • 予算が決まっていることと、一括請負でなければいけないというのは厳密には関係がないはず。
        • 予算が決まっていないお客さんはいない。最初にいくらかかるのかと継続的にいくらかかるのかというのは、程度の差があれど、一括請負であれ納品のない～であれ同じ。損益分岐点を考えいつ回収できるかを考えるべき。
        • →予算が決まっているから一括請負でお願いしたいお客さんについては、よく話し合って考え方を変えてもらう
      • 責任を開発会社に押し付けたいから（瑕疵担保責任）
        • 過去の裁判例から言うと、一括請負では責任が開発会社に寄りがちではあるが、お互いに歩み寄る姿勢がないと、発注元（顧客）にも責任の一端がありえる
        • →そもそもスタイルに合わないお客さんと思われるので、敬遠すべきか。チャンスがあるとすると、こちらの考えやシステムに理解のあるお客さんであれば説得の可能性はあるか。
    • 自分のところで（人集めて）作っちゃうよ！
      • 事例にもあるが、システム会社じゃないのにITエンジニアを雇うことは難しい

  • 向いているお客さん

    • 瑕疵担保責任がないことを理解してくれる
    • 納期が約束できないことを理解してくれる
      • 「ちゃんとやってくれるかな」という不安をどうやって解消するか
        • 無料お試し期間

経営者（サービス提供者）目線で考える

  • ？どんな（サービス）料金体系にするべきか
    • 利用料金も顧客満足の一部を担っている
    • バッファを積まないことの明示
    • 選任エンジニアが1名
      • ？2名以上にすると何が起きる？
      • スポット的に人手を厚くしたい場合（逆に薄くしたい場合も）があるとおもうので、そこに対しては対応できないが、代わりに料金体系が複雑化すると思われる
      • ☆プリペイド、チケット購入方式にするのはどうだろうか（提案）
    • ？おそらく料金体系的にはいわゆる1人月程度に近い額だと思われる
      • 1人月をどう考えるかだが、ベストエフォート型、特定企業へのフルタイムコミットではない（R&Dの時間）、会社の売り上げへの上乗せのことを考えると、月額n0万円くらいかなと予想（※料金は公開していないとのことなので、予想値ではありますが伏字にしています）
    • 3ヶ月程度でのプロトタイピングのことを考えると、一括請負に比べればやはり安い感じはする。
    • 問題は、作っていたそのサービスが終了に近づいてきたときなど、「別の新しいものを作りましょう」という提案をするのか、そのまま契約終了なのか
  • 小規模で社員の幸福を実現
    • 社員に求められていること
      • 自己組織化（セルフマネジメント、大きな裁量）
      • 何でも屋（コンサルティング、プロジェクトマネジメント、マーケティング、設計、デザイン、実装、テスト）かつ、特定分野でのプロフェッショナル
      • ↑かなり求められる能力値が高い
    • 高い能力を求められるので、必然的に採用や会社の思想の共有が難しくなる（なりそう）
    • ☆採用が難しいのは仕方ないが、会社の思想の共有は規模が拡大してもできるかもしれない（提案：選任エンジニアではなく、選任チーム。そして会社の規模拡大へ）
      • 難しいのは自分のことしか考えられない状態に陥っている状態の人で、そういう部分は面談やワークショップで解決できるのでは、という風に個人的には思う
      • 採用面（そして教育）はどうしても難しい気がするので、たとえば選任エンジニアではなく、選任チームとして案件をこなすのはどうか。
      • チームによるメリット：分業による効率化
      • チームによるデメリット：複数名を抱えることでのコスト増（サービス提供側）、助け合いの精神が無いと破綻する

↓会社の思想の共有や、強いチーム・会社を作るためにこの本がきっと役立つと個人的に思います