猫好きな老体気味SEの備忘録

タイトル通り、不定期更新、基本猫の話題は奥さんのブログに他力本願

課題の処理方法を考えてみる

リーン開発の本を読んでいても、現在最強とも言えるWaterFall配下で仕事してる関係で、そっちがすごく気になる。

リーン開発の本を読みながら、思いついたことをブログにして、実践して見るという営みにしてみよう。

このブログは備忘録

なのでね。

今日は

課題表について

業界に限らないかもしれませんが、やたらと列がある課題表を使ってます。
まあ、いろんな情報がフィルタで絞り込めるメリットがあるんですが、

にしても、横に長すぎるよ

画面が横に伸びるか、マルチディスプレイでないと、、、

こんな表で管理するのは、利用者の立場によって見たり更新する場所が異なるというのが事情なのである。
  1. 課題登録
  2. 課題受付、対応者振り分け
  3. 課題対応
  4. 登録者と対応者間の認識合わせ
  5. 課題のクロージング
この他にも、課題がどれくらい難航してるかというのも見ないといけないし、対応者がオーバーフローしてて着手すらできてないとか、課題がプロジェクト全体に関係する場合はちゃんと周知できてるかなど、マネジメントの問題を解決しなくてはならない。
これらは、発生確率の非常に高いリスクで、放置すると開発メンバー数の稼働に跳ねるので、インパクトが大きい。

なので、

リスク顕在化への予兆検知

ができるようにしておかないといけない。
こんなパラメータが課題表から自動的に集められれば、判断できそうだ。
  • 課題登録日から、何営業日経過?
  • 対応指示日から、何営業日経過?
  • 対応完了日から、何営業日経過?
  • 現在その課題(つまり、EXCELの行)は、誰のアクションか?
判断した後、適正な稼働指示になるかはわかりませんけど、無駄に止まって工数垂れ流しみたいなことにはならないと思いました。
もちろん、登録者、受付者、対応者の名前、それぞれの開始/終了日付が記録されてる必要がありますね。

本当にExcel課題表でいいの?

Excelには、ブックの共有というのがあり、複数人で同時に編集することができますが、編集に制限もありますし、結構デグレや破損の事故も発生します。

確かに、手軽に使えますけどねぇ。
いろんな情報を取り込んだ、一見完璧とも言える課題表は、

完璧に使える人が課題表作った人だけ

という問題もあり、

完全な形で運用されない

最悪

課題が放置される

何ヶ月も

でも何故か放置されてる課題は、メンバー内では解決してたりするわけですが、その決定経緯がわからず、大問題になったりもしますよね!

結論から言うと、

カンバン

のしくみ、チケット駆動の運営で、ステータスと稼働をメンバー全員で見えるようにしておくのが1番いいと思いました。

さあ、どうやって変えていこうかな。


リーン開発の解釈

これまた久しぶりの更新。
アジャイルが一時的に流行り出し、感覚的には言葉自体があまり使われなくなったかなあ、と思っていたんですが、最近になって近場で浮上。

というわけで、私自身が不勉強なので、読書して正しく理解はしておこうと思いました。

タイトルが「リーン」となってるのは、呼び方の問題。実際日本では、トヨタ生産方式「TPS」という方がメジャーなのかもしれません。
自動車生産方式をTPS、ソフトウエア開発方式をリーンと区別しますかね。

方式というより、精神・ポリシーというのが定まってますね。

概要

  • 全体を最適化する
  • ムダをなくす
  • 品質を作り込む
  • たゆまぬ学び
  • 速く提供する
  • 全員を巻き込む
  • 改善を続ける
重要なのは、全員を巻き込むことでしょう。

次に開発フレームワークとして

スクラム

  • 順番づけされたプロダクトバックログ
  • 職能横断型チーム
  • スプリント
  • 継続的にリリース計画を調整する
  • 継続的にプロセスを調整する
