2018年振り返り ~社外と自分~

 

だいぶ、忘れている...思い出しながら追いかけて書くのが大変...。なので、こっそり公開。

どこから振り返ればいいか...とりあえず、なにをやったか列挙と感想を書いてみるか。
かなり個人的な感想。自分のための記事です。
半年ごとに今年はインセプションデッキ更新とふりかえりを入れていこう...

 

2018ふりかえり
Redmine
・ソフトウエアテスト系

 

1月
Redmine
はじめたのはこの月かららしい。初顔合わせが2017/12なので、そんなものか。1年前か。
え、まだ知り合ってから1年か!!!まじか!(驚愕)
1/13、川崎産業振興会館の和室で初開催。何を話したかは全く覚えていない(笑)
Redmineをどうやってつかってる?とか、愚痴とかそんな流れだったかな...

 

2月
Redmine
でぶさみ、初参加。雅叙園すげーという小並感。こばさん登壇するので応援へ。
あんな大きな会場で安定の喋り、こばさんそんけーしかないっす。あきこさん、りょうまさんと初顔合わせ。会えてよかった。

 

3月
ソフトウエアテスト
3/7-8、JaSST Tokyoに参加。2日休暇取って。
ここに参加しないと1年が始まらないような気がしている。個人的に。
Miccoさんや、和田さんの自動化の話を聞いて、ちょっといろいろ思うところがあった。
そして、JaSST Tokyoはいろいろな人が集まるので、久しぶりに会えたり、はじめましての方とお会いできたり。目的はたくさん。
基調講演

togetter.com

招待講演

togetter.com
番外編

togetter.com

 

Redmine
さんぴあんで勉強会。なんとなくだけど、ここあたりで、SQiPに一度だしてみようか、という話になった気がする。マイルストン決めて、ゴール決めて。なにも定まらないままダラダラやるのは嫌い。

 

4月
Redmine
SQiPに提出する内容の最終調整。話の流れとかきめたかなぁ。
集まりだして半年もたってないけど、ゴールまで見えたのは、抱えている問題意識と、それをどうしていきたいの?っていうところの想いが
一緒だったから、迷走しながらもひとまず、出すことができたんだよなぁ。すげぇ。まどさん、こばさん、ありがとう。
そして、提出するにあたってレビューをしてくださった方々、本当にありがとうです!
特にあきぴーさん、感謝!!

 

ソフトウエアテスト(?)
褒め活やってみたお。8人も集まってくれて。やり方もわからないまま、手探りでやったけど、参加してくれた人たちはみんな「その場を楽しむ」ということを目いっぱいできる人たちなので、何の心配もなかった。
ふしぎな言葉が生まれて、それがいまだに合言葉に(?)なっている気がする。(笑)
このとき、やってよかった。プライベートでの発達障害親の会の勉強会のインプットにもなったし、2回目にもつながっている。何が大事なのか、ちゃんとつながっているっていう確信が持てた。

 

okandayo.hatenablog.com

  

5月
ソフトウエアテスト
とてかに参加。同行者を募り、7人あいのりの日帰り旅行をした。行く前からテンション高めで、最高でした。「メンバー」ネタで大盛り上がり...w
とてか自体も、期待通り「あのチーム」の話を聞くことができてますます理想像がかたまった。みわさんの、テストの地図(本物!!)も見せてもらえてほくほく。帰りの車では、なそくんの会社に対する熱い思いが聞けてなんかうれしかった。

togetter.com


JaSST Tohoku参加。
どうしてもワークショップ参加したくて。最初から最後までHayst法祭り。
1日しっぽりどっぷりつかることができたので、Hayst法、なんとなくふわっと理解できた気がする。JasstTohokuバージョンの理解。
実際に会社で個人的にしか試していないので、キワをねらえ的なプロダクトで試したい。
クリティカルなドメインのやーつ...あれだな...。
憧れのあきやまさんとツーショットを撮れたのは胸熱。腕もらっちゃいました...^^;

togetter.com


Redmine.Tokyo
仙台から朝移動で午後に参加。
ここも、どうしても聞きたい事例があった。Jaxaの運用。なんか、いままでどれだけテキトーにやってきたのかを思い知らされてちょっと凹む。でも、レベルやチームのサイズ感にあった運用でいいんだ、とも納得できたので、やっぱりチームレベルだよな~っていうところに落ち着いた。結局は、みんなそこにつながるのだ。

togetter.com


6月
ソフトウエアテスト
・ロジックブランチ勉強会。
しずか先生をお招きして、事例をもとにブランチを考える会をやった。みっきーさん、ゆきちゃん、ありがとうございました。自分の作業と、求められているゴールと。その辺の話が熱かったですね。
みっきーさんの京都ネタが面白くて、いまだに忘れられない。自分の修学旅行でみたものは...!!


Redmine
発表スライドを作るにあたっての流れに言及しはじめたころ。「さくせん」ネタに踏み込みだした。実務や家庭でもこの「さくせん」を意識していたから、話しやすかったなぁ。


7月
Redmine
ここで、SQiPでの資料の「作戦名」が固まった。ある程度の内容はきまったかな、という感じ。このセットと、やり方の簡易セットみたいなものがあるといいよね、という話になったけど、発散して終了~w


8月
Redmine
SQiP前資料ブラッシュアップ。夏休み前にある程度のたたき台をつくったけど、事例をいれてなくて、その話を。発表のプロが二人も仲間にいるので、すごく安心感があった。私もがんばらなきゃなぁ。
わかりやすい話し方って何?っていつも思う。
緩急つけて、反応見ながら注目点を絞って...なんてことができる人たち。すげぇ。そういうアドバイスもらっても...「わかった」と「できる」は違うのだッ!(泣)


