メトリクスの示す現象論 ~取得する目的とそのメトリクスとの関係~ 

メトリクスの示す現象論

 

 メトリクスは、何かをおこなったときの効果を定量的に測るツールになるので、「必ず」取得するための目的があります

そして、その目的を支配する法則があるのではと私は考えています。

その法則を見出すには、微分方程式から入るのが一番簡単だと思います。

 

微分方程式

現象が説明変数xと被説明変数yで記述できると仮定します。

簡単にするために、2次元で考えます。

 

yとxの微分方程式では、その間にある変化量を見ることができます。

なので、データは、以下の3つの微分方程式で表すことができます。

f:id:okandayo:20171215224829j:plain

 

それぞれの微分方程式を解くと、右の式になります。

基本形なので、すべてがこれというわけではなく、派生形も存在するということは付け加えさせていただきます。

 

副次的効果?

現象が数式で表せるということにより、以下のような嬉しいこと(笑)もできるようになります。

 

  • 数式から、統計的論理的に背景を検証することができる
  • 標本数が少ない場合には、この論理に従ってランダム関数などを使用して増やす(?)ことができる
  • モデル化されているので、メトリクス層別の判断基準の一つになる

 

 

参考資料

生産性と品質データの解析手法

www.slideshare.net

 

 

テスト対象のリスク度分析(素敵なメトリクス)

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

qiita.com

 

小ネタなので、すぐにできそうなところからご紹介♪

 

テスト対象のリスク度分析の一例を二つほど、ご紹介します。

ソースコードメトリクスを利用します。

 

ソースコードメトリクス

ソースコードメトリクスは、いろいろなツールで取得可能です。

 

その中から、一つ目のご紹介。

皆さんも使われている方も多いと思いますが、

サイクロマティック複雑度

を使用したテスト対象のリスク分析です。

すごく簡単。

一般的に、15を超えると保守性が低い傾向があるといわれており、バグが潜みやすい傾向にあるようです。

なので、以下のような策をとられるとよいかもしれません。

その際にはもちろん言うまでもありませんが、意味があって複雑度が高くなっているのか、それともコードを書いた人のスキルなのか、なども合わせて考慮する必要があります。

 

  • 複雑度が高いコードのコードレビューにはスキルの高い人を割り当てる
  • 複雑度を下げることができるように設計を見直す(リファクタリングをする)
  • ヒートマップなどで、どの関数が複雑度が高いかをみて、IntegTestに厚みを持たせる

 すぐにできることなので、参考になさっていただけると嬉しいです。

 

  

二つ目のご紹介。

 

以下のメトリクスを利用。

  • Essential:単純な条件構造(単純な if-else, while, do-while など)を、単一のステートメントで置き換えた制御グラフにおいて計測した複雑度
  • FanIn:関数に対する入力の数
  • FanOut:関数に対する出力の数

これは、Understandというツール

ソースコード解析ツール Understand | ソフトウェア品質保証 | テクマトリックス株式会社

www.techmatrix.co.jp

 

から取得することができます。

 

EssentialFanin・Fanout(二つのメトリクスを掛け合わせた値)このふたつをx,y軸に取り、散布図を描きます。

このメトリクスのプロットの意味するところは、もう想像がつくと思いますが、関数が複雑なうえに入出力値まで多ければ・・・そうです。ご想像の通りです。。。

ということで、判断基準としては、

Essentialの値が10以上、Fanin・Fanoutが400以上で囲まれる範囲を高リスクゾーンとし、集中的にテストを行う。

ということを一つの事例として紹介させていただきます。

 

以下のスライドの15ページ目でも、ご紹介しています。

 

www.slideshare.net

 

少しでもプロダクトの性質・特性を把握できれば、メトリクスの値と一緒に分析して品質を作りこんでいくことが楽になるかもしれません。

 

このサイトにも、ソースコードメトリクスを利用した分析の事例が掲載されています。

 

