インセプションデッキとRedmine ~ぼくらの11日間戦争~

Redmineアドベントカレンダー、12/14担当のあさこです。

adventar.org

Redmineアドカレなのですが、Redmineの画面一枚も出てきません(汗)。

チケット駆動をやる上で、チケットの粒度ややっている内容にブレが出ないように、スコープ、チケット粒度、管理の仕方などを先に決めて実施しましょう、という内容について触れさせていただきます♪

 

今回の事例について

この記事の中で触れた内容について、書いていきたいと思います。

okandayo.hatenablog.com

四年目、のところの夏休みの事例です。

小学生の子供ふたりと、夏休みを最大限に楽しむためには、夏休みの宿題やっつけプロジェクトをどのように運営したらいいのか?を検討して、実行して振り返るところまでをストーリーにしてみました。

 

つい先日(11/30)、JaSST北海道※1というシンポジウムで、LTにて発表した内容をもう少し詳しく書いたエントリになります。

※1 JaSSTソフトウェアテストシンポジウム-JaSST'18 Hokkaido-開催要項

 LT資料は、こちら。

www.slideshare.net 

インセプションデッキとは

簡単にいいますと、プロジェクト憲章。

アジャイルサムライという本の中で詳しく説明されています。

 ここが私にとっては一番わかりやすく説明されているサイトでした。

blog.nextscape.net全部で10の質問があります。

我われはなぜここにいるのか(Why1)
エレベーターピッチを作る(Why2)
パッケージデザインを作る(Why3)
やらないことリストを作る(Why4)
「ご近所さん」を探せ(Why5)
解決案を描く(How1)
夜も眠れなくなるような問題は何だろう(How2)
期間を見極める(How3)
何を諦めるのかをはっきりさせる(How4)
何がどれだけ必要なのか(How5)

ここから、小学生でも理解して、誤解が生まれないようなものを選択してみました。

①何をしようとしている?(ここにいる理由)

②さて、どうしようか? (エレベータピッチ、解決案)

③こんなふうになったらいやだ! (夜も眠れない問題)

④これはやらないでいい(やらないこと)

⑤これはできなくていい(あきらめること)

 

今回のストーリー

夏休み初日の朝。

はじまりはいつものごとく、だらだらとゆーちゅーぶを見る子供たち。

休みだから、だらけてもいいのです。ただ...目的もなく同じような毎日を過ごして、毎日夜になると今日もつまらなかった~、という愚痴を聞きたくないので、いっぱつシメるところからはじめることにしました。

最終ゴールは、二人とも夏休みを「めいっぱい!」遊ぶこと。つまらないなどという愚痴を最終日につぶやくことにならないこと。

ここが大きな目標です。

この目標を達成するためにはプロジェクトをどう運営していけばいいか。

考えました。しかし、毎年のように、親が独り相撲をしても宿題は終わりますが子供たちは満足いかないでしょう。

自分で決めていないから。合意をしていないから。

同じことを繰り返すのは愚の骨頂!

インセプションデッキ!

 

①何をしようとしている?(ここにいる理由)

 母:さて。あなたたちは、誰?何をするひと?

子供たち:え~。人間~、子供~。

母:(スルー)何をすればやりたいことができるのかを考えるんだよね。

子供たち:うん!遊びたい!ゲームしたい!

母:おかあさんも、ふたりが笑っている顔が見たい!楽しんでいるところがみたい!

 

②さて、どうしようか? (エレベータピッチ、解決案)

娘:宿題早く終わらせれば遊べるんじゃね?

息子:そうだね!

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

毎日日記以外の【夏休みの宿題すべて】

7月中に終わらせる!!!

実行可能な計画:母がredmineで管理

 

③こんなふうになったらいやだ! (夜も眠れない問題)

・毎日おかあさんからおこごとを言われる

・おかあさんの顔がいつも以上にこわい

・どこにも遊びに行けない

・つまらない夏休み

 

④これはやらないでいい(やらないこと)

・習ったところより先にすすんだ勉強

・寝る時間をけずって宿題をやること

・お母さんの命令にしたがう お手伝い

 

⑤これはできなくていい(あきらめること)

・自由研究(娘) →読書感想文をかくことで、自由研究をやらない選択をした

・11日間はともだちとめいっぱいあそぶこと(息子)

・あそびたいきもちを優先させること(娘)

・旅行や、まる一日でかけること(母)

 

そして、Redmine

スコープが決まったら、毎日できる量は本人たちに決めてもらいました。

昨年までは時間ドリブンでしたが、今年は宿題の問題の数全体を数えて、日数で割るという単純なものですが、掛け算をマスターした年齢の小学生がいるので、チャレンジしてみました。

※問題数は同じなのに、かかる時間が違う、というところもしっかり実感していただきました(笑)

毎日8問ずつ。読書感想文には重みをつけて、6問と数えて、さらに状態遷移(笑)も、考えてもらいました。

本を読む ⇒ 母に説明する ⇒ 話したところから、一番良かったところを箇条書きしてみる(付箋紙利用) ⇒ 感想文の形に並び替えてみる ⇒ 清書

 RedmineはScrumプラグインを使って実施。ユーザストーリーは教科。

1日分の問題をチェックリストプラグインをつかってチェックボックスに印をつける。

タブレットで見ながらやってもらいました。

 

無事、目的達成、毎日日記以外は7月中に終了しました。

ちいさな成功体験ゲット!です。

 

振り返り

振り返り(宿題を終えて)

息子:あきらめることをきめといてよかった!

