読者です 読者をやめる 読者になる 読者になる

yfj2’s Automatic Web Test Related Blog

yfj2のWEBテスト自動化に関わるブログ

ロジカルシンキングについて再考する(1)

著者:ふじさわゆうき

更新日:2016/07/27

システムエンジニアになって、かなりの年月がたちました。

最近は、Webの世界からアプリに世界が広がったことで、多くのことを業務で扱いますが、毎日覚えることが沢山あって大変です(そもそも何を勉強したらよいのかわからないときも・・・)。

そういう状況では、基礎的な学習しておくことで、業務での能力向上が見込めると考え、基礎的な勉強に1日1時間くらい時間を作ることにしました。

まずは、システムエンジニアの基礎である「ロジカルシンキング」について再考してみることにします。

以下、何回かに分けて「ロジカル・シンキングー論理的な思考と構成のスキル」を要約します。

本書は、私が大学院のときにコンサル会社に勤めていた友人から勧められたもので、修士論文を作成したり、レポートを作成するのにとても役に立った非常に良い本です。

対象書籍

ロジカル・シンキング―論理的な思考と構成のスキル (Best solution)

ロジカル・シンキング―論理的な思考と構成のスキル (Best solution)

第1章 相手に「伝える」ということ

  • ビジネスの世界では世界では、自分の考えや提案が、
    • 相手の頭に正しくインプットされ、
    • 思考回路の中で正しく理解され
    • 自分が望む反応が出てくる
  • までの時間が勝負になる
  • 大事なことは「あなた」が大切だと思っていることではない。それが相手にとって期待されている「メッセージ」になっているかどうかである
  • 自分の考えを論理的に伝える第一歩。それは「いきなり伝える中身について考え無いこと」

相手に伝えるべきメッセージとは?

  • メッセージとは何か。以下3つの条件を満たしているものだ
  1. 答えるべき課題(テーマ)が明確であること
  2. その課題に対して、必要な要素を満たした答えがあること
  3. そのコミュニケーションの後に、相手にどのような反応をしたもらいたいのか、つまり相手に期待する反応が明らかであること
  • 「課題」「答え」「相手に期待する反応」の3点セットが、本書で定義するメッセージである
  • つまり、人の話を聞いたときに、「課題」はこれで、それに対する相手の「答え」はこれで、「自分にこれをしてほしい」ということが頭に明確に残ることをクリアして初めてメッセージとなる。
  • 重要なことは、①課題(テーマ)を確認する②相手に期待する反応を確認する、という2つの確認作業をすることだ
確認1:課題(テーマ)を確認する
  • 自分が相手に答えるべき課題は、何なのか、確認しよう
  • 相手が「今検討すべき課題」と認識していなければ、議論の土俵にすら登れない
確認2:相手に期待する反応を確認する
  • 相手にどのようにしてもらいたいのか、どんな反応を引き出したいのか、という期待成果の無いコミュニケーションは「独り言」でしかない
  • 伝えることによって、相手に理解してもらったり、相手のニーズや意見を引き出したり、あるいは相手に何かのアクションを取ってもらうなど、相手になんらかの「反応」をとってもらうことが最終目的であるはずだ。伝えることは手段であり、目的ではない!
  • ビジネスにおいて、相手に期待する反応は以下、3つにまとめることができる
  1. 相手に理解してもらう
    • 業務連絡、事務連絡はこのケースに当てはまる
  2. 相手に「意見や助言、判断などをフィードバック」してもらう
    • ヒヤリングやテストマーケティングで顧客のニーズを引き出す場合がこれにあたる。社内での会議や報告なども該当する
  3. 相手に行動してもらう
    • キャンペーンへの参加依頼などを実施する場合、アンケートに答えてもらう場合はこのケースに当てはまる
  • 同じ課題であっても、相手に「理解」してもらいたいのか、「意見や助言、判断をフィードバック」してもらいたいのか、「アクション」を取ってもらいたいのか、という相手に期待する反応を確認することによって、答えとして伝えるべき深さや広がりは大きくことなることは想像できるだろう

何を言えば「答え」になるのか?

  • 以下の質問にイエスと答えられるかどうかが、課題に対する答えの要素があるのか、無いのかのチェックポイントである
    1. 課題に対して、伝え手が、どのようなアクションを取るべきだと言っているのか?
    2. イエスなのか?ノーなのか?
    3. 結論に至った根拠に納得感があるか?
    4. 結論がアクションの場合、具体的なやり方が示されているか?
    5. 自分がそのアクションについて部下に指示を出す場面を想定した時、指示の中身が具体的にイメージできるか?
  • 「結論」 -> 「根拠」 -> 「方法」
    • 結論: 課題に対する答えの核をなすもの。何かのアクションを提示する場合と、評価や判断を表すものの2つがある
    • 根拠: その結論にどうして至ったのかという理由。事実と判断の2つがある
    • 方法: 結論がアクションの場合、相手がそのアクションを取れるよう、具体的なやり方を提示するもの