understand-jp.blogspot.jp

 

 番外編

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

このメトリクスを取得できるツールは、有償無償だと、私が知っているところでは以下のものがあります。

有償:Lattix (テクマトリックス社取り扱いソフトウエア)

無償:ccfinder(32ビット版しかないかも・・・)

 

取得できるメトリクスはかなりたくさんあります。

また別の機会に、このメトリクスを利用した事例をご紹介したいと思います。

 

Enjoy your Testing life♪

 

Modeling Forum 2017 simple レポート

参加して

先週参加してきたモデリングフォーラムのレポートです。

流れが見えにくいレポートになっております。

資料と一緒に見ていただけると嬉しいです。

それぞれのセッションの資料は公開されているので、閲覧できます。

下のサイトからどうぞ~。

※原田 騎郎様の資料は、掲載されておりません。(2017/11/15現在)

 

 

umtp-japan.org

 

午後の三つしか受講できず非常に残念でしたが、どの講演も、とても興味深いものでした。

 

このフォーラムの前日に参加したJenkinsDaysJapanのとあるセッションで、「これからはビジネスを創造できる人材が特に必要であり、そのスキルが問われる。そのために生産性を上げていく必要がある」と言われていたばかりで、このモデリングフォーラムでも同じ結論が聞けるとは思ってもいなかった。

つながりを感じてさらにワクワクした一日でした。

 

開催概要

◇名称   Modeling Forum 2017
— Society5.0を支えるモデリング
◇会場   TEPIAホール
〒107-0061
東京都港区北青山2丁目8番44号
http://www.tepia.jp/
◇日程   2017年11月10日(金) 9時45分 – 17時45分 (受付開始 9時15分)
◇主催   特定非営利活動法人UMLモデリング推進協議会(UMTP/Japan)
特定非営利活動法人UMLモデリング推進協議会(UMTP/Japan)

  

●AI、IoT時代におけるモデリングとは?

株式会社エクスモーション 代表取締役社長
一般社団法人組込みシステム技術協会(JASA)理事
渡辺 博之

モデリングがどうなっていくのか?
このままうかうか過ごしていたら危ない。今日は警告を発しに来た。
日々の進化が激しくて、もうすでに欧米にかなりな遅れをとっている。日本は頑張る時期にきている。頑張るべき領域は、CPSだと考えている。
第4次産業革命⇒CyberPhysicalSystem
従来の組込みシステムもCPSである。
ただ、どう制御しようかという対象を絞っただけのモデルである。
AIはエンジン・モデル、IOTはシステム・インフラ、ビックデータはモデルの元ネタと考えることができる。
機械をオペレーティングするのはAIになるので、生産性の制約はなくなってくる。そうすると、影響範囲は大きくなる。ヘアーカットなど、日常のものにも波及してくる。
国の方向性と企業の方向性を合わせていかないと負ける一方になる。
そのおかげで、経産省のHPをよく見るようになった。


★これからの時代に求められるふたつの観点のモデル

いろいろな産業が入り込んで来るので、お互いの合意形成・説明責任のすり合わせなどが必要になるのではないだろうか。
モデリングは2種類必要になると思われる。
一つ目は制御するための制御モデル。これは、従来と同じ。機器の制御。
二つ目は、ドメインごとの「こまったこと・うれしいことなどをねん出するモデル」が仮想世界では必要になるのではないかと考えられる。新しい価値の創出である。
今までの暗黙知を可視化してモデル化する。
ビジネス領域、ビジネスを横串したときの価値とか、ビジネスモデルをどうするかということを考えていく必要がある。
様々なビジネスで使えるモデルを整備した後に出てくるのが、モデル選択の基準である。これを話し合う活動をJASAで始める。
UMTPでの活動休止!JASAで組込みIoTモデリングWGをたちあげることになった。興味がある人は参加してほしい。