娘:8月に友達といっぱい遊べそう!

  宿題やるのは大した問題じゃない。全部がどのくらいあって、毎日何をやればいいのか、何をやれば終わるのか、がわかってよかった。

 

振り返り(夏休みを終えて)

息子:結構たのしかったかな。でも、ゲームクリアできなかったのはくやしい。

娘:自由研究本当にやらなくていいのかな、と不安になったけど、やらないと決めたし、その分読書感想文をしっかりかこうとおもったから満足。友達ともしっかり遊べた!

 

 来年への伏線

  • 一番大事なのは、自分も当事者になること。
  • はじめにインセプションデッキを作るとき、「やらなくていいこと」「できなくていいこと」を区別して出してもらうのが結構難しかった。(子供それぞれの性格・特性で気にするところ・大事にするところが違うので。)
  • ゴールが変わるので、振り返りを途中で入れるタイミングも計画したほうが良い。
  • やりたい度合い(ゴールへの熱量)がおもったより低くなってくるので、モチベーション維持をする仲間と施策がやはり必要。楽しみも継続は難しい。
  • エレベータピッチ上でホールドポイントを設け、その時点での振り返りをし、インセプションデッキへ反映していくことが最も大事。
  • 振り返ると同時に、チケットもできるならもう少し興味をそそるような「しかけ」を入れていくと、モチベーションも続くのではと思った。

 

と夏休みの振り返りを書いていますが、もう来週から冬休み...

もう少し楽にできる方法も考えようかな...

ということで、trelloにも挑戦しております。

また、感想はいずれ書きます。

 

ここまでお付き合いくださってありがとうございました!

 

 

 

メトリクスって、合否を決めるための指標じゃないよねっ♪

こんにちは!

ソフトウェアテストの小ネタ AdventCalender2018、12/10担当のあさこです。

qiita.com

 

今年も、小ネタはメトリクス系でいかせていただきます!

昨年も、12/10に書いていた...^^;

okandayo.hatenablog.com

 

今回いいたいこと

今回は、アーキテクチャメトリクスと、メトリクスを利用する前提条件について触れて行きたいと思います。

そのココロは...、メトリクスは指標じゃなくて、あくまでもリスクなどを判断する一つの材料なんだよね...ってのを言いたかった。その一例(アーキテクチャメトリクス)と、なんで材料に過ぎないの?というところ(前提条件)をちょっと紹介したかったのです。ちょっとだけ、お付き合いくださいませ。

 

今回のお品書き

以下のような内容を、小ネタなので、簡単にお伝えします。

 

 

アーキテクチャメトリクス

ccfinder

ccfinderは、みなさんご存知でしょうか?

一言で紹介しますと、コードクローン探知ツールです。

http://www.ccfinder.net/ccfinderx-j.htmlwww.ccfinder.net

フリーツールですので、お気軽に...試せるかと思いきや、そんなことはありません...

32bit版しかリリースされていないので、64bit上で動かそうとするといろいろクセがあります。もし、チャレンジなさりたい方は、こちらを参照ください!

qiita.com

こちらで取れるメトリクスはいろいろありますが、コードクローン除去を目的として「あたり」をつける時には、以下に着目します。

<ファイルメトリクス>に出てくる、RSA、RSI、CVR、NBRです。

RSA、RSI、CVRが1に近い(クローン含有率が高い)ファイルや、NBRが1以上(他ファイルに影響のあるクローンが存在する)のファイルメトリクスに注目して、コードクローン率を下げて行きましょう!

※画面などが無くてごめんなさい。

 さらにいうと、これもソースコードメトリクスかもしれませんが、アーキテクチャ目線でみることができるなぁと思ったので、勝手にアーキテクチャメトリクスに入れてみました。

 

Lattix

テクマトリクス社から出ている、有償のツールです。

今出ているツールの中で、アーキテクチャをしっかり見ることができるツールはこのくらいなのではないか、と思うので、紹介させていただきます。

www.techmatrix.co.jp

パッケージや、クラス単位で変更をするとどのていど影響が出るのか、などをメトリクスで見ることができます。シュミレーションができるツールになります。

 有償ツールなので、メトリクスも一部紹介にとどめておきます(笑)。詳細は、上記リンク先をご覧ください。

 

システム規模の計測 システム規模を把握します。
  • 素数
  • 複雑度
  • 依存関係数
  • 依存度平均
変更に対する感度 変更に対するシステムの影響の度合いを把握します。
  • システム安定性
  • 影響度平均
結合の度合い 要素の結合の度合いを把握します。
  • 結合度
  • 結合濃度
  • 結合強度

 など

 

メトリクスで分析する上での前提条件

 分析する目的

もちろん、予実差を見たり、実績がどんな状況なのか(大丈夫なの?やばいの?)を把握するためですよね。どんな状況なのか?を見るのは、何かと比較する。

大丈夫なの?やばいの?を見るには、大丈夫!って思えるよりどころがないと把握できない。とすると、「今やっているもの」が、うまくいっていた前例と同じクラスタに属するという仮説が成り立たないとダメですよね。

「同じ母集団に測りたいもの・比較するものが属している」ことが必要、ということです。

 

使うツール

統計。統計まで行かない分析もありますが、良く使われるのは、「統計」かなぁと思います。目的のところに書きましたが、母集団は同じで無いといけません。

そして、母集団が同じところからサンプル(標本)を持ってきます。

特性は同じでも、サンプルを示すベクトルが平行だったり、等倍の関係だったり...という間柄では使えません。