プロダクトオーナーとスクラムマスターという役割がポイントのようです。
後は、イテレーションという短いスパンで開発を進めて、こまめにリリースして、イテレーション後に都度振り返り、プロセスを調整する改善しながら進めるという感じです。

で、実際の開発は

XP(エクストリーム・プログラミング)

こいつは、いくつか方法があって、XPだけを使って、「アジャイル開発やってます」みたいなことを聞いたりもしましたが、今はさすがにないかな。
で、方法とは
で、製造工程を可視化するのが

カンバン

少し前だと、ホワイトボードにワークフローを列にした表を書いて、ポストイットにタスクを貼り付けて、そのポストイットに担当者の名前を書いて進めたことが思い出された。
違いは、下記のWIP、つまりワークフロー単位に作業制限を加えてないことだったのか。
制限無かったから、対流状況がいまいち共有されなかったんだと思われる。
ポイントを以下に示します。
  • ワークフローを可視化する
  • WIP(仕切り作業)を制限する
  • サイクルタイムを測定し管理する
これらを見ると、OSSRedmineというツールがマッチするように思いました。
実際カンバンを意識して構築することができれば、滞留状況やWIP制限なんかもRedmine側で検知・ガード・優先予約とかもできそう。
しかも、このかんばんという開発推進方式は、10年の歴史があるので、Redmineプラグインにありそうですね。


概要としては、以上です。
実践的なところを、後日図で補強しますね。


リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営


Analytics 2014 レポート その4

いよいよ、有名な統計家の登場です。
前にこの人の公演を聞く予定でしたが、体調が悪くきけなかったんです。

今回は、SASからのオーダーで、サッカーネタに分析手法を話してくれってことで、データ的には古いですが、2011年ベストイレブンを自分なりにセレクトして、実際どうかという検証してらっしゃいました。


本はだしたが、全く売れなかった。

サッカー分析

たぶんこちらかと思われます。

データ分析は、下記の必読書からは逸脱しない。


データ分析者の必読者

Research Design: Qualitative, Quantitative, and Mixed Methods Approaches

Research Design: Qualitative, Quantitative, and Mixed Methods Approaches

知識とはなんぞや?というところから書かれてるので、分野問わずに、定量的な分析と定性的な分析をmixさせる。

xxとはなんぞやをちゃんと叩き込まれてることが重要

例えば、研究とは何かを正しく叩き込まれてれば、、、STAP細胞のようなことは起きないはず。

仮説思考の限界①

検証する前に立てた仮説が採用されないことが良くある
データマイニングは、予測だけになっていた。

大事なのは洞察だ!

人間の頭を使って、検証する必要がある。

仮説ではなく、「問い」を!

  • 1番嬉しい状態をどうやったらできる?

解析単位のアウトカム

具体的に「望ましさ」を定義する!
解析単位は、比べる単位
説明変数は、左右しうる特徴

結局これは、どんな分析でも使えることを示してる。

この先は、本題のサッカーで勝てるチームを、、、

後で、資料見ながら補足します。
当日は、結構早回しだったのと、私自身がサッカー選手の名前だけでは着いていけなかったというのが、この中途半端さに至ってます。

あとがき

結果的に2011年のベストイレブンとほぼ同じ結果が導けたそうです。
見る人が見ると、おお、人気、実力共に選ばれしものだったかという納得感があったんでしょう。

ポイントは、アウトカム、つまり望ましさをちゃんと定義し、比べる単位とその値が変化するものをきめるということなんでしょう。
サッカーに限らずですね。

Analytics 2014 レポートその3

午後のセッション2つ目のセッションは、情報システム部門の方です。


前回の記事と違って、この方がどれほどのメンバーでどんなレベルで分析してるかわかりませんでした。

資料は、かなり非公開らしく、報道関係者含めて撮影禁止!

Analytics 2014 レポートその2 - 猫好きな老体気味SEの備忘録


というわけて、これはちゃんと聞かないといけないな、とはいえ寝落ちリスクも高い時間、、、頑張りましょう。


