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

こんにちは！

ソフトウェアテストの小ネタ 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が１に近い（クローン含有率が高い）ファイルや、NBRが1以上（他ファイルに影響のあるクローンが存在する）のファイルメトリクスに注目して、コードクローン率を下げて行きましょう！

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

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

Lattix

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

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

www.techmatrix.co.jp

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

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

システム規模の計測　システム規模を把握します。

• 要素数
• 複雑度
• 依存関係数
• 依存度平均

変更に対する感度　変更に対するシステムの影響の度合いを把握します。

• システム安定性
• 影響度平均

結合の度合い　要素の結合の度合いを把握します。

• 結合度
• 結合濃度
• 結合強度

 など

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

 分析する目的

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

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

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

使うツール

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

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

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

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

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

前提条件まとめ

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

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

 明日は、なそくん（@hiroyuki3gou  ）です！バトンタッチ！

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

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

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

okandayo.hatenablog.com

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

www.software-quasol.com

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

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

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

（どろどろした個所は省いたりしています（汗））

問題構造図の作成手順

事前整理

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

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

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

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

②そのサービスの顧客は？　（広めに考えてみる）
例：直接顧客～間接顧客
→直接：現場のPL、PM、担当者など　 間接：自分

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

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

STEP1,2

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

　　　⇒　事例が得られない

　　　⇒　車輪の再発明になる。

ここでの注意事項

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

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

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

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

STEP3

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

www.software-quasol.com

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

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

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

STEP4

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

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

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

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

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

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

STEP5

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

STEP6

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

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

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

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

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

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

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

こちら。
www.software-quasol.com

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

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

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

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

今回は、第一弾！

SaPIDってなに？

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

www.software-quasol.com

参加しようと思った動機

期待していたこと

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

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

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

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

• Tが浅い。できなかったことを裏返しているだけ。なぜその施策を実施したのかを追い切れていない。
• KPTを使っているという認識をもって振り返りをやっているかどうか不明
• 振り返りに使う時間もばらばら。
• そもそも？ファシリテータは、自分がファシリテータだと思っているのだろうか・・・？
• 振り返りは何のためにやっているのかを理解している人はどれだけいるのだろうか？

⇒結果、やってもただやって終わり、ただの反省会になってしまっているケースが散見される。これはヤバシ！と思った。

ただ、そこには背景がいろいろあって...一人では導き出せる自信がなかった。

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

参加した結果

何を得られたのか？

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

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

期待以上でした。得られたことの二つめに書いた通り、ひと、技術、仕組みと分けることができて、何をしなければいけないのかを明確化できました。これは、おそらく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#のチームがいるとする。
最初からある程度の自動化できるしくみを準備した。
どんな環境が自分たちの組織にはあるのかを把握し、共通化できるところを見つけた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おわり。

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

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

こちら。

project.nikkeibp.co.jp

参加動機

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

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

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

以降、簡単な紹介です。

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

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

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

 

概要

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

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

セッション紹介

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

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

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

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

しかけ

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

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

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

マーケット

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

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

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

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

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

四季醸造体制の確立

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

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

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

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

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

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

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

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

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

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

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

アグリガール

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

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

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

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

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

これからの新時代

５G時代の到来（2020年）
VR、AI・・・

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

 

「次世代技術」

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

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

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

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

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

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

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

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

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

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

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

「6次産業化」

これなら出来る! 農業ビジネスを成功させる事業計画書づくり

-企業の協力も不可欠な6次産業化、参入ポイントを学ぶ-

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

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

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

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

この事例の紹介。

project.nikkeibp.co.jp

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

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

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

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

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

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

前書き

redmine.tokyoでLTをした事例。

Redmine tokyo #13 LT from Asako Yanuki

www.slideshare.net

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

これはほぼ1年前。

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

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

目的

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

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

私は、

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

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

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

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

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

First TRYから現在まで

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

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

Sqip2018 チームビルディングにおける心理的障壁の傾向と緩和策の提案 from Asako Yanuki

www.slideshare.net

 

1年目

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

下の子は年中さん。

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

「できた！」

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

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

２年目

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

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

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

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

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

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

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

３年目

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

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

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

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

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

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

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

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

時間確認をしながら。

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

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

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

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

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

４年目

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

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

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

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

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

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

ここ数週間

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

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

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

つづく

映画【鉄コン筋クリート】2006年公開

かなり久しぶりに見返したくなった映画。

そろそろ、娘にも見せられるかな。

www.tekkon.net

本当にすっばらしい映画だと思う。

多くの人に見てほしい！

見た当時に書いた感想をそのまま掲載。

ーーーーーーーーーー

勝手に自己評価・・・９０／１００．

「クロにないネジ、シロがみんなもってる！」

非常に、おもしろかった。大好きなネタの映画だった。
5年くらい前にみた映画、「ヘドウイグ・アンド・アングリーインチ」とにた映画。こちらはアニメ、向こうは洋画。

Looking　for　missing　half.

自分の相棒を探す旅でもありましたが、本当の自分を探す旅。
すごく好きです、こういう設定。
どちらが欠けてもなりたたない。
鍵を必ずどちらかがもっており、二人でひとつの完全体となる。

途中、ばらばらに行動しなければならなくなったときの両者の崩壊ぶりが映像で非常にリアルに描かれていた。
壊れている過程。
寸前にたてなおそうとするが、闇に奪われていく自我。
一緒になったとき、涙で我を取り戻す。
ひとつにやっと戻る一瞬。

「僕を探して」という、アメリカの本を、昔よんで、いたく感動しました。
絵本なんですが、奥が深すぎる絵本なんです。
一部がかけたパックマンのような生き物が、かけている部分を探しにいくという、簡単なストーリーですが`...

人によって、その「かけている部分」の認識が違うはずです。
読んで、知らないうちに、涙があふれてきました。
シロとクロの関係は、この「僕を探して」の、かけらと本体のような関係だったんだなぁ、と思います。

「もちも～ち、こちら、地球星、シロ隊員。応答ちぇよ～」

この内容...もし、自分に子供ができたら。

その子供たちは果たして分かるのだろうか・・・
おそらく、押井監督や、大友監督の作品が好きな人が、この映画を見るととてもうれしく思うのではないかと思います。

そういう人に、オススメ。
何年かたって、大切な人を見つけ、実感したとき。
もう一度みてみたい。

長文、お付き合いしてくださった方ありがとうございました！