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でも話しておりますので、ご興味ありましたら聞いてみてください。

UniFa Developer's Podcast

スクラムとは何なのか？

はじめまして。認定スクラムマスター（なりたてほやほや）の渡部です。

スクラムには、必須とも言えるスクラムイベントや、定義された様々なルールが存在します。

多くの場合、まずは教科書のやり方に倣って導入されるチームがほとんどだと思います（実際、それをオススメします）が、 ただ書いてある通りに運用しているだけだと、「う〜ん、こんな場合はどうするんだっけ？」「そもそも何のためにやってるんだっけ？」「うまくいってる実感が無いけどどうすれば…」という疑問が出てくるときがあると思います。ありますよね？

そんなとき、「そもそもスクラムとは何なのか？」を理解しておくことで、最適な判断を行えるようになりますし、現状のやり方は何がイケてないのか？どうするべきなのか？を考えることができるようになります。

そこで今回は、下記2点について解説していきたいと思います。

本記事で解説する内容

• スクラムってそもそも何なのか？
• スクラムイベントって実のところ何をしてるの？

想定読者

• スクラムを勉強中の方
• スクラムを導入したが、いまいち各種イベントがしっくりこない方
• スクラムを自分のチームなりにアレンジしたい（or アレンジしたは良いが、これで良いか分からない）方

スクラムってそもそも何？

まずスクラムガイドを参照してみると、以下のように記載されています。

複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

と、アジャイル開発のフレームワークの1つであることがわかりますね。

さらに読み進めていくと、スクラムの3本の柱について記載されています。
僕なりにスーパーラフに説明すると次のようになります。

スクラムの3本の柱ってなぁに？

• 【透明性】
  • あらゆるもの・ことが見える化されてることだよ！
    タスクはもちろん、作業の進捗、プロセス、メンバーの幸福度、困ってることなど、本当にありとあらゆるものだよ！
• 【検査】
  • 見える化されたあらゆるもの・ことをチェックすることだよ！
• 【適応】
  • 検査されたものの中で、悪いものは良い方向に、良いものはもっと良くなるよう、変更・調整をかけることだよ！

スクラムのあらゆるイベント・ルールは上記「3本の柱」の上になりたっていますので、 一言で、スクラムとは「あらゆる作業を見える化し、問題を特定し、着実にカイゼンを積み重ねるフレームワーク」と言えます。

上記を理解せずに運用してしまうと、せっかくのイベント、1つ1つのプロセスに価値を見いだせなくなってしまうでしょう。

スクラムを行ううえでは、（スクラムマスターは特にですが）チーム全員が上記を理解することが大切です。

そして当然の事ながら、スクラムマスターはチームが上記を理解できるよう、支援をすることが必要になります。

スクラムイベントで行なっていること

この章では、スクラムイベントで行なっていることを、上記「3本の柱」に当てはめて見ていきます。
激しくラフにまとめていますが、ざっくりイメージを掴んでいただければよろしいかと思います。

そうすることで、各スクラムイベントの目的とは何なのか？何をしているのか？の理解の助けになるなぁと個人的に思っています。

また、これは経験談ですが、自分のチームなりにアレンジする際にどう調整すれば良いのかも判断しやすくなると考えています（というかなりました）。

※各イベントで具体的に何をすべきか、どうするのが良いか等は、また別の機会にお話できればと思います。

スプリントプランニング

【透明性】スプリントで成し遂げることを決定し、
【検査】成し遂げると決めたことが、確実に完了できるかを詳細に確認し、
【適応】完了を阻害する要因がある場合、確実に完了できるよう調整・変更を加える

上記を行うことで、 確実にスプリントで完了できる計画をたてることが可能となります。

デイリースクラム（朝会）

【透明性】チームで毎日集まって、やったこと、これからやること、困ってることを話し合うことで
【検査】作業の進捗、問題、他チームメンバーの作業への影響などを把握する
【適応】-

上記を行うことで、 大きな問題になる前に気付くことができたり、困っているメンバーのフォローをすることができるようになります。

※デイリースクラムの場では状況の把握までを目的としています。 問題がある場合は、デイリースクラム終了後に時間をとり、必要な人のみで議論します。

スプリントレビュー

【透明性】スプリントで完成したもののデモや、最新のスケジュールを共有することで、
【検査】関係者の適切な確認・フィードバックを得ることができ、
【適応】必要に応じて、バックログの修正やスケジュールの調整、開発計画の見直しを行う

