MacPortsとHomebrewはどっちが良い？
Macで色々とツールやらソフトウェアをいれるにあたって
MacPortsとHomebrewの２種類のパッケージ管理システムが
あって、どちらが良いのか調べてみたメモ。
以下、ブログによると、以下の理由からHomebrewの方がオススメとのことでした。
MacPorts と比べて Homebrew は依存関係でインストールされるソフトが少ないためか、パッケージ管理システムとしての人気が高まってきています。
MacPorts は、Mac に最初から入っているソフトウェアを無視してパッケージが依存するソフトを新規でインストールするという性質を持っていますが、Homebrew は極力 Mac に入っているものを使うように作られています。ゆえに、パッケージ導入時のシステムへの負担や、インストールにかかる時間が比較的少なくて済むようです。
また、Homebrew はスーパーユーザでコマンドを実行する必要が無く、一般ユーザー権限で使うことが出来ます。
また、他のブログでも以下の理由からMacPortsよりもHomebrewの方がオススメとのこと
個人的に大きかった理由としては、ディスク容量を食うこととである。MacPortsでは基本的に現在インストールしているOS Xのシステムに依存せず、自身で必要なパッケージをインストールする傾向にあり、OS X本体にあるソフトとMacPortsにインストールされるパッケージが重複することが往々にしてあった。
これはOS Xの環境への依存が少なく、OS X環境とMacPorts環境をある程度切り分けられるという利点はあるが、インストール時間の増大やディスク容量の圧迫の原因になるほか、パッケージ依存が複雑になる傾向にある。また、パッケージが増えれば増えるほどアップグレードの際に時間がかかるようになってしまう。
そういった不利な部分が出てきたため、そういった弊害が少ないとされるHomebrewへの移行を決断したのである。
まとめ
MacPortsよりもHomebrewの方がオススメ
- OS X本体のソフトをなるべくを利用してくれるのでインストールにかかる時間やディスク容量に優しい
- sudoでコマンドを実行する必要が無く、一般ユーザー権限で使うことが出来る
Macを買ってからやったことメモ
Macを買ってからやったことメモ
著者：ふじさわゆうき
更新日:2016/09/07
先日、MacBook Airを購入しました。
バッテリーの持ちがとても良いです（12時間持続するとか）
今後、Macを買い換えることも考えて、セットアップのメモを
残しておきます
バージョン情報
MacBook Air 1600/13.3 MMGG2J/A
(1) .bash_profileの作成
$ vi .bash_profile
# custom prompt setting PS1="[\u@\w]$" # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs ## PATH=$PATH:path export PATH
$ source .bash_profile
(3) Homebrewのインストール
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
(5)gitのインストール
$ brew install git
ロジカルシンキングについて再考する
著者：ふじさわゆうき
更新日:2016/07/27
システムエンジニアになって、かなりの年月がたちました。
最近は、Webの世界からアプリに世界が広がったことで、多くのことを業務で扱いますが、毎日覚えることが沢山あって大変です（そもそも何を勉強したらよいのかわからないときも・・・）。
そういう状況では、基礎的な学習しておくことで、業務での能力向上が見込めると考え、基礎的な勉強に1日1時間くらい時間を作ることにしました。
まずは、システムエンジニアの基礎である「ロジカルシンキング」について再考してみることにします。
以下、何回かに分けて「ロジカル・シンキングー論理的な思考と構成のスキル」を要約します。
本書は、私が大学院のときにコンサル会社に勤めていた友人から勧められたもので、修士論文を作成したり、レポートを作成するのにとても役に立った非常に良い本です。
対象書籍
ロジカル・シンキング―論理的な思考と構成のスキル (Best solution)
- 作者: 照屋華子,岡田恵子
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2001/04/01
- メディア: 単行本
- 購入: 37人 クリック: 962回
- この商品を含むブログ (243件) を見る
第1章 相手に「伝える」ということ
- ビジネスの世界では世界では、自分の考えや提案が、
- 相手の頭に正しくインプットされ、
- 思考回路の中で正しく理解され
- 自分が望む反応が出てくる
- までの時間が勝負になる
- 大事なことは「あなた」が大切だと思っていることではない。それが相手にとって期待されている「メッセージ」になっているかどうかである
- 自分の考えを論理的に伝える第一歩。それは「いきなり伝える中身について考え無いこと」だ
相手に伝えるべきメッセージとは？
- メッセージとは何か。以下3つの条件を満たしているものだ
- 答えるべき課題（テーマ）が明確であること
- その課題に対して、必要な要素を満たした答えがあること
- そのコミュニケーションの後に、相手にどのような反応をしたもらいたいのか、つまり相手に期待する反応が明らかであること
- 「課題」「答え」「相手に期待する反応」の3点セットが、本書で定義するメッセージである
- つまり、人の話を聞いたときに、「課題」はこれで、それに対する相手の「答え」はこれで、「自分にこれをしてほしい」ということが頭に明確に残ることをクリアして初めてメッセージとなる。
- 重要なことは、①課題（テーマ）を確認する、②相手に期待する反応を確認する、という2つの確認作業をすることだ
確認1：課題（テーマ）を確認する
- 自分が相手に答えるべき課題は、何なのか、確認しよう
- 相手が「今検討すべき課題」と認識していなければ、議論の土俵にすら登れない
確認2：相手に期待する反応を確認する
- 相手にどのようにしてもらいたいのか、どんな反応を引き出したいのか、という期待成果の無いコミュニケーションは「独り言」でしかない
- 伝えることによって、相手に理解してもらったり、相手のニーズや意見を引き出したり、あるいは相手に何かのアクションを取ってもらうなど、相手になんらかの「反応」をとってもらうことが最終目的であるはずだ。伝えることは手段であり、目的ではない！
- ビジネスにおいて、相手に期待する反応は以下、3つにまとめることができる
- 相手に理解してもらう
- 業務連絡、事務連絡はこのケースに当てはまる
- 相手に「意見や助言、判断などをフィードバック」してもらう
- ヒヤリングやテストマーケティングで顧客のニーズを引き出す場合がこれにあたる。社内での会議や報告なども該当する
- 相手に行動してもらう
- キャンペーンへの参加依頼などを実施する場合、アンケートに答えてもらう場合はこのケースに当てはまる
- 同じ課題であっても、相手に「理解」してもらいたいのか、「意見や助言、判断をフィードバック」してもらいたいのか、「アクション」を取ってもらいたいのか、という相手に期待する反応を確認することによって、答えとして伝えるべき深さや広がりは大きくことなることは想像できるだろう
何を言えば「答え」になるのか？
- 以下の質問にイエスと答えられるかどうかが、課題に対する答えの要素があるのか、無いのかのチェックポイントである
- 課題に対して、伝え手が、どのようなアクションを取るべきだと言っているのか？
- イエスなのか？ノーなのか？
- 結論に至った根拠に納得感があるか？
- 結論がアクションの場合、具体的なやり方が示されているか？
- 自分がそのアクションについて部下に指示を出す場面を想定した時、指示の中身が具体的にイメージできるか？
- 「結論」 -> 「根拠」 -> 「方法」
- 結論: 課題に対する答えの核をなすもの。何かのアクションを提示する場合と、評価や判断を表すものの2つがある
- 根拠: その結論にどうして至ったのかという理由。事実と判断の2つがある
- 方法: 結論がアクションの場合、相手がそのアクションを取れるよう、具体的なやり方を提示するもの
なぜ、相手に自分の「答え」が通じ無いのか？
理由1. 結論が「自分の言いたいことの要約」になってしまっている
- 「要するに、どっちなの？」という発言が相手から出てしまっては、コミュニケーションは失敗
- 本当に答えるべき課題に対する答えの核になっているかを常に見直すべき
- いかなる場合も、課題と答え、答えの核となる結論は整合していなければならない
理由2. 「状況に応じて」「場合によっては」の基準が曖昧
- 相手に結論が明確に伝わる、という点で留意すべきなのは、どうにでも解釈できるような曖昧さを排除する、ということだ
- 「状況によっては」「場合によっては」と曖昧なな言葉ではなく、「売り上げが前年度比105%を上回ったら」など定量的な言葉にしたり、定性的な中身を具体的に伝えるかによって、明確にすることである
根拠が伝わらない時の3つの落とし穴
- 結論が正しくてもなぜそれが正しいのか、すなわち根拠が正しいと説明できなければ相手を納得させることはできない
- 以下、3点を留意するだけでも、その精度は高まる
- 「Aが必要だ、なぜならAが無いからだ」では、相手は納得しない
- 「それは事実なのか？それとも判断仮説なのか？」と思わせた途端に信ぴょう性は半減する
- 例えば、「当社の売り上げ不振の原因は、時代の空気をうまくとらえていないからだ」と言われた場合に「うまくとらえていない」は「事実なのか判断なのか」が聞き手が判断できない。もし、事実だとすれば、具体的にどのような現象をさしているのか示すべきだし、そう判断したのであれば、根拠を明快に示さなければ根拠を説明したことにならない
- 与えられた課題に、答えを出すに上で事実に対してどうみるのか、という判断軸、もしくは前提条件が示されていない。
方法が伝わらないときの2つの落とし穴
- 他の会社、10年前でも通用するような公理では人は動かない
- 教科書に書かれているような公理をいうのではなく、公理を自分の企業に当てはめて、具体的に何をすべきかを伝えなければ意味が無い
- 修飾語で物事が具体的になることはない
- 自分で方法を書いてみて、どうも具体的ではないと思ったら、それは問題が具体的に解けていないということである
- 具体的に書くためにはどうすればよいのか。そのためにはなぜなぜすることが重要である
- 客からのクレームが多い > なぜ？
- 商品の故障そのものより対応の仕方に不満が高い > なぜ？
- 販売員は、販売には熱心でも修理対応には関心が無い
- 以上のように「なぜそうなっているのか」の質問を繰り返すことで初めて具体的な方法がみえてくる
- 具体性があるかどうかをチェックするときにおすすめなのは、「自分がその実施者の立場だったら、何を知っていれば具体的に動けるのかと自問自答してみることだ」
- どうやって？どの程度？いつからいつまでに？誰が主体で？ etc
DeNA Technology Conference 2016に行ってきました
著者：ふじさわゆうき
更新日:2016/02/04
DeNA Technology Conference 2016（主催: DeNA TechCon）に参加してきました！！
DeNAのこれからに期待の持てるプレゼンばかりでワクワクを感じることができたカンファレンスでした。
以下、カンファレンス概要、プレゼン資料、会場の雰囲気、参加したセッションの内容をまとめましたのでご参考ください！！
目次
- カンファレンス概要
- プレゼン資料
- 会場の雰囲気
- 13:30〜「DeNAのネイティブアプリ開発」
- 14:30〜「DeNAが取り組むSWETの道」
- まとめ
- 関連記事
カンファレンス概要
- 公式ページ #denatechcon
以下、４つのカテゴリ毎に平行して行われる形式のカンファレンスでした。
- 『DeNAが切り拓く最前線』
- 『DeNAの新しい挑戦』
- 『DeNAを支える技術』
- 『DeNAのゲーム開発』
DeNAが技術に特化した大規模なイベントを主催するのは初めてということでした。
以下、登壇者の一部です
- DeNA システム本部 技術開発室 奥 一穂
- DeNA オープンプラットフォーム事業本部 副事業本部長 山口 徹
- DeNA システム本部 技術開発室 小倉 豪放
- DeNA 執行役員 Japanリージョンゲーム事業本部 副事業本部長 池田 修
- DeNA 取締役 川崎 修平
- DeNA 執行役員 システム本部長 木村 秀夫
etc
後日、プレゼン映像も公開されるということで期待しましょう
＊一部、公開できないプレゼンもあるみたいですが。
プレゼン資料
2016/02/04時点で公開されているプレゼン資料です。
＊見つけ次第、順次、更新します
会場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のアプリ開発って遅くね→おっしゃる通りです」みたいなスライドがあった
- ２０１３年１１月からネイティブ開発を始めるにあたってしたことは、１７項目で１５０人以上をスキル評価したこと
- 評価の結果、３人しかネイティブ開発できるエンジニアがいなかったらしい
- メンバーの育成にあたってハードルになる部分は、「非同期プログラミング」と分析していた。なぜなら、その点がウェブアプリと大きく違う点だと感じていたから
- プログラミングパラダイムの変化をDeNAに求めたとのこと。同期（Web、サーバー）から非同期（ネイティブアプリ）へ
- マルチメディアも大きく違う。サウンドデータも開発者が悩まなければいけない
- Webは全データを全ユーザが共有できるが、ネイティブは、端末のリソースのみが利用できる点も違う。リソースマネジメントの違い
- チートも違う。ネイティブアプリはチート（不正利用行為）されやすい環境。ユーザーの手元にある
- DeNAの戦略としては、Webゲームの成功体験のある技術者をアプリ開発者に転身させること。アプリ開発者に人員を投下すること。勉強会を社内で開催して成長させること。ネイティブの難易度の高い技術要素はやらないと決めること。などの施策をやってきた
- サウンドなど、育成困難な部分は内製しないなど「やらないことはやらない」との割り切りもしてきたとのこと
- DeNAで採用しているゲームエンジンは２つ。UnityとLiftEngine
- 3DゲームはUnity。2DはLiftEngineという使い分けをしている
- サーバーサイドは、SakashoとIRISの２つ
- Sakashoはゲームアプリ向けのBaaSのこと
- IRISは、マルチプレイを実現するサーバーのこと
- ネイティブアプリの開発力を上げるために、サーバーサイド基盤であるSakashoで統一とすることとした。
- サーバーサイドに工数をかけない方針
- 新規タイトルは、３０−４０人で作成する規模。小規模開発はやらないこととした。過去の経験として、小規模開発してうまくいった場合に、大規模化するのが難しいことを踏まえての方針。始めから大規模前提でチームを構成することにしている
- 小規模開発でやるのは、最近だと危ないという考え。アイディア一つでヒットアプリを出すのは、最近、難しくなっているということらしい
- 開発プロセスをDeNAではカッチリしている。マイルストンレビューというものを実施していて、Proto/α/β/RCという段階を踏んでリリースするプロセスになっている
- α版では、基本となるゲームが体験できるもの。例えば、装備、ガチャの機能。１画面だけ、リリース品質にしてみる。１画面のどこかのパーツができていない状況だとレビューは通さない
- β版は、チュートリアルをやってみてゲームにのめりこめるかどうかをみるなど。１０〜３０分やってみて面白さが伝わってこないとレビューで指摘する
- 新規タイトルだと、新規バグが出ない（２日くらいテストしてみて）状態をクリアしないと、リリースはさせない体制
- ネイティブ開発を始めてみて、コールバック使いすぎ問題がネイティブ開発においては多発したらしい。コールバックによる通知と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のメンバー３名が著者のselenium本が2016/2/2に発売されるらしいので手に入れたいと思います。
以下、発表メモ
- SWET = Software Engineer in Test
- SWETの定義では、WIKIではQAのジョブだと定義されている(Wiki > Set > Technology)。しかし、googleのテスティングブログでは開発者の役割としている。SWETは、開発者のコードがテストしやすくする環境を提供するのが役割
- Software Engineer in Test, a Quality Assurance job title in some software companies
- The SET or Software Engineer in Test is also a developer role except their focus is on testability.
- 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の実機検証がブラウザから可能になるという便利なもの
- STFの操作にAPIが提供されるようになっていて、JenkinsからSmartphoneのテストが自動実行できるようになっている。これは画期的！！
まとめ
DeNAのネイティブアプリ開発とSWETという自動テストグループについてブログに書きましたが、どちらもこれからの将来性に期待の持てるプレゼンでワクワクを感じることができました。これからも、DeNAの技術動向に注目していきたいと思います。
来年もDeNA Technology Conferenceが開催されることを期待しています！！
＊それにしても、懇親会のお寿司は美味しかったです。ご馳走さまでした！
関連記事
わなみんさんが手書きでまとめた資料がすごかったので掲載しておきます
TechCon2016のLT8名分グラレコしました！音声小さめ&スライド見えなかったけどエンジニアさん方の熱意は話から伝わりました！同じチームの人も登壇してて嬉しかった！#denatechcon #graphicrecord pic.twitter.com/Gh1OGuxMBZ
— わなみん (@wanami3103) 2016, 1月 29DeNA TechCon 2016のTogetter
DeNA Tech Con2016に行って来ました yoshida 261
下記セッションについて書いたブログです。
- 爆速でAndroidアプリをビルドするための仕組み(TOYAMA YOSAKU)
- DeNAが取り組むSoftware Engineer in Test(NAKAGAWA MASAKI)
- DeNAのマルチプレイゲーム用サーバ「IRIS」(IKEDA OSAMU)
- カジュアルトーク
- チラシルの話(途中から参加したためタイトル不明)
- シニアエンジニアが新規サービス立ち上げたあれこれ（とかなんとか）
DeNA Tech Con 2016に行ってきました！ spangled shalalala blog
下記セッションについて書いたブログです。
- Webを速くするためにDeNAがやっていること〜HTTP/2と、さらにその先〜(KAZUHO OKU)
- DeNAが取り組むSoftware Engineer in Test(NAKAGAWA MASAKI)
DeNA TechCon 2016にデザイナーだけど参加してきました LOGzeudon
下記セッションについて書いたブログです。
- DeNAのネイティブアプリ開発
- Webエンジニアが学ぶ自動運転を支える技術
- Anyca におけるUIフレームワークとスマホによるドア操作の仕組み
- B2B2Cなヘルスケアサービスの作り方
- チラシルiOSでの広告枠開発
- MERYで CM 乗り切った話〜女の子のかわいいを守るために〜
- iOS レガシーコード改善ガイド〜マンガボックス開発における事例〜
Mac、AtomでC#のIntelliSense機能を使えるようにする
著者：ふじさわゆうき
更新日:2016/01/14
UnityでC#の開発をできるようにする必要があったのでそのメモ
前提環境
AtomでC#を扱うのに必要なもの
- omnisharp-atom
- $ apm install omnisharp-atom
- .NET Version Manager (DNVM)
- $ curl -sSL https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.sh | DNX_BRANCH=dev sh && source ~/.dnx/dnvm/dnvm.sh
- $ brew tap aspnet/dnx
- 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に行ってきました。
その話の中で、「テスト自動化パターン言語」が紹介されていたので調べてみました。
テスト自動化パターン言語とは
- .reviewrc(コミュニティ)により提唱されている自動化のパターン
- 開発だとアンチパターンが有名だが、それのテスト自動化におけるパターンだと思うのが一番わかり易い。例えば、開発のアンチパターンは以下、２冊がおススメ
テスト自動化パターン言語の定義は次の通り
テスト自動化において、みんなが共通してハマることが結構ある（良いものも、悪いものも）。それらの共通点を分類してパターン言語としてまとめたものがテスト自動化パターン言語である。
パターン言語の狙いとしては、暗黙化されている失敗体験や成功の要因をわかりやすい形で共有することで「体系化された知見が少なく伝達が難しい」「上手くやれる人が少なく活動が手探り」という課題を解決することを目指している
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 ガイドライン
以下、３つのカテゴリにわけで、詳しく解説している。デスクトップアプリケーション開発において役に立ちそう
1. 優れた UX の設計
2. UX チェック リスト
3. 成功する UI の作成
グーグル 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の楽しい面や人間的な性格は邪魔をしません。
感想
それにしても、Windows、Googleともに会社として理念やUXを明確に掲げているところが素晴らしいですね。チームマネジメントでも参考になりますし、個人の仕事でもこういうものを目的として掲げておいて日々の業務や、勉強会の選び方に活かすのは大事かなと思いました