★これからのエンジニアに期待されること
今後のエンジニアは、ビジネスユニットごとに人間の経験・知識・合意をとりながら、ビジネスを横断した活動が期待されることなのではないかと考えている。
・ビジネスデザインができる人
・システムを俯瞰的に見ることができる人
これが必要とされている。
日本は給料が安いから、いい人材が来ない。

でも、給料上げてきている業界もあるので、
これからそこを起爆材としてのびてくるのではないだろうか。


統計学におけるモデルの役割について:直感・説明・検証

農研機構・農業環境変動研究センター ユニット長
東京大学大学院 農学生命科学研究科 教授 三中 信宏

★モデルを立ててデータを考察する。
データをちゃんと理解しているのか?分析結果に納得できるのか?
人間は、心理学的にとても良い「差のある・なし」を判別できる能力がある。
基本的で有名なものに、分散分析というものがある。F分析・F検定で判断される。
F値というのは、我々にとってはとても直感的にわかるようなものなのかもしれない。
(平均とか)
我々が感じてきたこと・見てきたことを数値化したものなのかもしれない。

 

以下の二つの文献の文言で示されるように、一方は「データそのものから現象をみる」行為と、「ある種のパターン化されたデータのばらつき・組み合わせなどがあり、そこで現象をみる」というものが考えられる。

クラフト・エヴィング商會
データをみて人それぞれの解釈がある<>データの向こうに真実がある

・歴史・レトリック・立証(カルロ・キンズブルグ2001)
視界を妨げる壁<>開かれたまど ゆがんだガラス


証拠を逆なでしながら、それを作り出した者たちの意図をさからって読むすべを学ばなければならない。
データから先を見るには?・・・モデル。モデルで説明をする。
では、データを見たときに、どうやったら説明できるだろうか、納得できるだろうか?
データの持っている特性・特徴を見える化するのがモデル。

データを見て現象を把握するだけでなく、説明するということがこれから求められてくるので、やはりモデル化する能力・見抜く能力というのは必要なものである。

 

★モデルとデータの接点に触る
モデル(共通要因・個別要因)⇒データ(統計的誤差)
単純なモデル、複雑なモデルのどちらを選択すればよいのか?
・モデルの良し悪しの判定(モデル選択の基準)
・データの当てはまりをどう追及していけばいいのか
複雑だからよいというわけではないという判断で使うもの⇒AIC
複雑度の高いモデルは、データの実値を優先に考えるので、値のフィッティングが揺れると「弱い」予測能力になる。

p-valueの使い方にも注意してほしい。0.05というものではなく、より精度を求められる実験などを検証するときには、0.005というより厳密な値を使うことを勧める。

 

●DevOpsにも役立つモデリング

株式会社アトラクタ Founder 兼 CEO
原田 騎郎

 12年前に、モデルを役に立てようという試みをしていた。
ソフトウエア開発で一番危なっかしいのは「ビジネス」。
そこで、「ビジネスをモデリングしよう!」ということをはじめた。


DevOPSも、一種のビジネスのモデル。
素早くすることでリスクを下げる。
反応速度を早くすることで計画を立てなきゃいけない期間を短くする。
リスクを下げる。リードタイムを短くする。スループットを増やす。
1週間・2週間でSWリリースできるのにサーバ3か月もかかるのは、やってられない!

そこから、アジャイルインフラ&オペレーションを考えるようになり、リーンシンキング、ToCなどを取り入れていった。


「もの」と「情報」の流れ図(=ValueStreamMapping)
カイゼンの実行計画を考える際に、現状や未来や理想像を描くのに使う。

これもモデリングである。
見えないものはカイゼンできないならば、みえるようにする。モデルを書く。
現状のストリームの地図を描く。将来のストリームの地図を描く。
変更計画を作り出す。逆流率と直行率を出す。
手戻りの線を矢印で結んで手戻り率を計算する。
ECRS(Eliminate、Combine、Rearrange(QAの人を最初に連れてくる、とか)、Simplify)

