Monthly Archives: 9月 2014

「「納品」をなくせばうまくいく」第7回 (9/30)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 pp.192-217

6章 エンジニアがナレッジワーカーになる日

  • 04 ナレッジワーカーとしてのエンジニアをどうやって育てるか
    • ルールで縛らずメンター制度で
      • p.192 l.6
        顧客に見立てる社内の人間は非エンジニアだろうか。
    • エンジニアは「ナレッジワーカー」
    • 「ワークレビュー」の進め方
      • p.196
        ワークレビューは、ふりかえりの事?
      • p.198 後ろ6行
        上辺だけのなぜではなく、なぜを繰り返して本質が見えてくることも多いと思うし、そうしてそもそもがわかってくることもあると思う。
    • ワークレビューでカルチャーが浸透していく

7章 「納品のない受託開発」をオープン化する

  • 01 「納品のない受託開発」がもたらす未来
    • 一括請負と競合はしない
    • 新しい選択肢としての「納品のない受託開発」
    • ソフトウェア業界における位置づけ
      • p.206 図
        左半分は受託開発ということですね。
    • ソフトウェア業界に革命を起こす
  • 02 小さな会社の大きなビジョン
    • 目の前のパンを分け合える仲間として
    • 小さな会社の方が幸せを感じやすい
    • 規模が優位でなくなるこれからの社会

「「納品」をなくせばうまくいく」第6回(9/26)

Posted on by 0 comment

参加者 今井(読み手)、青木、沼田(記)
範囲 pp 156 – 191

5章 「納品のない受託開発」を支える技術とマネジメント

  • 02 「納品のない受託開発」を支える技術戦略
    • クラウドを活用した自動化と合理化
    • 幅広いスキルを備えたエンジニアの兼務
  • 03 アジャイル開発によるマネジメント
    • アジャイル開発とは何か
    • 「アジャイル開発」導入のメリットと効果
      • p.165のアジャイル開発のプロセスの図
        この描き方だと、コミュニケーションをとるのとプログラムを書くのは別の人のように見える。
  • 04 人を信頼し、中心におく経営
    • マネジメントしない会社
    • 自己組織化されたチームを作るために
    • 「属人性の排除」より「人を大事にする」
      • p.170の後半
        やはりプログラムの読みやすさは大事ですね
    • 役立つ情報発信で顧客はついてくる

6章 エンジニアがナレッジワーカーになる日

  • 01 アジャイル開発を実践する新しいビジネスモデル
    • これまでの受託開発は「別の業種」
    • アジャイル開発にフィットした「受託開発」
  • 02 エンジニアにとっての幸福な働き方とは
    • エンジニアを一生の仕事に
    • エンジニアが正当に評価される仕組み
    • 向上心のあるエンジニアには最高の舞台
    • 会社は顧客と社員を幸せにする仕組み
    • 在宅勤務や海外ホームステイの社員も
  • 03 優秀なエンジニアを採用するには
    • 一人の採用に半年かける
    • 採用で見極める「TIPS」

「「納品」をなくせばうまくいく」第5回 (9/19)

Posted on by 0 comment

参加者 沼田(読み手)、今井、青木(記)

範囲 pp.123-155

4章 事例に見る「納品のない受託開発」

  • 01 まるで“子育て”のようなソフトウェア開発 —【事例1】株式会社AsMama
    • 【顧客企業の声】最初は小さく作って大きく育てる“リーンスタートアップ”を実践
      • ソフトウェアを作るのは目的ではない
      • 最初は小さく作って少しずつ改良していく
      • 一緒に会社を変えていくCTOのような存在
  • 02 仕様変更に柔軟かつスピーディーに対応 —【事例2】株式会社トライフ
    • スタートアップが大手企業に勝つには
    • 【顧客企業の声】いったん作ったソフトウェアをリセットしてユーザーの声を反映したシステムを構築
      • 課題だらけの旧システム
      • 相次ぐ仕様変更に対応
        • 我々の業界ではプロジェクトの開始にキックオフミーティングというミーティングを行うのですが、「キックオフ△△」という言葉は、他業界でも使うのですねー
      • 学生の生の声をシステムに反映させて
      • フラットでフェアな採用市場の実現を目指して
      • エンジニアの立場で経営コンサルティングを

5章 「納品のない受託開発」を支える技術とマネジメント

  • 01 「完成」から「持続」への変化
    • エンジニアに求められるパラダイムシフトへの対応
    • 「バグはゼロに」ではなく、すぐに直せること
    • 落ちないサーバーよりすぐに復旧できるサーバー
    • 「あらかじめ仕込む」よりも「必要になるまで作らない」
    • ソフトウェアは所有から利用へ
  • 02 「納品のない受託開発」を支える技術戦略
    • 格安航空会社はなぜ成立するのか?
    • 扱う技術の統一化
      • p.154 l.9 「その中身で何で動いている」→「その中身が何で動いている」の方がしっくりくる

「「納品」をなくせばうまくいく」第4回 (9/16)

Posted on by 0 comment

参加者 青木(読み手)、今井(記)

範囲 pp.99-122

