いもろぐ

思い立ったら書いていくスタイルで

ダイエット 中間報告

前回のエントリが ダイエット始めました から約一ヶ月、こんな結果になってます。

体重

目標: 60kg台にする!
開始時: 74.5kg
7/12時点: 70.8kg

f:id:sakaimo:20170717110209p:plain

体脂肪率

目標: 18~22% (あまり気にしてなかったのですがこれが標準らしいので)
開始時: 24.4%
7/12時点: 21.1% ←達成してるじゃん!

f:id:sakaimo:20170717110218p:plain

引き続き「炭水化物を極力摂らない作戦」を継続中です。 体が慣れてきたのか、ごはんなくても十分生きていけるなーというのと、逆にこれまで炭水化物食べ過ぎだったんじゃないかなーって思うようになりました。とはいえ、美味しいからたまに食べちゃうけど、食べた後に体が重く感じるし眠くなるのよね。(ビールもたまに飲んじゃうけどね)

70kgの壁が超えられないので、なんらか別の手を打たねば。

筋力をつけると基礎代謝が上がってカロリーを消費しやすくなる、という話を聞いたので、筋トレしようかな。

ダイエット始めました

2017/5/24 唐突に「ダイエットやりましょう」ということで、会社の席の近い人4人でダイエットはじめました。どんな風にダイエットするかは各自おまかせですが、7月末までに達成する目標を決めて取り組む、と。

私としては年明けの健康診断で初めて「要精密検査」をもらい、「血液脂質」(いわゆる悪玉コレステロール?)で引っかかりました。

40歳を超えてそろそろまじめに健康について考えないとなっておぼろげながらに思ってたところに背中を押された感じ。

私の目標

5/24時点で74.5kgだった体重を、7月末時点で60kg台まで落とす。

(ちなみに私の標準体重は63.8kgだそうです)

体脂肪率はこだわらない。

やってること

食生活を変える:炭水化物を減らそう

ここ20年くらい、明らかに食べ過ぎな生活です。

食べ放題とか、おかわり自由とか、に無意識に魅力を感じてしまう食生活でした。

そこで「炭水化物を極力摂らないようにする」にチャレンジ中。

炭水化物といえば「米、パン、麺」です。主食です。これの摂取量を減らすところから。

例えばある日の昼ごはんがこちら。豆腐とサラダとサラダチキン。

f:id:sakaimo:20170529131140j:plain

ポイントは「サラダチキン」つまり肉。 そうなのです。肉は食べていいんです。タンパク質だからね!

極端に走ると継続できなと思ったので、摂取量をゼロにすることは考えてません。

朝食として「卵かけご飯」食べることもあるし、昼もみんなと一緒にランチ行ったりするし(ご飯半分にしたりはしますが)、夜も飲みに行くしフライドポテト頼むこともあります。(でもその後のラーメンとかはしない)

まず、上述の通り「肉」はOK。だからこれ↓もOK。(半ライスにしたけどね)

f:id:sakaimo:20170611221601j:plain

実際の満腹感というよりも「食べたぞ!」とう気持ちの問題。これ大事。

これくらいの「ゆるさ」で始めようかと。

いかんせんこれまでが食べ過ぎだったので、「炭水化物の摂取量が半分になる」だけでも影響出るんじゃないかと思って。 (炭水化物というよりも、摂取カロリーを気にした方がいいのかもしれないけれど)

体を動かす

といっても、ジムに行ったり、フットサル始めたりはしてないです。意識してやってるのは「階段を使う」ことと「子供と全力で遊ぶ」の2点。

階段については、オフィスが8階にあるので、1日に最低1回、多くて3,4回は8階まで階段で登るようにしてます。

始めの頃は8階につくとゼェゼェいってましたが、だんだん慣れてきました。 これを始めてから駅とかでもエスカレーターではなく階段を選択することも増えました。

子供と遊ぶについては、うちには小4男子と小2女子がいるのですが、こいつらと「全力鬼ごっこ」をやります。

大人は(というか私は)だいたい週末は疲れてて「とーちゃん公園行こうよー」に対して「えー、やだよー」って返しちゃうことが多かったのですが、いやいや、むしろこれはダイエットチャンスだ。受けて立とうじゃないか、って考えるようになりました。自分の体力の衰えにがっかりしますがそれはそれとしてw

体調の変化

良い影響としては「食事後に眠くならなくなった/なりにくくなった」です。 炭水化物の分解に体力を使っていたのかもしれないですね。(本当にそうかわからないけど、実感として)

良いか悪いかわからない影響として、食後の「お腹のたまり具合」が変わった気がします。 これまでは胃の方が膨れてた気がするのですが、それがもっと下の方にたまる感じ。 まったくもって個人の感想で、説明しにくいのですが、それが不快というわけでもないのでいいんだろうけど。

悪い変化としては、集中力が続かなくなることがあります。おそらく糖分が足りてないから? そゆときはチョコレートとか食べたりします。ダイエット成功者の言によると

空腹感が大きいときに食べると、急に血糖値が上がってよくない。100kcal以下の間食をうまく挟むことで、空腹感を大きくしない方がいい

