滑り込みで東京オリンピックの抽選申し込みを済ませました、Webエンジニアの本間です。 どの日でもよいので抽選に当たって欲しいのですが、全部当たると困ってしまう、なかなか悩ましい気持ちになりました。
さて弊社では、現在開発中のプロジェクトのフロントエンドの実装において Vue.js を使っています。 今回、Vue.jsを使った実装をしている中で、複数ページにまたがるフォームの実装で調査した内容を紹介しようと思います。
続きを読むsudo実行時のカレントディレクトリや環境変数などの挙動について
おはこんにちばんわ！ ひさびさなユニファのインフラのすずきです。
最近八王子から、都心に引っ越してきました。
やはり通勤時間が短いと快適ですよね。
そして先日AWSのRe:Inventのチケット申込みが始まりましたね。
今年は行きたい…い゛ぎたい！！！！
と前置きはおいて今回は2度めのsudo関連のブログです。
前回のsudoの記事はこちら、
なんかそこそこ見てもらえてるみたいで、関連記事かけという強いプレッシャーの元今回書くことにしました。
では本題
続きを読むCore Imageをつかって画像処理はじめました
こんにちはiOSエンジニアのしだです。
写真の画像補正をiOS上でOpenCVを使って実装したらメモリの消費やCPU使用率が激しくつらい気持ちになりました。
CIFilterいいよって教えてもらって、Core Image をあまり真面目に使ったことがなかったのですが使い始めてみました。
はじめは ビルトインの CIFilter と CI Kernel Language を見ていたのですが、 CIKernel(source string: String) のAPIが非推奨になっていたため調べてみたら Metal Shading Language が使えるようになっていました。
WWDC2018によると今後はCI Kernel Language は非推奨になってくようです。
CI Kernel Language は実行時にコンパイルされるのに対して、Metal Shading のほうはアプリのビルド時にコンパイルされるのでシンタックスエラーもすぐわかるので便利です。 CIKernel 向けの Metal Shading Language を使ってみたので、いくつかサンプルを上げておきます。
続きを読むUniFa Developer's MeetUp＆LT会 #1を開催しました。
こんにちは。ユニファエンジニアの田渕です。
長かったGWも終わりましたが、みなさまどのようにお過ごしでしたでしょうか？？
今日は、少々前のお話になってしまいますが、4月に開催した「UniFa Developer's MeetUp＆LT会 #1」について お話していこうと思います。 合わせて、同じイベントについてPodcastでも話しておりますので、ご興味ありましたら聞いてみてください。
続きを読むスクラムとは何なのか？
はじめまして。認定スクラムマスター（なりたてほやほや）の渡部です。
スクラムには、必須とも言えるスクラムイベントや、定義された様々なルールが存在します。
多くの場合、まずは教科書のやり方に倣って導入されるチームがほとんどだと思います（実際、それをオススメします）が、 ただ書いてある通りに運用しているだけだと、「う〜ん、こんな場合はどうするんだっけ？」「そもそも何のためにやってるんだっけ？」「うまくいってる実感が無いけどどうすれば…」という疑問が出てくるときがあると思います。ありますよね？
そんなとき、「そもそもスクラムとは何なのか？」を理解しておくことで、最適な判断を行えるようになりますし、現状のやり方は何がイケてないのか？どうするべきなのか？を考えることができるようになります。
そこで今回は、下記2点について解説していきたいと思います。
本記事で解説する内容
- スクラムってそもそも何なのか？
- スクラムイベントって実のところ何をしてるの？
想定読者
- スクラムを勉強中の方
- スクラムを導入したが、いまいち各種イベントがしっくりこない方
- スクラムを自分のチームなりにアレンジしたい（or アレンジしたは良いが、これで良いか分からない）方
スクラムってそもそも何？
まずスクラムガイドを参照してみると、以下のように記載されています。
複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
と、アジャイル開発のフレームワークの1つであることがわかりますね。
さらに読み進めていくと、スクラムの3本の柱について記載されています。
僕なりにスーパーラフに説明すると次のようになります。
スクラムの3本の柱ってなぁに？
- 【透明性】
- あらゆるもの・ことが見える化されてることだよ！
タスクはもちろん、作業の進捗、プロセス、メンバーの幸福度、困ってることなど、本当にありとあらゆるものだよ！
- あらゆるもの・ことが見える化されてることだよ！
- 【検査】
- 見える化されたあらゆるもの・ことをチェックすることだよ！
- 【適応】
- 検査されたものの中で、悪いものは良い方向に、良いものはもっと良くなるよう、変更・調整をかけることだよ！
スクラムのあらゆるイベント・ルールは上記「3本の柱」の上になりたっていますので、 一言で、スクラムとは「あらゆる作業を見える化し、問題を特定し、着実にカイゼンを積み重ねるフレームワーク」と言えます。
上記を理解せずに運用してしまうと、せっかくのイベント、1つ1つのプロセスに価値を見いだせなくなってしまうでしょう。
スクラムを行ううえでは、（スクラムマスターは特にですが）チーム全員が上記を理解することが大切です。
そして当然の事ながら、スクラムマスターはチームが上記を理解できるよう、支援をすることが必要になります。
スクラムイベントで行なっていること
この章では、スクラムイベントで行なっていることを、上記「3本の柱」に当てはめて見ていきます。
激しくラフにまとめていますが、ざっくりイメージを掴んでいただければよろしいかと思います。
そうすることで、各スクラムイベントの目的とは何なのか？何をしているのか？の理解の助けになるなぁと個人的に思っています。
また、これは経験談ですが、自分のチームなりにアレンジする際にどう調整すれば良いのかも判断しやすくなると考えています（というかなりました）。
※各イベントで具体的に何をすべきか、どうするのが良いか等は、また別の機会にお話できればと思います。
スプリントプランニング
【透明性】スプリントで成し遂げることを決定し、
【検査】成し遂げると決めたことが、確実に完了できるかを詳細に確認し、
【適応】完了を阻害する要因がある場合、確実に完了できるよう調整・変更を加える
上記を行うことで、 確実にスプリントで完了できる計画をたてることが可能となります。
デイリースクラム（朝会）
【透明性】チームで毎日集まって、やったこと、これからやること、困ってることを話し合うことで
【検査】作業の進捗、問題、他チームメンバーの作業への影響などを把握する
【適応】-
上記を行うことで、 大きな問題になる前に気付くことができたり、困っているメンバーのフォローをすることができるようになります。
※デイリースクラムの場では状況の把握までを目的としています。 問題がある場合は、デイリースクラム終了後に時間をとり、必要な人のみで議論します。
スプリントレビュー
【透明性】スプリントで完成したもののデモや、最新のスケジュールを共有することで、
【検査】関係者の適切な確認・フィードバックを得ることができ、
【適応】必要に応じて、バックログの修正やスケジュールの調整、開発計画の見直しを行う
上記を行うことで、 スプリントごとに正しい方向性を都度確認しながら、手戻りの少ない開発を進めることが可能となります。
スプリントレトロスペクティブ（ふりかえり）
【透明性】次のスプリントを始める前にチームで、人 / 関係 / プロセス / ツールの観点でふりかえることで
【検査】良かったこと・改善が必要なことを特定、整理でき、
【適応】次のスプリントで実施すべきカイゼン計画を行える
上記を行うことで、 スプリントを経るごとに、一歩ずつですが着実に生産性を向上させることが可能となります。
おわりに
上記のように、スクラムでは【透明性】【検査】【適応】の「3本の柱」がいたるところに組み込まれており、（これがまた難しいのですが、）しっかりと理解し適切に運用することができれば、着実に生産性を上げられるようになっています。
これが、スクラムで生産性が向上する秘密というか仕組みです。
- スクラムとは何なのか？
- スクラムイベントでは何をやっているのか？
拙い文章ではありますが、上記を理解する上での一助となれば幸いです。
JaSST'19 Tokyo に参加してきました
ごあいさつ
こんにちは。 ユニファのQAチームの斉藤です。 今回ははじめてJaSST東京に参加してきました。 JaSST九州には参加したことがあるのですが、東京は規模がとっても大きい！そして今年のテーマは「AI」でした。 私は初日だけ参加しましたが、AIの基調講演、直近の業務に活かせそうなテスト技法や開発プロセスのセッションを回らせて頂きました。 以下、レポートになります！
JaSST'19 Tokyoとは
http://jasst.jp/symposium/jasst19tokyo.html
NPO法人ソフトウェアテスト技術振興協会（ASTER）さんが開催するソフトウェアテストシンポジウムです。 海外から著名なエンジニアを招いての招待講演、テスト技術者や研究者による研究・実践・ツール適用事例の発表、登壇者と参加者の交流会などもあります。
弊社リーダーの鶴岡も、QAエンジニアのキャリアデザインセッションに登壇しました（＾＾）＜ お疲れさまでした！
基調講演：AI-Driven Testing:A New Era of Test Automation
Ultimate Software社のTariq Kingさんによる講演です。 AIや機械学習の概要から、AIにテスト設計～テスト実行してもらう時のイメージ、AIテストの限界についてお話をされてました。 AIにテストをしてもらう時、以下の流れになるようです。
インプット → 魔法の箱 → アウトプット
まずインプットとして、ドメイン知識や仕様書の情報を与えます。 インプットを受け取る魔法の箱（AIの心臓部）はプログラムで、インプットを元に、テスト設計やテスト実行を行います。（これが最初のアウトプットになります。） Tariq Kingさんいわく、最初のアウトプットはおそらく散々なもの、人間の期待とずれたものになるだろう、とのことです。 そして、そのアウトプットを人間が評価します。 評価を、魔法の箱（AIの心臓部）へ学習させます。 学習によって、魔法の箱（AIの心臓部）は自分自身をアウトプットの精度があがっていく、という流れだそうです。 学習のために必要な、アウトプットの評価は、私たちの人間の役目になります。
AIテストに関しては、テスト技術者は「AIテストのアウトプットの評価」と「評価を学習させる」という関わり方をしていくのかな…と感じました。 講演後の質疑応答、AIのテスト結果に対して自信をもってＯＫを出すには？という質問に対して、Tariq Kingさんは
- ブラックボックス（魔法の箱＝AI）の中を理解しなければならない
- またテストのどこでAIを適用するか？を考えなければならない
と回答されてました。 テスト業界で大きな注目を集めるAI。AIがもたらす変化に適応できるよう、少しずつでも学んでいきたいなと感じた講演でした。
セッション：テストプロセス改善「XDDPにおけるテストプロセス」
AFFORDD T4研究会の長友さんによるセッションです。 派生開発の特徴や起こりやすい問題点と、それに対応した開発プロセスであるXDDPについて説明されてました。 派生開発の特徴は
- 短納期
- 仕様書がないもしくは更新されてない中で部分理解を強いられたまま変更や追加
- 「一人プロジェクト」になりやすい
これらは現場でよく見かける状況なので、イメージしやすかったです。 このような派生開発の振り返りで、「もっと全体を理解してから進めればよかった」という感想がでるそうです。（たしかに、聞いたことあります。） それに対して「全体を理解すれば問題が解決するのか？」という問いかけが、すごく印象に残りました。
全体理解するための資料や時間もない、アサインされた担当者によってはドメイン知識も少ないかもしれない、 XDDPはそれらの問題に対応しやすいプロセスや成果物で構成されています。 特に適用事例の中でご紹介された「変更要求T型マトリクス」は開発要件・機能・モジュールという点から、影響範囲を開発者とQAが認識合わせられるとのことで、今後、自分が仕様をよくわかっていないシステムのテストをする時には、作ってみたいなと思いました。
チュートリアル：中級者セッション「JSTQB Advanced Levelテストアナリストのシラバスでテストを学ぼう」
JSTQB技術委員会の須原さん、福田さんによる、JSTQB Advanced Levelテストアナリストのシラバスを使って、テスト技法を学ぶセッションです。
- 同値分割法
- 境界値分析
- 原因結果グラフ法
- 組み合わせテスト技法（ペアワイズテスト / クラシフィケーションツリー法）
- ドメイン分析
について、講義とワークの二本立てで学びました。今回一番楽しみにしていたセッションです。
JaSSTのテスト技法のセッション参加は２回目ですが、前回も今回も感じたことは、テキストの図や説明がとても分かりやすい！ということ。 ひとつひとつのテスト技法について、他テスト技法とのメリット・デメリット・使いどころの比較があってイメージしやすかったです。
最初は、同値分割法と境界値分析について。 JaSST九州では焦って小さなミスが多かったのですが、今回は落ち着いてワークに取り組めました。 今回、［参考］として同値分割の「ズームインとズームアウト」、「どこまで同値分割する？」という問いかけがありました。 「どこまでテストするか？」は、現場でも意見分かれる問題かと思います。 これに対して、テスト技法を用いながら「どこまで？」を適切に設定することがテストアナリストに求められるのだろうな、と感じました。 日常のテスト業務でも「これはどこまでテストする？」と自問しながら取り組んでみると良いかもと思いました。
次に、原因結果グラフ法。 まず結果を見つけ、その結果に影響する原因（条件）を見つけ、結果と原因（条件）をAND / OR / NOTの関係性で結ぶグラフです。 これだけだとテストケースに落とし込みにくいので、グラフにした後、デシジョンテーブルに変換します。 私がテストを考える時、原因（条件）から洗い出して途中で膨大になったり、条件と条件の関係性で混乱しやすいので、これをうまく使えるようになるとテスト設計時にすごく楽になるなと感じました。
この他にも、組み合わせテスト技法のクラシフィケーションツリー法や、ドメイン分析などを学びました。セッションの残り時間の関係で、後半は駆け足になりついていくのがやっとでした。 （後で復習が必要です…！！）
テスト技法は、テスト設計をうまく行う手助けになるやり方。とテキストに書いてありました。 私はまだまだテスト技法を使いこなせていないので、ひとつひとつ勉強して現場のテストに活かしていけたらなと思います。
情報交換会
中級者セッションのワーク、ドメイン分析でわからないところがあったのですが、講師の方に声をかけるタイミングがつかめずにいた私。 初日終了後の情報交換会に講師の方も参加されていたので、思い切って声をかけてみました。
そうしたら、講師の方、テスト業界の先輩QAエンジニアさんが一緒にテキストを見て下さり、「たしかにここは疑問に感じるかも…」「テキストのレビューで私ここ指摘した気がする…あの時は…」など、皆であーでもないこーでもないとプチ勉強会みたいな雰囲気に。
疑問もスッキリ理解でき、「他の人と疑問を共有しながら考えるのって、楽しいな」と感じました。
反省
次回は、人見知りを克服して、いろんな人に話しかけるぞ。