3章 顧客から見た「納品のない受託開発」の進め方

  • 03 顧客が分担する作業もある
    • 打合せには顧客の責任者が同席
    • できることはお互いに協力し合う
      • p.102 顧客による文言の修正に関して
        構成管理はどのように行っているのだろう?
  • 04 開発と運用を繰り返して改良し続ける
    • 3か月単位にマイルストーン
    • 「操作がひと回りする」こと
    • 作業の優先順位を決める
      • p.109 上図
        タスクからプログラムへの矢印がなければわかりやすいのに。
    • サービスの開始と運用
      • p.111 最終行~ 動作確認環境から本番環境へ反映に関して
        「継続的デリバリー」にあったような仕組みができているのだろう。
    • 何のために繰り返すのか?

4章 事例に見る「納品のない受託開発」

  • 01 まるで“子育て”のようなソフトウェア開発 —【事例1】株式会社AsMama
    • 「子育てシェア」でがんばるママやパパをサポート
    • 【顧客企業の声】最初は小さく作って大きく育てる“リーンスタートアップ”を実践
      • システム不信、エンジニア不信に…

 

「「納品」をなくせばうまくいく」第3回(9/12)

Posted on by 0 comment

参加者 今井(読み手)、青木、沼田(記)
範囲 pp 66 – 98

2章 時代が「納品のない受託開発」を求めている

  • 03 「納品のない受託開発」の契約
    • サービス業に見積りは不要
    • 「お試し期間」でチェック
    • 契約の終わるとき
      • p.69 …顧客はサービスの提供は継続していける…(最後の行)
        • 顧客「に」の誤り?
        • 顧客は「エンドユーザーに」ということだろう
    • 重要なのは誠実さと信頼関係
  • 04 この世界に「銀の弾丸」は存在しない
    • 「納品のない受託開発」に不向きの案件
    • 求めるのは「ソフトウェアの完成」ではない

3章 顧客からみた「納品のない受託開発」の進め方

  • 01 「何を作るか」よりも「なぜ作るのか」
    • 「納品のない受託開発」の全体の流れ
    • ソフトウェアよりも顧客のビジネスが大切
    • 毎週のミーティングですること
  • 02 開発と運用が同時並行で進んでいく
    • 動いているソフトウェアが「仕様」です
    • 開発と運用を分けて考えない
    • ソフトウェアの保守性でも有利
  • 03 顧客が分担する作業もある
    • 顧客のビジネスを推進する“チーム”

「「納品」をなくせばうまくいく」第2回 (9/9)

Posted on by 0 comment

参加者 沼田(読み手)、今井、青木(記)

範囲 pp 30-65

1章 常識をくつがえす「納品のない受託開発」とは

  • 03 ソフトウェアはなぜそんなに高いのか?
    • 開発と運用で業者が別
    • 最大事を想定したハードウェアの購入
      • ムーアの法則は思ったより古く(1965年)からあるのですね。
  • 04 「納品のない受託開発」が問題を解決する
    • 「納品」こそがすべての問題の根っこ
    • 月額定額の受託開発
    • 成果契約の受託開発
    • 顧客のパートナーになりたい
  • 05 弁護士や税理士のような”顧問”ビジネスとして
    • 本業以外は専門家に任せる
    • エンジニアを雇用して内製することの難しさ

2章 時代が「納品のない受託開発」を求めている

  • 01 スタートアップに適したシステム開発とは
    • 主な顧客はスタートアップ
    • インターネットが企業を顧客を結びつけた
    • 新規事業における課題とニーズ
    • 最初はスモールスタートで
  • 02 「納品のない受託開発」で解決できること
    • 要件を一度に決めなくていい
    • どれだけ仕様変更してもいい
    • 「作らない提案」をすることも
    • 何でも気軽に相談できる

「「納品」をなくせばうまくいく」第1回 (9/5)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 pp.1-30

  • 表紙
  • 奥付
  • はじめに
  • 目次

1章 常識をくつがえす「納品のない受託開発」とは

  • 01 受託開発なのに「納品」がない?
    • 「納めて終わり」からの脱却
    • 「一括請負」に潜む様々な問題
    • 「要件定義」は誰のためか
    • 「ソフトウェアの価値」とは何か
      • p.18 図
        • このグラフは時間に対する、それまでにかかった総費用を表している?。
          – 固定費と書かれている水平な線は(例えば)ソフトの購入費で納品時にかかるだけ
          – 変動費とかかれている点線は(例えば)ランニングコストのその時間までの総費用で時間と共に増えていく
          – コストの斜め線はこの二つの合計
          ということか?
          横軸が売上額ではなく時間軸なので、変動費、固定費という言葉が何かわかりにくい。
          全体として言いたいことは良くわかる。
        • ソフトウェアだけでなく、製品を購入した場合は大抵このようになるのではないか。
  • 02 「納品」が引き起こしてきた問題とは
    • 「完成リスク」を引き受けるビジネス
    • 創意工夫を阻む「ディフェンシブな開発」
    • これまでのシステム会社の価値は保険?
      • p.24 左から4行目~
        「人月」を使わなくても労働集約型になってしまうのでは?
        → この先読み進めていって考えてみよう。
    • ダメなエンジニアの方が儲かる!?
      • p.26
        過去にそう感じることはあった。
  • 03 ソフトウェアはなぜそんなに高いのか?
    • ソフトウェア開発の費用対効果の悪さ
    • 見積における過大な“バッファ”