カンバン仕事術へつながる。

 

 

 

 

Jenkins Day Japan 2017 レポート

 

先週、Jenkinsのセミナーが開かれた。

テクマトリックス主催の、太っ腹な企画。

その内容の簡単なレポート。

発表資料は、下記サイトからダウンロードできます(入力事項あり)ので、ぜひどうぞ!


日時:11/9(木)9:30~17:00
会場:ベルサール半蔵門
内容:Jenkins Day Japan 2017

 

cloudbees.techmatrix.jp

 

 

コンテンツ:
1.組織横断的な環境でのソフトウェア開発を加速させる、段階的なCI
 (原題:Multi-Stage-CI System to speed up the SW development in a cross-organizational environment)
  Robert Martin 氏 BMW Car IT GmbH SW Project Leader
2.テンプレート、Groovyを用いて、Jenkinsを”Sweet”に
  (原題:Sweeten your Jenkins with template and Groovy system)
  Harald Gottlicher 氏 Robert Bosch GmbH Software Architect
3.テストのフィードバックサイクルを早めて、変更に強いソフトウェア開発を実現
  野中 亮 テクマトリックス株式会社 システムエンジニアリング事業部
4.Jenkinsの生みの親、川口耕介氏が語る(仮題)
  川口 耕介氏  CloudBees, Inc. Chief Technology Officer

 

[全体の感想]


BMWの事例は、大規模でかつ数億行というソースコードをHW込みでテストする環境をCI化しているというすごい事例だった。
その際には、ひとつのジョブの単位の設計をしっかりやらないと、HWのテストまでどういうパイプラインで流れていくようにするかという目的を達成できなくなる。
ジョブの単位の設計はしっかりしないと、結局は手動と同じという結果になりかねない。
Jenkinsの利用により、技術的負債を増やさずに価値をすばやく判断し、ビジネスの創造に時間をかけていかなければならない、という川口氏の講演には、日本と欧米の意識の違いが大きく出ているなぁと感じた。

いや、もうすでにやっている会社さんも多くなってきたが、日本のスタンダードということにはまだなっていない感覚を持っています。

川口さんは、危機感を持ってください、ともおっしゃっていたので、その感覚もあまり間違っていないのかもしれない。

 


[概要]


1.組織横断的な環境でのソフトウェア開発を加速させる、段階的なCI


 ・BMWのHWを含めた開発で行っているCIがどう行われているか、という内容。

  大規模プロジェクトでのCIは、多段階のCIシステムにする必要がある。
  SWアーキテクチャから考えるのが大切。
  部門ごとに分けられた内容を考えるのではなくて、機能ごとに分けられているチームを考え、CIを設計する。
  最初からリリースまで、どのくらい時間がかかるかを測った。
  1人の人のたった一行のコード変更が反映されてリリースするまで、5週間かかる。
  一つのものをリリースするのに、こんなに時間がかかっていたら、担当者はやっていたことを忘れてしまう。
  CIでは、誰かがこけたら(Failしたら)次にいけないようにしている。
  自動化されていない手動の作業は、ソースコードの修正だけ、という状況にしている。
  HWのテストまでを30分以内でやらなければいけないとわかっている。
  これよりもかかるようであれば、さらに細分化する必要があると考える。

 

 ・夜間ビルドとCIの違い
  CIシステムを導入したら、Failがある場合は、必ず次に行ってはいけない。
  働き方の時間を見ながら、何分以内でCIを回す必要があるのかをちゃんと考える必要がある。
  夜間ビルドの場合は、失敗がまとめて報告されるので、切り分けが困難だったりする。ところが、失敗したら次に行かないというCIがあれば、失敗の修正と回復は最小限の時間ですむようになる。依存関係の少ないアーキテクチャを目指すべきである。
  協力会社、自社内での関係等、SWのアーキテクチャや契約もみていかないといけない。
  多段階CIシステムには、専門のCIチームを用意する用意がある。
 
 ・早い開発が何で必要になるのか。
  変更に強い、費用対効果がある(時間を削減=自由な時間ができる)、そういったことをチームで議論し続ける必要がある。