とのこと。

体重の変化

やるからには結果は大事です。

5/24: 74.5kg

6/9: 72.1kg

当社比 -2.4kg

うおっ!これはいいペースなのでは? 実感として「あれ、ベルトゆるくなった?」って思うようになりました。

ってことで待て続報!

仕事と会社と自分と、の話

4月になって、新入社員が入ってきて社会の(会社の?)現実の真ん中に入った時に「自分に合わない」って言って辞めていく、みたいな話を目にすることがあります。

過去にヨドバシカメラが投稿してた元記事がなくなってるようなので、まとめをリンク。(2014年の記事だったか?)

matome.naver.jp

過去に数回転職をしている私は、この記事にある「公務員志望シンドローム」を発動したこともあります。 ゲームの例や部活の例はとてもわかりやすいし、本当にそう思います。

本当の楽しさにたどり着くには、努力と情熱が必要だ。転職を繰り返す人は、これと同じ。楽しさにたどり着く前に職を変えてしまうから、幸せになれない。

って、きっとそうなんだろうなと思う。

一方で、努力と情熱を向けてまでたどり着きたい先をイメージできている人ってどれくらいいるんだろう。 正直なところ、私が社会人になってから5,6年の間はここに書いてあるKさんと同じだったですよ。将来の夢とかなりたい自分とかあったわけじゃないし、例え話にある「転部を繰り返す子」とまったく同じだなと。

新卒採用に関わっていたことに思ったのは、学生の時から自分の将来を本気で考えてる人が多くてすごいなーって。そゆのってホント大事。その上で「自分に合う」会社を選ぶってことをすればミスマッチは少なくなるだろうなと。

でもね。そこまで真剣に考えて選んだ会社だったとしても「合わない」「思ってたんと違う」ことはあるのよね。 その時にどういう行動をするかに正解はないだろうけど、流されてるのか、自分の意思なのか、の違いは大きいと思います。 あ、ちょっと違うな。「働いている」のか「働かされている」のか、の違いかな。

自分で選べないから流されてるんだろうけど、流されながら選べるようになった私としては辞めたければ辞めていいんじゃない?ッて思う。 世の中の大半の社会人は「働かされている」と感じてると思うのですが、そう感じてるのは半分は自分のマインド次第だと思います。 「働いている」と考えられるようになるまで時間がかかる人もいるし、残りの半分は(自分では変えられない)環境だと思います。

ガイアックスからアディッシュに転籍しました

2017年2月1日に、株式会社ガイアックスからグループ会社であるアディッシュ株式会社に転籍しました。

ガイアックスには2009年10月に入社し、7年4ヶ月所属していたことになります。

入社してすぐに思ったことですが「こんなに自由にやっていい会社があるんだー!」って思いました。私は過去に何回か転職していますが、ようやく自分に合う会社が見つかったな!!って。

前職が組込(デジカメ)のQAをやっていて、そこからWebというオープンで自由で何でもあり(?)な環境に変わったことで確実に自分の世界は広がりました。 プロセスがしっかりしていてそれを守ることで効率よく大量生産する世界から、失敗するかもしれないけどその時の最適なやり方を採用することで結果を追い求める世界。後者のほうが私に合ってたんだと思います。あと、社員の年齢・世代がだいたい同じというのも大きな要素でした。私が入社した当時は平均年齢が20歳台だったし、今でも30台前半なのでまぁだいたい「同年代」っていう印象だし、だいたい話は合う(わけわかんないおっさんとかいない)のはラクだなと思いました。そのうち私のほうが老害になりそうで気をつけないとな。

この7年間で何をやってきたんだろうと振り返ると、一番大きかったのは(私の採用理由でもあるけれど)「QAチームが存在しなかった会社にQAチームを立ち上げ、運営していく」という役割でしょうか。

これに関しては第5回Quesで

www.slideshare.net

を発表できたのはとてもいい経験でした。いやホントに。これがきっかけでいろんな人と出会えました。

あとJaSSTね。まさか自分がJaSSTに登壇することになろうとは思っても無かったし、そもそも入社当時に私はJaSSTを知らなかったしw

sakaimo.hatenablog.com



QA以外では、開発部のマネージャ(の1人)として部署運営に関わったり、エンジニア新卒採用に関わったり。全社合宿の宴会で下ネタぶっこんで、その後の人事評価面談で当時のCTOに怒られた(正確には「たしなめられた」)のは懐かしすぎる思い出です。「自由」って言ったって限度ってものがあるよねって身をもって理解した瞬間でした。


あと、この会社はとても趣味人が多いんですよね。

私は人前では「バンドとカメラとアイドルが好きです」って言ってるのですが、学生の頃から麻雀が好きで入社早々に2卓で徹マンしててこの会社楽しーって思った。最近そゆの無いな。

バンドについては音楽やってる人がやたらと多くて、プロ活動してた/してる人もいて、だったら社内でライブやろうぜ、ってことで企画したのが社内非公認イベント「ガイアックス音楽祭」です。これについて書いたのが音楽はいいねぇ「ガイアックス音楽祭」 - 社内報じゃない報になります。ほら、めちゃくちゃ楽しそうでしょ?そろそろまたやりたいね!

