「納品」をなくせばうまくいく

かなり良本。
私個人も現代のSIer業界に違和感を感じて悩めるエンジニアに対してキャリアコンサルを提示しているが、本来エンジニアのあるべき姿。
特にフリーランスSEという働き方はあるが、本来フリーランスはプロ（個人事業主）。ようは1人社長だ。
なのにも関わらず、某エージェントの「簡単に稼げる」という...続きを読む煽り文句の広告のせいで、ナレッジワーカーな姿勢が見えない、中途半端なフリーランスSEが増えて来た。
最終的にはスキルもないのに「楽して高収入」目的で、フリーランスに入る。
エージェントにはワガママを、現場にはできないタスクを押し付ける微妙なエンジニアも増えていく。
ぜひ、エンジニア、そして全てのSIer業界の役職ある方達は読んで欲しい良本。
むしろ2014年に発刊して、未だに変わらないこの状態であることが不思議。
だからこそ、我々から見ると穴だらけなのだが多くの人は気づいていない。

以前勤めていた職場のつながりもあって読んでみた一冊。今の仕事でもそうだし、この形での働き方は求められているだろうなと思いました。これまでのやり方を踏襲してうまいことまわそうとすると、技術の進歩のスピードやお客さんの要望の変化するスピードとのギャップが大きくなりがち。割と地方の中小企業のIT相談役のよ...続きを読むうな役回りをしている企業はこういう問題を多く抱えていると思うし、ベストエフォートで定額で一緒に頑張っていきましょう、の方がお互いに無理なく前に進んでいけると思いました。いいヒントをもらったな、という印象です。

自分はシステム開発など、全く門外漢ですが、とても、共感できる内容。
自分が働きたいのはこんな仕組みの会社だなと感じました。

スッキリとして読みやすいのに、とても整理された文章も印象的。会社の内容と同時に、こちらもスッキリしてムダがない。そして、芯がしっかりしています。

この理念というか考え方は、...続きを読む今後、日本の中小企業が皆見習うべき部分だと思います。

システムの受託開発を長くやっていると、顧客と開発者との間に意識のギャップを感じることが時々あります。システムの完成させるという目標は一致しているはずなのに、その先の最終ゴールの捉え方が致命的に異なるのです。
こうしたギャップは、システムを使ってビジネスを拡大したり作業を改善することをゴールと捉える側...続きを読む（顧客）と、システムを完成させること自体をゴールとする側（開発者）の立ち位置の違いから考えると、当然なのかも知れません。
このようなジレンマを抱えながらシステムの受託開発をやってきた私のモヤモヤを、本書は多少なりとも晴らしてくれたような気がします。

システム開発側（特にエンジニア）はとかくシステムを作ることだけに目が向きがちですが、「ソフトウェアは使い続けることではじめて価値が出る」「なぜそのソフトウェアが必要なのか」等々を常に念頭に置いて顧客と接することで、顧客からの信頼を勝ち取ることにも繋がるのではないでしょうか。
特にソフトウェアは出来上がるまで目に見えない分、使ってみることで顧客が本当に必要とするものが分かることが多々あります。そういった意味でも「納品のないソフトウェア開発」のスタイルは、本当に必要なものだけ作ることが実現できる分、余計なコストがかからず顧客にとっても嬉しいはずです。
一方エンジニアにとっても、顧客からのフィードバックを受けやすく、やりがいのあるやり方であると言えるでしょう。

本書にも書かれているとおり、「納品のないソフトウェア開発」はサービスを提供する会社やスタートアップ企業と相性が良いようです。一方で、少数精鋭のエンジニアで臨む分、大規模な基幹システムには向かないような気がします。
ただ、たとえ大規模システムであっても、顧客と開発者の連携やワークレビューなど「納品のないソフトウェア開発」のやり方を応用することで、従来のプロセスを見直すヒントになるのではないかと感じています。

株式会社ソニックガーデンで実際に行われている
「納品のない受託開発」という新たな開発スタイルに関して、
・どんなものか説明
・どのような利点があるか
・既存の受託開発の問題点
・自社の枠に留まらない「納品のない受託開発」の展望
などについてまとめてあります。

従来のウォーターフォール・人月見積もり...続きを読むなど問題点の多くある
業界では、未だにそういった状況を抜けだせていない現場が多い。

アジャイルな手法を導入してみるものの失敗したりしている現場もあるが、
非効率な商慣習の縛りをそのままにアジャイルの手法を導入しているため、
うまくいかなかったり・・・。

そんなケースが多い中、「納品のない受託開発」では顧客との取引方法を
根本的に変え・取引相手も開発スタイルに適した相手に絞ることで、
アジャイル・スクラムなど有効とされる開発手法を徹底的に導入して
システム開発会社・エンジニア・顧客全てがWin✕Winになります。