2.テンプレート、Groovyを用いて、Jenkinsを”Sweet”に


 ・テンプレートで特有のUIを作ることができる。
  いろんな商品・製品を扱っている。
  開発者でない人たちもいる。そういった人たちが意識しなくても、勝手に背後で動いている、そういうCIでなくてはいけない。
  Jenkinsを知らないひとたちでも使えるシステムを提供できる。
  ビルドを自動化するのは当たり前だが、例えば、jobをつくるなどのjenkinsの機能も自動化する。
  以下のようなテンプレートをGroovyで作成すると、管理者も楽になる。
  -マルチブランチパイプライン
  -フリースタイルジョブ
  JenkinsFile(groovyで記述)も、変更したらGitで管理する。プロジェクトマネージャがテンプレートファイルを複製してプロジェクトに提供する。
  パイプライン自体が「モノリシック」になってしまうこともあるので、注意が必要。

 

 

3.テストのフィードバックサイクルを早めて、変更に強いソフトウェア開発を実現


 ・変更があるごとにビルドなどのジョブをしかけることで、負債の蓄積も最小にすることができる。
 ・ビルド~テストを仕掛ける単位はなるべく影響範囲が小さいうちに実施したほうが良い。
 ・テスト自動化する象限は第4象限がよい。⇒実践アジャイルテスト
 ・変更を割り振っていって実行を適切に行うもの⇒jenkins


4.Jenkinsの生みの親、川口耕介氏が語る(仮題)


 ・Jenkinsの生い立ち~成長期
  生物と同じで、カンブリア爆発があり、多様性が起こった。進化そのものは徐々に起こる。
  Jenkinsへアップデートセンターを作ったので、プラグインの作成をするコミュニティがどんどん出てきて、利用が爆発的に広がった。

 ・Jenkinsの恐竜期
  昔、ツール整備する人は職人気質。自動化はチーム内でやる作業だった。
  プラグインを組み上げて自分のCICDを作っていた。そこを、ある程度標準な組み合わせを最初に用意する。
  なれて、変化点が見えてきたら自分たちの使い方に合わせた環境を作れるようなプラットフォームにしておく。合わせてドキュメンテーションをしっかり整える必要がある。

 ・現在~未来
  ビルド職人がやるという時代は終わった。ビジネス価値を早く届ける必要がある。
  実験と反復を早くやる必要がある。自動化職人はチームに所属しない。組織としての専門チームで存在しているべき。
  痛みを伴ったデジタルトランスメーションをすることで、中央に生産性向上の専門チームができることが多い。そのチームが会社の開発プロセスを決めていく。
  ビジネス価値の創造にフォーカスしていけるか、が大切である。生産性を上げることで変化に強くなる。すぐに結果などを得られるようになるからである。大規模な会社ではこういった取り組みが必要である。

 ・これからのCIのあるべき姿
  継続的デリバリーをする、そこからビジネス価値を創造する方向へどう行けばいいのか。自動化だけにフォーカスせず、一歩下がって開発全体を見なければいけない。
  パイプラインを作った一つの理由として、視野を広げやすくなることが挙げられる。一歩下がって開発全体を見て、組織を見て、ビジネスを見る。これがこれからに必要となることだ。

 

 

 

クラウドチャレンジ ~働き方どうする?~

 

クラウドチャレンジ

11月某日。私にTOCfEというものがあると教えてくれた、師匠からCLRを学ぶ機会をいただいた。

TOCfEとはtocfeblog.wordpress.com

上記のブログを参照してもらえればわかるが、3つの道具が提供されている。

  • ブランチ:物事や起きてることのつながりを考える
  • クラウド:対立の解消を考える
  • アンビシャスターゲットツリー:目標を達成することを考える