統計処理をする上では、同じ村に住んでいても、血縁が濃すぎると異常結果しか導出できないからです。(たとえが悪いかな...)

なので、「お互いに独立」であり、「直交」している間柄である必要があるのです。

 

前提条件まとめ

  • 同じ母集団に測りたいもの・比較するものが属している
  • 「お互いに独立」であり、「直交」している間柄である
  • 上記ふたつは、あくまでも仮説のうえになりたっているので、「絶対」という条件ではない。よって、合格/不合格などの「指標」として扱うのではなく、「参照」「参考」として扱うべきなのではと私は考えています。

 

以上、小並感な感想記事でした。

 明日は、なそくん(@hiroyuki3gou  )です!バトンタッチ!

 

SaPID Bootcampレポート ~問題構造図の作成編~

第二弾、問題構造図の作成編です。

 

f:id:okandayo:20181104143946j:plain

SaPIDへの想い編は、こちら。 

okandayo.hatenablog.com

 

公式サイトに掲載されている、本Bootcampのレポートです。

www.software-quasol.com

 

問題構造図の作成とは。簡単に表現すると、
「自分の課題を含め、流れを簡単にする。」

 

作成する際に重要になるのは、
「大局がとらえられることも大事」「個別の具体性もわかることが大事」
というところだと思っています。

では、問題構造図の作成手順と、私が実施した課題の一部をご紹介しながら書いていきたいと思います。

(どろどろした個所は省いたりしています(汗))

 

問題構造図の作成手順

事前整理

f:id:okandayo:20181104144023j:plain

以下の4つをあらかじめ考え、問題構造図の「インセプションデッキ」のようなものを決めていきます。自分は何者なのか、何のために、どういうところについて問題を可視化したいのか。

構造図のスコープが大きくなりすぎたり、何のためにやっているのか見失ってしまう可能性もある(私の場合は特に...)ので、ここはとても大事だと思います。

スコープが変わるなら、以下の1~4もかわります。そのたびに、問題構造図をリファインしていこう!


①自らの仕事と役割
  例:***さーびす
 ⇒【伴走者さーびす】 とした。


②そのサービスの顧客は? (広めに考えてみる)
例:直接顧客~間接顧客
→直接:現場のPL、PM、担当者など  間接:自分

 

③サービスで顧客に提供している価値
例:顧客にとっての価値・自分にとっての価値
⇒顧客:仕事が楽になる、楽しくなる
 自分:笑顔を見ることができる、現場と自分の会話が増える。

 

④自らの仕事・役割の評価方法
例:どうなれば成功?何で評価する?
→相談の回数、振り返り時間、自分の落ち込む回数の減少度

 

STEP1,2

1.まずは、頭の中にあるものをそのまま吐き出そう!あとで具体的にしていけばいい。
2.時系列を気にして、内容をより具体的にしていく。
  手段の裏返しになっているものは、「それがないと何が困るの?」に変える。
  例:部門横断でディスカッションする場がない

   ⇒ 事例が得られない

   ⇒ 車輪の再発明になる。

ここでの注意事項

「~がない、系のカードには気をつけろ!」

 解決手段を検討せずにだすことになるぞ!裏に理由があり、その理由を解決する手段はいくつかあるはず。その中に真意があるかもしれないぞ!

「どこでも(時系列的に)適用敵るようなものであれば、抽象度が高いもの、と判断せよ。」
ファシリテーションするときには、「それはいつでもおこることですか?」と聞く。
できれば、。5W1Hを意識する。

「要素精査完了=いつのタイミングで、どんなことがおきた、が分かるカード

 

STEP3

要素精査の次は、因果関係の線を引く。
モデルのリファクタリングの方法などは、ここで紹介されている。

www.software-quasol.com

見づらくならないように、交差する線は作らない、線を増やさない、なるべく減らす。
解析しやすくするために可視化しているので、複雑化しないような工夫をすること。
納得がいくまで構造をリファクタリングしていくこと。

f:id:okandayo:20181104145644j:plain

f:id:okandayo:20181104144402j:plain

その際に気を付けることは、第一弾記事でも書きましたが、

「上部に「管理」真ん中に「メインストリーム」下に「仕組み」を意識して配置すると線が雑多にならずやりやすい」ということかと思います。

 

STEP4

改善ターゲット検討・特定のフェーズです。
問題構造図 左側がカイゼン要因・根本原因となり、右側がメトリクスになる。
中間にカイゼン要因があるとなると、これは中間目標になることもある。

他者は変えることはできない。なので、スコープは自分に絞る。

自らがカイゼン可能な箇所に焦点を絞る。


[カイゼン可能な箇所としての目安:3か月以内くらいに完了する内容]


もっと早く終わるような小さなものがあるなら、そこからやって、次に進む・・・とやっていくとよい。

例えば、「レビュー」に絞ったら、さらに「レビューの問題構造図」を作る。
(中身がまだたくさんの構成要素がありそうな場合は別途やる感じ。無ければ当然やらない。)



STEP5

STEP1、2などで出した改善策の裏返し付箋などを再度持ち出して検討したりする。

 

STEP6

メトリクスをきめる。
最初に決めたメトリクス(事前準備の時にきめたもの)につながるとよい。
「どうあればOKなのか?」「どう測るか?」

 

わすれないうちに、社内でもやります!

それとは別に...どなたか、一緒にやってみませんか?

