2018 振り返りとこれから ～子供とのかかわり～

わんばんこ！（ふるっ！）

あさこです。2018年は、本当に本当に皆さんにお世話になりっぱなしで、感謝しかありません。2019年、本年もよろしくお願いいたします。

反省と、これからの内容などを勝手に書いていこうと思います。

お時間のある方はお付き合いくださいませ...。

なんでいちいち振り返るの？

人生半分折り返したなぁ、と思う齢になりました。あと半分、めいっぱい楽しんで終わりたい。毎年、そんな一年になるように過ごしていきたい。

なので、毎年の振り返りと、一年という短いマイルストンごとの目標設定はこれからも大事にしていきたいと思っております。

一度しかないこの一年。

「ボーっと生きてんじゃねぇよ！」って怒られないように(笑)。

大事な人たちとの機会を損失しないよう、自分が何をしたいのかを忘れず、でも、時々道を踏み外して（迷子になって(笑)）も、戻ってくることができるように。

地図を描く

振り返るときには、軸があって、どこに効果があったのか、結局はどうしたかったのか、じゃぁつぎにどうしようか、・・・とつなげていくことが大事だと思っています。どこにつながるのか、全体が見えないと迷子になるだけ。

なので、地図を作ります。

（せめて、人生の迷子にはならないようにw）

自分のありたいすがた

どんな時でも、いつでも戻ってこれる場所でありたい。

戻ってきてそのままでは返さない。必ず笑顔をプレゼント。

そんな人でありたい。

自分軸

振り返りとマイルストン設定に当たり、柱は３本。

3本あって自分です（毛利家じゃないですが(笑)）。

大事にしていきたい軸

1. 子供とのかかわり
2. 社外とのかかわり、仕事の充実
3. （特性を持つ子供の）親の会をひっぱっていく

本振り返りは、まず１と3から。（後日ゆっくり2についても..）

2018振り返り

やったこと

結構、いろいろと遊んできました。いくつかは、過去記事で書いてみました。

• 学校の宿題管理にアナログ看板からRedmineへ戻す
• 夏休みの宿題管理にインセプションデッキとRedmine融合
• 時間管理を学ぶためにCCPMカレーワークをやる
• 読書感想文構成に付箋紙を使って構成を考える（論理構造作成）
• ブランチ（TOCfE）をつくってみる（Qくんを題材に）
• 恋愛問題（娘）の心の揺れ動きを状態遷移図で表してみる
• 親の会で月に1~2回のペースでペアレントトレーニング講座開催。

（ほかにもあったかな..）

わかったこと

子供

とにかく、悩んだらすぐに解決しよう！をモットーにやってきました。

この習慣をつけてあげたくて、すぐにやりました。

毎日、あったことを素直に話してくれるという関係性ができているので、次のステップとしてこの施策をやってみています。

（小学生になったら、まずはじめにやってもらったこと。それは、先生の行動や言動で、面白いと思ったことを３つ毎日見つけて教えて、というミッション。これをやることで、先生に興味を持ち、親との会話を常態化でき、会話の練習、人の観察方法など、いろいろ学ぶことができます。おすすめです( ・∇・)）

少しずつ試して、軌道修正する。本当に少しずつですが、想いは伝わっているようです。

子供たちの口癖の中に、「はい、次、次！」「切り替え切り替え！」

「面倒くさいことはすぐ解決！」がでてきていることが証拠の一つかな、と。

あと、きわめつけは。

「ま、いっか！」です。

親の会

「どうすればいいのかわからない」という言葉がなくなりました。

親も、自己受容が必要なのです。親も同じように特性を持っている方もいる。いっぱいいっぱいの中、参加してくださっている。

何かを必ず持ち帰ってもらえるように、自分の経験談ややっていること、笑いを交えて必ずお話ししました。

「おもしろそう！」「それならできる！」「こんな時は？」など、お悩み相談やディスカッション中心になるときもあり、自分自身にもためになる会になっています。

次にやること

子供

強い特性を持つ息子。人とのかかわり、短期記憶が極端に苦手分野。（WISCのWM値※１が極端に低い）

茶番劇(笑)ではないですが、まだ娘が付き合ってくれるうちに、いろんなシーンを想定した、ちょっとした劇(笑)を、週一でもやっていきたいなぁと思います。そして、軌道修正しなければいけないところを早く体験して見つけてほしい。