今回は、このうちの「クラウド」を教えてもらった。

 

実際にやってみた

クラウドで、対立する事象を解消させようということを試みた。

わたしが持って行ったお題はこれ。

「今後の働き方、どうすればいいかな?」

これに対して、二つの対立する事象(行動)は以下の通り。

  • このまま時短で働き続ける
  • フルタイムへ戻して、残業もある程する

時短をしていたら残業はできない。

 


f:id:okandayo:20171115211012j:image

 

両者が時間軸上で同時に起こりえない事象という条件の下で選んだ。

 

そこから、なぜなぜ分析みたいに探っていく。

まず、上の図のように、対立する「行動」を上げる。

そして、その行動を達成するのはなぜか、という観点で「要望」を上げる。

「行動」をとる。なぜならば、「要望」となるからだ。

わたしが実際にやった事例は、以下の写真の通り。

検証すると、

「時短で働き続ける」なぜならば、「子供たちの生活リズムを崩したくない」からだ。

という感じになる。

 

f:id:okandayo:20171110200101j:plain

わたしの事例

 

同じように、

フルタイム勤務に戻す」なぜならば、「もっと仕事がしたいから」である。

こんな感じ。

 

「要望」を上げた後は、その両者に共通する「目標」を考える。

ここは非常に簡単に目標を考えることができた。

「家族が幸せになる」

先生によると、この「共通の目標」部分には、「世界平和」とか「幸せになりたい」とかそういったものが来ることが多いとのこと。

 

理由を考える

骨組みができたところで、「行動」⇒「要望」、「要望」⇒「共通の目標」の理由を考えていく。自分が望んでいる理由だ。

いやぁ、いっぱい上がりましたが、先生のファシリテーションがなければ本音は出せなかったです。はい。

フルタイムに戻したいというところでは、「子供かよ!」とおもうような理由も・・・。あとは、上から目線だったり・・・^^;

  • 相方ばっかり残業できてずるい
  • 大人になったときに楽しく仕事ができるように背中を見せたい
  • 自分がやりたいことをできなかったと後悔したくない

など。

 

結局、なんとなく解決策は最初から想像ついていたのですが、こんな感じ。

 

  • 時短を続ける(あと2年しか取れない)
  • 取れなくなることには、上の子が自分のことをできる年齢(11歳)になっている

 

理由を挙げているときに、本心に触れることができてすっきりする ことが、上記の解決策を得るための一番の近道なのかもしれない、とやってみて思った。

 

まとめ

きっと、頭を整理するにも誰かに聞いてもらいたいっていう願望があるし、それはファシリテーターさんが聞いてくれるというところで解消できる。

 

いろいろな理由にも優先度とか余計なことをかんがえちゃうけど、「とりあえずぜんぶまるっとあげちゃえ!」という師匠の言葉をもらえたからこそ、いろんな心をだすことができたんだなぁ、と思ったり。

 

一度やってみると、なんとなくわかった気になってしまう。

今度は、仕事で対立すること結構あるので、やってみようと思う。

 

師匠、ありがとうございました💛

 

恋文  ~WaterFall からAgileへの讃美歌~

 


f:id:okandayo:20171104111121j:image

あきこさん(@akiko_pusu)画

 

僕、48歳、独身、とある会社の課長をやってます。名前はWater・Fall。

うちの課にいる”やばい子”が気になりだして数年。「やばい子」は、A・Girl (A・Gile).

そう、僕にとっては唯一無二の女の子。

年齢差があるので、想いを伝えるかどうかはまだわからない。この年になって恥ずかしいが、やはり怖いのだ。ダメだった場合の負い目を感じながら教育していくことはできないし、でもこの想いはどんどん成長していってしまっている。

今の自分の気持ちの整理として、ラブレターもどきを書いてみようと思う。

一度しかない人生、悔いのないように楽しみたい。