ちなみにここ数年、社外発表時の自己紹介にアイドルネタを入れているのですが、実はこの会社に入るまで「アイドル」なんてこれっぽっちも興味が無かったです。ある人が朝礼でももクロの話をしたことがきっかけで、ももクロでんぱ組.inc→BABYMETALとドハマリするという、人生の大きな転換期を与えてくれた会社です。あ、最近はアイドル熱が落ち着いてきてしました。


そんなこんなしてるうちに、会社の経営方針として2015年から機能別組織から事業別組織に切り替えることになりました。これによってQAチームは解散(QAする役割の人がいなくなったのではなく、その役割の人が事業所属になった)し、私はどの事業にも所属せずにQAとして(プログラム)技術から品質にアプローチしようとトライしたのですが力不足にて断念。「(プロダクト)開発もできるQAエンジニア」にはなれませんでした。無念。

社内で仕事を探して、2016年4月からグループ会社のアディッシュの「業務改善」を行ってきました。 業務効率化、工数削減を目標に、業務フロー洗い出しと改善ポイントを特定して改善していったり、VBAやGASやWindowsバッチファイル(!)を書いて手動作業を減らしたり。またこれらの現場を知るために福岡センターにある運用部に行ってスタッフの作業を横で見て改善ポイントみつけたり。

…という期間を経て、この2月に転籍しました。


アディッシュという会社がどんな事業を展開しているのかは事業内容 | adishあたりを見ていただくとして、熱いのはチャットボットのhitoboでしょうか。チャットボットですよ、流行りの。流行ってはいるけどどれだけ成果出せるかはこれからだと思うので期待大ですね。(AIって言うと怒られるので、AIじゃなくて機械学習ね、うん。)

役割としては引き続き業務改善を行ったり、現行システムの保守運用を受け持ったりします。QAとかテストからは離れることになりますが、勝手に「エンジニアと非エンジニアを繋ぐ役割」になろうと思ってます。

組織の中にいる時には「その組織が好きであること」を前提として「役割を全うすることよりも、組織に貢献できることのほうが重要」と思っています。私は役割(職責?)として15年くらいQAとかテストをやっていました。アディッシュでもQAという役割を通して組織に貢献できれば(自分がこれまで身につけているスキルを存分に発揮できるという意味で)それがいいけど、QAという役割じゃなくても貢献したい組織だなと思える会社なので、これからも頑張ります。そしてまだまだ勉強することがいっぱいある。

業務改善と効率と全体最適と

この記事はGaiax Advent Calendar 2016 - Qiitaの2016/12/13の記事です。

このところ、仕事では業務改善とか効率化に関わっています。そんなタイミングで2016/11/13に投稿された 見えない非効率 ー 今、動いているんだからいいじゃないか の記事を読んで思ったことを書きます。耳が痛いというか、刺さった感じがしました。元の記事も2,3分あれば読めると思うのでぜひ一読いただきたいです。こういうのって組織で働く上で誰でも経験することだと思うのと、エンジニアだけではなく、むしろエンジニア以外の職種と関わりながらプロジェクトを進める人には思い当たるフシがあるのではないでしょうか。(お互い)

元記事のサマリー

見えない非効率 ー 今、動いているんだからいいじゃないかの中でキーになる部分を引用すると、

実務層が勤勉で真面目すぎるから、仕事のシステムが多少おかしくても、一所懸命にカバーして動かしてしまう。その結果、かえって問題が隠れて見えなくなってしまうのだ。

とか

だって現に今、動いているんだからいいじゃないか? これが、多くの組織で改善をはばむ最大の心理的障害なのだ。たとえ出来のわるい業務の仕組みでも、現場の人たちが真面目で優秀だと、なんとかだましだまし動かしてしまう。もしかしたら効率は低いのかもしれない。だが、現に今、動いているんだ。何の文句があるんだ? それを変える時間などないほど、忙しいんだし。

のような、「本来あるべき姿とは?」とか「今あるものを改善する時の障壁」とか、そういう話だと私は解釈しました。

私が思ったこと

最初の例で出てくる「工場の書類」の話と我々の業務

毎日の業務(開発業務だけではなく、運用も営業もバックオフィスも含めた「業務」)としてWhat(何をやるか)が定義されていることは多いです。業務のルールや手順書とかまさにそれですよね。「この手順でこれをやること」が仕事として定義されている。これのメリットは「誰がやっても、同じ結果が、短い時間で再現できるようになる」ことです。

この手順書を作った時、作った人の中にはWhy(なぜやるのか)が存在します。何らか解決したい課題があったはず。「オペレーションミスが起こったので再発防止のために別の人がWチェックする手順を追加する」みたいなのありますよね。そこから時間が経ち、人が入れ替わり、その後に新しく入社した人には「これをやるときはWチェックをすること」という手順だけが受け継がれます。

...というような話です。