言われたことをやるだけでは、すぐに忘れてしまう息子。

何度も経験して、自分で理解して腑に落ちて納得しながら学んでいく。

この体験を家にいながらできるような環境を作っていくことが、私の使命であり、今いろいろ学んでいることでできることかなぁと思っています。

 ※１　WISCのワーキングメモリー。短期記憶の能力を測定する指標。短期記憶とは、記憶(情報)を一時的に保持し、操作をする能力です。

親の会

自分を理解する。何が得意で何が苦手なのか？

そこが把握できていないで、子供を理解し、促す...なんて、思い上がりも甚だしい。聖人ですか？と。

そこまできつい言葉では言いませんが、まずは自分を認めて受容する。受容することで余裕ができてくる。そこからがスタートです。

なので、来年度のチャレンジは。親の会で褒め活！です。

ゴール

望むことはただ一つ。

選択肢が絞られてしまうというマイナスを感じるのではなく、これだけ選択肢があるんだなぁ、とプラスに考えて行動ができる人間になってほしい。

こう感じることができるように伴走していくことができる人を増やしていきたい。

これが私のモチベーション。

・・・と、酔った勢いで投稿！

「三方良し」であるために、戦略マップ～テスト戦略を考える

こんにちは！

ソフトウエアテスト Advent Calender 21日目担当のあさこです。

qiita.com

昨日は吉武ぺんぎんさんの「ブラウザ自動化ツールのインストールとサンプル実行6選 」でした。
yoshitake-1201.hatenablog.com

序

みなさん、ソフトウエアテストを考えるとき、組織戦略を考えたりすることはありますか？

受託でも製品事業でも、組織...会社...経営の観点から考える優先順位やとるべき対策、手段などがあります。それは、プロダクトが関係している以上、ソフトウエアテストにも、もちろん関係します。なので、本アドカレで選択して書いてみようと思いました。

少しだけ触れていきたいと思います。

私は戦略マップを策定したことはありません。（経営層の役目）

プロセスを定義したり、策定された戦略マップに基づいてプロジェクトの改善を「一緒に」進めていく立場にあるので、書いた内容には想像が含まれています。

なので、ここはこういう風にとらえたほうが良いよ、などのアドバイス大歓迎です！（鋭意勉強中なので、アドバイス・コメントいただけると嬉しいです！）

目次

破

戦略マップ（バランススコアカード）

バランススコアカードの詳細はこちらを参照ください。
journal.addlight.co.jp

安くて質の高い製品を提供するだけでは、市場に追いつけなくなってきたという背景がある。では、どうずればよいのだろうか？

改善点を見つけるために、測定をするが、測定されなかったことは誰もうまく管理ができない。そこで、このバランススコアカードという構想が生まれた、とのこと。

経営するとはどういうことなのか？

ミッション⇒価値観⇒ビジョン→戦略マップ、バランススコアカード→KPI

いいかえると・・・

何のために自分たちは存在しているのか（自分たちのいる意味）、何が大切なのか、どうありたいのか、そのためにはどういう戦略を練るのか。

ここまで書くと、インセプションデッキやん！と思いますが、粒度が「組織」になっただけで、考えは共通しているのは至極当たり前の話ですね。

戦略マップには、主に４つの視点があります。

1. 財務の視点
2. 顧客の視点
3. 内部プロセスの視点
4. 学習と成長の視点 

この４つで、プロジェクトや、従事する人々がどんなスキルを持つべきか、どういう分野の知識が必要になるのか、をマップで示し、KPIとして必要な資格を持つ人数とか、資格を取得するための講座受講費用とか細かい話に波及するのかな、と想像します。

自分たちが行うテスト。どんな部分を大事にしなくてはいけないかという戦略からの方針をちゃんと経営層から受け、自分はどうあればよいのかがわかると、必然的に何を学び、どうふるまえばよいのかが見えてきますよね。

 CMMIレベル５　OPM

 CMMIの成熟度ML5に、OPMというプロセスエリアがあります。

OPM＝組織実績管理。

www.cmmiconsultantblog.com

ここには、成長を続ける、改善を続けるためのベストプラクティスが描かれています。