相互にファシリテートの練習でも(^^。

 

ここまで読んでくださってありがとうございました!

 

SaPID Bootcampレポート ~SaPIDへの想い編~

10/21-22で、三浦海岸にて開かれたSaPID Bootcamp。
そちらに参加してきました!

f:id:okandayo:20181103095806j:plain


こちら。
www.software-quasol.com

 

天気も良くて、マグロもおいしくて。
控えめに言って最高の二日間でした。

f:id:okandayo:20181103095847j:plain

ハロウィンが近かったので、謎な生き物がたくさん展示してあった会場:マホロバ。

突っ込みどころ満載で、またそこがこの合宿での楽しさの一つかな★

 

第一弾レポートとして、参加して得たこと・期待していたこと・SaPIDについて思うこと(SaPIDへの想い編)、第二団レポートとして問題構造図作成編を書きたいと思います。

今回は、第一弾!

 

 

SaPIDってなに?

ソフトウェアプロセス改善手法。
フレームワークといってもいいと思う。

www.software-quasol.com

 

参加しようと思った動機

期待していたこと

振り返りのプロセスに課題を感じていた。

仕事ではいつも振り返り議事録を見たり、振り返りに参加していて悶々としていた。

振り返り結果の問題と思うところが多くて。。

その問題構造図がきれいになったりするかなぁ~というところに期待していた。
課題と思っていたことの一部ですが、こんな感じ。ここを問題構造化してみました。

  • Tが浅い。できなかったことを裏返しているだけ。なぜその施策を実施したのかを追い切れていない。
  • KPTを使っているという認識をもって振り返りをやっているかどうか不明
  • 振り返りに使う時間もばらばら。
  • そもそも?ファシリテータは、自分がファシリテータだと思っているのだろうか・・・?
  • 振り返りは何のためにやっているのかを理解している人はどれだけいるのだろうか?
⇒結果、やってもただやって終わり、ただの反省会になってしまっているケースが散見される。これはヤバシ!と思った。
ただ、そこには背景がいろいろあって...一人では導き出せる自信がなかった。

そこで、bootcampの力を借りてみた。


参加した結果

何を得られたのか?

  • 求めていた問題構造図...想定と違う答えがやっているうちに出てきたのは驚きました。ファシリテータさんが、「**ってなんでしょう?本当に困っているのはそこですか?」という促し?をしてくれて、そこからあれよあれよという間にどんどん出てきました。1枚じゃ収まりきらず、床で実施する【ブロッコリーチャレンジ】も達成(?)することができました。
  • 講師の方から問題構造図を作成するときのポイントとして、上部に「管理」真ん中に「メインストリーム」下に「仕組み」を意識して配置すると線が雑多にならずやりやすいかもね、というアドバイスをもらいました。
  • 今回、自分が選択した「問題」は、簡単にいうと「ツールの使い方」。ツールにまつわることといえば、使うための仕組み(プロセス)、人、技術...3つの条件が必要になるだろうなということはうっすら思っていました。結果、きれいにその3ブロックに分かれてマッピングされました。
  • ちゃんと分析すれば、こういう風になっていくんだな、とファシリテータの重要性を痛感しました。

 

期待したことは達成できたのか?

期待以上でした。得られたことの二つめに書いた通り、ひと、技術、仕組みと分けることができて、何をしなければいけないのかを明確化できました。これは、おそらくSAPiDだからこそできた成果なんじゃないかなぁと思いました。

 

感想

SaPIDも、振り返りのツールとして使えるので、今回「振り返りのやり方」の問題構造図を描いて導いた解決策(?)

  • やり方の布教
  • ワークショップ実施

というところで、SaPID自身をつかっていけるといいなぁと思いました。
ただ、自分にとってロジカルシンキングはかなりな苦手さを誇る敵なので、そこはTOCfEをしっかり学んで、論理の飛躍をなくしたり、因果のつながりを意識できるようにしたいと思いました。  

 

SaPIDへ想いを馳せること

すごく楽しくて、温泉も気持ちが良くて。
生きていれば誰でも課題や壁に当たる。
一人でクローズする問題なら、一人でこの構造図作成をチャレンジするのもいいかも。
ロジックを分解するところが難しい。ファシリテータの力は本当に必要だなと思った。
組織や家族、仲間の間で感じる課題も、自分から見た課題は、他人は課題と思ってなくて当たり前と思っていたり、関係者で話していくと面白い発見につながっていく。
深く話していくと、相手の価値観や軸がどこにあるかを理解できるし、理解することでもっと関係性が良くなっていく。
SaPIDは、この「理解する」プロセスを踏むツールの一つでもあるなぁと感じました。

部分最適で少しずつ解決していくやり方もあるけど、大局を見ないと本質をつかめなかったりする。
単一の中に学ぶものはない。価値観が唯一の世界に発展はない。

一人の視野じゃなく、みんなで。
All for one, One for All。

出会えたことに感謝。本当に素敵なメソッド。

 

読んでくださってありがとうございました!

Jenkins Day Japan 2018 レポート

昨年から開催されている、年に一回の祭典「Jenkins Day Japan 2018」。

今年も非常に面白かったです。

こちら。

cloudbees.techmatrix.jp

 

昨年との違い

昨年の記事はこちら。

 

okandayo.hatenablog.com

大きな違いは、昨年は「SREのようなものを作っていく必要がある」という川口さんの講演があり、今年はその実例を聞くことができた。確実に少しずつ進歩している。…海外は。

しかも、海外の2事例は、面白くも両極端のようにも見える。

中央集権型と地方分権型。

しかし、いずれもスキルのある人を事業規模に合わせて選択し相応の報酬、権限を与えて運用しているということ。実は両極端ではなく、同じ施策を部分最適全体最適か、という目的に合わせて選択しているだけ。

非常に興味深かった。

来年に期待することは、日本でのSRE事例が発表されること。川口さんの発表の中にあるように、事例発表をしていくことは悪ではない。社内にとどめるのではなく、成功も失敗も共有して、フィードバックループをまわしていけばいい。

社外発表申請が「本当に」重い会社が多い。

やることをやっているなら、もっとその事例を出して、よい策を享受するようにしていけばいいのにと思う。

 

セッション紹介

以下、印象深かった二つの講演をご紹介。

大企業におけるDevSecOpsの変革

Moied Wahid 氏 Experian社 (元:PayPal社)


やりたいことはそれぞれで違う。
目先の、小手先のことをするのではなく、大局をみて、大きな絵を描いてやることが大事。北極星のようなものを伝えること。決めたビジョンをみんなに伝え、納得してもらうことが大事。
 仲間を見つけていくことが大事。

 

ビルドするだけで24時間かかっていた。そこがボトルネックだった。
達成されたとき、マイルストンが達成されたとき、お祝いすることが大事。
それは、外から見えるようにするということでもある。アピール力。

見えないものを見えるようにすることが大事。
定量的に計測することで、カイゼンが進む。
そのままとどまるのではなく、プロジェクトサイズを大きくしていくことも大事。

自動化するには時間がかかるが、そこから先はそのうまみを享受できる。
そういう視点をしっかり持って計画すること。

 

サービスを開始するにあたり、検討したこと。
JS,C,C++,C#のチームがいるとする。
最初からある程度の自動化できるしくみを準備した。
どんな環境が自分たちの組織にはあるのかを把握し、共通化できるところを見つけた。

570万件のテスト・・・毎日生み出されている。
巨大な環境をしたから支えていたのがJenkins。
再現可能性。それを達成するには、パッケージングする必要がある。
巨大なスケールでの運用をしていると、あるべきものとのずれ、ドリフトが発生して、物事を難しくしてしまう。

モニタリングも必須。
ドリフト部分を発見できる仕組み。
計測するとノイズも入るので、真の値を見極める仕組みも必要。

インフラがコードとして整備されている、これは大事なことである。

作られたバイナリをデプロイすること。
ソースコードの責任者を把握しておく。
ソースコードのトレーサビリティ・・意図との追跡可能性が重要。

ブランチ戦略はあまり気にしていない。Git-flowなどで簡単な仕組みで回ればそれでいいと思っている。

120億のサービスエンドポイントへのアクセスを生む、そのくらいの大規模なシステムで動かしている。
これだけ大きいと、サイロ化されたテスト環境は現実的ではない。共通化された環境が必要である。

運用可能性。実行状況を把握できるメトリクスをとったり、ログ戦略をたてたり、起こったことを後からちゃんと追跡できる仕組みを重要視して構築した。
ソフトウエア生産性に重要視して真摯に投資してきた会社というのは、優秀な開発者を引き寄せている。

開発者に権限を与えてあげる。
開発者はQAにコードを渡しておしまいではない。本番環境にテストして失敗したものがいかないようにする仕組みを用意してあげる。
自己修復してくれる有機的なSWを作る必要がある。

うまくいかなかったインタラクションのデータを取得して、なぜうまくいかなかったのかをスピード感をもって解決できることも価値となる。
これを続けていき、ソフトウエア技術者の価値を高めていく。
ソフトウエア開発者への投資をしていくことを強く言い続けていきたい。

会社の経営層、開発者、それぞれの立場の人向けのダッシュボードが必要。開発プロセスをいじった時に、どういう影響を及ぼすのかという影響範囲・・原因と結果を結びつけて解決することができる。それぞれの立場からの究明。

問題を発見するためのサイクルタイムを短くする。その仕組みを作ることに投資を惜しまない。
開発チームと運用チームに分かれていたが、今は一緒。投げ合うのではなく、googleなどで提唱されているDevOPS-SREを構築した。

実行時のソフトウエアの性能などに責任を持っている人たちをSREという。

新しいSWをつくるのに、ダウンタイムなしに作業に移れる仕組みを構築している。
ダウンタイム=お客様と話したり、「止まってしまう」時間のこと。

みんなのソフトウエア開発を支える組織。このチームにこそ、他よりもスキル・能力のある方たちを配置する。
自動化なしにはもう成り立たない環境。そこを「あたりまえ」に支えるチームにこそ光を。
IaSの考えをもって仕組みを構築している。

社内のことだけに視野狭窄になるのではなく、産業全体にアンテナを張り続け、その成果を自分のプロジェクトや環境に反映し続けることも大事。
当然、産業へも。共益。

シェアドサービスの人たちがもっと組織に理解され、その功績をアピールして立ち位置を揺るぎのないものにする努力をする人が必要。



DevOpsを前進させるCloudBeesの取り組み

川口 耕介 氏 CloudBees, Inc. Chief Technology Officer 

スケールアウト。人のスケールアウト、組織のスケールアウト、インフラ。
できる人は社内コンサルみたいになってしまって、ぜんぜん技術が組織にスケールアウトしない。どこに必要で、どこに課題があって・・・というサイクルを回すには、データの力が必要。
全体をみてクローズアップしていって課題を見つける必要がある。
ガバナンス 企業のプロセスをどう分解して守り、エンジニアにとって蜘蛛の巣みたいにならないで済むのか?
いいプロセスをどう適用していくのか、開発者に価値を届けられるのか。
目に見えない「人のアクティビティ」を可視化しなければいけない。

現場の人たちの仕事の負担を軽くしてあげたい。注力させてあげたい。

中央の人たちが開発する人たちにペコペコしないで済むようにい押し疎通してできるようにしたい。

パイプラインを中央の人がコントロールした方がうまくいくのはわかっている。
⇒開発者が今までやっていたことを取り上げてしまう。そうでなくて、どうぞ、そこは知らなくてもいいんですよね、別なところに注力してください、というように持っていきたい。

結果の利益だけを享受するだけでうまくいくようなことを考えている。
ラクティスとして取り込んでいる。自動化にあったプロセス、文化を作っていく


DevOPSはエンジニアリングのためのエンジニアリング。
2段階のテコが働く。だからそのつなぎの部分は本当に大事。
全体にかかわる話になるから経営層の理解も必要、納得も必要。上からも下でも納得をしていないといけない。


事例発表をしていこう。みなさん!積極的にです。
会社の名前を出して発表できないのは、何がいけないのかな?
国内だけで済む時代ではない。我々はそのままでいいの?
自分たちの組織の中でどう変化させていかなければいけないのか、を共有してほしい。
チェンジエージェント。

あらゆる人がSW産業にかかわっていく。農業など。
ラクターがデータを取得して、解析して、適切なところに適切な処理をできるようにする、とか。

自分のクリエイティビティを発揮して自分の技術で解決したい。
クリエイティビティをしっかり把握する必要がある。これは営業?
その技術でどのくらい利益が得られるのか?などの予測できるようにならなければいけない。可視化。
なるべく早く得られなければいけない。

一見相反する課題を解決することができる。

データを理解することでよりよいアクティビティを起こせるようにする。
何が産業にとって一番大事なのか?

広い視野で、俯瞰してみていきましょう!

 

おわり。

 

未来開墾ビジネスファーム 簡単まとめ

10/24 、品川プリンスホテルにて開催されたものに参加しました。

こちら。

project.nikkeibp.co.jp

 

参加動機

最近、異業種交流などに興味があり、ちょっと個人的に足を運んでみました。

ただ、このシンポジウムの方向性も、ITを異業種へ!というものだったので、基本的な概念は変わらんなぁというのが感想です。

抽象化した概念は不変。当たり前だけれども、それをしっかりと実感した良いシンポジウムでした。

以降、簡単な紹介です。

途中寝てしまいましたので、そこは割愛(汗)。

一番よかったなぁと思ったセッションは獺祭社長のご講演。

今まで作ってきた自信、プライド、作ってきたブランド力。そこが軸になり、負けない価値観を提供してくれている。シビレタ。

 

概要

あらゆる産業が成長を目指して創造的イノベーションを繰り返す中、農業ビジネスの成長と拡大スピードも目覚ましいものがある。政府が輸出1兆円を目標とし、訪日外国人からはユネスコ認定された和食が注目され、技術立国ならでは機能性食品には飛躍の可能性がある。そして全ての源となる食材。

農業が農業生産者とその周辺だけで発展を遂げる時代は終わった。生産者を陰日向に支える屋台骨のJAグループの「自己改革への挑戦」自体がその象徴でもある。
俄かに注目を集めている農業ビジネスが健全にこのまま拡大するか否か。その成否の鍵は、農業生産者とJAグループ、そして読者の皆様にかかっている。農業ならではの課題(就農者数、地域振興、所得拡大、付加価値創造と民間連携など)をどう解決し、その先にどんなビジネスチャンスを描けるか?
農業ビジネスの疑問、課題から解決への道標を徹底討論する。

 

セッション紹介

純米大吟醸「獺祭」を通して、ニッポンの農に想うこと
~思うままにならない"魅力"と"醍醐味"

旭酒造株式会社 会長 桜井 博志 氏

農業ビジネスと密接なJA。使い倒してほしい。

獺祭をとおして、日本の脳に思うこと。
獺祭は、山口健岩国の過疎地で作られている。

しかけ

マンハッタン97丁目、700人のお客様を集めて、参加費90ドルでの試飲会を定期的に開催している。
参加者は一般の人。自由意思で集まっている。獺祭を愛し、好み、日本の文化を知ることを目的として集まっている。女性が多い。
女性、若い、外国人という3つのワードに共通すること。
日本酒に対する知識がない。
知識がない=(いい意味で)思い入れがない。
地元の酒で乾杯しなくちゃいけない!そんなものは彼らにはない。
「おいしい」だけが、一番の訴求ポイント。
一番おいしいお酒を造りたいと思う想いは日本一だと自負している。

 

米と水だけで作る。これがポリシー。ここにこそおいしさの源泉がある。
杜氏を使わず、社員だけで作っている。100人くらいの人数。
スタッフの投入人員と製造量の比率を考えると、ほかのところの3倍人員を投入している。山田錦というコメのみを使っている。自動化はほぼしていない。人の手のみで作っている。
酒税を払わないお酒が売れている。海外に行っている。2000トンのコメが海外に出ているのと同じ。

大量販売の論理からお客様の幸せ志向商品へ。

マーケット

ディスカウントストア。スーパーマーケット。お酒を扱っている。
お客様が買うものを選択できるようになった。
以前は、自分たちが作ってものを買っていただくということが主軸だった。
選択肢が多いということは、選んでいただくための価値を最優先に追求するということ。

昔はおさけか高級品だった。所得に対しての比率がありえないものだった。
昭和30年代。
安いお酒を作ろうと努力した。岩国の中の酒蔵で四番目だった。どう考えても、つぶれる勢いだった。負け組だったからこそ、頑張れたと思っている。
自分たちの価値をちゃんとわかってくれるところとしか取引しない。
中間凝視なしなので、輸送経費は落とした。
桜井様が社長になってから出荷本数36倍、売上150倍。
お客様の立場になって考えることを追求したので、ここまで行けた。

伸びた理由
1.山奥の過疎地だから
負け組。外、東京市場に出ていかざるを得なかった。
売れるためにはどうしたらいいか?
純米大吟醸じゃなきゃいけないという価値追求。
2.県内で米が入らず
県内で、いい米をもらえない、相手にしてもらえなかった。負け組だたので。
今は山田錦を20000俵くらい取引している。全部お酒へ。
全能さんとけんかしちゃったので、県内では入手できず。
全国を行脚して手に入れる道を作った。それが、今の入手経路につながっている。
3.杜氏がFA宣言
2億損害。杜氏に給料はらえないので、杜氏はほかの酒蔵に移籍。
困って、ド素人の社員三人と社長ともう一人と五人で作り始めた。
2億まで売り上げ伸びていたが、杜氏がいないので、やるしかない。
そこまできたら、自分が作りたいものを作ろう、とおもった。
杜氏もいない、社員はド素人、社長の言うことを聞いてくれる。
抵抗勢力なしw

過去10年間売れなかった商品を、売れなかった取引先を通して、売れなかったお客様に一生懸命売る努力をしていた。当然売れるわけがない。

宅急便の出現、コピー・ワープロの低価格化。
宅急便が開発されて、FAXも普及した。
地元で負けて東京に出ていったのが、宅急便が開発された時代なので実現できた。
コピーワープロがあったので、印刷屋さんにお願いできなくても何とか自分たちで発信できた。情報発信能力、輸送能力。そのインフラが整ってきた時代だった。

四季醸造体制の確立

土日休みなし
一番良い状態のお酒をお客さまに・販売の増減にも柔軟に対応。地元で働けるようになる。そうすると、杜氏もいない。今までの雇用形態が維持できない。
⇒夏も作ろう!社員とともに作り始めた。一年間作り続ける。緊張が切れない。
 
日本酒は日本の歴史と文化により洗練された素晴らしい酒
であるがゆえに、「伝統の手法」に固執することは弱点。
本当は日本酒に伝統の手法などない。

「結果のために手法というものはある」

海外の話
30億程度売り上げがある
高所得者層しか相手にできないだけに、自分たちのお酒で勝負できる。
高所得者層は、フランス、中国・・・結構嗜好が似ている。

米の話
山田錦は経験者じゃないとつくれない、ということを言われる。
そうじゃなくて、どんどん作れるんだから、酒造は買えよ!と言ってほしい。

酒造りを数値化、分析してみたら機構のせいなどではないと思えてきている。
米つくりも、データ化、数値化をして分析していったほしい。

被災したら公的な支援を・・・ではない。
企業は、自分たちの商品をもって社会に何ができるのかを考えるべきだ、
赤字が出ても、ブランド力、自分達意の価値がわかった。
これだけでも、本当にいみのあることだった。

 7月の豪雨で、獺祭のほとんどがダメになりそうな時に、島耕作の作者からの申し入れで売った商品。頑張ろうとおもった。

以下は、その島耕作の商品紹介。

獺祭の蔵元 旭酒造株式会社

 

一次産業を支えるドコモの農業IoTの取り組み
~アグリガールとパートナー企業との"協創"

株式会社NTTドコモ 取締役常務執行役員 古川 浩司 氏


アグリガール

始まりは2014年、農業ICTプロジェクト。以下のような背景がある。
・TPP協定
・高齢化
・農地拡大・・・担い手がか高齢化することにより、一人当たりの面倒を見なければいけない面積が拡大

B2Bが主流だったが、B2B2Cモデルへ移行。

新事業を行う上での大事な点
・小さいチーム スピード重視
・大きな方向性 ビジョンの提示:ICT/IoTで農業に貢献する
・メンバーの想いを尊重

上から言われた仕事は数多くあるけれど、やってみて自分の課題意識、
満足度に通じる仕事ができているので満足ですという声をもらった

共感、共通の志、そういうもので無図ばれたチームは強い。

 

これからの新時代

5G時代の到来(2020年)
VR、AI・・・

ドローン活用など、様々な変化がこれからおこってくるであろう。

 


「次世代技術」

鍋八農産 代表取締役 八木 輝治 氏

トヨタ自動車 アグリバイオ事業部 

農業支援室 先端農業G GM 
喜多 賢二 氏

日経BP総研イノベーションICTラボ
上席研究員 菊池 隆裕

トヨタ自動車がもの造りで培ってきたトヨタ生産方式を農業に応用したICTシステムの「豊作計画」と現場改善活動を導入し、農業生産での生産性向上に加えて、人材育成の取り組みについて紹介する。

 

鍋八産業 愛知県 米麦大豆の生産などを行っている。
農機具、肥料などみんな高い。
田んぼのどこにいるか、位置などもわからず・・という悩みがあった。
TOYOTAが提供するソリューションの力を借りて、クラウドとデータをやり取りをしてグラフ化できるという見える化に手を出した。
「豊作計画」

カンバン、ふりかえり、朝会、タスクの見える化CCPM,ワンベスト。
置き場所を決めて。QC活動・・・5S,4S・・・
「ものを探すのは仕事じゃない」

自分が支持するのではなく、見える化して気づきを与えるのが社長。

 

コンサルをして、TOYOTAとして得たものは何か?
稲作の「あたりまえ」な価値観。
相互のビジネスドメインをみて、当たり前が全然違う。
触れ合うことができてよかった。

異業種連携の難しさ:
言葉が違う、定義など。


最近の農家は米と野菜、などという複合農家が多い。
なので、連携よりも個別最適になってきている。
なので、もっと幅広い技術などの知識が必要になってくる。

6次産業化

これなら出来る! 農業ビジネスを成功させる事業計画書づくり
-企業の協力も不可欠な6次産業化、参入ポイントを学ぶ-

 

BEER EXPERIENCE 代表取締役社長
吉田 敦史 氏

農林中央金庫 営業第四部
鬼丸 純一 氏

日経BP総研マーケティング戦略ラボ
研究員 丸尾 弘志

遠野のクラフトビール事例。 beer experience社。

この事例の紹介。

project.nikkeibp.co.jp

前例のないものの説得。 これが一番大変だった。 ホップ棚とか、パドロン生産は日本初。

初のものを説得するには、前例のあるところから試算するなど、一人ではできない。

コーディネート機能を発揮しないとできない。

仲間を増やしてから行くしかない。 リスクがどのくらい見えるか、がキーになる。

 

最後までおつきあいくださり、ありがとうございました!

 

家庭でRedmine、その後... ~嵐の前の....~

前書き

redmine.tokyoでLTをした事例。

www.slideshare.net

この中で、日々の学校の宿題・次の日の支度などの習慣をつけるため、子供たち(上:娘、下:息子)と試行錯誤をしてたどり着いたカンバン施策までの道のりを紹介しています。

これはほぼ1年前。

 

ここからだいぶ姿が変わってきました。

少しだけ(勝手に)ご紹介していきたいと思います。

 

目的

「困りごとを最小限にする」

年齢以上のことができることはゴールではありません。むしろ邪魔になるかもしれません。

私は、

【子供には今しかできない遊びや体験をしながら、困りごとをなくすための施策自体を楽しむ姿勢を小さいころからはぐくむ。】

を育児方針としてやってきました。

これは、これからも変わらないかなぁ。。。

そして、一緒に自分も成長できるので、みんなで一つのチームです。

(背景にはもう一つ大きな目的があるのですが、いずれ...書くかもしれません)

 

First TRYから現在まで

その後に近いものを、以下で発表しました。

【事例1】の内容です。(P33-35)

www.slideshare.net

 

1年目

1年目は、上の子が一年生になるときに、毎日やることを体で覚えてもらうために、同じ時間に同じ内容をやるような働きかけをしました。

下の子は年中さん。

1年生への助走をつけるタイミングとして最適。

「できた!」

「すごいね!ひとりでできたの??お母さんは毎日部長におこられてるよ~」

こんなやり取りで場を明るくしながら(?)習慣を身に着けていきました。

 

 

2年目

口頭確認でのストレスが最高潮・半端なくなってきました。

ここで、登場していただいたのが、チェックリスト。

リストを作成して、毎日子供とチェックをしながら、その中に絵をかいたり感想を書いたり。

交換日記のようで、楽しんで実施しました。

この施策の最後のほうでは、娘から進んでチェックリストを作成し、自分のお気に入りのキャラクターを周りに書いて可愛くするカイゼン(笑)までしてくれていました。

昨年より、確認の回数がぐっと減りました。

チームとしての成熟度が上がってきました(笑)。

 

 

3年目

チェックリストも形骸化します。

子供たちは飽きる生き物です。

ここで、取り入れたのがポケモン施策&夏休み宿題Redmine管理。

ここは、上記redmine.tokyoのLTで詳細をご紹介しております。

Redmineで安定するかと思いきや、家の中にあるRedmine端末が、子供たちの動線から離れていたため、定着せず。そして、2年目のカンバン+施策へ落ち着きました。

付箋で移動する➡シールチェックと、変遷しました。

目的を失わなければ、ツールは何でもよいのです。

確認回数は、1週間に2回。土日はやはりダレてしまうようで、口頭確認必須。

時間確認をしながら。

平日は、流れ作業のように、体で覚えてくれたようです。目的八割達成です。

それどころか、わすれんぼうさんの弟を姉がしっかりフォローするようになりました。

ここから、ぷちサーヴァントリーダーシップ風な流れに。

サブリーダの心が芽生えてくれたのでしょうか(汗)

母がだらしがないと、子供はしっかりしてくるものですね....

 

 

4年目

 息子は相変わらずカンバン使用ですが、娘はタブレットを操れるようになってから、Redmineスマホで見れるアプリを使って自ら更新するようになりました。

発行忘れていると、チケットタイトルにちゃんと、「宿題」とか「塾の課題」とかを入れて発行して、完了ステータスへ。

やってくれるようになってから、セルフマネジメントが始まりました。

 

夏休みには、ダレないような施策を入れてみました。

子供たちとインセプションデッキを作り、ゴールを明確にして、何をやる・やらないを導出してみました。

この内容については、どこかのLTでやる予定です。(笑)

 

ここ数週間

ここは、LTが終わってから詳細を書こうかと思っています。

端的に書くと、プロセスの変遷。

目的の変化。成熟度向上。こんなところでちょうか。

 

つづく