anahiappiki
http://w.atwiki.jp/anahiappi/
anahiappiki
ja
2017-01-09T06:30:46+09:00
1483911046
-
レンガアプローチ自作
https://w.atwiki.jp/anahiappi/pages/40.html
2017-01-09T06:30:46+09:00
1483911046
-
PC遍歴(1992~)
https://w.atwiki.jp/anahiappi/pages/38.html
2016-07-16T02:26:44+09:00
1468603604
-
実家の風呂の要件
https://w.atwiki.jp/anahiappi/pages/39.html
*実家の風呂の要件
**実家の風呂について
実家のお風呂は鏡の位置が変です。
#image(IMG_4652.JPG,width=400)
これじゃあ顔や体を洗うときに鏡で顔や体を見られないじゃないですか。
間取り図っぽく表現するとこんな感じ。(図1)
#image(無題.png,width=300)
これ、いま窓があるところに鏡が置かれるべきなのではないでしょうか。
そして窓は別の場所、例えば下図のように配置されるべきだったと思います。(図2)
#image(無題2.png,width=300)
**なぜこうなったのか
実家が建ったのは20世紀最後の年である2000年、私が高校生だったときです。
地元の小さな建設業者(もう潰れた)に建ててもらいました。
両親曰く、設計と実装(実際に造られたもの)が異なるわ、後から追加請求はあるわで散々だったようです。
曰く、この風呂の窓もその一つのこと。
こちらが提示した要望は、&bold(){換気のために大きめの窓がある}ということ。
また、風呂の配置は家の角で、広さは0.75坪(一軒家にしては小さい)ということについて、業者と合意ができていました。
ん???
これ、要望を出した側の無知のせいなんじゃないか?
- 在来工法の木造住宅の場合、家の角には通常筋かいが入るため、窓を設置できません。(図2は無理ということ。)
- そこそこ大きな窓を設置しようとしたら、今ある位置(図1の位置)にしか配置できません。
- 0.75坪のユニットバスの場合、入口の場所が決まると、自動的に浴槽の位置が決まり、さらにシャワーの位置も決まります。
こう考えると、いまの位置に窓があるのは、大きな窓が欲しいという要望を満たしていて、
風呂の配置や大きさも&bold(){要件通りで問題}なし、ということになります。
**どうすればよかったのか
たぶんうちの両親の無知(無関心?)が背景にあるわけですが、
無知に対して、&bold(){副作用が伝わるように}説明しなかった業者にも落ち度があるでしょう。
あと当時の私の無関心もちょっと影響している。
大きな窓じゃなくて縦長の小さな窓なら、図2の位置に配置できたかもしれません。
「大きな窓を置こうとすると、どうしても筋交いの関係で図1の位置になってしまって、不便ですよ。」
と、建設業者から一声あれば変わっていたかもしれません。
**教訓
構造や仕組みを知っている人は、そのあたりに明るくない顧客に対して、構造や仕組みの観点からその要望を実現するときの副作用を示しましょう。
お医者さんや薬剤師さんはそういうことをちゃんとやっていますよね。
2016-07-16T01:36:20+09:00
1468600580
-
PPTのノート欄の文字数をカウントする
https://w.atwiki.jp/anahiappi/pages/37.html
2016-03-20T15:04:40+09:00
1458453880
-
日記/2016-03-19
https://w.atwiki.jp/anahiappi/pages/36.html
2016-03-20T14:32:07+09:00
1458451927
-
家を建てる(希望通りの家を建てるために)
https://w.atwiki.jp/anahiappi/pages/35.html
2016-01-26T01:17:19+09:00
1453738639
-
家を建てる(土地購入編)
https://w.atwiki.jp/anahiappi/pages/33.html
2016-01-25T23:55:44+09:00
1453733744
-
家を建てる(要件定義〜設計編)
https://w.atwiki.jp/anahiappi/pages/34.html
2016-01-25T07:42:09+09:00
1453675329
-
SQuBOKと人材育成
https://w.atwiki.jp/anahiappi/pages/32.html
*SQuBOKと人材育成
読者のみなさんメリークリスマス!
先日サンタクロースから私の息子のプレゼント配送を請け負ったのですが、
電話会議とか、この記事の更新に精を出してました。
**SQuBOKの認知度はいまひとつ?
今回、読破会ではSQuBOKを読み切りましたが、○○BOKで有名なものといえばプロジェクトマネジメントの知識体系であるPMBOKです。
私も、この業界に入って最初に知ったBOKはPMBOKでした。
仕事柄、PMBOKに絡んだプロジェクトマネジメント教育などはよく目にします。
SQuBOKはどうなんだろう?ということで、少しまとめます。
||SQuBOK|PMBOK|
|関係する資格試験|[[JCSQE>http://juse-sqip.jp/jcsqe/]]|[[PMP>https://www.pmi-japan.org/]]|
|受験資格|誰でもOK|かなり長い期間のPM経験が必要|
|対策セミナー|少しある|たくさんある|
|資格の維持|失効しない|研修を受け続けないと失効する|
|資格の実施団体|日本の団体|米国の団体|
PMPはIT企業でも所持したい資格の一つとしてよく認知されています。自分の知る限りでは、維持するためのセミナーもいろいろなベンダがたくさん実施しており、とても盛んな印象です。
それと比べるとJCSQEはそんなことなさそうです。定量的に受験数など示せればいいのですが、そんなことしなくても明らかではないでしょうか。
私もソフトウェア品質やソフトウェアテスト系の研修を受け持つときに研修生に聞くのですが、SQuBOKやJCSQEを知る人は(僕の客には)ほとんどいません。だから受けに来ているのかもしれませんけど。&font(white){でも品質第一をうたってる企業グループのくせに、参加者のほとんどが知らないのは酷いなぁと思うわけです。}
**ソフトウェア品質の教育を見直したい
資格を広めるでも何でも良いのですが、ソフトウェア品質についてもっと体系的に学んで、知識を実践していくという風土を醸成していくべきだと思います。せっかく先人たちが築いた素敵なメソッドやらテクニックやらがあるのですから。
そのために私として取り組みたいのは、ソフトウェア従事者に対するソフトウェア品質の教育を見直していくというものです。
アーキテクト育成が私の周りでのキーワードになってます。それはもちろん取り組んだほうが良いことだと思います。
ですがその前段として、ソフトウェア品質についてこれまでどんなことが考えられてきたのか、一通り知っておく必要があると考えます。
なぜなら、アーキテクチャは品質要求を実現するためのものなのだから。
なぜMVCパターンを使うのか、なぜ構造化設計をするのか、なぜ開発フレームワークを使うのか、なぜイベントドリブンなのか・・・、そういった説明を筋道一つ立ててできないとすると、アーキテクチャの知識だけ被った似非アーキテクトだと思います。
偉そうに言ってしまってごめんなさい。私もただの研修インストラクタですから、どっちかというとその類の人です。
ソフトウェア品質業界は資格ビジネスを展開すべき、というわけではありません。
PMに関していえば、PMP保持者がいてもうまく回ってないプロジェクトがたくさんあるわけですし。
(まぁこれについては、高いお金を会社から出してもらって維持してる人はもっと頑張れよって感じです。)
ソフトウェア品質の教育を見直すとして、取り組みたいのは次の点です。もちろん業界全体を再構築してやるというような大それたことをする気はなくて、自分の手の届く範囲で見直していくということです。
- 国産のソフトウェア品質技術について教育の中で触れる。
日本の社会風土のなかで育ってきた日本固有の技術を知らずして、輸入品ばかり使うのはどうかと思うわけです。国産品、輸入品の良いところ悪いところを知ったうえで使い分けるべきです。
- 技術を学んだ人がひとまずそれを小さく回す場を用意する。
テスト設計コンテストなんかはまさにそれにあたると思います。セキュリティ分野、プログラミング分野ではこういったコンテストが活発ですよね。
**おわりに
SQuBOKにはソフトウェア品質を取り巻く古今東西の技術がたくさん詰まっていますが、それを広く知ってもらうための教育などの施策が伴って初めて本当に役立つと言えるのだと考えます。
一方で、SQuBOKを広めるための施策はまだ不十分だと考えます。
技術は人に依存しないものですから、自ら技術を求めて勉強する人しか使えないという状況は、技術教育を提供する身としてはまだ教育方法に改善の余地があると思うところです。
やる気のあるやつだけ掬えばいいじゃないという意見もあるかもしれませんが、教育者としてそれではプロとは言えません。
今回の読破会のように、勉強会後はお酒も飲みながら楽しくなれるような場が誰にでも受け入れられるようにできればいいなぁと思う次第です。
ということで、次回がAdvent Calendar最終回です!
2015-12-24T23:40:58+09:00
1450968058
-
素人とSQuBOKの話をしてみた
https://w.atwiki.jp/anahiappi/pages/31.html
*素人とSQuBOKの話をしてみた(お話風)
**まえがき
私はSQuBOK読破会メンバだ。よくSQuBOKを持ち歩いている。
ある日の昼下がり、SQuBOKをカバンに入れたまま友人女性のところを訪ねた。
1歳の息子を一生懸命面倒みている子育てママだ。
**登場人物
Aさん(29) 人妻
趣味:ヨガ、ウォーキング、自分磨き
好きな色:イエロー
欲しいもの:マイホーム
着いて間もなく、お茶とお菓子を出してもらった。
A「安い紅茶でごめんね。」
たぶん本当に安い紅茶なのだろうが、ティーカップまでよく温まっている。
子育てで忙しいだろうに、こういうところまで気が利くのはさすがだ。
母子と他愛もない会話をしていたら、母のほうがこう言ってきた。
A「何その分厚い本?」
私「あ、これのこと?」
どうやら分厚くて僕のカバンからはみ出ていたよう・・・
私「SQuBOKっていう、ソフト品質に関する本だよ。」
A「なんでそんなの持ち歩いてるの?」
なんででも良いじゃないか・・・
そう思いながら、
私「仕事柄、ソフトの品質についていろいろ勉強しとかないといけなくてね・・・」
とりあえず適当に答えた。
A「ふーん、大変ね。」
うん、適当に答えたのがバレバレらしい。
適当に返されてしまった。
話を戻そう・・・そう思っていた矢先、
A「実は私、ソフトの開発したことあるよ。」
私「え、そうなの?」
A「産休に入る前はネットワークスイッチの制御ソフトの開発をしてたんだ。」
これでは素人とSQuBOKの話をしてみたというタイトルに矛盾するじゃないか。
私「プログラミングとかしてたの?」
A「プログラミングももちろんだけど、設計からテストまでやってたよ。まぁ先輩に頼りまくってたけど。」
私「スイッチの制御ソフトのテストってどんな感じなの?」
A「別に普通だと思うよ。」
いや、スイッチの制御ソフトというテスト対象に対して、ほかのソフトにないテスト観点でもあるのかなと思って聞いたんだけど・・・確かに聞き方が悪かった。
私「テストケースとか作ってたでしょ?どういうテストケースなの?」
A「テストケースはあったけどあんま覚えてない。それよりテストケースじゃないところでよくバグを見つけていた覚えしかないんだけど。」
私「あぁ・・・アドホックテストでバグ出しちゃう感じね。」
A「何それ?」
私「思いつきのままテストすることをアドホックテストって言うんだよ。テストの質がテスト担当者の経験にものすごく依存するからそれだけだといまいちで、なのでテストケースを作って計画的なテストもしてるわけ。こういう思いつきのようなものは、経験や直感に基づいたテスト技法って言ってこの本にも書いてあるよ。」
そう言ってSQuBOKをカバンから出した。
A「別にいいよ、難しそうだから。」
読んではくれないらしい。
でもここまで話したら、もう止められなくなっていた。
私「テストケースを使ったテストであまりバグがでないのは、きっと殺虫剤のパラドックスってやつだね。この本じゃないけど、[[JSTQB>http://jstqb.jp/]]というテストの資格試験のシラバスに書いてあるよ。テストケースを使いまわしていると、そのテストで出せるバグは当たり前だけど出なくなってくるでしょ?」
私「あと、経験や直感に基づいた技法としては探索的テストというものがあるよ。ソフトを動作させて対象ソフトを学習しつつもテスト設計とテスト実行を探りながらやっていくようなテストだよ。よくテスト技法っていうと同値分割とか境界値分析というのが出てくるけど、いろいろあるんだよ。」
A「へーそんなのあるんだ。」
A「でも同時にやるってことはテストケースを最初に作らないんでしょ?ってことはテストケースの数とか決まってないんだよね?そしたらきっとサボると思う。テスト期間短すぎて余裕ないもん。」
A「みんながあなたの周りにいるようなやる気満々なエンジニアばかりならしっかりやるんだろうけど。」
私「それたぶんテクニックとしてのテスト技法の話だけ見ていて、マネジメントの話をまったく考えていないからだと思う。」
私「探索的テストだけじゃなくて他の技法でも、特に客観的な目標が示されなければ適当にテストケースを作っちゃうんじゃない?」
私「かといって、ふつうよく使われているテストケース数や密度を適当に決めてあげるのが最適かと言うと、そんな気もしないよね。そもそもバグは偏在するっていうのにバグ密度やテストケース密度だけでプロダクトやテストプロセスの出来栄えを見るのは良くなさそうだよね。(と似たようなことを誰かが言ってた)」
私「なのでテスト対象や目的に応じてテストの重みについてテストケース数とかじゃなくても良いので関係者間で合意を取れればよいと思ってる。重視する品質やテストの重みについてはまず大きな戦略や方針があると思うんだけど、そういった方針をテストケースに落とし込むには、その手前のテスト設計というところで、重みを考慮した構造を示してあげればいいんじゃない?」
A「言ってることがさっぱりわかんない。」
私「ちょっと違うけど、SQuBOKにはメトリクスの話(3.1/p.196)やテストマネジメントの話(2.18/p.166)も載ってるよ。たとえばテスト計画とか言ってよく線表だけ出てくることない?SQuBOKにはIEEEのテストドキュメント体系の規格が紹介されていたりして、計画ってそれだけじゃないんだよってことが書かれていたりして勉強になると思う。」
「あいとっぴー」
だれが喋ったかと思ったら息子さんか。ここまで大人しくLEGOで遊んでいた息子さんがついにしびれをきらしたらしい。しかしこの年でIEEE(あいとりぷるいー)を口にするとは。
A「あーごめんねー。おじさん変な話ばっかりしてるね。」
そうして僕らのテスト話は終わった。
**あとがき
- この話はフィクションです。著者の妄想によって書かれています。
- 関係者にレビューしてもらったら、「テストの重みについて関係者間で合意とれば」とか書いてあるけど、テストケース数に拘るおっさんがいるし、関係者多すぎて無理。って一蹴されました。
- なんかもっと、素人奥様とのふつうの日常会話でもSQuBOKは役立つんだぜ、というようなことを書きたかったのですが、難しかったです。ごめんなさい。
2015-12-16T08:32:02+09:00
1450222322