ここで思うのは

  • 手順とかルールとかはwhyと一緒に定義されているとわかりやすいし、その都度、最適なものに変えていけるようにしておけるといいな。
  • だから「Whatだけじゃなく、Whyもセットにしよう」
  • そして「今の状況」と「Why-What」がマッチするのかを考えよう
  • 例えば上記の例だと、「オペミスが許容値まで減った=課題が解決した」ならWチェックをやめよう、でいいと思います。
  • (エンジニアリング的には、根本解決としてそのミスが起き得ない状況にする、というのがスマートだろうけど)

過去のある時点での最適解と、現在の最適解が同じとは限らない(人がやることでも、システムがやることでも)ので、定期的にルールを見直して、判断して、変える行動力をもつ。

「ルール」というとわかりやすそうですが、ここで言いたいのは「明文化されてるもの」だけじゃなく、暗黙的に行われてる我々の「当たり前なこと」に疑問を持つということかと思います。当たり前に疑問を持つのは難しいです。時には自分(たち)を否定してみることになります。

変えることへの障壁

最初に引用した「動いてるんだからいいじゃない」というのはシステムだけじゃなく、業務全般に言えることです。

実際に一番多いのは、ルートCのように、業務のやり方を変えたために、いったんパフォーマンスが下がってしまうパターンである。その後、皆が新業務になれて、システムが落ち着いたら、きっと成果は上がるだろう。だが、こういう話を聞いたら、皆は何というだろうか。「なぜ、自分がそんなリスクを背負わなければいけないの? 現に今、仕事は一応動いているんだから、何も変える必要はないじゃないか!」 

これ、ありますよね。えぇ、ありますよ。「なんで私がリスクを負う必要があるの?」って思うじゃないですか。

ここでいうリスクってなんですかね?

  • パフォーマンス(=自分の成果)が下がる可能性がある → 自分の評価が下がることに直結
  • 自分たちが築き上げてきたものを壊したり、やめることへの抵抗感
  • 他人(社内外)と「変化」についての合意を取る過程で発生するであろうハードネゴシエーションへの忌避感

こんなところが思いつきました。特に3番目。「お客さまの要望で」っていうのが殺し文句になることありますが、「それ、本当に必要?何を解決したいの?」ってお客様に返すのって難しくないですか?

元記事の最後の言葉ですが、

大事なのは、目の前の仕事を懸命に支えることではない。いったん仕事の手を止めてでも、あるべき姿を考えて、問題解決に向かう勇気を持つことなのである。

ここで浮かんだのが

  • なんで「あるべき姿」を求めるんでしょうか。
  • 私とあなたの「あるべき姿」は同じでしょうか。

という問い。

ちょっとここで、ソフトウェア品質勉強会「開発とテストが一体となったソフトウェア開発」 で聞いた話を引き合いに出します。

ヤフーが「爆速」って言い始めたタイミングで、社内の体制が機能別組織から事業別組織(カンパニー制)に切り替わったようです。これにより、自分が所属する事業で採算が取れるようにすることが必須になったと。

<補足>
1つのチーム(これがイコール「事業」ではないようですが)の構成は、エンジニアが多くて8人くらい、に加えてビジネスの人1,2人+テストエンジニア1,2人、がいる規模だそう。リリースは1週間~2週間に1回。
</補足>

それで何が変わったかというと、それまでテスト担当者は、ばっちりテストをすることで給料をもらえてた。だけど、カンパニー制になったことで、いくらテストをうまくやってもカンパニー自体が利益を上げなければ給料もらえない状況になった。とのこと。

その時の言葉で、

何のためにいるのか?を職責で分けると「プロダクト売れてないけど、テストちゃんとやってるので給料あげてくれ」が起こり得る(ビジネスなんか知らねぇ、的な)。それじゃやっていけない。

というのが印象的でした。

その後、テストエンジニアたちは、テストの内容を変えたり、中にはテスト自体をやめて別なことで事業に貢献する、という判断と行動をした人が出てきたそうです。

「あるべき姿」に話を戻します。

この場合の「あるべき姿」は「カンパニー単体として利益を上げること」(実際はもっと求心力のある言葉でミッションが定義されていると思いますが)なんだと思います。そのための手段として「これまでやっていたのと同じテスト」が本当に必要なのか?を問われた結果なんだと思います。

それを判断するためには「我々には何が必要なのか」(我々のゴールは何か)の共通認識と、「今の状況」を俯瞰できることが大事なハズ。そしてそれは「誰かが俯瞰できる、誰かが俯瞰してくれてる」ではなく「みんなが俯瞰できる(あるいは俯瞰しようとしている)」が大事なことだと思うんです。それには皆が同じ情報にアクセスできる仕組みが必要だし、自分から情報を取りに行く姿勢も必要です。持ってる情報が違えば「私とあなたが考えるあるべき姿」が大きくズレていきます。

時間もコストも有限なので「あれもこれも」はできません。「あれかこれか」で選択する必要があります。その中で何を選ぶか。今回の話の流れで言えば「ゴールに近づくためのもの」になると思います。



(いったんここでおしまい)