なぜ、相手に自分の「答え」が通じ無いのか?

理由1. 結論が「自分の言いたいことの要約」になってしまっている
  • 「要するに、どっちなの?」という発言が相手から出てしまっては、コミュニケーションは失敗
  • 本当に答えるべき課題に対する答えの核になっているかを常に見直すべき
  • いかなる場合も、課題と答え、答えの核となる結論は整合していなければならない
理由2. 「状況に応じて」「場合によっては」の基準が曖昧
  • 相手に結論が明確に伝わる、という点で留意すべきなのは、どうにでも解釈できるような曖昧さを排除する、ということだ
  • 「状況によっては」「場合によっては」と曖昧なな言葉ではなく、「売り上げが前年度比105%を上回ったら」など定量的な言葉にしたり、定性的な中身を具体的に伝えるかによって、明確にすることである

根拠が伝わらない時の3つの落とし穴

  • 結論が正しくてもなぜそれが正しいのか、すなわち根拠が正しいと説明できなければ相手を納得させることはできない
  • 以下、3点を留意するだけでも、その精度は高まる
    1. 「Aが必要だ、なぜならAが無いからだ」では、相手は納得しない
    2. 「それは事実なのか?それとも判断仮説なのか?」と思わせた途端に信ぴょう性は半減する
      • 例えば、「当社の売り上げ不振の原因は、時代の空気をうまくとらえていないからだ」と言われた場合に「うまくとらえていない」は「事実なのか判断なのか」が聞き手が判断できない。もし、事実だとすれば、具体的にどのような現象をさしているのか示すべきだし、そう判断したのであれば、根拠を明快に示さなければ根拠を説明したことにならない
    3. 与えられた課題に、答えを出すに上で事実に対してどうみるのか、という判断軸、もしくは前提条件が示されていない。

方法が伝わらないときの2つの落とし穴

  1. 他の会社、10年前でも通用するような公理では人は動かない
    • 教科書に書かれているような公理をいうのではなく、公理を自分の企業に当てはめて、具体的に何をすべきかを伝えなければ意味が無い
  2. 修飾語で物事が具体的になることはない
    • 自分で方法を書いてみて、どうも具体的ではないと思ったら、それは問題が具体的に解けていないということである
    • 具体的に書くためにはどうすればよいのか。そのためにはなぜなぜすることが重要である
      1. 客からのクレームが多い > なぜ?
      2. 商品の故障そのものより対応の仕方に不満が高い > なぜ?
      3. 販売員は、販売には熱心でも修理対応には関心が無い
    • 以上のように「なぜそうなっているのか」の質問を繰り返すことで初めて具体的な方法がみえてくる
    • 具体性があるかどうかをチェックするときにおすすめなのは、「自分がその実施者の立場だったら、何を知っていれば具体的に動けるのかと自問自答してみることだ」
    • どうやって?どの程度?いつからいつまでに?誰が主体で? etc

DeNA Technology Conference 2016に行ってきました

著者:ふじさわゆうき

更新日:2016/02/04

DeNA Technology Conference 2016(主催: DeNA TechCon)に参加してきました!!
DeNAのこれからに期待の持てるプレゼンばかりでワクワクを感じることができたカンファレンスでした。

以下、カンファレンス概要、プレゼン資料、会場の雰囲気、参加したセッションの内容をまとめましたのでご参考ください!!

目次

  1. カンファレンス概要
  2. プレゼン資料
  3. 会場の雰囲気
  4. 13:30〜「DeNAのネイティブアプリ開発」
  5. 14:30〜「DeNAが取り組むSWETの道」
  6. まとめ
  7. 関連記事

カンファレンス概要

  • 公式ページ #denatechcon

techcon.dena.com

以下、4つのカテゴリ毎に平行して行われる形式のカンファレンスでした。

  • 『DeNAが切り拓く最前線』
  • 『DeNAの新しい挑戦』
  • 『DeNAを支える技術』
  • 『DeNAのゲーム開発』

DeNAが技術に特化した大規模なイベントを主催するのは初めてということでした。

以下、登壇者の一部です

  • DeNA システム本部 技術開発室 奥 一穂
  • DeNA オープンプラットフォーム事業本部 副事業本部長 山口 徹
  • DeNA システム本部 技術開発室 小倉 豪放
  • DeNA 執行役員 Japanリージョンゲーム事業本部 副事業本部長 池田 修
  • DeNA 取締役 川崎 修平
  • DeNA 執行役員 システム本部長 木村 秀夫

etc

後日、プレゼン映像も公開されるということで期待しましょう
*一部、公開できないプレゼンもあるみたいですが。

プレゼン資料