紹介されている各トピックは、勉強熱心なエンジニアの方ならどこかで
聞いたことのある内容が多いと思います。
しかし、色々と既存の制約に縛られがちな日本の受託システム開発において、
これらのトピックを有効活用し、実運用に活かせるように適用する方法を考え、
実際に事業を回していることにこそ、この手法の価値があるのだと思います。

システム開発に関わるものであれば、
読んで何かしらを得られる良書だと思います。

納品に追われ、終わったら別の顧客（案件）という流れにいる身としては、全く対極で刺激的な内容。お客さんと、月額に対する成果の価値観に差がでないか？など気になる点もあるけど、うまくできれば顧客との関係や働き方、やりがいなどプラスの面も多そう。

「納品のない受託開発」というソニックガーデンのビジネスモデルについて、効果・仕組み・向き不向き・事例などについて、従来型の一括請負の問題点の指摘とともに説明されている。

「納品のない受託開発」は合理的で素晴らしい仕組みだと思うが、本書でも注意喚起されているとおり万能ではなく、また、実現のための前提...続きを読むが難しいものになっている。
たとえば、エンジニアや会社のスキルやモチベーションの要求水準が高いこと、顧客側の作業や体制への要求も比較的高いこと、システムの会社や規模に制約があること、など。
つまり、ソニックガーデンやそれに類するレベルの高さが要求されるため、誰でも容易に真似できるわけではないという点は留意したい。

本書は昔買ってから時々つまみ食いのように読むだけで積んだままになっていたが、唐突に読みたい気持ちが高まってきたので読んだ。
スピードを重視して4章と7章は流し読みした。

35ページ
納品があるから見積りが必要で、逆算して人月を使わなくてはいけないし、バッファが入って高くなる。さらに、現実的でない要件定義をしなければいけないし、開発と運用の切れ目ができて担当者が変わると、その引き継ぎコストがかかるなど、一つもよいことがありません。
→わかる。そういうものだと割り切っている。

37ページ
毎月の決まった金額の中で、「できる範囲」で精一杯の「開発と運用」を行います。ソフトウェアの開発と運用を分けることなく一体的に担い、その他にもソフトウェアに関わるあらゆる問題について対応します。
→よい答えではあるけど、担当者のハードルが高い。高いスキルとモチベーションが必要になる。

52ページ
エンジニアを採用してインソーシング（内製）することの難しさと、一括請負でアウトソーシングする要件定義の難しさの両方に困った会社が、要件定義をしなくてもよい「納品のない受託開発」を求めているというわけです。
→たしかにこのシチュエーションなら非常にマッチすると思う。実際問題としてエンジニアの採用は採用側がエンジニアであったとしても難しいし、要件定義をするにもエンジニアリングのノウハウがなければ成功率は低いだろう（まぐれで成功することもあるとは思う）。

71ページ
実際にこのビジネスモデルには、それを遂行する上での課題や注意点が多くあります。その中で時間をかけて経験を積み、ノウハウを得ていくことでしか、うまく進める方法はないと思います。
→これもわかる。容易ではないし、これを実行できているソニックガーデンはすごい。

99ページ
事業の設計段階はもとより、開発段階での毎週の打合せの際に必ずお願いするのは、打合せの場に顧客の事業責任者に同席してもらうことです。
→ハードルが高い。巷でアジャイルのマネごとをしてもうまくいかないときにありがちな原因のひとつ。開発会社だけががんばって取り組んでも、同じタイミングに顧客側が同じくらいがんばって取り組めなければうまくいかない。開発会社は顧客の理解を得て誘導しなければいけないし、顧客は理解した上でついていかなければいけない。

102ページ
たとえば、毎週の打合せや動作確認も、顧客からすればそれなりの時間と手間を取られることになります。
→99ページの件と同じくハードルが高い。

147ページ
これに対して、「納品のない受託開発」では顧問のエンジニアがずっと担当で付くことや、チーム内での情報共有をしっかりすること、誰が読んでもわかりやすい見通しの良いプログラムを書くようにすることで、何かあってもすぐに治せることに重点を置くのです。
→素晴らしい。この考え方は納品のない受託開発に限らず、通常の開発であっても適用するべきだと思う。

158ページ
それだけの幅広いスキルを備えたエンジニアはなかなかいないのでは、と思われるでしょう。たしかに誰にでもできる仕事ではないと思いますが、私はそもそもソフトウェア開発とは、誰にでもできるものではないと思っています。
→ハードルが高い。しかし書いていることはごもっともである。

