開催お知らせページ
https://easg.smartcore.jp/C22/notice_details/QjJNSVBnPT0=
今回はソニックガーデンの倉貫さんが講演されるということで、申し込もうとしたら既に満員締め切りでした。
前日、無理を承知でお問い合わせページから参加させていただきたい旨、カキコしたところ、事務局の方から参加許可いただけました。
お願いしてみるものですね。感謝。
以下、講演時のメモ。
メモはあまりとらず傾聴してたので、メモ内容は単発系です。
倉貫さん、今日はエンタープライズということで、わざわざ背広を着て、散髪してきたとのこと（笑
この日もアイスブレークから冴えてます。
「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル
posted with amazlet at 16.01.24
倉貫 義人
日本実業出版社
売り上げランキング: 47,715
日本実業出版社
売り上げランキング: 47,715
リモートチームでうまくいく マネジメントの〝常識〟を変える新しいワークスタイル
posted with amazlet at 16.01.24
倉貫 義人
日本実業出版社
売り上げランキング: 11,891
日本実業出版社
売り上げランキング: 11,891
前者は存在を知っていたのですがまだ読んでなくて、この日はその話を聞くために参加しました。
後者は最近出たそうです。この日も、リモートワークについての話が結構出てきました。
■ 納品のない受託開発
- 受託だと何をやってもうまくいかなかった。会社で偉くなっても営業を自分でやっても、受託の限り上手くいかなかった。
- そこで、受託から社内システム開発に変えると上手くいくようになった。
- クラウドビジネスは納品しないで改善していくので、アジャイル開発がフィットした。
■ エンタープライズアジャイルとは
- 「エンタープライズアジャイル」ってなんだ？と2日くらい悩んだ。
- 言葉からスタートすることを止めて、企業を取り巻く状況から考えることを始めた。
■ ソフトウェアありきの企業の台頭
- Uberというタクシー配送会社は、配車からすべてITありきで動く。ソフトウェアありきの企業。
- Uberの登場により、西海岸のタクシー会社が倒産した。
- ホテル不動産業でも、空き家を短期旅行者に貸すビジネスが登場した。これもITありき。
- 「IT活用」じゃなくて「IT前提」のビジネスに変わってきた。
■ 「アジャイル企業」という発想
- 事業に合わせてITも変化させ育てていかないといけない
- ウォーターフォールでやってって、事業に合わせて変化に追随できるのか？
- それはできないので、「アジャイルありき」で経営を考えていく。
- 「アジャイルが前提の会社」＝「アジャイル企業」これは倉貫さんの造語。
■ 戦術としてのアジャイル、アジャイルのための戦略
- 与えられた環境の中でアジャイルってどう上手くやるんだろ？みたいなのを考えるのが、目標としてアジャイル。
- ぞうじゃない。アジャイルを「目指す」のではなくて、アジャイルになる「環境を整える」ことが大事。
- アジャイルは目標でなく、結果。
- 経営からアジャイルにしていき、社員は自然とアジャイルで仕事するようになれば、それは究極のアジャイル。至高のアジャイル、とは真逆。
- そこを考えるのに、「エンタープライズ」とか、どーでもいい。
■ アジャイル企業の目指すポジショニング
- 4象限にわけてみた。
- コスト、品質、スコープの3軸がある三角形の図をよく見かける。
- 3軸のうち、スコープをを変えて変化に対応するのがアジャイルです、という説明をよく見る。
- でも、これは目標を先に決めてる予測型。
- 普通の会社は予測計画型。この予算で達成しましょう、と決めてその通りにやる計画型ビジネス。これは図でいうと左側。
- Facebookとかは予測型でない。まずサービスを初めて、ヒットしすぎてから、どうしよう？と考えるタイプ。
- 「エンタープライズ」を議論するより、左（予測型／計画重視）か右（適応型／結果重視）かをまず考えたほうがいい。
- 左（予測型／計画重視）の会社が一生懸命アジャイルしようとするから上手くいかない。
- 「エンタープライズアジャイル」 ではなく、「アジャイルエンタープライズ」として考える方が良い。
- （アジャイルをエンタープライズに適合させるのではなく、元々アジャイルで上手くいっていた少人数プロジェクトを、どうエンタープライズにスケールさせていくかを考える）
- アジャイルの価値観を経営に。
■ アジャイル開発と受託開発
- 一括請負だと、作ることがゴールになる。人月見積もりなのに完成責任を負わされる。仕様凍結vs要件詰込の対立。
- これはビジネスモデルの構造的欠陥なので、受託開発である限り誰も幸せになれない。
■ 納品のない受託開発
- ソニックガーデンでは、一人のエンジニアが「顧問」として、すべての役割を担う。
- 納品のない受託開発では、要件定義をしなくてもよい、仕様変更をいつでも出来る、という顧客メリットがある。
- そもそも要件定義をしたいのはベンダ側の理論でしかない。きちんと要件を決めておかないと、あとで追加変更に苦しめられるから。
- ユーザ側が仕様変更をちょっと相談しようとすると、ベンダはすぐ追加見積もりをもってくる。なのでユーザは嫌がる。
- その弊害を取っ払う。
- 納期を死守しない。
■ ワークスタイル
- 違う場所で同じ時間に働く。
- チームなので、苦手なところをサポートしあう。
- エンジニアは腕を磨いて目の前のお客さんを満足させることだけを考えればいい。
- 好きな仕事をやっているならば、縛る必要は全くない。
■ 「管理」のいらない良い人材を集める
- 焦って人を入れて上手くいったことがない。いい人がいるまで採用しない。
- 変な人を採用しない、いい人しか採用しない。なので人の管理もいらない。
- プログラミングできることは前提でしかない。
■ 経営モデル
- 売り切りの商売をしない。細い客をたくさんもつほうが会社は安定する。
■ アジャイルエンタープライズ
- アジャイル企業としてスケールする。
- 従来のでかい企業がどうアジャイルになるか、の方向じゃない。
■ アジャイル企業マニフェスト
- 売上や規模の拡大よりも社員の幸せを
- 経営者として価値観をきちんと表明すること。新しい価値観の会社がでてきてもいいんじゃないか。
★感想：
倉貫さんの語りは自信に満ちあふれているというか。
きっと、自分の主張と成果が一致しているからなのでしょうね。
倉貫さんの思想をいきなり自社に適用するのは難しいとしても、プロジェクトのチーム編成時とかで参考にできると思いました。
あと、
プログラマーを一生の仕事にする
プログラマを誇れる仕事にする
というビジョンとミッションは心に響きますね。プログラマがほんと好きで、敬意を払ってることが伺えます。
倉貫さん、関係者の皆様、ありがとーございました。
ちなみにこの日の金曜ロードショー、ラピュタだったんですが、勉強会からの帰宅が間に合ったので詠唱しておきました。
バルス
— makopi23 (@makopi23) 2016, 1月 15