2016/02/04時点で公開されているプレゼン資料です。
*見つけ次第、順次、更新します

会場B 13:30〜 爆速でAndroidアプリを ビルドするための仕組み TOYAMA Yosaku さん

www.slideshare.net

会場A 14:30〜 DeNAが取り組む Software Engineer in Test 中川 勝樹さん

www.slideshare.net

会場A 16:30〜 これからの Microservices 山口 徹さん

www.slideshare.net

会場B 16:30〜 iOS レガシーコード 改善ガイド 〜マンガボックス開発における事例〜 松前 健太郎さん

www.slideshare.net

会場C 16:30〜 DeNAtechcon_DeNAのセキュリティの取り組みと、スマートフォンセキュリティ(same-origin policy) 杉山俊春さん

www.slideshare.net

会場の雰囲気

会場の雰囲気については、以下ブログに写真が多数掲載されていますので覗いてみてください!
blog.kushii.net

13:30〜「DeNAのネイティブアプリ開発」のメモ

プレゼンを聞いてみての感想

  • ネイティブアプリ開発は、2013年11月から本格的に取り組み始めたとのことですが、その時点で150人以上のエンジニアのうち、3人しかネイティブ開発のスキルを持ったエンジニアがいなかったらしいです
  • そんな状態から、色々な施策を経て、サーバーサイドエンジニアをネイティブエンジニアに転身させてきたのはすごいなと思いました
  • 「コールバック使いすぎ問題」、「非同期プログラミング問題(プログラミングパラダイムの変化)」などを組織のトップである池田氏が把握して、解決に取り組んできた姿勢が大きいと思います。他の大手企業だと、上の方は「技術がわからない」でトンチンカンな方向に行きそうですが、それがDeNAではトップでも最新の技術に理解があるのはいいなと思いました
  • そういう組織体制だからこそ、サーバーサイドエンジニアをネイティブエンジニアに転身させることができたんだろうなと思いました
  • またネイティブアプリの技術面だけではなく、開発プロセスもしっかりしている面がすごいなと思いました。プロトタイプ版、α版、β版、RC版と段階を踏んでレビューをしっかり行っていて、「これって面白い」とユーザーが思えるアプリだけをリリースしようという姿勢もすごいなと思いました