上記を行うことで、 スプリントごとに正しい方向性を都度確認しながら、手戻りの少ない開発を進めることが可能となります。

スプリントレトロスペクティブ（ふりかえり）

【透明性】次のスプリントを始める前にチームで、人 / 関係 / プロセス / ツールの観点でふりかえることで
【検査】良かったこと・改善が必要なことを特定、整理でき、
【適応】次のスプリントで実施すべきカイゼン計画を行える

上記を行うことで、 スプリントを経るごとに、一歩ずつですが着実に生産性を向上させることが可能となります。

おわりに

上記のように、スクラムでは【透明性】【検査】【適応】の「3本の柱」がいたるところに組み込まれており、（これがまた難しいのですが、）しっかりと理解し適切に運用することができれば、着実に生産性を上げられるようになっています。

これが、スクラムで生産性が向上する秘密というか仕組みです。

• スクラムとは何なのか？
• スクラムイベントでは何をやっているのか？

拙い文章ではありますが、上記を理解する上での一助となれば幸いです。

Flowplayer の API を使って動画をアップロードしてみた

こんにちは、 rightgo09 です。

今回は、動画やライブの配信サービス Flowplayer の API を使って動画をアップロードしてみました。

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エンジニアさんが一緒にテキストを見て下さり、「たしかにここは疑問に感じるかも…」「テキストのレビューで私ここ指摘した気がする…あの時は…」など、皆であーでもないこーでもないとプチ勉強会みたいな雰囲気に。

疑問もスッキリ理解でき、「他の人と疑問を共有しながら考えるのって、楽しいな」と感じました。

反省

次回は、人見知りを克服して、いろんな人に話しかけるぞ。

良いプロダクトは良いチームから

　こんにちは、ユニファCTOの赤沼です。最近は私自身でプロダクションのコードを書くことはほとんどなくなり、チーム作りがミッションとなっているわけですが、少し前の Podcast で if-up 2019 というカンファレンスの参加レポートに含める形でチームについて話したので、改めて要点を書いてみたいと思います。

　ちなみにその時の Podcast はこちらです。

podcast.unifa-e.com

結局はチームが全て

　Podcast のタイトルにもしていて、いきなり結論からになりますが、プロダクト作りにおいては結局はチームが全てなのだと思っています。全く新しい技術を生み出すための研究や、エンジニアが一人でプロダクトを作っていくようなケースでは別でしょうが、ユニファのようにチームで自社サービスを作っていく場合には、技術的な問題というよりはチーム作りの良し悪しがプロダクトの成否を分けるのだと思います。プロダクト作りは総合力です。もちろん技術力は重要ですが、とにかく高い技術力があれば必ず成功するかと言えば、そうではありません。if-up で使われていた言葉を借りれば、最近のプロダクト作りは「ものづくり」から「ものごと作り」へと変わってきて、高いレベルの技術が使われていれば良いわけではなく、いかにユーザーの良い体験を作れるかが勝負になってきています。そうした中で、いかに目線を合わせ、技術至上主義にならず、いかにユーザへの良い体験を作ることにフォーカスできるか、その為には時にはエンジニアとしての技術面でのこだわりを妥協できるか、ひいては事業を加速していくためのエンジニアリングができるチームを作っていけるかということが、勝負になってくるのだと思います。どんなプロダクトができていくかは、どんなチームができているか次第ということです。

世界一を本気で目指すチームを

　チーム作りの目線を合わせていくという点でも、メンバーが皆本気で世界一を目指しているか、というのはかなり重要です。絵空事ではなく、本気で世界一になれると思って目指すチームを作る、またそういう環境に身を置くことは、個人の成長という点でも大きく影響してきます。ユニファでは創業時から代表の土岐は、グローバルで No.1 になる、と内外に向けて発信しています。やるからには本気で世界一を目指す。世界一になるには世界一のプロダクトが必要です。プロダクト開発に責任を負う開発チームとしては世界一のプロダクトを作っていく必要があるのです。本気で世界一を目指し続けるCEOと仕事ができる環境はあまり多くはないのではないかと思います。せっかくそういうCEOと仕事をしているのですから、私自身も改めて本気で世界一を目指したいと思っています。その為にはいかに良いチームを作っていけるかが勝負です。単純な技術レベルやチーム規模で行ったらそれこそ Google や Amazon などの大企業には太刀打ちできませんが、ユニファがサービスを提供する領域において、世界一のユーザ体験を提供するということであれば、その可能性は大いにあると思っています。

