三という支配からの考察 ~redmine.tokyoについてちょっと考えた~

三方良しの「三」とは?というブログを前回かいてから、「三」という数字..

世界を支配する「三」という存在に脳をジャックされてしまった。(中二的)

 

okandayo.hatenablog.com

 

 

その脳の状態のまま、勉強会のあり方についてちょっと考えたので、その考えをメモ。

ちょうどいいタイミングで、redmine.tokyoがあり、仲間も同じようなこと(?)を考えていたようなので、ちょっとうれしかった。

分科会っていう感じで分かれてもいいよね、という流れ。

 

以下が、なんとなく考えたメモ。

Redmine.tokyoは、Redmineがあるからうまくいく”

ちょっと汎化すると、ツールがあって、勉強会ではそのツールの周りを取り巻く全てを学ぶということと考える。
それは、人間が人間である所以である、喋る、考えるってのをふんだんに使う領域。
ビューを変えて、Redmine.tokyoが、ツール(Redmine中心)ではなく三種の神器の三つのうちの他の二つ(スキルとプロセス)なら、きっとここまでうまくいかなかったんじゃないかなぁ、と、想いを馳せた。
Redmineエバンジェリスト会(分科会)では、ツール以外の二つの観点を中心とする議論をしている。で、それが発展してきたのは、ある程度クローズドだから。
オープンで多様性、母集団がでかい勉強会だと、発散するところなのかなぁ、と思う。
Dockerとかrubyとかも、手段の勉強会になるのかなぁ、と。スコープを限定する要素。

勉強会のあり方とかも、ある程度この法則使うとあるべき姿が見えるんじゃないかと思った。見るべきビューって、この3つに集約されるんじゃないのかなぁ〜と。。

 

もう少し具体例をいれて、考えを突き詰めていきたいなぁと思ったので、メモでした。

 

なぜ「三方よし」の「三方」は「三」なのか

きっかけ

あきやまさん、安達さんと、SaPID(※1)について話していた中で、ふと不思議に思ったことがあった。

