いつでも発展途上

猫と珈琲とゲームが大好きです。ITエンジニアらしいです。メモ代わりにいろいろ書いています。

ジュンク堂トークセッション「システム開発の未来―システムと組織を同時に変革する―」に参加してきました

2011年6月9日に、池袋ジュンク堂書店 4F 喫茶で行われたトークセッション「システム開発の未来―システムと組織を同時に変革する―」に参加してきました。
エリック・エヴァンスドメイン駆動設計(いわゆる DDD 本)を翻訳なされた和智さんと、フューチャーセンターファシリテータの野村さんによる、参加型対話セッションです。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

DDD は、ユーザと開発者の共同作業を重要なものとしています。ユーザはしばしば企業であることを考えると、組織変革をテーマにされている野村さんとの対話はとても刺激的なものになるだろうと考え、参加しました。
以下は、わたしの個人的なメモ書きになります。あまりまとまっていませんし、自己流解釈となってしまっている箇所もあると思います。

大きな課題

問いかけと話し合い

1. システム開発の課題って?
  • 「ユーザ or 開発者の言葉がよくわからない」
  • 組み込みハードを作っているが、ソフトウェアの人と話しが通じないという悩みがある
  • 業務システム発注をしているが、仕様を伝えても理解してるのかしてないのかわからず、あとでトラブルになる
  • 仮想アイドルが流行ったとき、CGを学ぶ若者に制作を頼んでもイメージがうまく伝わらないことがあった。数値で言えば伝わるが…
2. どこのコミュニケーションがうまくいってない?
  • ユーザも開発者も、すべて!
  • ユーザ側の意見をとりまとめる人がいないとうまくいかない
3. システム開発にどんな夢がある?
  • システムを通じて社会を幸せにしていきたい
  • ユーザと開発者の共同作業としていきたい

DDD について(和智さん)

  • 「ソフトウェアを作る上で、ビジネスパーソン本当に協力していきたいと思うなら、この本を読みなさい」 by エリック・エヴァンス
  • 顧客のビジネスを理解せよ
    • 顧客の言葉で理解せよ
    • その先にある「モデル」を理解せよ(※顧客がビジネスに対して持っている全体像)
  • ソフトウェアは、モデルに従ってつくれ
  • ソフトウェアは話し合いながらつくれ
    • ソフトウェアは、育てるもの
  • 顧客のビジネス全体のことを考えよ
  • 実装してみるとモデルの矛盾に気づくことがある。ユーザにフィードバックするとよい
  • …という話しは、当たり前のこと。しかし、実践はむずかしい
  • なぜできないのか?
    • 大きなコスト、承認のプロセス(予算、稟議…)
    • それで本当に幸せなシステムができるのか?
  • 開発者が頑張るだけではダメ。ユーザも変わる。
    • 組織に、コミュニケーションを重視する風土が必要

DDD と組織論(野村さん)

  • いまの和智さんのお話、組織論とどう関係ある?
    • ゲーム会社では DDD が当然となっているが、システム開発ではできないことが多いと聞き、何か問題があるのではと思った(参加者の方)
  • 自分自身(野村さん)がこうかなと思ったことをお話します
    • 自社でナレッジマネジメントの研究をしていた。ラベル付け替えではなく、本当のビジネスにしようとした
    • 組織の中の「価値」ってなんなのか?
    • IDEO からは「チームがもっとも大事なことを知っている」というやり方を学んだ
    • しかし、承認のプロセスに阻まれてしまった
    • 会社を変えないと、いいものを世に出すこともできない。→フューチャーセンターへ繋がる
  • フューチャーセンターをやる
    • ゲーム作りのように普段の仕事をする
    • みんなで参加し、アイディアを出しあって手を動かせば「自分ごと」だと思える
    • 「自社のためだけに(商品を)作っていたら、会社は駄目になる」
  • 新しい文化を持ち込まないとダメ
  • 日常で行っている、そのプロジェクトのやり方自体を変えよう

質問タイム

  • 企業の人はフューチャーセンターになぜ来てくれるのか
    • 空間、ファシリテート、方法論のパッケージを求めている
    • コミュニケーション不全は日本の組織の共通課題(縦割り組織、タコツボ化?)
    • 「暗黙の仮定」を壊さないといけない(納期を守らないとクビになる…とか)
  • システムの一部にならない、と決めた人がシステムを変えていくだろう
    • 隣の人がやってるからやる、という人はそのシステムに加担している
    • 辞めるつもりでやる
    • 会社の枠を外して考える。会社のリソースを使ってやろうぐらいの気持ちで。
    • 新しい企業とお会いしたらまず「ゲリラ戦士」をさがしている
    • ゲリラ戦士とは、自分の立場を破壊してでも、組織を変えたいと思っている人
    • 保身しながら会社を変えることはできない
    • ゲリラ戦士を褒めてくれるのは、ゲリラ戦士だけ。でも、トップは見ていてくれるかも…?
  • 会社を変えるための、もうちょっと安全なヒントをもらえませんか?
    • 社長をフューチャーセンターに誘ってみる
    • 「あなたの知識が必要なので、フューチャーセンターに参加してくださいますか」
    • 反応ないなら諦めた方が…
    • 社長の限界は、会社の限界(!)

まとめ - システム開発の未来

  • 基本はコミュニケーション。つかう人と一緒に考えていく
  • ソフトウェアデベロッパは、社会変革者でないといけない

個人的な感想

DDD と組織論は切っても切り離せないものだと感じつつも、それを切り開くための壁は高そうだとも同時に感じました。なので、あえて違う道で DDD を含めた「システム開発の夢」を実現できないのかなぁーと考えてしまいました。
そして、会社ってなんのためにあるんだろうなあ、とも。
和智さん、野村さんを始め、ジュンク堂および翔泳社のみなさま、そして DevLOVE スタッフの皆さん、ありがとうございました。