・・・あ。これも、彼女の受け売り・・・。

 

ラブレター

 

僕はあなたを尊敬している。そして、大好きだ。

僕にない素晴らしいものを多く持っている。

突然こんなことを言われて戸惑うかもしれない。

こう思うようになったいきさつ、素晴らしいと思うところについて、出来事を振り返りながら書かせてほしい。

からかいでもなく、誇大表現でもなく、これは僕の素直な気持ちなのだということをわかってほしい。

 

出会い

君が入社してきたのは5年前。

きれいな子だなとは思った。でも、それ以上でもそれ以下でもない。

僕は43歳で、課長になりたてだった。新人が入ってきたのも久しぶりで、ちょっと新鮮だった。

 

入って来て早々、君はいろいろと僕に食い掛ってきたね。すごい度胸だと思ったよ。

君の価値観は、君の生い立ちからきているということを知ったのは、飲み会で二人で話したときなので、この2年くらい後かな。それは、また別の機会に触れて書くことにしよう。

 

とにかく、衝撃的で刺激的だったよ。僕の気質が、すべて綿密に最初にきめて、それをゆるぎないものだと確信してから動くタイプだから。

 

あの時。社員旅行で飛行機に乗ろうとしたときの出来事。君のすばらしさを痛感した初めての出来事だ。

 

僕は課員分のチケットを1か月前から手配していた。

当日にチケットを受け取ると、それは行きの分ではなく、帰りの分のチケットだった。

綿密に計画し、社員旅行費もきっちり見積もってそれに見合う計画を立てていた。なのになぜ?どこでこんな間違いがあったのだ?僕の計画に失敗があるなんて・・・。最初からこんなイレギュラーなことがおこってしまった。

目の前が真っ暗だった。そんな状況の時に、君は、なんていったか覚えているかい?

 

「とりあえず、明日の便を確保してきました!いま羽田にいるし、今日はTDLでもみんなで行って楽しんじゃいましょう!近いし!」

 

「どうすればいいんだ・・・」

こんな気分でいっぱいだった心を、君の柔軟さが、太陽のような笑顔が溶かしてくれた。

僕に反抗するばかりだった君が、なぜ僕のために?と思い、質問をしたね。

「フォローありがとう。なんで動いてくれたんだい?僕のために・・・」

すると、君はまたまた僕の想像を超えた答えをくれた。

「WFさんのためじゃないです。社員旅行は、みんなのものでしょ?ダメなら楽しそうな次の施策を考える。時間がもったいない。みんながしらける時間が長いと、心も離れて行っちゃう。だったら、動ける人が動く当たり前じゃないですか?」

 

これを機に、君が気になりだしたんだよ。この子はただ若いだけじゃない、バカじゃない、ってね。あ、怒らないでくれよ。最初の君の印象が悪すぎただけなんだからね。

 

みんなを大事に、そして柔軟な心

 僕の課は、僕が課長になる前から静かだった。本当に、「静か」。この言葉がしっくりくる環境だった。

中計で中期的(5年程度)の仕事の戦略をたて、年計で次年度の計画を立てる。

その年計に従い、各人がしっかり計画を立てて自分の担当分をこつこつとこなす。

各人が専門性をもってとがった人たちなもんで、領域をおかすことなく仕事をこなしていた。

 君が2年目に入り、一年間の流れがわかったころのできごとだ。

 また、その流れをぶった切るような一言を君が言い放ったんだよ。

 

「仕事を縦割りにするんじゃなくて、もっとかかわりあいませんか?ちょっと、無駄がある気がしませんか?」

 

何を言っているのか最初は意味が分からなかった。

君が、ホワイトボードになにやら書き出した時には、びっくりしたよ。

一年間、みんなの仕事の内容をここまでしっかりみていたんだな、と。

新人という立場を利用して、皆にいろいろ質問をしていたのは、みんなの仕事を把握するためだったんだな、と。

 

