「納品」をなくせばうまくいく を読んだよ

感想

目的とするところ

p.82 より抜粋

なぜそのソフトウェアが必要なのか，その事業で実現したいこと，そのために妨げになっている課題は何か

ここにタイトルの全てがつまっている気がする．
顧客企業と自社で，同じく事業の成長を望む意識でまとまって動けるかどうか．
一括請負との対比で，一括請負の場合は，自社(自分) の利益に留まってしまう．
ということかな．

顧客企業に上記価値を提供するためには，というところで，
「技術力」「素早い提供」などがある．と

大事なポイント

p.106 より抜粋

「操作がひと回りする」こと

私たちが顧客と最初に考えるのは「操作がひと回りする」ことです．
「ひと回りする」とは，サービス全体の流れの中で，ソフトウェアを利用するユーザが最初に使い始めて，ひと通りの操作から作り上げてしまう必要はなく，人力で対応する(運用でカバーする)部分があってもよいのですが，とにかく操作が「ひと回りする」ところまでを想定します．

これすごい同意できます．
局所的に言うと，最初にデプロイできるところまで作る話と近いでしょうか？
それを事業の単位で考えておく．ということですね．
モノを作るだけのエンジニアでは到達できない状態だと思います．
顧客側も考え方をシフトしないとできない話ですね．

技術力とは

顧客に価値を提供するためには，「選択を提示する」くらいの技術力が必要である．
チーム(会社)として仕事をする場合に，統一された技術 が必要です．

そもそも技術など情報発信が営業を兼ねている．

技術が自動的に向上する仕組みみたいなイメージでしょうか．

読んでいて気になったポイント

• インターネットが対象領域，社内システムなどは難しい．というところだった．
  • → 受託開発では，という意味だろうか．社内の開発部が同様のことを意識してもいい気がします．まあ，そうすると「納品」との対比にならないか…

• ドキュメントが無いというのも，社内でリスク分を担保しているんだろう．(開発方法の標準化などで，そもそもドキュメントの必要性を減らしたり，というのもあるかもしれない)
  • → 技術の統一というそのまま書いてありました．

• 分担範囲とか．技術者は，どこまでやるのだろうか？
  • 思い付きの機能を却下する文脈で，事業に不適切かどうかを考えるかどうか，
  • 事業自体についても考え始めたらどうなるのか？
  • → 下にありますが，全部こなせるようになるのは，良い．ということかな？

• エンジニアのキャリアとは
  • → 企画から考えて，ひと通りの工程をこなせる．一生成長できる．という仮定みたい．

• エンジニアの評価とは
  • → 実績が自社のビジネスの結果に結びつく

その他

一括請負 <-> 納品のない受託 という構図だと思っています．
技術者と発注者が別の会社ではなくて同じ会社でもいいのかなと思ったりしましたが，
そこまで書くと発散するからあまり触れていないのかもと思いました．
リスクヘッジなどを考慮して，顧客が複数の方がいいんですかね．

(顧客) <-(仕事)-> (受託会社) <=(所属)= (個人) =(ワーク，コモンセンス)= (個人)

(受託会社) =(ギルド)= (他の会社 or のれんわけ)

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

デカめな技術的な仕組みという点では，こちらも読み返してみる．

テストから見えてくる グーグルのソフトウェア開発