情報資産をビジネスに生かすための取り組み


株式会社NTTドコモ
白川 貴久子 氏

情報システム部の情報戦略担当
関西でマーケティングの戦略とか、営業やってた
IT知識がない、、、おそらく統計手法やマーケティング手法には長けてて、プログラムを書けないというお話なんだと思います。話っぷりからEXCELで統計解析程度はご自身で対応できそうな、、、

docomoには、モバイル空間統計という研究成果がある!
ビジネスサイドにいた白川さんがデータを活かす目的を明確にしやすいはず

データマイニングは少しかじった
→無理に使うほどでは無かった。
Excelで処理できる程度

今は処理速度が格段に進化

その価値を知りビジネスに生かそうとする企業全体の風土

ドコモの分析組織とは

情報戦略担当は2003年4月に発足
情報資産を活かすための組織
  • 分析チーム
  • データ抽出チーム
  • セキュリティチーム、顧客データ

システム担当

  • データ構造知識
  • システム活用スキル

ビジネス部門

この2部門と連携

提供後に手戻り

本当に欲しいものだったのか?
ビジネス部門のバックボーンなしに作業
データ項目、データ定義など、何に活かすかを伝えないから。

解約でもいろいろ種類があるので、
分析したいことが伝わらないという問題
→縦組織でよくある話

ヒアリング手法

NGワード「とりあえず」
更に実作業はプロパーから言われるSEなので、言われたことを予想しながら、疑問も出せないままやって失敗

5年経過後、今は手戻り少なくできている

分析請負ではなく、データ活用のパートナー

期待以上のアウトプットが鍵

社内活用のための組織

電話での対応から、Q&Aボードへ
電話は1人しか対応できない。

名前をデータ分析お助けコーナーに変更

2年前の問い合わせが未回答だったので、活用されなかった。とりあえず、すぐに回答するようにプロセス改善
初動を迅速に!
  • 事例発信
  • 1人の悩みは全員で共有

分析力を高める取り組み

  • 分析事例発表会→4Q毎に地域持ち回り
  • 分析設計演習・マーケティングレクチャー
4年継続して、大分意味をなしてきた。
支社発信の内容が全国展開された事例にまで発展
地域の営業を巻き込むことで、化学反応が起こってきた。
繋ぎ役として、継続した。

回を重ねると、発表会だけでは飽きる

マーケティングマインドをもって

分析設計ができる演習を開催
  1. 戦略編
  2. 戦術編
  3. 実践編
ディスカッションさせる
自分がどういうことに偏りがちなのか?を気づかせる
演習させると、出来なくて、
フィードバックで、セオリーを語る
マーケティングセオリーなので、フィードバックの内容は理解できる。

変化を浮き彫りにする工夫

基準、区分、スパンの見方
先を見る
データが膨大だと見落とすので、何が見つけたいのかをちゃんと定義する

なんでそれが必要だったの?

とかの振り返りで迷いが出ないように。

データでわからないこと

  • 現場のリアリティを知ること
  • 声に耳を傾ける
  • 素直に観察する
  • 現場の感も大事にする
  • 声にならない気持ちを洞察→なりきって考え抜く

"なりきって考え抜く"

これを継続していく

「解約予兆モデル」

99年にやっていてなかなか良かった。
ただ、5ヶ月待たないと予兆が示せなかった。
3ヶ月だと解約予兆がない人も含まれる、という問題があった。

目的は喜んでもらうための分析だということ

施策の響き具合は、すぐに変わっていく

なので、モデルの精度が良くても施策が良ければ、そっちが採用される

故にライトに施策を実行し、繰り返し改善していくのだ!


あとがき

過去の事例でしだか、docomoさんも凄いマーケッティングの勉強をされてて、縦組織の壁も徐々に崩して行ってるのかも?と思わせるような発表でした。

途中でお話があったように、利用者が喜ぶという目的で、組織間の潤滑油としての活動内容をこれからも公開していって欲しいです。