やっている仕事の手順、内容を細分化し、重なっている部分を指摘した。

「ここが無駄です。scrumさん、XPさん、一緒にできることありますよね。毎日残業してもったいないです。声を掛け合って、一つずつ終わらせていきましょう~!細かい事務作業は、私が最後に文書化したりしますから!」

 

それから、「静かな課」という印象はなくなった。

会社が、「仕事場」ではなくなった。「学校」・・・?違うな。

「共生の場所」。そう。みんなで楽しく笑いながら仕事をする場所に変わった。

君がいると、いつも笑顔が満ち溢れる場になる。

 

本当に・・・。感謝しかない。

ありがとう。

 

これだけでも、君の魅力ははちきれんばかりに僕の心からあふれて止まらなくなる。

君と飲むようになって、君を知って・・・。

そこからのことはまた別の機会に振り返ることにするよ。

 

最後に、君が言ってくれたうれしい言葉で締めることにする。

「WFさん、あなたが今まで築き上げてきた地盤があるから、変化することができるんですよ。確固たる信頼と協調。この土台がなければ、柔軟性なんてくそくらえなんですよ!」

 

ありがとう。僕は僕のやり方がしっくりくるところでしっかり頑張れる。君がそう言ってくれたから。

 

また明日。会社で会おう。

 

 

アドホックな探索的テスト?

昔の経験を探索的テストで思い出した。

 

20年前に遡る。結構規模のでかいプロジェクトのテストチームに配属されていた。

 

新人のときにいたテストチームで、とある機能の結合テストを手伝っていたとき。

いつも、バグ多めのプログラムを描く方がいた。

その方の機能テストをした時、担当したテストケースの一部では、たまたまなのかほとんど出なかった。なんで出ないのかな?と思って聞いてみたら、通信する相手先が、かなり優秀な…最高のプログラムを描く人の機能だった。

想定して、色々なエラー処理を入れていたらしい。

苦手とする機能の実装を予想して、どんなデータが来ても対応できるようなコードを書いていたそうな。

すげえと思った。

 

でも、バグ多めの人の機能で出ないのはおかしい…前はこんな感じの操作をしたときに出たよな…と、規格書に、書かれていないことをやったら、ビンゴ。

すぐに機能担当者に報告した。

その周りの実装を再チェックしてもらった。

 

自分がテストの担当をする機能のコードを描いた人たちの癖は、なんとなく掴んでいた。どういうエラーを毎回出すか、どういう処理に弱いのか。

 

担当者ごとの弱点マップみたいなものを書いて、テスト依頼される前に配ったりしていた。

 

当時のプロジェクトでは、テストチームが関わるのはシステムテストから。たまに工程が押してきたときは、ヘルプで結合テストから入ったりもした。

なので、弱点マップを渡すタイミングには悩んだりした。自分たちが関わるときに渡すとすごく嫌な顔をされるけど、単体テストをやっているときに渡すとニコニコしてくれる。これってなんだろう?っと。

 

20年経って思い返すと。

この弱点マップって、テスト観点だったり、探索的テストのチャータなのかもしれないな、と。

 

新人の私は、境界値分析とか同値分割とか、テスト技法と言われるものは何も知らないおバカさんだった。

V字とか、フロントローディングとか多分なかった時代かなあ。

 

という意味を考えると、アドホックな探索的テストをやっていたのかなーと思う。

根拠はないけど(=アドホック)、この人はここでよくバグを出す(=チャータもどき?)から、叩いてみよう(=探索的?)、というもの。

 

こういうテストをする人、多分いるんじゃないかなーとも思う。

技法を知らなくても感覚で捉えた内容は、結構間違っていない。

その感ってやつの根拠・仮説を証明して、きちんと分類できるようになるためにテスト技法をそこから勉強した気がする。

こんなきっかけも、あるかな、と思った振り返りでした。

 

とりとめもない内容を読んでくださってありがとうでした!