9月
ソフトウエアテスト
地震で、JaSST Hokkaidoが中止。(この時は中止と発表された)
大きな地震。とにかく、関係者のみんなが心配だったし、精神状態も心配だった。
でも、SQiPで元気な顔を見ることができた人も何人かいた。すごく安心した。

 

Redmine

・SQIP

昨年からいろいろと議論してきた内容の途中成果を発表した。
その後しばらくは、反応なかったけど、今年に入ってから、関連の話をする機会が増えた。
社内でも、社外でも。やってきてよかったと思った。一緒にやってきた仲間に本当に感謝。

 

・Lychee Redmineユーザ会
これは楽しかった。特に、EPGやPMOといったスタッフ目線での運用、活用、保守、展開の話が聞けたのがよかった。ユーザ目線の発表のほうが減ってきているのかなぁ。
「どうすれば・どうやれば、うまく軌道に乗るのか」という観点が増えてきた気がする。管理者目線でほしいと思うダッシュボードをリリース予定とのことで、楽しみだなぁ。


10月
Redmine
ちょっとだけ、燃え尽き感がある小休止っぽい感じだったかなぁ。さくせんで、ある程度うまくいきはじめた場合はどうなっていくか。その状態を維持できるように、リスクに先手を打って予防型の運用にいくよね、と。
そうすると、人間工学、心理学、ソフトウェア工学...いろんな文献につながっていくんじゃないか、という危惧を少し感じた。一通り見ることは厳しいから、目にした・聞いたことがある・これから目にするものは、タグをつけて頭の中に入れたり、メモを残したりしていっている。
どこでどうつながるかわからない。いつでも取り出せるように、広い視野で見ることができるように。

 

ソフトウエアテスト
・テスコンOPENクラスチュートリアル
にしさんの熱い講演にひさしぶりにワクワクした。
「テストの意図」「テスト目的」「テストフレーム」「テストレベル」「テストアーキテクチャ」「テスト観点」「テスト計画」「テスト戦略」「テストコンテナ」...
たくさん用語がはいって軽い混沌世界とタグが頭の中で走り出す。SPECの当麻の習字バラマキが再現された感覚。
テスト観点はテストの意図。ここだけでも、だいぶ理解が進んだ。正解はないけど、きちんと考えるために大事にするところは、そこなんですねぇ。

togetter.com

 

11月
JaSST Hokkaido参加。
もてるモデル、RDRA。神崎さんの本はだいぶ前に買って読んでいたが、読むだけで実践したことがほぼ皆無に近かったので、ワークできたのは本当に良かった。
一緒にチームになった人たちが、話を振ると積極的にいろいろアドバイスくれたり、議論してくれたりして、ワークの時間はあっという間だった。ラストまでたどり着かなかった...--;
同じ会社の後輩くんで、RDRAに非常に興味を持っている子がいて、誘ったけど業務でこれなかった。来年(もう今年)のやつは、一緒にいけるといいなぁ。

 

Redmine
・第15回redmine.tokyo
「ツールとプロセスとスキルとマインドだな」
akipiiさんたちとTwitterでやりとりしていてたどり着いた4種の神器(?)。一つ多いんだけど...
ツールとプロセスとスキルはよく言われるけど、ゴールを一緒にしてその方向へ走っていくという「覚悟」は「マインド」という言葉になるよなぁと思う。川口さんの言葉「パッションスキルスモールチーム」の「パッション」だよなぁ、と。
なんとなく、見えてきた気がする。

togetter.com


12月
Redmine
形式知暗黙知、個人ーチーム」これで二次元マッピングするような話の流れになって...
結局は、PM✚TMと同じだよなぁ、という話になった、気がする。
来年はどこに向かってマイルストン設けていこうかなぁ、という話もした。レベルごとの導入セットかな。目指せ、海外!

 

後日、もう少しきれいに書き直す。たぶん。

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

わんばんこ!(ふるっ!)

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

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

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

 

 

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

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

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

一度しかないこの一年。

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

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

 

地図を描く

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

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

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

 

自分のありたいすがた

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

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

そんな人でありたい。

 

自分軸

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

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

大事にしていきたい軸

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

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

 

2018振り返り

やったこと

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

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

(ほかにもあったかな..)

 

わかったこと

子供

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

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

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

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

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

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

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

あと、きわめつけは。

「ま、いっか!」です。

 

親の会

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

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

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

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

 

次にやること

子供

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

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

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

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

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

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

 

親の会

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

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

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

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

 

ゴール

望むことはただ一つ。

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

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

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

 

 

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

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

こんにちは!

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

qiita.com

 

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

  

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

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

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

 

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

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

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

 

目次

 

 

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

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

 

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

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

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

 

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

いいかえると・・・

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

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

 

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

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

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

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

 

 CMMIレベル5 OPM

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

OPM=組織実績管理

www.cmmiconsultantblog.com

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

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

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

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

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

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

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

にあると思っています。 

 

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

(森崎先生、小説お借りしましたw)

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

 

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

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

 

その中でも、

ミッション:「自分たちの会社の利益を確保!(存続する)」

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

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

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

(途中略)

KPI:親会社からの受託案件 利益率**%(赤字にならないように依頼された部分は極力引き受ける)

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

プロジェクト(テスト)計画:

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

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

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

 

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

 

急(まとめ)

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

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

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

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

 

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

 

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

 

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

 

参考文献: 

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

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

 

  

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

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

 

 

インセプションデッキと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。

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

 

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