170ページ
日本語の資料を残さない代わりに、プログラムの読みやすさには徹底的にこだわっています。
→素晴らしい。巷のシステム開発では、ドキュメントは書かず、プログラムも難解で読みづらい状態になっているというケースが少なくない。ドキュメントを書かないこと自体は問題ではないが、その分、保守性を担保できるような手立てを用意して責任を取るのがプロの仕事である。

180ページ
私の言うプログラマーとは、「納品のない受託開発」で求められるような、企画の段階から考えて、画面のデザインや仕組みの設計ができて、それを自らプログラミングし、クラウドでの運用まで、ソフトウェア・エンジニアリングに関わるすべての工程をこなせる人のことを指しています。
→ハードルが高い。必要な仕事であってもそこは自分のスコープ外だからやりません・知りません、という態度をとって見向きもしないような人間ではいけない。

189ページ
これは、テクニック（T）、インテリジェンス（I）、パーソナリティ（P）、スピード（S）の4つの頭文字を合わせたもので、この4つの視点は、私たちが優れたエンジニアを選抜する際に考えていることにそのまま当てはまります。
→使えそう。マネしてみようと思った。

196ページ
進行としては、KPTのKとPを、レビューされる側（＝レビューイ）がまず一人で出します。出揃った段階で、レビューする側（＝レビューア）とともに内容の確認をします。
→KPT自体は元々知っていたしやったこともあったけど、ワークレビューとして使う点や、K・Pをレビューイだけで書き出す点は理解できていなかった。

199ページ
社内規則（ルール）を明文化して社員を縛るよりも、ワークレビューを通じて、良識（コモンセンス）を共有することで社員を育てるという感覚を大切にしています。
→素晴らしい。実現性・有効性のあるオンボーディングの方法に悩んだことがあったので、今後はマネしようと思った。

200ページ
「ワークレビュー」は採用の際にも使えます。
→素晴らしい。目から鱗でした。これもマネしたい。

210ページ
90年代に登場したJavaは、最初はおもちゃのようだと思われていました。
→このエピソードは例え話なので本題ではないのだけど、この事実を知らなくて驚きがあった。たしかに冗長で過小評価されるのも理解できるし、その後のWindows・GUIの普及とJavaの躍進はむしろ過大評価かもしれないけど。

215ページ
もちろん、セルフマネジメントができているということが前提であって、真面目な性格であることも重要でしょう。そして、そういう社員だけを採用しているからこそできるのです。
→何回書いたかわからないけどハードルが高い。

229ページ
よく講演などでは「心はプログラマー、仕事は経営者」と自己紹介をしたりしています。
→よい。これも参考にしたい。心はユーザー、体はエンジニア、仕事はマネージャー。

ソフト開発を月額定額制料金にして、納品なし顧客のパートナーになるというソフトウェア開発会社。
ソフト開発者の理想の形かと。

5年ほど前の本なので知っている内容がほとんどだったが、ビジネスモデルとして実践しているという点でとても参考になった。

これまでのソフトウェア開発の狭間を埋める、納品のない開発。所有ではなく、利用に焦点を絞って、毎月定額で、ソフトウェア開発サービスを提供するという感じか？成果に焦点を当てるという非常に意欲的な取り組み。取り回しの良い小規模企業でないとなかなか上手く行かなそうだが、ギルドという仕組みで、フリーランスやそ...続きを読むれ以外の共感する人々を取り込んで行こうという発想は素晴らしいと思う。

以下注目点

・本当に必要な機能を本当に必要な順番に少しずつ開発していく
・デフェンシブな開発からアグレッシブな開発へ。
・オーダメイド、納品しない、派遣しない。
・開発と運用を担当
・完成責任は請け負わない代わりに、圧倒的な費用対効果を提供する
・専門性の高い職種に対して、他の社員と同じ扱いはできない。
・プロフェッショナルサービス
・新規事業と要件定義の相性は最悪
・一ヶ月から3ヶ月程度で開発できる機能で、はやめに運用に入る。
・作らない提案。思いつき程度の機能は、すぐには作らない。
・納品ではないので、瑕疵担保責任は負わない。
・ドキュメント読み終わった、訪問読み終わった、納期や完成品の約束読み終わった。
・要件を定義するのではなく、事業の目的を共有する。
・顧客が動作確認できるレベルで作業を切り出す。
・なぜその機能が必要なのか
・所有から利用へ、完成から持続へ
・本当に必要になるまで、予想で作ったりするのはやめよう。
・資料を残さない代わりに、コードを読みやすくすることにこだわっている。
・KPT keep, problem, try
・そもそもを考え、何をやらないかを決める。