匠塾第10回 企業改革からIT構築までの見える化事例大集合（後編）

勉強会

匠塾第10回 企業改革からIT構築までの見える化事例大集合（前編） - n-3104の日記
ちょっと間が空きましたが、後編です。

IT構築での見える化事例
「ビジネス価値につなげたアジャイル開発」
株式会社永和システムマネジメント サービスプロバイディング事業部 木下 史彦

概要

スライドは匠塾 第10回 「企業改革からIT構築までの見える化事例大集合」で講演しました - Ruby x Agileで公開されているので、特に心に残った点のみ記す。

  • お客の要求が常に変わっていくためアジャイル。最初に決めない。
  • 柔らかい言語なのでRuby。
  • チームの人数は基本2,3人。最近だと10名のプロジェクトがあり、この人数でも回った。
  • 設計スケッチはホワイトボードに書く。そして、消す。消して次の打ち合わせで書けないと、理解が出来ていなかったことが分る。
  • お客に対して悪いことも含めて正直に話すことで信頼が生まれる。
感想など
  • 実践されている方の話のなので、とても実感を持って聞けた気がする。
  • Rubyまともに触った事ないけど、いいんだろうなぁ。
  • アジャイルでやってみたいなぁ。お客さんと一緒にシステムを作り上げてみたいなぁ。

パネルディスカッション
「ユーザー視点からみた見える化するメリットとビジネス価値の関係」

概要

最後はパネルディスカッション。途中、アジャイルの見える化に寄ったりしつつ、東京海上日動の401kのシステム開発事例を元に見える化について話し合っていた。

  • ユーザー企業に業務がわかり、開発力もある人が減っている。
  • 見える化のジレンマ。見える化に時間を取られすぎて他のことができない。
  • 見える化
    • 要はトヨタ生産方式。異常が見えて、アクションに繋がる。
    • 頭の中の見える化と活動の見える化がある。
    • ソフトウェアは見えない。だからこそ、見えるように擦る必要がある。
    • 見える化の価値を考えて置く必要がある。単に見えただけではどうにもならない。
    • 可視化とは違う。
  • 東京海上日動での事例
    • 最初にセンターに行って作業を教えてもらったも見えてこなかった。
      • 要するに何をしているのかと聞いたら止まってしまった。
      • なので、まずはワークフローを作った。
      • 整理の仕方が重要。問題を見える化する。
        • 見えないとそもそも議論できない。
    • チームワークが素晴らしかった。どうやって作った？
      • 目的を何度も話した。
      • だんだん良くなっていく。
        • 何度も作っては壊した。
      • 問題が見えるとせざるを得なくなる。
        • 手を変え品を変え見せた。困ったマップを作ったりした。
      • 作る人に現場を見てもらうようにした。
        • 協力会社の人まで全員は無理なので、ビデオを撮って見てもらうようにした。
    • 困ったマップってどんなもの？
      • ExcelでA3。
      • 業務と工程を入れ、そこにふき出しを入れた。
      • この手のは一度作成すると更新しづらくなるが、その点はどうしたのか？
        • 見える化が目的であったので、完成した時点でお役御免。更新する必要がなかった。
  • 問題を放置すると、麻痺してきて、問題がある状態が当たり前になってしまう。
  • ある車屋さんの部長さん？の話。ひたすら困ったことを言う。そして部下が共感してくれれば終わり。
    • ちなみに、共感までが仕事。それ以上口をはさむとかえってやる気を無くす。
  • 人に仕事を振る際は、その人ではなく、その人の仕事の先の人まで考えて振る。
  • 技術はボトルネックにならない。
  • 日本の産業構造の中でいかにしてアジャイルをやっていくか。
    • アメリカはインハウス。日本は契約。
感想など
  • お客さんの現場を見に行かせるっていいな。そうだよね、お客さんの仕事してるイメージがわかなきゃ、いいもの作れる訳ないよね。見に行くのが無理な場合にビデオを使うのもいい方法だなぁ。
  • 困っていることに共感してもらうのって重要だよね。共感していれば、何とかしようとするモチベーションもあるし、いろいろアイディアも湧いてくるだろうし。
  • マネージャの継続的な働きかけって本当に重要だと思う。モチベーションって自分だけで維持するのってかなり難しくて、最初だけケアしても途中で途切れたりすることはよくあることだと思う。だからこそ、継続的な働きかけが重要なのだと思う。
    • 自分が勉強会に参加しているのも同じ理由。楽しいし勉強になるってのもあるけれど、勉強会に参加することで継続的にモチベーションを再生産するという狙いもある。
  • ソフトウェアの見える化という点で、クラス図を3Dに出来ないかなぁ。ブロックのおもちゃみたいなイメージ。それぞれ形が違っていて、組み合わせてパッケージが出来る感じ。コード数と大きさを比例させるようにすれば、直感的になっていいと思う。ステレオタイプ毎に色を分けたりしてもいいし。これが出来れば、誰でも直感的に違いがわかるようになると思うんだけどなぁ。いいライブラリは小さいブロックがきれいに関連していて、悪いのは極端に大きいブロックとかパッケージ間の依存関係が循環してたりするのが一目でわかるようになると思う。
  • このように素晴らしセミナーを無料で公開してくれて本当に感謝です。次回も参加できるといいな。