こういうことを考えていると、私は「全体最適部分最適」というワードが浮かびます。「部分最適じゃなくて全体最適なことをしよう」がセオリーですが、「何が全体最適なのか」に全員が同意できることがまず大変なのと、「全体最適を求めるのが、その時点での最適解か」という問もあります。全体最適を実現するための労力と、目の前のことを(全体最適ではない方法で)解決する労力。おそらく後者の労力の方が小さくて済むし、後者が将来に必ず負債になるとは限らないじゃないですか。全体最適解でないと先に進めない、だとスピード感が失われると思うんです。

さてどうしましょうか。

「状況によるのでよく話し合って決めましょう」が結論だと面白くないのであえて私の答えを書いてみると、誰かが決めればいいって思います。人任せという意味ではなく、お互いが理解していること、背景・経緯を出し合って、それでも意見が対立してたら先に進まないので、それを踏まえて誰か(おそらく責任者、リーダー、オーナーと呼ばれる人)が決めるしか無くないですか? 絶対の正解なんてない世界なので少しでも前に進んだほうがいいと思うんですよね。もちろん、そういうふうに進めるんだという合意とメンバー間の信頼関係があった上でですけど。



明日のGaiax Advent Calendar 2016はナイスミドルな@hige-taharaさんです!

久々にプラモデルを作った話

久々のブログ更新です。QAとかテストから離れてしまっているのでブログ名も変えてみました。なんか思うことがあったら書いていこうかと思ってます。今回はミデアの話。

f:id:sakaimo:20161210200429j:plain

おそらく20年ぶりくらいにプラモデルを作りました。機動戦士ガンダムに出てくる地球連邦軍の輸送機「ミデア」

なぜミデアかというと、社内で使う効率化ツールを作っているのですがそのプロジェクト名をミデアにしたからです。せっかくだからプラモデル組み立ててプロジェクトリリースまで飾っておこうかと思いまして。詳細は控えておきますがプロジェクトの内容もミデアにちなんでいるのです。ほら、プロジェクトの見える化って大事じゃないですか。(最後はドムに落とされるじゃないかとか言わないで)

プラモデルに触れること自体が久々すぎて、組み立てるために何が必要かも忘れてしまったので、とりあえず必要なプラモデル用接着剤を買いに隣駅まで行ってきました。ついでに棒ヤスリも買ってきました。合わせて400円くらい。ホントはニッパーも欲しかったのですが、プラモデル用ニッパーって意外に高かったのでハサミでなんとかすることにします。

今回、ミデアを作りながら思ったことがあるので書いてみます。

自分との闘い

まず第一にこれは自分との闘いであるということ。

説明書通りに組み立てれば(塗装は別にして)完成します。がしかし。ヤスリがけ、バリの処理、はみ出してしまった接着剤の処理など、どこまでやったら完成なのかと。じつに作業時間の7割はヤスリがけに使ってました。別に誰のために作ってるわけでもなく(プロジェクトメンバーに見せるくらいはするけれど)ほぼ自分の趣味でやってる作業なので、自分が良ければそれでいいのに妙に細かいところが気になってしまうわけです。自分の中での「完成の定義」が必要なわけですね。

↓ランナーから切り離したところ。多少多めに残してますけど。

f:id:sakaimo:20161210223046j:plain

↓余計な部分を整理したところ。

f:id:sakaimo:20161210223333j:plain

...ま、そんなにうまくない。

プラモデル作るのって性格出るなーと思ったです。組み立てた後に内側に入ってしまって見えなくなる部分なんだけど、なんかこう、自分が納得できるまで仕上げたい欲。これに塗装が入ってきたらこだわり度ハンパないんだろうな。

1つの作業に集中できる

パーツが小さく、集中していないと組み立てられない箇所がいくつかあります。音楽を聞きながら組み立てていましたが、手は離せないのでスマホがブルってもメッセージに返信するとか、そういう作業は対応できません。手だけでなく、目も離せませんでした。小さい部品の組み合わせだったり接着剤をいかにうまく付けるかとか、細かい作業の連続なので。結果として「ひたすらプラモデルと向かい合う」という修行のような状態になりました。これって「プログラムと向かい合う」のとは少し違った感じがしました。頭の使う部分が違うという感じもしたし、実際に手(指先)を動かしてものを作るというのが今の私の日常には新しい刺激だった気がします。

おまけのドムが最後の難関

このプラモデルには3体のドムがついています。そう、黒い三連星です。こいつらですがドムの前面と後面の2パーツに加えて、ドムバズーカを持った右手だけが別パーツになってるんです。

f:id:sakaimo:20161210233540j:plain

↓手首の接着面が極小!!どうやってつけろと。

f:id:sakaimo:20161210233946j:plain

↓手首だけだと不安だったので腕部分も接着しといた。

f:id:sakaimo:20161210234133j:plain

