あらすじ
ソフトウェア業界の“常識”をくつがえすビジネスモデルを大公開！
これまでの「一括請負」には、予算・人員・納期が限られるなかで、開発企業は疲弊していき、ユーザー企業も料金に見合う満足度を得られないという根深い問題がありました。
こうした通弊を解決するのが「納品のない受託開発」。これは、開発企業がユーザー企業と月額定額制の顧問契約を結ぶことで、納期を廃して、開発から運用までをトータルで継続的にサポートするもの。
従来とはまったく逆の発想をゆく新たなビジネスモデルを考案し、日々実践する経営者が業界の構造的な問題に鋭く切り込み、新たなソリューションを提示します。
ソフトウェアエンジニアをはじめ、システムインテグレーター・IT企業の営業担当者や経営幹部、ユーザー企業の担当者、就職学生、起業家などにもオススメです！
【目次】
1章 常識をくつがえす「納品のない受託開発」とは
受託開発なのに「納品」がない？
「納品」が引き起こしてきた問題とは
ソフトウェアはなぜそんなに高いのか？
「納品のない受託開発」が問題を解決する
弁護士や税理士のような“顧問”ビジネスとして
2章 時代が「納品のない受託開発」を求めている
スタートアップに適したシステム開発とは
「納品のない受託開発」で解決できること
「納品のない受託開発」の契約
この世界に「銀の弾丸」は存在しない
3章 顧客から見た「納品のない受託開発」の進め方
「何を作るか」よりも「なぜ作るのか」
開発と運用が同時並行で進んでいく
顧客が分担する作業もある
開発と運用を繰り返して改良し続ける
4章 事例に見る「納品のない受託開発」
まるで“子育て”のようなソフトウェア開発──株式会社AsMama
仕様変更に柔軟かつスピーディに対応──株式会社トライフ
5章 「納品のない受託開発」を支える技術とマネジメント
「完成」から「持続」への変化
「納品のない受託開発」を支える技術戦略
アジャイル開発によるマネジメント
人を信頼し、中心におく経営
6章 エンジニアがナレッジワーカーになる日
アジャイル開発を実践する新しいビジネスモデル
エンジニアにとっての幸福な働き方とは
優秀なエンジニアを採用するには
ナレッジワーカーとしてのエンジニアをどうやって育てるか
7章 「納品のない受託開発」をオープン化する
「納品のない受託開発」がもたらす未来
小さな会社の大きなビジョン
「ベストエフォート経営」で社員の幸せを大事にする
「納品のない受託開発」を拡大する「のれん分け」と「ギルド」
Social Change! 自分の変化を世界に広げていくこと
感情タグBEST3
Posted by ブクログ
かなり良本。
私個人も現代のSIer業界に違和感を感じて悩めるエンジニアに対してキャリアコンサルを提示しているが、本来エンジニアのあるべき姿。
特にフリーランスSEという働き方はあるが、本来フリーランスはプロ（個人事業主）。ようは1人社長だ。
なのにも関わらず、某エージェントの「簡単に稼げる」という煽り文句の広告のせいで、ナレッジワーカーな姿勢が見えない、中途半端なフリーランスSEが増えて来た。
最終的にはスキルもないのに「楽して高収入」目的で、フリーランスに入る。
エージェントにはワガママを、現場にはできないタスクを押し付ける微妙なエンジニアも増えていく。
ぜひ、エンジニア、そして全てのSIer業界の役職ある方達は読んで欲しい良本。
むしろ2014年に発刊して、未だに変わらないこの状態であることが不思議。
だからこそ、我々から見ると穴だらけなのだが多くの人は気づいていない。
Posted by ブクログ
以前勤めていた職場のつながりもあって読んでみた一冊。今の仕事でもそうだし、この形での働き方は求められているだろうなと思いました。これまでのやり方を踏襲してうまいことまわそうとすると、技術の進歩のスピードやお客さんの要望の変化するスピードとのギャップが大きくなりがち。割と地方の中小企業のIT相談役のような役回りをしている企業はこういう問題を多く抱えていると思うし、ベストエフォートで定額で一緒に頑張っていきましょう、の方がお互いに無理なく前に進んでいけると思いました。いいヒントをもらったな、という印象です。
Posted by ブクログ
自分はシステム開発など、全く門外漢ですが、とても、共感できる内容。
自分が働きたいのはこんな仕組みの会社だなと感じました。
スッキリとして読みやすいのに、とても整理された文章も印象的。会社の内容と同時に、こちらもスッキリしてムダがない。そして、芯がしっかりしています。
この理念というか考え方は、今後、日本の中小企業が皆見習うべき部分だと思います。
Posted by ブクログ
システムの受託開発を長くやっていると、顧客と開発者との間に意識のギャップを感じることが時々あります。システムの完成させるという目標は一致しているはずなのに、その先の最終ゴールの捉え方が致命的に異なるのです。
こうしたギャップは、システムを使ってビジネスを拡大したり作業を改善することをゴールと捉える側（顧客）と、システムを完成させること自体をゴールとする側（開発者）の立ち位置の違いから考えると、当然なのかも知れません。
このようなジレンマを抱えながらシステムの受託開発をやってきた私のモヤモヤを、本書は多少なりとも晴らしてくれたような気がします。
システム開発側（特にエンジニア）はとかくシステムを作ることだけに目が向きがちですが、「ソフトウェアは使い続けることではじめて価値が出る」「なぜそのソフトウェアが必要なのか」等々を常に念頭に置いて顧客と接することで、顧客からの信頼を勝ち取ることにも繋がるのではないでしょうか。
特にソフトウェアは出来上がるまで目に見えない分、使ってみることで顧客が本当に必要とするものが分かることが多々あります。そういった意味でも「納品のないソフトウェア開発」のスタイルは、本当に必要なものだけ作ることが実現できる分、余計なコストがかからず顧客にとっても嬉しいはずです。
一方エンジニアにとっても、顧客からのフィードバックを受けやすく、やりがいのあるやり方であると言えるでしょう。
本書にも書かれているとおり、「納品のないソフトウェア開発」はサービスを提供する会社やスタートアップ企業と相性が良いようです。一方で、少数精鋭のエンジニアで臨む分、大規模な基幹システムには向かないような気がします。
ただ、たとえ大規模システムであっても、顧客と開発者の連携やワークレビューなど「納品のないソフトウェア開発」のやり方を応用することで、従来のプロセスを見直すヒントになるのではないかと感じています。
Posted by ブクログ
（納品のない受託開発とは？）……本当に必要な機能を本当に必要な順番に、少しずつ開発をしていくことが大事になります。一度に「作りきる」のではなく、少しずつ作っていくために、私たちは月額定額制で「納品をしない受託開発」をすることにしました。
（格安航空会社はなぜ成立するのか？）……・使用する飛行機の機種を統一することで整備費やパイロットの訓練費を削減したこと。・搭乗手続きのオンライン化などITを活用した自動化・乗務員が機内の清掃などを行い一人何役もこなすことによる人件費の削減です。
（「バグはゼロ」ではなく、すぐに直せること？）……「納品のない受託開発」では顧問のエンジニアがずっと担当で付くことや、チーム内での情報共有をしっかりすること、誰が読んでもわかりやすい見通しのよいプログラムを書くことで何があってもすぐに直せることに重点をおくのです。
Posted by ブクログ
株式会社ソニックガーデンで実際に行われている
「納品のない受託開発」という新たな開発スタイルに関して、
・どんなものか説明
・どのような利点があるか
・既存の受託開発の問題点
・自社の枠に留まらない「納品のない受託開発」の展望
などについてまとめてあります。
従来のウォーターフォール・人月見積もりなど問題点の多くある
業界では、未だにそういった状況を抜けだせていない現場が多い。
アジャイルな手法を導入してみるものの失敗したりしている現場もあるが、
非効率な商慣習の縛りをそのままにアジャイルの手法を導入しているため、
うまくいかなかったり・・・。
そんなケースが多い中、「納品のない受託開発」では顧客との取引方法を
根本的に変え・取引相手も開発スタイルに適した相手に絞ることで、
アジャイル・スクラムなど有効とされる開発手法を徹底的に導入して
システム開発会社・エンジニア・顧客全てがWin✕Winになります。
紹介されている各トピックは、勉強熱心なエンジニアの方ならどこかで
聞いたことのある内容が多いと思います。
しかし、色々と既存の制約に縛られがちな日本の受託システム開発において、
これらのトピックを有効活用し、実運用に活かせるように適用する方法を考え、
実際に事業を回していることにこそ、この手法の価値があるのだと思います。
システム開発に関わるものであれば、
読んで何かしらを得られる良書だと思います。
Posted by ブクログ
納品に追われ、終わったら別の顧客（案件）という流れにいる身としては、全く対極で刺激的な内容。お客さんと、月額に対する成果の価値観に差がでないか？など気になる点もあるけど、うまくできれば顧客との関係や働き方、やりがいなどプラスの面も多そう。
Posted by ブクログ
アジャイルのスクラムとほぼ同義ではあったので、ある程度知っていることは多かった
とはいえ、顧客にも分かりやすい言葉で噛み砕いて書かれているので、これは発注者こそ読むべき一冊だと思う
また、昨今受託ビジネスはコンサル寄りに移っております、まさに納品という形ではなく顧客のビジネスを共創していくことが求められているので、時代は変わりつつあると実感できる
Posted by ブクログ
「納品のない受託開発」というソニックガーデンのビジネスモデルについて、効果・仕組み・向き不向き・事例などについて、従来型の一括請負の問題点の指摘とともに説明されている。
「納品のない受託開発」は合理的で素晴らしい仕組みだと思うが、本書でも注意喚起されているとおり万能ではなく、また、実現のための前提が難しいものになっている。
たとえば、エンジニアや会社のスキルやモチベーションの要求水準が高いこと、顧客側の作業や体制への要求も比較的高いこと、システムの会社や規模に制約があること、など。
つまり、ソニックガーデンやそれに類するレベルの高さが要求されるため、誰でも容易に真似できるわけではないという点は留意したい。
本書は昔買ってから時々つまみ食いのように読むだけで積んだままになっていたが、唐突に読みたい気持ちが高まってきたので読んだ。
スピードを重視して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ページ
よく講演などでは「心はプログラマー、仕事は経営者」と自己紹介をしたりしています。
→よい。これも参考にしたい。心はユーザー、体はエンジニア、仕事はマネージャー。
Posted by ブクログ
これまでのソフトウェア開発の狭間を埋める、納品のない開発。所有ではなく、利用に焦点を絞って、毎月定額で、ソフトウェア開発サービスを提供するという感じか？成果に焦点を当てるという非常に意欲的な取り組み。取り回しの良い小規模企業でないとなかなか上手く行かなそうだが、ギルドという仕組みで、フリーランスやそれ以外の共感する人々を取り込んで行こうという発想は素晴らしいと思う。
以下注目点
・本当に必要な機能を本当に必要な順番に少しずつ開発していく
・デフェンシブな開発からアグレッシブな開発へ。
・オーダメイド、納品しない、派遣しない。
・開発と運用を担当
・完成責任は請け負わない代わりに、圧倒的な費用対効果を提供する
・専門性の高い職種に対して、他の社員と同じ扱いはできない。
・プロフェッショナルサービス
・新規事業と要件定義の相性は最悪
・一ヶ月から3ヶ月程度で開発できる機能で、はやめに運用に入る。
・作らない提案。思いつき程度の機能は、すぐには作らない。
・納品ではないので、瑕疵担保責任は負わない。
・ドキュメント読み終わった、訪問読み終わった、納期や完成品の約束読み終わった。
・要件を定義するのではなく、事業の目的を共有する。
・顧客が動作確認できるレベルで作業を切り出す。
・なぜその機能が必要なのか
・所有から利用へ、完成から持続へ
・本当に必要になるまで、予想で作ったりするのはやめよう。
・資料を残さない代わりに、コードを読みやすくすることにこだわっている。
・KPT keep, problem, try
・そもそもを考え、何をやらないかを決める。
Posted by ブクログ
顧客のビジネス成功をゴールとするシステム構築をする場合、派遣やSESなどの客先常駐をすることが多いのだが、本書ではそれをせず、月ごとに定額の費用を払うビジネスモデルの解説をしている。
実際にこのようなビジネスモデルに理解をしてくれる顧客が多い企業だとできそう。従来の企業、大企業などは理解を得られにくいかも？でも実現できればお客様・働く側双方にとって良いビジネスモデルとなるから広まって欲しいと思った。
Posted by ブクログ
製品ではなく、サービスを提供する点、またコンサルもできるエンジニアであること。顧客満足度・エンジニアの達成感ともに非常に強く感じられ、ベストなビジネスモデルであると感じた。
また一般的な開発であっても、顧客が真に必要としていることを読み解き、システム化していく点については、共通して重要であり、難しい要素が多いと感じた。
Posted by ブクログ
デスマーチを経験して、受託開発のデメリットを実感した中でこの本を読んだ。
受託開発自体は魅力的な仕事であると思うので、この本に書いてある事が理想的な受託開発だと感じた。
Posted by ブクログ
業界の問題を解決する為に自分でビジネスモデルを作る
ことは凄いと思う。作者の思想がよく描かれていて理解もできるけど、会社経営の視点でみると最低限の利益を得なければ長期的な経営が難しいのではないかと思う。
印象としては気の合うエンジニアの集まりに近い感じが
する。若手を育てる感じはあまりなさそう。
Posted by ブクログ
受託開発（会社）の観点から、顧客のみならずその先のエンドユーザーそして社員を幸せにする仕組みとしての会社ないしはビジネスのあり方を提唱している素晴らしい一冊。
製造業からサービス業へ、工場から工房へ。サービス開発やソフトウェア開発そのものが目的ではなく、ビジネスを成長を望み、目的と手段が混同せず、正しいを追求する姿勢を保ってくれる素晴らしい発想だと思う。
Posted by ブクログ
業務内容としては、別に珍しくもなんともない、技術的にそれほど凄くもない、規模的にも非常に小規模を想像させるな。。。と7割ほど読み進んでから、ようやくビジネスの話がされて、おぉぉ！と唸った
基本的に顧客は自分達の条件に合う企業のみに絞っているという点がある。
・システムは資産化しない、解約＝システム利用不可
・技術はこちら選定（それ以外は受け付けない）
・打ち合わせはWEB or 自社訪問限定
これに見合うとしたら、顧客は小規模、かつ起業間もない起業となる。実際にSierには高額＆ハイスペックすぎて頼めない企業が顧客となるようだ。
現在、日本の起業率の低さをこのビジネスモデルが少しでも解決、また地方でアイディアは持ちながらも実現できない人々を支援できるならば、それは凄いなぁと感じた
これ以外にも今の社員たちを、のれん分けで独立させるなど、まだまだ色々とありそうだ。
Posted by ブクログ
アジャイル開発を前提とした、ソフトウェアビジネスモデルの話。
市場の反応を見ながら仕様を変えていくwebサービスにぴったりというか、いわゆるITベンダーならどこもやっていそうな話。
非IT企業に同じような開発プロセスを提供できるビジネスモデルというところが新しい。
1番の問題は、受け入れ側に、今まであった要件定義という明確な仕様がない状態での発注ができる仕組みがあるかどうか、というところだったりする気が。
製造系の会社って、なぜなぜ的な問いの立て方は得意だけど、そもそも系の問いの立て方は苦手なイメージというかステロタイプがあるので、文化の違いで衝突しそうな…。
そもそも、そんなアタマの硬い製造業の会社はもう淘汰されているか。
Posted by ブクログ
従来の一括請負ではなく、月額定額でソフトウェア開発の対価をもらうビジネスモデル。
エンジニアは基本１人で対応するため、ビジネスを理解し、かつ技術的にもフルスタックエンジニアが求められるので大変そう。
また、著者も言っているが、今のところ大規模開発には対応できない、と。
ただ、この業界にいる身としては、契約形態のパラダイムシフトの第一歩、って感じで良いな、と思った。
Posted by ブクログ
DevOps の実践の一つでしょうか。
瑕疵担保責任はないため、善管注意義務でユーザ側がリスクをテイクできるかがポイントでしょう。
あとはユーザ側に使用を決める設計者がいることも必要。
Posted by ブクログ
スタートアップの会社には
・新規事業の要件が煮詰まり切っていなくても明確な事業方針があれば開発に着手でき、
・進めながら変わっていかれる
・スタートアップの会社がこだわりたい見せ方は、顧客側で作る（一緒に作り上げる）
・月額設定なので事業計画も立てやすい
といった面で魅力的。
Posted by ブクログ
ソフトウェア業界の"常識"を変えるビジネスモデル「納品のない受託開発」を紹介するビジネス書。
職場の知り合いから、長い間借りたまま積読になっていたので、そろそろ返さないと、と半ば強制的に読みました(^-^;
タイトルを見たときから「アジャイル」と何が違うのかが気になってましたが、要は広義のアジャイル開発手法というか、「手を動かすコンサル契約」のようなイメージのビジネスモデルです。
実際、開発手法を「スクラム」のようなアジャイルで進めようとしても、顧客との契約が旧来の契約である限り、また社内開発であっても、プロジェクトの評価方法が旧来の方法である限り、アジャイルは絵に描いた餅になります。
おそらくSIerで働く誰しもが、契約面から見直さないとアジャイルの適用は難しいと感じていたと思いますが、この書籍は、その契約面からのアプローチを実際に実践した形だと思います。
今後は、こういったビジネスの形が主流になっていくような気がしていますが、多くのユーザー企業は欧米のように自社でエンジニアを抱えて、アジャイルで開発していくようになるんじゃないかなー。。
なので、こういったビジネスモデルは、自社でエンジニアを抱えられない、中小規模の会社をターゲットにやっていくのでしょう。結局は、多くのITコンサルと同じですね。
それにしても、SIerの未来が心配です。ホントに世の中に置いてかれるぞ・・・。
Posted by ブクログ
ソフトウェア受託開発の人月ビジネスに疑問を抱いた筆者が、「納品の無い受託開発」という新しい形に挑戦している姿を書いた本。
理念と行動は悪く無いと思う一方で、ビジネスとしては限定的になってしまうかなとも感じた。
さくっと読める一冊。
メモ
自分達のポリシーに合わない仕事をしない、会社とお付き合いしない。
一部参考になる部分はある。
確かに人月ビジネスは違和感と変な部分は多々ある。その常識に真っ向勝負するのは素直にカッコいいと思う。
がしかし、まだまだ理解はされないし、スケールは難しいだろうから、中々業界を変えるまでは時間が掛かるだろう。
納品が無い分、チームになりやすく、最終的に良いプロダクトになる確率は高まるかとも思う。
ソフトウェアを「所有」から「利用」への考え方のパラダイムシフトという考えはとても良い
ワークレビューは面白い考え方。
Posted by ブクログ
読みやすいです。同僚にも読んでもらいたい。
WEBシステムは最初からやりたいことが決めらられなんだから、だったら最初から「納品」をなくした方がいいんじゃない？という話。
最初にやることを決めない替わりに、1週間単位でやることを決めて実装していくというスタイル。
こんな会社で働きたいと思った。
気になったのは、以下の二つ。
* 人の単価をどうやって決めるのか？「この人は何年目だからこの単価です」とかで、客は納得してくれる？
*「来週ここまでやります」という、何を説得材料として説明するのだろうか？
Posted by ブクログ
必ずしも全てのSIに適用できる訳ではないものの、適用できるケースであれば、方法論としてはアリだよな。やはりそもそも、事前に机上で全ての業務、データパターン、イレギュラー処理まで設計するのは容易ではないし、その時は出来たとしてもビジネスが進んでいくと実際の業務との差異も生まれてくる。なので、定額請負の中で、少しずつシステムを成長させていくことは、本来理にかなっているはず。ただ、お客様にもベンダーにも高い意識が求められるので、その理解が得られるかが鍵になるのかな。
