BP Study#18 リーンソフトウェア開発

勉強会 ソフトウェア開発

MOONGIFTの人


途中から参加

せつめー

毎日ビルド&テスト
決定は先に遅らせる
  • 例えば、開発が始まるずっと前にフレームワーク等を決定してしまうと柔軟性がなくなる
  • 状況の変化
    • あらかじめオプションを用意しておく(各特性を把握しておく)
    • どこで判断するかは経験則
  • 気が変わる
    • 速く(気が変わる前に)提供する
人を尊重する
  • マイクロマネジメントはやる気を損なう
  • エキスパートエンジニアを育てる
    • ある程度シャッフルして3人のエキスパートチームを作るとかもあり
全体最適化
  • 顧客のビジネスまで含んで最適化
  • 利益に相反する最適化については別途交渉する
  • 全体最適化に合致するインセンティブ
    • 時給だと生産性低い人の方が給料をたくさん貰える
  • 個々人がプロフェッショナルにならないといけない

事例

段階的開発
コーディング量の軽減
  • Rails利用、plugin活用
  • テスト量は増えた
オプションとして提示したもののうちいくつかはポシャった
    • お客さん的にも最小限のものを使って、それから必要なものを出していく事が大事
    • 認証を後々の事を考え過ぎてLDAPにするのではなく、独自にさくっと実装(ただし後で差し替えられるようにはしてある)
テストファースト
料金体系
  • リリースまでは最低限(開発側が貰う上での最低限で、お客さんが何とか納得出来る額)
  • リリース&検収後に残りを貰う(成果報酬形式)
  • 全額随時貰うとお客さんが納得出来ない、全額検収後に貰うと開発会社の資金繰りが厳しい
  • 金額的には、最低限:残り=1:2
  • 見積もりの中身については、自分たちの利益がどれくらいになるかまでオープンにする
  • お互い誠意を見せるのが大事

感想

  • 変化を自然として受け入れると気持ちがいい
    • 何でも無制限に受けるという事ではなく、受け入れる事によってどうなるかお客さんとちゃんと話し合う
  • 契約より信頼
    • 信頼あってこその契約
  • 手早く組み立てる癖ができる

リーンについて

リーンとオープンソース
リーンとエンジニア
  • 金型工
  • 顧客のアバウトなニーズを具現化し、さらに変化に強くある職人
  • 様々な類似技術を知り、数字データを元に採用すべき技術を提案出来る
  • いかに素早く顧客のニーズに応えられるか追求
リーンとは結局何か？
  • リーンは無駄を省く事
  • 無駄は会社や個人によって違う
    • 日々継続的な最適化

おまけMOONGIFTについて

  • 情報は咀嚼して利用可能な状態にしておくのが大切
    • 上っ面だけなぞるのは駄目
  • 紹介するオープンソースソフトウェアは可能な限り試す