保育をハックする

　プロダクトを開発していく上では、様々な課題をクリアしていく必要があります。技術で簡単に解決できるような課題もあれば、解決の道筋がなかなか見えないような難題もあります。そうした時にも、その過程を楽しむ姿勢を持っていたいと思うのです。最近ではハックという言葉は色々なところで使われていますが、開発チームの指針としても、「保育をハックする」というのを打ち出しています。ハックするというのは、様々な制約を打破・回避していくことを、知的な難問を解いていくものと捉える、能動的、創造的行為です。ユニファにおいても保育に関する様々な制約、慣習、課題を、スキルやチームワーク、保育に関する知見によって能動的、創造的に解決していく、またその過程を楽しむということを意識していきたいと思うのです。

まとめ

　ユニファの開発チームも人数が増えてきて、今年中にはさらにチーム規模が大きくなっていきます。そうした時に、いかに少人数だった時の良い空気を残していけるか、また、改善すべきだったところはこのタイミングで改善していけるかが今後の課題となってきます。その為にも様々な施策等も行なっていきたいと思っていますので、また機会があればどんなことをやっているかは紹介できればと思います。

　また、ユニファでは一緒に世界一を目指してくれるエンジニアも募集中ですので、興味のある方はぜひご連絡ください。

ユニファ 株式会社の採用/求人 | 転職サイトGreen(グリーン)

深海へと

こんにちは。 カメラマンからデザインチームへと部署異動をした三好です。

世間でいうアラフォーと呼ばれる部類に属してしまった今日この頃、ようやく自分自身のことが正確に見え始めてきていると感じています。

何に対して生きている実感を得られるのか、奥深くに潜む欲求が満たされる瞬間、どの種類の苦痛であれば耐えられるのかなど、ひっくるめて適正というものを見極めた結果デザインという道に辿り着きました。

部署異動について

異動をしてまず思ったことは、見る角度が変わるだけで会社がまるで違う生き物に見えてくるということに驚きました。

「井の中の蛙大海を知らず」というたとえが正しいかどうかはわかりませんが、日々の業務に追われその慌しさを盾に、自ら心地の良い壁を作り出して生活していたような気がします。

その無意味な壁を壊すことができただけでも異動した価値はあったと思います。

もちろん周囲の方の理解や後押しがあったからこそなのですが。

写真とデザインについて

写真とデザインの少し似ているところを話したいと思います。

フォトグラファーを大きく分けると2種類存在します。ビジネスサイドのフォトグラファーと自己表現の手段としてのフォトグラファーです。

この2種類は全く性質が異なります。そしてデザイナーに関してもやはりアーティストと比較されることがあります。

社会に属している限り、利益に携わる限りはデザイナーもフォトグラファーも純粋な美を追い求めることはできません。自由に飛び回ることはできず、常に制限のある世界で生きています。

当たり前ですが他の職種と同じようにユーザーの視点、客観的視点を最優先に仕事を全うしますが、この世界の住人は美に対して敏感であるがゆえに自分自身の中に絶対の正義を持っています。明確な正解の無い世界では大きくブレないための指針としてこの正義は必要なものですが、そのために常に主観と客観の狭間で葛藤しています。

しかしその葛藤が決してネガティブな意味だけではないことは強く主張したい。

デザインに関しては特に社会という制限の中に放り出され、多くの人の思考を巻き込み、制作者の予測しない方向へ飛んでいき大きく形を変えていく。

そうすることによって1人の人間の内面だけでは生み出されないような強靭な創作物が姿を現すこともあると信じています。

と、偉そうなことを話しましたが私は駆け出しのデザイナーなので実際のところは何もわかっていないのかもしれません。

感性だけでは生きていけないのもデザインの世界。

凄まじい数のツール、まるで深海のように底の見えない情報量。

今はその海を手探りで潜っているような状態です。

ただし、気持ちの良い苦痛ではありますが。

ミリ単位の世界

　　

最後にテキストだけではつまらないので以前私が撮影した写真を掲載します。

普段見慣れている動物をほんの少し角度を変えた視点から切り取り、”creature”としての姿を浮かび上がらせようと意識したものです。

ミリ単位で表現は姿を変える。

そういう意味では、写真もデザインと同じかもしれません。