↓3時間?4時間?くらいかけて完成しました。塗装は始めからあきらめていたのですが、シールは貼ってみました。(私が小学生のころに作ってたプラモデルのシールって、水に濡らして貼るタイプ(水転写デカールというらしい)だったのですが、最近のは普通のシールなんすねー。ピンセットでつまんでペタリ。

f:id:sakaimo:20161211000841j:plain

↓プロの仕事はここまでやるらしい。(この塗装は不可能だろ...)

f:id:sakaimo:20161210233655j:plain

せっかく作ったので写真撮るか

ここまでの写真は作りながらスマホで撮ってたのですが、翌朝にマクロレンズを引っ張り出して、デジタル一眼レフカメラ(Canon7D)で写真を撮ってみました。

f:id:sakaimo:20161211114222j:plain

f:id:sakaimo:20161211114446j:plain

うん、ミデアもドムも黄色なので全く雰囲気わかんないですねw 見た目って大事。

↓実際はこんな感じでした。もっといいシチュエーション(ジオラマ?)揃えたい欲が出てきたw

f:id:sakaimo:20161211114712j:plain

感想

せっかくプロジェクト名にしたからプラモデル作って飾っといたらウケるかな、から始まったのですが、作ってみたら意外に楽しかった。そしてこの20年でプラモデルも進化していて、接着剤不要だったり、始めからパーツが塗装されたり(プラモデラーからしたら邪道なのかもしれないけど)して、なんだかすごいことになってるみたいです。

あと、ワンフェスに行きたくなってきた。(撮る方で)

Ques#8 VR元年、QAしようゼッ! 感想とメモ

第8回Quesのレポ

イベント告知ページ 第8回Ques #ques8 : ATND

今回のテーマは「VR元年、QAしようゼッ!」ということで、VRサービスのテストや品質について。

発表は3本立てでした

  • はじめてのVRQA
  • Pepperアプリケーション開発で気をつけるべきこと
  • GRID VRICK VRインタラクティブコンテンツ開発の話

先に感想を

ヘッドマウントディスプレイ(以下HMD)などのハードウェアも含めた品質保証をするにあたって、どんなところを大事にするか(どんなところを検証するか)、がとても興味深かった。
これから普及してくるであろうサービスなので、これにともなう「品質」も何をもってOKとしたらいいかを自分たちで考えていくところから始まっていて、産みの苦しみはあるのだろうけれど、QAとしては「俺達が作る!」みたいな意気込みになっているんだろうなと推測。楽しそうだ!

Pepperと「人工知能機械学習」あたりは親和性が高そうだし、GRID VRICKのように「リアルと仮想が一緒になる」ようなサービスも面白い。これがどんなサービスになりそうかはイメージできていないのですが、まず最初の感情として「楽しい!」って思えるのが大事なんだろうな。

以下、資料がアップされるかもしれないけれど、私のメモと感想。 スライドすべてはメモれなかったので、私が気になったところだけ。 スライドの内容と私の感想を一緒に書いてしまいましたすみません。。。

発表1:はじめてのVRQA

グリー株式会社 WrightFlyerStudios事業本部
大塚 直英様

VRQAは非機能テストが重要

  • VR酔い
    • どのように解決するか、がキモ
    • 実際のカラダと、感覚のズレが不快感=酔いになる
    • ズレがどこで発生するかをみつける作業
    • 各画面ごとのズレを主観で3段階で評価(n=10人以上)
    • その結果をどう判断するか、は悩みどころ(例:8人中2人が「ちょっと酔う」)
    • 対応例:1人称視点から3人称視点に変更する
    • (VR体験者が少ない時代で、VR酔いを体験すると二度とVRに触れない、という状況は作りたくなかった。カジュアルVRというコンセプトがあった)
    • 一方で3人称視点はVRならではの体験が減る
      • ユーザーが求めているのはVRならではの体験。1人称視点

この後も「VR酔い」がフォーカスされていて、こんなところがポイントになるのかと思ったです。これを評価する方法も「複数の主観でテスト、数字で表現する」というやりかたなのですね。

VR酔いをどうテストしたか

  • 要因
    • 移動、加速、減速、音声の発生源、遅延、視野角など
    • Oculusベストプラクティス、ってのがあるらしい
  • 種類
    • 吐き気、頭痛、目が疲れる、めまい
    • SimulatorSickness Questionaire が参考になる

VR酔いのテスト項目

  • オープニングでの酔いの有無
  • 画面Aでの酔いの有無

など、それぞれの画面(およびそこで起こるアクション?)で、「酔いチェック」するらしい。

わかりやすさ

VR最大の問題 → 手元が見えない

  • 手による入力操作の難易度があがる(キーボードからの入力はまず無理)
    • ゲームパッドがギリギリ
    • 視線で操作させる(一点を見つめると選択される)方法はある
  • 説明書・攻略サイトがみえない
  • プレイヤーが見ている方向で条件が変わる
    • その時の向きによって、「右を向け」みたいな指示ができない。
  • 対策
    • 説明文を表示させる
    • ゲームの演出として視線を誘導する(蝶を飛ばして、そこに視線を移動することで次の操作を教えてくれる)

わかりやすさのテスト項目

  • ゲームの目的が理解できるか
  • 次に何をすれば良いかわかるか

を判断するために、テスターにテストプレイしてもらう

プレイ時間

  • プレイ時間が長いと疲れる
  • テストすると疲れる
  • 5分を超えるとつかれる、という声が出る
  • 2~5分が今のところ良さそう
  • 画面の切り替わりが早いと目が疲れるという意見も
    • MenuやLoadingの画面、表示
    • Loadingが早過ぎる(すぐ出てすぐ消える)と逆に疲れる

VR特有の機能テストが、品質特性ごとに分けられてました。

@HelloTakuyaさんのツイート

テストする環境

機材確保

  • テスターの大量投入ができなかった
    • HMDの台数が確保できない(発売前だった)
    • スペースの確保
      • センサーを使う仕組みのため、1台あたりのスペースが広い
      • PCとHMDとカメラと。。。
    • VRを動かすためには高性能なPCが必要(1台うん十万円)

→ 少人数を、テスト期間長めで実施することで対応

人材の確保

  • VRテスト人材で一番注意しなければならないこと → メガネ
  • 必要な人材像
    • PCの3Dゲームが得意、テスト経験
    • 3D酔い(VR酔いではなく)しない
    • 探索テストが得意
    • ゲームエンジンでゲーム開発したことがある
    • VRゲームを遊んだことがある
    • (メガネをしていない)→最近のHMDはメガネ対応しているので大丈夫w

テストツール

  • 画面キャプチャ機能は必ず用意する!
    • HMDを装着したままキャプチャできるといい
    • 不具合が発生したときの画面を撮るのは必須
  • FPS表示機能 (flame per secconds)
    • フレームがリアルタイムに表示されるような機能
    • あとで見返せるようにFPSロガーがあるといい(どこでフレーム落ちが発生したか)

こゆの面白い。

今後のVRQA

  • VR酔いの評価方法

    • どこまで許容できるか
    • 定量的に判定できるか
  • テストする環境

    • テストスペース確保
    • 今後はネットワーク対応 ←そのテストを行うための人数
    • イベントなどでの使用を想定したテスト
      • イベント期間中の長時間動作
      • デモ用のオペレーションの用意
  • テスト支援ツール

    • HMDを装着したままバグ報告を行える機能があるとサイバー

サイバーすごいw HMD外さずにバグチケット起票できるとかね。そんなテスターが数十人いたとして、その場を見学してみたい。

まとめ

  • 酔い対策 vs VRならではの体験
  • 人材、機材の用意も入念に
  • VRQAはまだまだ発展段階

Q&A

Q: テスターの規模は? A: 東京ゲームショウに出したのは2名で一ヶ月。製品レベルだとこれの2,3倍か

Q: エイジングのテスト(発熱とか) A: 本格的にはやってない。夜中動かしっぱなしで大丈夫か、くらい。イベント対応で8時間連続動作は担保した


発表2: Pepperアプリケーション開発で気をつけるべきこと

株式会社ネクスト HOME’S事業本部 業務支援推進部
流通ネットワークユニット
上津原 一利様

Pepperについて

人型のコミュニケーションインターフェースである。
ロボット、というといろんなことができそうな気がしちゃう。

部位 役割
頭脳 クラウド
デプスセンサー、カメラ
手、頭、足元 タッチセンサー
タブレット アンドロイド
頭部マイク
耳スピーカー

勝手に話しかけてくる、タッチセンサー付Siriとのことw

「ユーザーが思うPepper」と開発者のギャップ

実際はロボットじゃなく、先行者

  • 脳になるクラウドは公開されていない
  • 都合のいい機能は無い
  • コミュニケーションのシナリオも自分で作る

ユーザーは「Pepperは自分で考えている」と思っている。このギャップ。 ユーザーが期待する体験のレベルは非常に高い

頑張ったけどがっかりなコンテンツになる

これをいかにすり合わせていくか、期待に答えるようにするかが課題

ロボットコンテンツの体験づくり

  • 体験ストーリー
  • ストーリーに必要なコンテンツ(タブレットUI、アニメーション)
  • 実際に実行
  • 改善を繰り返す

特有なのは「会話をする」
いろいろ省きながらユーザーを誘導する
大事なのは、最後まで体験してもらうこと

Pepperはコミュニケーションがメイン。コミュニケーションができなければ人はすぐ離れる。だからこそストーリーが大事。

円滑に話をする。話を面白くする。最後までコミュニケーションする。

QA時に考えるべきこと

  • どういう場所?
    • 状況に合わせた対応。銀行?家電屋さん?
    • 屋外はNG
  • Pepperの役割は?
    • メイン?アシスタント?
    • 途中で止まることもある。音声認識できないこともある
    • アシスタントとして使うのがオススメ
  • どんな人がくるのか?
    • 大人、子供、ビジネス
    • 子どもと大人で、話しかける位置が違う
    • 子供は本気で殴る
  • どんなものならユーザーは喜ぶのか?
    • 面白い?ためになる?
  • ユーザーが何を手に入れたら成功なのか?
    • 好印象?商品購入?
  • ユーザーの抱いているPepper像は?
    • かわいい?カッコイイ?賢い?
    • どんなPepperなら受け入れられるのか
    • 声が変わるとユーザーは驚く(声色が変わる、しゃべり方が変わる)
  • 途中でユーザーが諦めないか?
    • 問いかけは正しいか?
    • Pepperにしゃべりかけたいと思えるか

↑主観、だけど、コミュニケーションインターフェースなので、ここ大事。

  • 肯定の選択肢
    • はい、うん、そうだね、そうだよ、イエス、おっけー、いいよ、、
  • 否定の選択肢
    • いいえ、ちがう、だめ、嫌い、やだ、いらない、、、

など、判別しやすい回答が返ってくるような質問をするようにプログラムしておく。

展示場の例

住宅展示場のイベントスケジュールを話すだけ。要件は満たしたがユーザーはがっかり。→その場で、ユーザーが話しかけてくる単語に反応するようにした

「こんにちわ」「かわいい」「おはよう」など。

ひとこと返事して、スケジュールをアナウンスするとウケるようになって、コンテンツも読んでくれるようになった。

よりよいロボットコンテンツへ

  • Pepperというだけで受けるのは今だけ
  • キャラクターと立場が活きる
  • コンテンツづくりが大事

Pepper(ロボット)だから許せる、かわいい、おもしろい、わかりやすい

人が聞いても答えてくれないけど、Pepperが聞くと話せちゃう。 それを収集する→ビジネスに活かす

↑確かにこれ、今のGoogleだって「知らない間に情報を取られている」ことを考えると、こういう手段での情報収集って熱いよなと思いました。これをPepperにやられると、、、なんだろう、へんな気持ちw

クオリティ=コミュニケーションデザインが問題なくできているか?
アニメーションがしょぼいとかはいい、コミュニケーションがおもしろいか がキモ


発表3: GRID VRICK VRインタラクティブコンテンツ開発の話

株式会社ネクスト グループ経営戦略部 R&Dユニット
リッテルラボラトリーグループ
上野 哲史様

GRID VRICKのデモムービー


GRID VRICK

レゴで部屋を作ると、VRになる レゴをOpenCVで解析、UNREALでCGにしている

大事なこと

  • 家造りの楽しさ
  • 現実と同じリアリティ

  • 楽しい体験、わかりやすい操作

  • 画像解析
  • リアルでインタラクティブな3Dコンテンツ
  • (余談)エンジンとの戦い

楽しい体験・わかりやすい操作

  • 3Dコンテンツ作成の課題
    • 作るのが大変 → ブロックで簡単組み立て
    • 知識が必要 → ブロックで直感的
    • 一人しか操作できない → 何人でも
    • 作業つらい → 触れてたのしい

ブロックとタッチディスプレイで解決!

VRの課題

  • VRだとHMDしてる人しか楽しめない
    • →ブロックの配置をリアルタイム反映。VRの内外で一緒に楽しめる
  • 操作が難しい
    • →操作を分割
      • ブロック:家の構造作成
      • PC画面:インテリア変更
      • VR:ウォークスルー
  • 様々な場所でのテストと改善
    • 社内、イベント出典
    • 学会、勉強会
    • ユーザーの行動を観察(Occuralしながらブロック並べるとかw
    • 筐体の形も改善。

画像解析

課題

  • 照明環境への対応
  • 影の影響
  • 認識物(ブロック)以外の除外

→ブロックの色判定

対策

  • キャリブレーション用のブロックを配置
  • 照明安定用ライト(真上から当てると反射するので角度を持たせる)

リアルでインタラクティブな3Dコンテンツ

数人で開発。経験も少ない

パフォーマンスとの戦い

課題

  • 照明が増える(太陽光、反射光、照明、、)と重い
  • インタラクティブなもの→さらに重い(リアルタイムに変更する

対策:現実とは異なるが、リアルに見えるように

  • 天井ライトを互いに被らないように設置
  • 画面外、今いる部屋以外のライト無効化
  • 反射光を下からのライトで擬似表現
  • 全体光

現実の写真と見比べると違うところはある。が不自然と感じなければOK

パフォーマンス

  • モデルのポリゴン削減
  • オブジェクト数減らす

VRへの対応(これから)

  • インタラクティブ性を重視した、ある程度のクオリティのコンテンツ
  • クオリティを重視した静的コンテンツ
  • そろそろ発売されるGTX1080(グラボ)に期待w

エンジンとの戦い

  • オブジェクトをたくさん置くと、、、オブジェクトが光るw

    • エンジン側のバグ。半年後に直った。
  • コンパイルすると関数名が戻る

    • 原因不明
    • 設定ファイルで回避

テスト、QAの話

課題

  • UXはトラディッショナルなテスト技術では評価が難しい
  • ユーザーの「どの感覚」を計測するのかの検討が大事
  • ハードウェアリソース使用量など、性能評価(合否基準の設定など)が難しい

まとめ

  • アナログ多し
  • 体験の質の向上は、様々な人の反応から
  • 3Dコンテンツのクオリティは「リアルに見える」ように作成
    • 現実と同じ構造では作っていない(省いても不自然に感じないものは無くす)