ただ、howは当然のことながら、書かれていません。

自分たちの強み改善点を知るための定量的測定箇所を見定めるツールとして、バランススコアカードを利用している組織も多いのではないかと思っています。

CMMIでは、組織レベルだけでなく、もちろんプロジェクトとしてのベストプラクティスが書かれています。このフレームワークを用いて、自分たちのミッション、組織戦略から実際に従事する受託案件・製品事業、サービス事業で成し遂げなければいけない大事な部分を見出していく。

なので、howとしてこの戦略マップ・バランススコアカードをCMMIフレームワークの中でtoolとして使用し、改善点からのテスト戦略、強みからのテスト戦略を導出することもあるよな、と思います。

個人的にCMMIで一番大事にされているなと思う部分は、

「組織の目標からプロジェクトの目標が根拠をもって説明されてつながっており、合意されて落とし込まれていること」

にあると思っています。 

とある小説内に出てくる組織では

（森崎先生、小説お借りしましたw）

とある小説に、こんな企業グループの事例が書かれていました。以下、転載（？）。

グループの子会社では、親会社から受託案件が降ってくる。

子会社のバランススコアカードの「顧客の視点」には、親会社のミッションを達成する支えになるというものがある。

その中でも、

ミッション：「自分たちの会社の利益を確保！（存続する）」

価値観：「顧客の事業戦略を支える」

ビジョン：「共創する会社」

戦略：「別グループにかっさらわれてしまった部分を奪還する策を提供する」

（途中略）

KPI：親会社からの受託案件　利益率＊＊％（赤字にならないように依頼された部分は極力引き受ける）

テスト戦略：親会社が受注した案件は（顧客から無理難題言われても、スコープが変わっても）納期必達できるよう、自分たちの部分の品質は当然確保、支援に回れるよう提案・支援する

プロジェクト（テスト）計画：

• 出荷時誤り混入率＊＊件/KL
• コンティンジェンシー内は顧客のテスト支援最優先
• 要求分析段階ではF/Sの視点を提案する
• 品質特性は「信頼性」「保守性」観点重視（**ドメイン）

戦略受注でもなく、ただ共創を願う。

なんていい会社なのでしょう・・・。

ここで小説は途切れている...。

急（まとめ）

ほとんどテストに触れていないのにここに書いていいのかなとも思いましたが...

テストをするのも人間、そのプロダクトをつかって恩恵を受けるのも人間。

顧客との共創、組織としての立ち位置、人間として幸せに生きる義務。これらを「三方良し」で達成できるように、戦略を立てて、「納得」して仕事をしていけるようにありたいと願います。

その観点の一つとして、小説の内容はアレですが、大事にする部分をしっかり見定めた戦略・計画を立てられる硫黄な組織になるように、自分たちで導いていきたいなという願いをこめた内容です。

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

※ざーっと構成しっかり考えずに書いてしまったので、後日内容を一部修正するつもりです。

明日は、@mty_mno さんの、テスターちゃんですっ！

参考文献： 

戦略マップ [復刻版]: バランスト・スコアカードによる戦略策定・実行フレームワーク

CMMI標準教本 ~プロセス統合と成果物改善の指針

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

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

adventar.org

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

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

今回の事例について

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

okandayo.hatenablog.com

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

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

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

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

 LT資料は、こちら。

Jasst hokkaidoLT from Asako Yanuki

www.slideshare.net 

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

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

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

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

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

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

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

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

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

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

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

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

今回のストーリー

夏休み初日の朝。

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

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

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

ここが大きな目標です。

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

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

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

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

インセプションデッキ！

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

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

子供たち：え～。人間～、子供～。

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

子供たち：うん！遊びたい！ゲームしたい！

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

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

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

息子：そうだね！

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

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

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

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

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

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

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

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

・つまらない夏休み

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

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

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

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

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

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

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

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

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

そして、Redmine

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

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

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

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

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

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

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

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

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

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

振り返り

振り返り（宿題を終えて）

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

娘：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が１に近い（クローン含有率が高い）ファイルや、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産業にかかわっていく。農業など。
トラクターがデータを取得して、解析して、適切なところに適切な処理をできるようにする、とか。

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

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

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

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

おわり。