ビープラウド社長のブログ

株式会社ビープラウドの社長が、日々の思いなどを綴っていきます。

アジャイル時代のモデリング〜匠の冬祭り2018 in 関西 その3

2018年2月2日(金) に開催された「匠の冬祭り2018 in 関西」に東京からサテライト枠で参加しました。

it-takumi.connpass.com

第三部は、平鍋健児さんの「アジャイル時代のモデリング」がテーマでした。

f:id:haru860:20160710192748j:plain

以下はまとめです。

平鍋さんがアジャイルに向かった経緯

「仕様書通りにつくりました、検収してください」はつまらないので、アジャイルの方に向かった

デジタルビジネスとアジャイル開発

ミッション・リスク分割型ビジネスとウォーターフォール型開発(従来型)
  • 市場→(市場分析)→ビジネス→(発注)→IT
  • ビジネスとITで綱引きになる
ミッション・リスク共有型ビジネスとアジャイル型開発
  • 顧客開発と製品開発
  • ニーズとシーズ、どっちが先か
  • スタートアップ(新事業)→シーズとニーズの中間を成長させる
  • リーンスタートアップ

アジャイルは3周目

  • (1)エンジニアがいかに良い仕事をするか
  • (2)少人数で製品をつくりだす(リーンスタートアップ)
  • (3)先進的大企業が、社内スタートアップを立ち上げる

    • アジャイルを大企業に(スケールアップ)は失敗する。予算と承認の壁

GEのデジタル化

  • データを使って資産の生産性を上げる
  • 重要スキル:サイエンス、セキュリティ
  • 重要課題:スキルのある人を集めて難題を解かせる
  • GE Growth Value(成長) → GE Belief(信念)
  • コーディングは全てのイノベーションの素:読み書きそろばんと同じ

開発の型による違い

  • ウォーターフォール型開発

    • 壮大な伝言ゲーム
  • アジャイル型開発

    • 組織横断で、アントレプレナーシップを持っている人たちを参画させる

      • 企画、品質、開発、UX、Analyticsなどを招き入れる。コタツモデル
    • 今までのアジャイル型開発は開発にフォーカスが当たっていた

f:id:haru860:20180216005727p:plain

ここからの資料は以下。

ITのモデリング

  • 成果物:コードしか残っていない
  • INPUT(User Requirements)→活動→OUTPUT(WORKING Software)
  • "While code is the truth,is is not the whole truth." by Grady Booch

  • BDUF(Big Design Upfront)

  • NDUF(No Design Upfront) :一貫性がない、拡張性に悩まされる
  • "Let's keep the modeling baby but throw out the bureaucracy bathwater."(大事なものまで流してしまうな。いらないものは流してしまえ)

なぜモデルを使うのか?

人間はイメージの方が概要をうまく掴むことができる

KEEPするもの

  • Architecture
  • Domain Model
  • Key Use Cases

これらが無いと、コミュニケーションの時間を無駄にしてしまう

Temps

  • Casual Modeling
  • Class, Sequence Diagrams

  • UMLに写真を入れる。味気ないから

  • Key Usecases

    • ユーザーから見たシステムの代表的なつかいかた
    • 誰がユーザーで何が嬉しいのか

チームが大きくなった時(Scaling)

  • 小さなものをやっつけてからチームを分割する
  • 人づてで知識を伝える
  • チームに新しく人が入ってきたら、モデルを使ってウォークスルーで伝達する。

    • 紙で渡した時点で、2〜3割の情報になる
    • "Model to have a conversation"(会話のためのモデル)

問題と解とモデル

  • 簡単な問題は、モデルをつくらなくても問題→解に進めることができる
  • 複雑な問題は、問題→分析モデル→設計モデル→解へと進む

f:id:haru860:20180216010651p:plain

感想

アジャイルソフトウェア開発宣言には、ソフトウェア開発の価値として「包括的なドキュメントよりも動くソフトウェアを」と書かれています。

この文を拡大解釈し、ソースコードこそ最高のドキュメントという考えのもと、ドキュメントや図(モデル)を軽視する人が時々見かけられます。

しかし、ソースコードから全てを読み解き、システムの全体像を捉えるのは時間がかかりすぎてしまいます。

平鍋さんの発表では、モデルの良さ、ソースコードの良さを活かしながら、人が最大に価値を創り出せる新しいアジャイル開発のかたちを感じさせてくれました。