以下、発表メモ

  • スライドのターゲット
    • ゲームアプリ開発でぐったりしてる人(笑
  • DeNAがネイティブを始めたのは2015年からでまだまだ最近で「 DeNAのアプリ開発って遅くね→おっしゃる通りです」みたいなスライドがあった
  • 2013年11月からネイティブ開発を始めるにあたってしたことは、17項目で150人以上をスキル評価したこと
    • 評価の結果、3人しかネイティブ開発できるエンジニアがいなかったらしい
  • メンバーの育成にあたってハードルになる部分は、「非同期プログラミング」と分析していた。なぜなら、その点がウェブアプリと大きく違う点だと感じていたから
    • プログラミングパラダイムの変化をDeNAに求めたとのこと。同期(Web、サーバー)から非同期(ネイティブアプリ)へ
  • マルチメディアも大きく違う。サウンドデータも開発者が悩まなければいけない
  • Webは全データを全ユーザが共有できるが、ネイティブは、端末のリソースのみが利用できる点も違う。リソースマネジメントの違い
  • チートも違う。ネイティブアプリはチート(不正利用行為)されやすい環境。ユーザーの手元にある
  • DeNAの戦略としては、Webゲームの成功体験のある技術者をアプリ開発者に転身させること。アプリ開発者に人員を投下すること。勉強会を社内で開催して成長させること。ネイティブの難易度の高い技術要素はやらないと決めること。などの施策をやってきた
  • サウンドなど、育成困難な部分は内製しないなど「やらないことはやらない」との割り切りもしてきたとのこと
  • DeNAで採用しているゲームエンジンは2つ。UnityとLiftEngine
    • 3DゲームはUnity2DはLiftEngineという使い分けをしている
  • サーバーサイドは、SakashoとIRISの2つ
    • Sakashoはゲームアプリ向けのBaaSのこと
    • IRISは、マルチプレイを実現するサーバーのこと
  • ネイティブアプリの開発力を上げるために、サーバーサイド基盤であるSakashoで統一とすることとした。
    • サーバーサイドに工数をかけない方針
  • 新規タイトルは、30−40人で作成する規模。小規模開発はやらないこととした。過去の経験として、小規模開発してうまくいった場合に、大規模化するのが難しいことを踏まえての方針。始めから大規模前提でチームを構成することにしている
    • 小規模開発でやるのは、最近だと危ないという考え。アイディア一つでヒットアプリを出すのは、最近、難しくなっているということらしい
  • 開発プロセスをDeNAではカッチリしている。マイルストンレビューというものを実施していて、Proto/α/β/RCという段階を踏んでリリースするプロセスになっている
    • α版では、基本となるゲームが体験できるもの。例えば、装備、ガチャの機能。1画面だけ、リリース品質にしてみる。1画面のどこかのパーツができていない状況だとレビューは通さない
    • β版は、チュートリアルをやってみてゲームにのめりこめるかどうかをみるなど。10〜30分やってみて面白さが伝わってこないとレビューで指摘する
  • 新規タイトルだと、新規バグが出ない(2日くらいテストしてみて)状態をクリアしないと、リリースはさせない体制
  • ネイティブ開発を始めてみて、コールバック使いすぎ問題がネイティブ開発においては多発したらしい。コールバックによる通知とpollingを適切に使い分けできない
  • ネイティブ開発をはじめてみて、データの設計がDBっぽい問題も発生。Webサーバーの感覚でネイティブアプリをつくるとメモリ等のリソースが大きくなりがち
  • MVCモデルから離れられない問題も発生。ネイティブアプリだと、MVCが当てはまらない場合でも無理やり当てはめようとしてしまうというWebエンジニアだと陥りがちな問題
  • サーバーサイドのエンジニアがネイティブアプリエンジニアに転身できることが実証できたとのこと

14:30〜「DeNAが取り組むSWETの道

プレゼンを聞いてみての感想

  • DeNAにおけるSWETについてよくわかるプレゼンでした
  • DeNAにおけるSWETを「開発生産性と訳されるDeveloper Productivityが大きな役割」と掲げて「プロダクトのサービス品質向上とエンジニアの開発生産性向上をミッションステートメント」としている点に非常に共感が持てました
  • 自動化チームとしてとても守備範囲の広いグループだと思いました。WebAPI, WebUI, Smartphone,Applicationと幅広く取り組んでいるグループは、他企業では、なかなか居ない存在だと思います
  • 自動化の勉強会にいくと熱い話題ですが、テストの分割、並列による高速化もSWETではすでに実現しているところもすごいなと思いました
  • SWETが取り組んでいるSTF (Smartphone Test Farm)は、これから注目の技術だなと感じることができました。実機端末をブラウザから操作できることは素晴らしいですね。実機がどこかにいってしまったり、ちらばってしまったり、画面キャプチャが取るのが難しかったりとありましたが、STFという技術がもっと発展していけばこういう問題が解決されるだろうという期待が持てました
  • SWETのメンバー3名が著者のselenium本が2016/2/2に発売されるらしいので手に入れたいと思います。

www.amazon.co.jp

以下、発表メモ

  • SWET = Software Engineer in Test
  • SWETの定義では、WIKIではQAのジョブだと定義されている(Wiki > Set > Technology)。しかし、googleのテスティングブログでは開発者の役割としている。SWETは、開発者のコードがテストしやすくする環境を提供するのが役割
  • SWETでは、開発生産性と訳されるDeveloper Productivityが大きな役割だと考えているとのこと
  • SWETでは、プロダクトのサービス品質向上エンジニアの開発生産性向上をミッションステートメントとしている
  • バックエンドのテスト自動化。次に、フロントエンドの自動化ブラウザテストの自動化で、Rubyを使ったブラウザゲームのプラットフォームのテストの自動化を上(フロントエンド)から下(バックエンド)まで押さえながらやってきた
  • SWETのメンバー3名が著者のseleniumに関する書籍がでた!!
  • Smartphone SDKの自動化も手がけている。Android, iOS, Unityに対応
    • Mobile Automationは、まだデファクトが確立されていない分野で、現状、Try&Errorを繰り返している。泥臭く挑戦中。昔は、Calabashを使っていたが、最近は、ブラウザテストとの統合もみすえてAppiumに着手している
  • 自動テスト対象として、WebAPI, WebUI, Smartphone, Applicationと幅広く取り組んでいる
  • SWETは、Game BaaS(Sakasho)のサポートも開始している
  • SWETは、テスト基盤チームも作って技術的な取り組みを強化している
  • SWETでは、テスト環境の高速化にも取り組んでいて、テスト実行計画管理ツールを開発した。それを使って、並列数に応じて、シナリオを分割する、シナリオ単位の実行時間を集計するなどができるようになっている
  • テスト環境の仮想化も進めている。Dockerの導入。Selenium + Appium + Docker。これによって、テストの並列実行が柔軟にできるように取り組んでいる
  • SWETグループでは、STFも進めている。STF = Smartphone Test FarmというOSSのツールを使って社内で運用中。このOSSのコミッターがSWETチームに在籍という環境。STFとは、Smartphoneの実機検証がブラウザから可能になるという便利なもの

github.com

  • STFの操作にAPIが提供されるようになっていて、JenkinsからSmartphoneのテストが自動実行できるようになっている。これは画期的!!

まとめ

 DeNAのネイティブアプリ開発とSWETという自動テストグループについてブログに書きましたが、どちらもこれからの将来性に期待の持てるプレゼンでワクワクを感じることができました。これからも、DeNAの技術動向に注目していきたいと思います。
 来年もDeNA Technology Conferenceが開催されることを期待しています!!

*それにしても、懇親会のお寿司は美味しかったです。ご馳走さまでした!

関連記事

わなみんさんが手書きでまとめた資料がすごかったので掲載しておきます


DeNA TechCon 2016のTogetter

togetter.com

DeNA Tech Con2016に行って来ました yoshida 261

下記セッションについて書いたブログです。

  • 爆速でAndroidアプリをビルドするための仕組み(TOYAMA YOSAKU)
  • DeNAが取り組むSoftware Engineer in Test(NAKAGAWA MASAKI)
  • DeNAのマルチプレイゲーム用サーバ「IRIS」(IKEDA OSAMU)
  • カジュアルトーク
    • チラシルの話(途中から参加したためタイトル不明)
    • シニアエンジニアが新規サービス立ち上げたあれこれ(とかなんとか)

imara.hatenablog.com

DeNA Tech Con 2016に行ってきました! spangled shalalala blog

下記セッションについて書いたブログです。

  • Webを速くするためにDeNAがやっていること〜HTTP/2と、さらにその先〜(KAZUHO OKU)
  • DeNAが取り組むSoftware Engineer in Test(NAKAGAWA MASAKI)

spangled-shalalala.hatenablog.com

DeNA TechCon 2016にデザイナーだけど参加してきました LOGzeudon

下記セッションについて書いたブログです。

  • DeNAのネイティブアプリ開発
  • Webエンジニアが学ぶ自動運転を支える技術
  • Anyca におけるUIフレームワークとスマホによるドア操作の仕組み
  • B2B2Cなヘルスケアサービスの作り方
  • チラシルiOSでの広告枠開発
  • MERYで CM 乗り切った話〜女の子のかわいいを守るために〜
  • iOS レガシーコード改善ガイド〜マンガボックス開発における事例〜

blog.rokuzeudon.com

Mac、AtomでC#のIntelliSense機能を使えるようにする

著者:ふじさわゆうき

更新日:2016/01/14

UnityでC#の開発をできるようにする必要があったのでそのメモ

AtomでC#を扱うのに必要なもの

  • omnisharp-atom
    • $ apm install omnisharp-atom
  • .NET Version Manager (DNVM)
  • DNX for .NET Core
    • dnvm upgrade -r coreclr
  • Mono
    • $ brew install mono
    • $ dnvm upgrade -r mono
    • $ ln -s /usr/local/Cellar/mono/***/bin/mono /usr/local/bin/mono
    • $ sudo ln -s /usr/local/bin/mono /usr/bin/mono

プロジェクトファイルの準備

  • AtomでEditするディレクトリにproject.jsonを用意する
    • $ touch project.json
    • 1 ProjectsになればOK

テスト自動化パターン言語って面白い。笑える。でも役立つ

著者:ふじさわゆうき

更新日:2015/12/17

先日、システムテスト自動化カンファレンス 2015に行ってきました。
その話の中で、「テスト自動化パターン言語」が紹介されていたので調べてみました。

テスト自動化パターン言語とは

テスト自動化パターン言語の定義は次の通り

テスト自動化において、みんなが共通してハマることが結構ある(良いものも、悪いものも)。それらの共通点を分類してパターン言語としてまとめたものがテスト自動化パターン言語である。
パターン言語の狙いとしては、暗黙化されている失敗体験や成功の要因をわかりやすい形で共有することで「体系化された知見が少なく伝達が難しい」「上手くやれる人が少なく活動が手探り」という課題を解決することを目指している

https://www.juse.jp/sqip/symposium/timetable/files/happyou_A3-4.pdf#page=15
を自分なりに要約してみました

参考になるパターンをいくつか紹介

以下、テスト自動化パターン言語プロジェクトのページがあるのでそこから、自分のお気に入りのパターンを紹介します
Introduction | テスト自動化パターン言語プロジェクト

自動化ハイ

自動化ハイは、自分のチームのあるあるです。私のいるテスト自動化チームは開発者のみで構成されており、みんなテストを勉強したことがないメンバーです。全体の設計をしないままに自動化をどんどん推し進めた結果、重複テストが沢山あることに気付きはじめるなどして、現在、困っています

自動化ハイ

■文脈

3分クッキングなどにより、自動化の導入には成功している。いよいよこれからが、自動化を全体に進めていく時である。

■問題

試験的に導入した自動化の面白さに取り憑かれ、全体の設計をしないままに自動化をどんどん推し進めようとしている。その結果、似たようなシステムが乱立し、以後の管理が困難な状態([建て増し旅館])になりかけている。

■フォース

特に現場手動で自動化を行っている場合、どんどん実装を行い自動化を進めて行きたくなってしまう。
プログラマの性として、一度うまく行き始めると、その勢いのままコードを書き進めてしまうことは大いに有り得る。
解決

一度冷静になり、[全体像を描く]ようにしよう。我々の目的はテスト作業の省力化・効率化であり、自動テストの実装はその手段にすぎない。どのようなテストが本当に必要なのか、メンテナンス性も含めて全体最適されているのか、現在の自動化システムで今後の拡張に耐えうるのか、冷静に判断をしよう。

■結果

自動化の全体像を描き、今後の拡張やメンテナンス性を考慮した自動化システムを構築することができるようになる。

自動化ハイ | テスト自動化パターン言語プロジェクトより引用

験担ぎ

験担ぎも、自分のチームのあるあるです。テストが失敗したからそのバグをチケット起票したのに放置されてテストが失敗し続けるなどが起こっています。自動テストで見つけるバグが、誰が直すのか取り決めが曖昧なまま進めている、テスト設計が良くないなど、「自動化ハイ」の副作用なんです(泣)。私のマネジメントが悪いので反省です。

験担ぎ

■文脈

テスト自動化環境が構築されて、少なくとも一度は効果が出た状況である。継続的にテスト自動化でのテスト実施が行われている状態ではあるが、効果がある活用と運用がされていない。「このエラーは出ても問題は無い」という意思決定で運用が行われている。

■問題

テスト自動化実施が定められているので自動化環境を動かす活動は行われている。テスト実施はされているが、明らかなエラーが検出されたとき以外は結果を誰も確認しない。 結果として、テスト資産が形骸化・陳腐化している。

■フォース

仕様変更などでテスト資産を変化に対して追従させる必要があるが、自動化環境はなぜか無視される。(担当者が異動になった場合などに発生することが多い:たこつぼ化)

■解決

最新のSUTと自動化環境の差を分析して、テスト資産を追従させる。
エラーが出ていることが、現場でもみ消せないようにプロセスを整備する。
エラーが出ない環境を作り、そのためのチームの規律を構築する。
自動化環境の保守を行う担当者{自動化奉行}を決める。
改善コストがあわないなら、そんな自動化やめちまえ。

■結果

SUTに適した自動化環境が整備され、変化に追従されている。 変化に追従した環境により、テスト自動化の効果が得られる状態になっている。 意味のないテスト自動化環境が無くなっている。

験担ぎ | テスト自動化パターン言語プロジェクトより引用

感想

テスト自動化パターン言語って面白い。笑える。でも役立つなぁーってのが素直な感想です。

暗黙知をアンチパターンという形式知にして、これから自動化を進める人が、先人と同じ失敗を繰り返さないように共有する活動ってとっても素晴らしいなと感じています。これらをまとめている森田誠さん、前川ヒロシさん、水野のりゆきさん、.reviewrcの皆様に本当に感謝です。これからも、テスト自動化パターン言語の拡充に期待しています

参考になるUXガイドライン

著者:ふじさわゆうき

更新日:2015/12/15

ふと記事を読んでいたら、なかなか参考になったのでメモ。
題材は「参考になるUXガイドライン」

記事元は以下の記事

UXとは

User Experienceの略です。UXの定義は以下の通り。

製品やサービスを利用する過程(の品質)を重視し、ユーザーが真にやりたいことを「楽しく」「面白く」「心地よく」行える点を、機能や結果、あるいは使いやすさとは別の“提供価値”として考えるコンセプト。
つまらぬいらいらや面倒なしに、顧客のニーズを正確に満たすことであり、次に所有する喜び、使用する喜びとなる製品を生産するといった簡単、簡潔なことである。

Nielsen Norman Group: UX Training, Consulting, & Researchより引用

参考になるUXガイドライン

Windows UX ガイドライン

以下、3つのカテゴリにわけで、詳しく解説している。デスクトップアプリケーション開発において役に立ちそう

1. 優れた UX の設計
2. UX チェック リスト
3. 成功する UI の作成

Windows デスクトップ用アプリの設計 - Windows アプリの開発より引用

グーグル UX10カ条

  • 「次代遅れのブラウザをサポートするように設計します」ってのが意外でしたが、ユーザーのことを第一におくとそうなるってことなのでしょう

1. Focus on people – their lives, their work, their dreams.
Googleユーザーエクスペリエンスチームは、世界の人々の生活、仕事、夢にフォーカスします。私たちのゴールは人々の生活を改善することです。

2. Every millisecond counts.
スリムなコード、慎重にセレクトされた画像などGoogleのページは、素早くロードするように設計されています。そして、不必要なクリック、タイピング、ステップなどは削除して設計しています。
スピードはユーザーに恩恵を与えます。

3. Simplicity is powerful.
シンプルというのは、強力なことです。私達の考える良いデザインというのは、人々がゴールを達成するために必要とする機能だけを含むものです。

4. Engage beginners and attract experts.
初心者や新規ユーザーは招待して、パワーユーザーには魅力あるスマートな機能を提供します。

5. Dare to innovate.
Googleでは、革新的な、リスクをとるデザインを奨励します。新しいアイデアを推奨して、そして実施します。

6. Design for the world.
世界の人々だけでなく、モバイル機器などのさまざまなデバイスや、次代遅れのブラウザをサポートするように設計します。そして利用者がスクリーンサイズやフォントサイズなどをどのように設定して利用するか研究して、プロダクトを設計します。

7. Plan for today's and tomorrow's business.
今日だけでなく、明日の未来のビジネス計画をします。将来ユーザー数を減らすものがあれば、そのプロダクトの収益を増やそうとはしません。すべてのプロダクトが収益を生む必要はありません。

8. Delight the eye without distracting the mind.
視覚的なイメージは大切です。ユーザーに第一印象で快適な印象を与え、信頼性が高くプロフェッショナルなものを提供します。

9. Be worthy of people's trust.
ユーザーに正直になり、信頼を得るように努力します。インターフェイスは効率的に設計し、広告は明らかに識別できるようにするなど実施します。

10.Add a human touch.
人間的な暖かみを加えます。Googleは人間的なたくさんの性格を備えています。ただし、大事な情報を探すときには、それらGoogleの楽しい面や人間的な性格は邪魔をしません。

Googleが実践するユーザーエクスペリエンス10箇条 | コリスより引用

感想

それにしても、Windows、Googleともに会社として理念やUXを明確に掲げているところが素晴らしいですね。チームマネジメントでも参考になりますし、個人の仕事でもこういうものを目的として掲げておいて日々の業務や、勉強会の選び方に活かすのは大事かなと思いました

『TPI NEXT 日本語版発刊記念セミナー』に参加してきました

著者:ふじさわゆうき

更新日:2015/12/12

目次

  1. セミナー概要
  2. 個人的感想
  3. TPI NEXTの概要メモ
  4. TPI NEXTの詳細メモ
  5. パネルディスカッションメモ

セミナー概要

hinshitsu-univ.connpass.com

  1. テストプロセス改善であるTPI NEXTについて、薮田さん、湯本さんからのプレゼン
  2. 薮田さん、湯本さん、皆川さんによるパネルディスカッション

という2部構成でした

個人的な感想

  • CMMIとTPI NEXTとの比較が多く面白かったです
  • CMMIの場合は、改善のプロセスが決まっているのに対して、TPI NEXTは、キーエリアとクラスタという概念を使って、改善のプロセスをその組織の目的に合わせて柔軟に優先順位を決めることができるというのが特徴とのことでした
  • また、CMMIの場合は、机上の論理なのに対して、TPI NEXTは、現場から出てきたフレームワークということで実践的であるともいっていました
    • 薮田さんがおっしゃっていたで面白かったのが、16キーエリアという適当な数が良いとのことで、理論的に行こうとすると16なんて中途半端な数にならないとのことです
  • TPI NEXTは、クラスタセットと16キーエリアのチェック項目に沿って改善の優先順位を決め、やるべきことをやることによって結果的にテストプロセス改善を狙った手法であると個人的には理解しました
  • 今回、薮田さん、湯本さん、皆川さんの話をうけて、TPI NEXTがぐっと身近になったと感じています。やはり、本で読んでもわからないことがこういうセミナーにでると一気にわかります
  • TPI NEXTの第一歩は、自分自身をチェックすることから始めてみて、そこからキーエリアの意味を理解することが近道ということなので、とりあえず、この手法を使って、自分自身のテストに対する姿勢で、どの部分が弱点でどう改善していくのか計画をたててみたいと思います

TPI NEXTの概要メモ

  • TPI NEXTとは
    • プロセス評価ではなく、キーエリアで評価することがポイント
    • 現場から生まれてきたフレームワークであって、CMMIと比較して実践的である
    • テストチームと利害関係者(プロジェクマネージャとか)とのやりとりを重視する。テストチームだけで評価してもうまくいかない
    • キーエリアがあって、それを自己評価して、クラスタセットをもとに改善の優先順位をつけて、改善活動を進めるのが大きな流れ
    • 改善計画が長期に渡って、システマティクにできるのがメリット
    • 「戦略と組織」「テスト管理」「テスト技術」という3つをバランス良く改善しようという考え方
    • CMMIと違って、キーエリア+クラスタセットで多角的に現状の組織を評価することができる
  • 薮田さんによると、1970年代から、テスト技術は、あまり変わっていない。だから、TPI next は有効な手段ということ

TPI NEXTの詳細メモ

  • 湯本さんによると仕事しながらも技術をキャッチアップしようという意識を「プロ意識」と翻訳した
  • TPI NEXTのクラスタAは、基本的なことが多いから軽く達成できる。なのでここから始めてみることが大事
  • TPI NEXTによる評価は、なれれば1時間位で実行することが可能
  • テスト戦略について、TPI NEXTはわかり易く解説しているので参考にするとよい
  • 「戦略と組織」「テスト管理」「テスト技術」など細かいことは、TPI NEXTの本を買って読んでくれとのこと
  • クラスタ、カスタマイズできるので、具体例は本を読んでくれとのこと

パネルディスカッションメモ

  1. プロセス改善は楽しい?
    • パネラー4人中3人は「楽しくない」と回答(笑)
    • 開発と現場の方々に嫌われるから辛い。色々と言われる
    • ただし、上司受けは良い
  2. テストプロセス改善のフレームワークでTPI NEXTが一番?
    • CMMI は権力と結びつきが強いが、TPI NEXTは権力との繋がりがないのが良いと、パネラーの意見。TPI NEXTは、現場で鍛えられてきたモデルなので、素敵
    • TPI NEXTは、改善のスコープを決めるのが良い。TPI NEXTを皆で輪読して、やってもいいし、リーダーが指摘しても良い。ただ、輪読はしやすいとのこと
  3. テストプロセスを改善すると利益はあがる?
    • 上がると信じてプロセス改善に取り組めばよい。きっと上がるよ(笑)
    • 開発プロセスとセットで改善することが大切。気になるのは、開発プロセスの理論は、10~15年単位でパラダイムシフトが発生しているのに、テストプロセスに関しては1970年代と変わっていないこと。だからこそ、TPI NEXTに取り組むことは意味があるといえる
    • テストは改善しないとコストがどんどんかかる分野だから、プロセス改善をしないとコストが下がらないし、むしろ上がっていく
  4. その他
    • TPI next は、プロダクト単位なのか、課とかの組織でみるのか、それは自由。弱点をみたい単位で、当てはめてみるのが良い

TPI NEXTについて学ぶ(2)

概要

  • TPI NEXTについて、以下の参考文献を要約することで学ぼうという趣旨です。

今回の対象

  • 2 テスト作業とTPI NEXTの位置づけ ~ 2.1 テスト作業のスコープと価値 p9-14

感想

  • "テスト作業によってビジネス上で想定される損害が軽減できれば、テスト作業のコストはプロダクトリスクに対する保険掛け金とみなすことができる"という考えかたが新鮮だった。
  • 経営層が、保険掛け金算定のもとになるプロダクトリスクの見積もりは難しいだろうし、そのリスクに対する掛け金の見積もりも難しいことから、それに対してテストチームから提供できる材料(レポートなど)は何か?は常に考えて仕事に取り組まないといけないなと感じた

要約

  • テスト作業の定義は、「品質とそれに関連するリスクの実態を把握して、助言を提供するプロセスのことである
  • テスト作業は、
    • ビジネスゴールに沿っていなければならない
    • Sftware Development Life Cycle(ソフトウェア開発ライフサイクル)の一部である
    • 許容できる事案とコストの中で「適切な」欠陥を検出し、満足のいく助言を提供するように構造化された、コントロール可能なプロセスでなければならない
    • 将来の課題にに対しても準備を整えておくべきものである。将来の課題とは、例えば新しい技術の出現、情報システムの複雑化、市場投入期間の短縮などである
  • その考え方を一言で言ったものがBDTPI(Business Driven TPI)である
  • TPI NEXTのモデルであるBDTPIは、組織のビジネス主導要因によってテラーリングすることができるツールである
  • テスト作業を、もっとも低コストな品質対策と考えてはいけない
    • なぜなら、開発プロセスの後半に位置するため、バグの修正コストは飛躍的に高くなるからである
    • 予防が是正(テスト作業)よりも優れた措置であり、かつ予防のほうがコストもかからないことを忘れてはならない
  • テスト作業の難しさは、
    • 時間やコストに制約があるから全てをテストすることが不可能であること
    • 一方で「これで大丈夫だ」と言わなくてはならない点である
  • テストチームは、割り当てられた要件や関連するプロダクトリスクをもとに、もっとも重大なエラーをできる限り早い段階で、かつもっとも効率的な方法で見つけなければならない
  • テスト作業によってビジネス上で想定される損害が軽減できれば、テスト作業のコストはプロダクトリスクに対する保険掛け金とみなすことができる
  • したがって、テスト作業に割り当てられるコストの金額はプロダクトリスクによって変わる。
    • そのプロダクトが、組織、あるいは社会、個人の健康や生活にきわめて重要であれば、テストプロセスにそれを反映させなければならない

参考文献

  1. 実践ソフトウェアテスト考現学,大西建児,2009/08/27
  2. TPI NEXT? ビジネス主導のテストプロセス改善,薮田和夫、湯本剛、皆川義孝 (著)