進化する「納品のない受託開発」

Transcript

1. 進化する 「納品のない受託開発」 株式会社ソニックガーデン 倉貫義人 2021年8月時点
2. 倉貫 義人 株式会社ソニックガーデン　代表取締役（創業者） 株式会社クラシコム　　　　社外取締役（2018年〜） • 1974年京都出身、10歳からプログラミング • 立命館大学 → 学生ベンチャー → ゲーム開発 • TIS株式会社、アジャイル開発の普及に貢献 • 受託開発 → 社内システム → 社内ベンチャー • 2011年、TIS社内ベンチャーをMBOして創業
3. 株式会社ソニックガーデン • ミッション「納品のない受託開発を提供する」 • ビジョン　「プログラマを一生の仕事にする」 • 2011年創業、社員5名→50名、10期連続増収 • 2016年〜オフィスなし、全員リモートワーク
4. 全国に散らばる仲間たち
5. 見積り/要件定義なし ドキュメントなし プロジェクトなし 契約時間なし 納品のない 受託開発 通勤のない 働き方 働く場所の縛りなし 本社オフィスなし 申請・制限なし 勤怠報告なし 管理のない 会社経営 上司/指示命令なし 承認・決裁なし 部署・管理職なし 売上目標・評価なし
6. 納品のない 受託開発 通勤のない 働き方 管理のない 会社経営 詳しくは本を読んでね
7. 納品のない受託開発 新規事業を 立ち上げたい 既存システムに 課題がある 基幹業務を システム化したい 業務改善で 効率化を図りたい まるで優秀な内製チーム、しかもマネジメント不要。 月額定額の顧問形式で事業の成長を支え続けます。
8. なぜやっているのか • 投資に対するソフトウェアの価値を最大化する • お客様のパートナーとなって事業を支え続ける • 習慣を変えることのできるソフトウェアを創る
9. 受託開発ビジネスの欠陥
10. お客さまから見た受託開発 納品したら開発 者は解散 直したくても 直せない 使い始めてから不 満が出てくる 何が必要か 予想は難しい
11. 従来の受託開発が抱える問題 • 発注者と受注者で目指しているゴールが違う • 利用価値よりも、要件定義に従うことが価値 • 生産性が低いほど、見積もり金額が高くなる
12. 開発者から見た受託開発 • 人月の見積もりは、生産性向上の意欲を削ぐ • 開発と保守の分離は、品質向上の意欲を削ぐ • 案件毎の体制は、チームワークの意欲を削ぐ
13. ディフェンシブな開発 • SIerの利益は何か？バッファを守り残すこと • SIerの価値は何か？リスクを丸受けすること • SIerの評価は何か？沢山の人数で大きな案件
14. ビジネスモデルの構造的な欠陥 • 要件定義のまま全て作るなら繰り返しは不適 • 多重請負の構造によるリスクバッファの無駄 • 労働集約と完成責任の捻れで利益が出せない
15. 誰も幸せにしないビジネスモデル • 開発会社は規模を追求するしか生き残れない • お客様は使えないシステムしか手に入らない • 開発者は成長のモチベーションが得られない
16. 「納品のない受託開発」
17. これから求められるソフトウェア開発 これまで これから 品質重視で作ってから売る 事前の計画に従う 大きく投資してビックバン 減価償却するまで使う リリースまでのプロジェクト スピード重視で市場に出す フィードバックから改修 初期投資はスモールスタート スケールアウトが前提 事業が続く限り改善も続く
18. 納品のない受託開発 • 月額定額で、開発と運用をずっと続けていく • 顧問として、一人ですべての工程を担当する • 働く時間でなく、働いた成果を提供する契約
19. お客さまは何が嬉しいか • 要件定義をしない、いつでも仕様変更できる • 営業が伝言しない、開発者に直接相談できる • 作らない提案がもらえる、気軽に相談できる
20. お客さまが抱えている課題 • 内製するのは、開発者の採用と育成が難しい • SIerに発注するのは、柔軟性が低くて高価格 • フリーランスに頼むのは、いなくなるリスク
21. 私たちの考えるプログラマ • お客さまと対話して、抱える課題に提案する • 仕様設計から実装まで、一気通貫で開発する • クラウドで安定運用して、継続的に保守する
22. 銀の弾丸でも万能薬でもない • ドキュメントは作らない、営業担当はいない • 客先に訪問しない、働いた時間の報告しない • 絶対に納期を死守するという約束はできない
23. ブルーオーシャン分析 低コスト構造化 差別化 要件定義なし ドキュメントなし 客先訪問、客先作業なし 営業担当、見積もりなし 納期の約束なし 一度に決めなくて良い 動くモノで確認できる 作る人と直接話せる 無駄なものを作らない ずっと相談できる
24. 「納品のない受託開発」の事例
25. 始めた当初に対応したニーズ • クラウド・スマホの普及、所有から利用へ • 要件定義できない新規事業やスタートアップ • 従来の受託開発では取り組めないマーケット
26. 10年で広がったバリエーション • 企業で新規事業を立ち上げたいが知見がない • 事業のスケール化にシステムが耐えられない • 人手不足や働き方改革のため業務改善が急務
27. 新規事業を立ち上げたい • 大企業の新規事業室からの相談が増えてきた • 新規事業の相談300件以上の実績で伴走形式 • 短期集中型の合宿プランでPoCのための開発
28. 事業のスケールに対応したい • 初期に開発したシステムのリプレースを実施 • 事業成長に合わせた体制強化＝チームプラン • 顧客サイドでエンジニア採用など内製化支援
29. 現場の業務改善したい • 業務システムに適したkintoneを活用して提供 • 業務ハックとはITを活用した現場業務の改善 • 顧客サイドでkintoneのメンテできるよう教育
30. 10年で広がった技術要素 プログラミング言語 Ruby, JavaScript, TypeScript, Swift, Kotlin サーバサイドフレームワーク Ruby on Rails フロントエンドライブラリ Nuxt.js, Next.js, Vue.js, React, jQuery, Stimulus, Bootstrap, Buluma, Tailwind モバイル技術 ReactNative, Flutter デスクトップアプリ Electron インフラ（IaaS, PaaS, SaaS） Amazon Web Service, Heroku, Firebase, kintone 継続的インテグレーション CircleCI, Github Actions モニタリング Bugsnag, Sentry, AWS CloudWatch, Nagios, Skylight, NewRelic
31. 求められるパラダイムシフト
32. “Point of Sales”から“Point of Use”へ 時間 構築 償却 利用中が最高品質 （サービス業の発想） 買った時点が最高品質 （製造業の発想） 時間 品質 品質
33. 組織のパラダイムシフト • 開発よりも運用、継続性と保守性の品質重視 • 完成よりも成果、コストパフォーマンス重視 • 計画よりも適応、事業の成長を最優先に置く
34. 品質のパラダイムシフト 「誰が顧客なのかがわから なければ、何が品質なのか もわからない。」 （リーンスタートアップより）
35. 開発のパラダイムシフト • 絶対バグを出さない → 出してもすぐに直す • 絶対サーバ落ちない → 落ちてもすぐに復旧 • 予見的なデータ設計 → データは変わる前提
36. 経営のパラダイムシフト • マーケの転換：お金をかけない、知識を使う • 営業の転換：儲けるためから、お客様のため • 管理の転換：働きやすい環境、自由にさせる
37. 予測型マインドセット 適応型マインドセット（アジャイル思考） • 未来の目標を先に設定する • 目標から逆算して計画を立てる • 計画通りに進める • 準備して将来の変化に備える • 予測を元に不足を補う • 役割に人をアサインする • 想定外をなくす • 結果や評価にこだわる • 数字は達成すべきもの • 無駄がないよう見極め大きく賭ける • 大量生産や製造に向く • 未来の成功を獲得する • 現在できることに集中する • 今の積み上げで見通しを立てる • 臨機応変に進める • 変化に対応できる状態を保つ • 実績を元に充足を知る • 人に合わせた役割がある • 例外を歓迎する • 手段や過程にこだわる • 数字は状態を測るもの • 無駄も受け入れて小さく試し続ける • 問題解決や創造に向く • 現在の幸せを続けたい
38. 「納品のない受託開発」の裏側
39. 納品のない受託開発の進め方 • 週一定例のテレビ会議、動く画面で仕様確認 • コストと期間を固定、機能を調整、MVP3ヶ月 • なぜ、なんのために作る？なるべく作らない
40. 同じゴールに向かう戦略 • 月額定額のキャップ、作っても儲からない • 一括請負しないので、長く続く方が嬉しい • 時間で働かないので、生産性と成果が大事
41. 技術を強みにする戦略 • 技術の指定は受けない＝技術は気にせず済む • 社内で技術要素を共通化してナレッジを蓄積 • 新しい技術は受託開発以外の時間で検証する
42. 体制とチーム • 一人で全工程を担当、開発と運用は分けない • 一人で対応しない、ペアもしくはチーム体制 • 一人あたり複数の企業を顧問として担当する
43. 営業を専任する社員なし • 営業社員はいない、開発者がお客さまと直接 • 営業するよりプロトタイプ、お試し期間あり • ストックだから、たくさんの引き合いは不要
44. 事業戦略 • 短期的な売上より、長期的な関係を築くこと • 自社の利益より、まずは顧客の役に立つこと • 大口顧客より、小さく多くの顧客を持つこと
45. おわりに
46. ソフトウェア開発の本質とは • 大量生産・ルーチンワーク・製造業ではない • デザイン・問題解決・ナレッジワークである • プログラミングを手段に、問題解決する仕事
47. 顧問プログラマの仕事 • プログラミングとコンサルティング共に必要 • ナレッジワーカー：属人的に問題を解決する • マニュアル化して再現する単純作業ではない
48. ナレッジワーカーの生産性 • 外発的動機より内発的動機で生産性が高まる • 細かく管理しない方が生産性が高くなる傾向 • 上司より現場の方が詳しい、指示命令は無理
49. ナレッジワーカーのマネジメント • マネジメントは管理・監視することではない • なんとかする、すなわち良い感じにすること • 内発的動機づけ重視で働ける環境を作ること
50. モチベーション • フロー状態を作る、難易度と技量の中間地点 • 成長の機会を作る、自己実現と社会貢献の場 • 心理的安全を作る、情報格差なし、人を見る
51. 経営の目的とは 高い技術を身につけ、知性を磨き 人格を陶冶し、自立心を育むこと その上で、自立できる人材が 働きたいと望む会社を作ること
52. ありがとうございました（講演者について） 倉貫義人 株式会社ソニックガーデン代表取締役 https://kuranuki.sonicgarden.jp ブログ 連絡先 kuranuki@sonicgarden.jp
53. プログラミングで 遊ぶ文化をつくる プログラマを 一生の仕事に 私たちの企業理念は「プログラミングで遊ぶ文化」を創り、 日本のソフトウェア開発を高い水準に押し上げることです。 高い山をつくるには、裾野を広げた土台が必要だからです。 そんな「プログラミングで遊ぶ文化」を創り出すためには、 仕事として職人のように極めていくプログラミングに加え、 趣味として誰しもが楽しめるプログラミングが不可欠です。 これからのプログラミングは、アートやスポーツのように、 修練を重ねて高い価値を生み出せるプロフェッショナルと、 アマチュアとして誰もが気軽に楽しむ社会にしたいのです。 これから、ソフトウェアの価値は今まで以上に高まる中で、 私たちは事業活動を通じて新たな文化を創ることに貢献し、 私たち自身も「プログラマを一生の仕事に」していきます。
54. 顧問プログラマ募集しています 詳しくは・・・ https://www.sonicgarden.jp/join_us