※1 SaPID(Systems approach based Process Improvement methoD

okandayo.hatenablog.com

 【なぜ「三方よし」の「三方」は「三」なのか】

 

sanpoyoshi.net

とてつもなく哲学的で心理学的で、つかみどころも無い現象・現実をおいかけることになるのではないだろうか?そんな疑問も脳裏に走った。

しかし、こういう疑問を一つずつ考えていくことは個人的にとても好きだし、観点を広げていくことで、(言いすぎかもしれないが)森羅万象の理論を把握するところに行き着くのではないか、と感じている。考えることをとめるのはもったいない。人間なのだから。

 

目次

 

具体例を考える

本題に入ろう。
疑問を改めて掘り下げる。どういう観点で追いかけたらよいのだろうか?

具体例→仮説を立てる→検証→考察 ですかね。やはり。

 

熟語の例

三方よし、の「三方」があらわす「三」と同じような意味を使った「三」を用いた慣用句・熟語などを考えてみた。
三権分立、一月三舟、一心三觀、三舟の才、一行三昧(~ざんまい)、などなど。
それぞれの意味をみてみよう。

  • 三権分立:権力の濫用を防止し、国民の政治的自由を保障するため、国家権力を立法・司法・行政の三権に分け、それぞれ独立した機関にゆだねようとする原理。
  • 一月三舟:仏道は一つであるのに、衆生しゅじょうの受け止め方で、種々の意味に解釈されるたとえ。止まっている舟から見る月は動かず、南へ行く舟から見る月は南に動き、北へ行く舟から見る月は北へ動くように見えるということ。
  • 三舟の才:詩・歌・管弦のすべてにすぐれていること。三船(さんせん)の才。
  • 一心三觀: 天台宗で説く観法。 空(くう)観・仮(げ)観・中(ちゆう)観の三観を同時に備えもつこと。すべての事物がそのまま仏教の理法にかなっていることを体得すること。 円教の三観。
  • 一行三昧:一つの修行方法に専心すること。特に念仏三昧をいう。

 

具体例の背景?

たまたま、趣味嗜好により、仏教系の用語が並んでしまったが(汗)、それぞれで「三」の意図するところには、
多様性があり、さまざまな観点から見るべき、ということや、事象を構成するものは3つ「技能・技術・実現する道具/対象」なのだ、ということがあるのでは、と思われる。
「自然・世の理」を「安定(最上の状態)」へ昇華させていく動きを表現しているのでは、と思った。


では、「安定最上の状態(at one's best)」とはなんだろう。


安定する、とは?どういう状態だろう?

あんてい【安定】
[名](スル)
1 物事が落ち着いていて、激しい変動のないこと。
 「心の安定を保つ」「物価が安定する」
2 平衡状態に微小な変化を与えても、もとの状態とのずれがわずかの範囲にとどまること。「安定のいい花瓶」
3 物質が容易に分解・反応・崩壊しないこと。「この元素は安定している」

上記をみて、なんとなく納得した。そうか、これか。
「ズレ」が生じても、「平衡状態」に戻せる。崩壊しない、本質の意味するところへ戻そうとする力を働かせ、その状態へ遷移させる。
この、小さい単位が、「3」だな、とうっすらと感じてきた。

 

検証する

”「ズレ」が生じても、「平衡状態」に戻せる。崩壊しない、本質の意味するところへ戻そうとする力を働かせ、その状態へ遷移させる。”

本当にそうなのか?

 

力学的観点から(自然原理から)

「三方」ということばが表すとおり、「方角」「方向」が3つ、とその言葉は表していると考える。ベクトル、と捉えても良いのではないだろうか。
「もの・こと」の安定、「平衡状態」に戻す「力」。ズレが継続的に発生すると、ある地点からどんどん遠ざかっていく。らせん状にどんどん広がっていくイメージが自分にはある。


ここで、「力のモーメント」を考えてみた。

 力のモーメントとは
 物体を回転させようとする作用のことを「力のモーメント」という。
 例:てこの原理、滑車の原理

 剛体を回転させようとする能力は、力の大きさFだけでなく作用線と回転の中心との距離rにも比例する。
 Fが大きいほど、rが長いほど、剛体を回転させようとする能力は高い。
 物体を回転させようとする能力を力のモーメントNといい、Fとrの外積で表す。
 外積なので、力のモーメントはベクトル量となる。
    N = r × F

 物理解体新書より

www.buturigaku.net

考察

この観点において、考察したことは、「ズレ」が生じた「力」を打ち消しあい、
「平衡状態」に戻すことができるベクトルの数が、「3」である、ということ。
2点では、力が強い方へ押し流されてしまう。そこへ、もう一点から支える力を作用させると、「平衡状態」になる。3点の合成ベクトルは、「逆」「打ち消しあう」ではなく、広がりを見せる。
必要な観点を広げる力が作用するのではと、かなり強引な結論かもしれないが...。
2点の場合は、打ち消しあう力が作用してしまう。
なぜなら、「つりあう」のは、逆向き・同じ大きさのベクトルであるためである。


心理学的観点から(自然原理原則の力が及ばない側面から)

 

心理学というのは、「「人間というのはこういうものだ!」というのを追求するもの」と言われるらしい。

人間の存在...関係の基本構成としては、一人・二人・複数になるのでは、と思う。

これは、人間の関係性は二人までならばベクトルは双方向で二本だが、人数が増えるに従い、複雑度が増す。俯瞰して制御する労力・スキルは格段に違ってくる。

三方よし、が意味するところは、【「売り手」「買い手」「世間」...売り手の都合だけではない、買い手のことを第一に考えた商売と商いを通じた地域社会への貢献をする】というところ。

双方の損得だけで考える、マウンティング・勝ち負けの世界ではなくて、その先にある幸せを考えよう、ということですよね。自分がだいすきなPayForwardの思想。

自分と「相手」。相手が一人なのか、複数なのか。相手が複数になったとたんに、最小単位は「三」になる。

 

ここから先は発散しそうなので、このツイートで...
(ここまで書いて疲れてきた)
もし機会があれば、もっと掘り下げて考えてみたいかも。

 

 

 

 

結び


結局、もとめるところは「花してはりまんの?」であり、お互いにそれを享受しあうところなのではないだろうか。

「花してはりまんの?」と言う言葉は、「存在が花をしている」の言い換え。

「そこに在ること」、「秩序をもった"存在の本質"」を喩えている言葉で、「五感がなくなり存在感だけが残る」を意味しているとのこと。

否定しあうのではなく、秩序をもった存在として認め合って、自分だけじゃなく、向き合う相手が「複数」であっても、本質は変わらない。ここに、最小単位として「三」がでてくるのではないかな、と思う。

 

「三」という数字は、自然原理からも、最小単位としてもっともな数字だと思われる(上記検証だけでは到底足りないが(汗))。(毛利家の3本の矢とか?トライアングルとか?)

心理学(?)的にも、前述のとおり、人間の関係性は、自分と「相手」。相手が一人なのか、複数なのか。相手が複数になったとたんに、最小単位は「三」になる。

...という結論を持ちました。

 

心理学だろうが、物理学だろうが、普遍的な考えは、本質は変わらない。
世界は厳しくつらいだけじゃない。きっと、楽しくなる普遍的なものがそこにはあるのでは、と。
いろいろ調べたり考えたりする中で、ひとつひとつのの観点が本当に面白いなぁと思った。(小並感)

この考えは、あくまでも個人的な観点からなっとくしたものなので、「こんな考えもあるよ~!」というものがありましたら、ぜひアドバイスくださいませ!
読んでくださってありがとうございました。

 

参考記事等

あきやまさんの記事

note.mu

三について具体例をかんがえた時の参考記事

www.mikkyo21f.gr.jp

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  )です!バトンタッチ!