SIerは、この視点が不足してますからね。技術屋全般かもしれないです。

f:id:inf12ty:20140412174305j:plain

Analytics 2014 レポートその2

昨日アップした基調講演に続き、各セッションのレポートです。

前回のレポートAnalytics 2014 レポートその1 - 猫好きな老体気味SEの備忘録

アクセンチュアという頭脳集団企業の人からの有難いお言葉でした。

率直な感想としては、数学での博士号やOSSのコミッターがいたところで、市場に訴求するまでの結果は出せない。

僕らみたいに各方面の専門家がチームを組んだら凄いんだよって話に聞こえた。

すごそうだけど、タイトルで受講した大半の人が期待していたであろう内容にはなってなかったのが残念でした。

有名コンサルファームの中で、IT業界にこれだけ名前が出てくるのはアクセンチュア以外居ない。IBMも手広いが、そもそもIT業界ですからね。

テーマ的には、マッキンゼーも顔出しそうだけど、あそこはこの手のセミナーには顔出したの見たことないからなぁ。


前置きはこれくらいで、レポートにいきます。

例によって、メモですが。


分析結果最適化プロジェクト成功の要諦とディシジョンサイエンスを支える人材の育成方法

アクセンチュア株式会社
工藤 卓哉 氏


どうしたら新たなプロジェクト・サービスを持続的に生み出せるか?
新たなアイデアを得る方法

今まではプロダクトアウト

マトリクスで、アナリティクスの進化過程と観点を示してました。
横軸
  • 古典的手法
  • リードユーザ型
  • ユーザ創造型
  • Analytics型、Deep Learnlng
縦軸

アナリティクス活用事例

データかけるアルゴリズムかける適用サービスイコール最適化
新規事業創造

試行速度の速さ

生鮮食品の需要予測は難しい
データに応じたアルゴリズムの最適化

アクセンチュアのサービス

PoC、センサーM2M、レコメンド
センサーログの解析の速さには自信がある。東京の人がメイン!

クロスプラットフォーム分析

例えば、ドコモのモバイル空間統計
アクセンチュアもデータ持ってる
  • 銀行とPOSデータから分析

銀行預金残高が高ければ、優良顧客とは限らない、とか。
私生活は、質素だったりすることが空間情報で見えてくる。プロファイリング。
なぜなら、外食が少ないとか、POSと結びつければスーパー利用頻度、利用額もわかってしまう。

脳波を分析して、

生産性の高い人と低い人を区分ける、みたいなこともやってる。
これを応用して、購買意欲を探ることもできるわけだ。。。理論的には!

相対性理論

数学だけやっててもダメ
ビジネスドメインに沿った仮説が立てられるか

データか仮説立案か?
経営の課題解決が目的なので、仮説が重要だ!

概念化と探索的

試行速度が早く、サイクルをたくさん回す
統計学者のJohn.W.Tukey
ClouderaのJeff Hammerbacher

なぜなら、統計は事実なので、自分の理論がいつか成立しなくなることがわかっていたから。

成功の要諦

アプローチ
発射台と標的設定
いろんな部門と協力して、現場把握と経営目標を設定する
部門のメンバ構成も試行

クロスインダストリーを成功させるためには、

経営幹部の協力が不可欠

無理に機械学習使ったりしないように!
最適なデータサイエンスモデルを使えること

在庫・補充管理の最適化をフルオートでできるようにした。

こ、、これは凄い!
小売業が1番頭を悩ますノウハウの塊かと思ってたことが、フルオートで実現してるわけですよ。

あとがき

詳しいことは、アクセンチュアの人に聞かないとわかりませんが、Oracleチューニングのような超人しか設定出来ないパラメータと機械学習が慣れる期間が必要なんだろうと思いました。
つまり、初期導入500万〜、年間保守100万〜、小売規模に比例みたいな費用体系が見えたような、、、

て、肝心の人材育成方法は?

以上になります。その3に続く。