Category Archives: Uncategorized

五軒家の仲間でデザインスプリント・ハッカソンをやった話

デザインスプリント&ハッカソンの開催に挑戦しました。次回以降や他のイベントの参考になればと思いまして、その内容をご紹介します。

経緯(Summary)

なにか作るよ!
何作るの?
自己紹介
全く新しいものを作ろうとすると難しいから、まずは自分たちの自己紹介を作るよ
期間は?
短期集中で
OK、スプリントやろう

参加メンバー

事前準備

資料作成をして買い出しをしました。

準備した資料

当日のプログラム考えたり、資料の作成をしておきました。

当日のおおまかな流れはGoogleのデザインスプリントを参考にして作成しています。

また、過去に参加したハッカソンの流れも参考にして作成しています。

資料1. 当日のおおまかな流れの説明

資料2. タイムスケジュール

資料3. ペルソナ作成用シート

買い出し

こんな感じの物品を買いました。後にわかったことですが、買いすぎです。

当日の様子

上記の資料を元に作成していったものを示します。

1. ペルソナ

最近乗りに乗っている厚切りな感じの方が出来上がりました。この後、詳細を詰める中で、彼は「ベーコン」と呼ばれることになります。

2. ユーザーストーリー

外国の方が利用することを想定したため、インターネット経由、特にFacebook経由での利用を想定しました。

この流れの中で何が重要か考えた結果、今回は自己紹介を行うコンテンツの作成についてアイデア出しをすることにしました。

3. アイデア出し

狙い通り沢山のアイデアを出せました。作成例を示します。

基本的に意味不明ですが、当人に分かればOKというスタンスで作っているためです。数出せることと、尖ったアイデアが出ることを重要視しました。

4. 企画書作成

5枚の企画書ができあがりました。

企画書1. ベーコンの心をつかめ!厚切り五軒家

五軒家の紹介サイトを作る案でした。

本のイメージでできているようです。

企画書2. これが五軒家だ

同様に五軒家サイトを作る案でした。

実際の五軒家をそのままWebサイトとして再現する案でした。

企画書3. 五軒家アプリ

カタログアプリを作る案です。

スマホアプリはオマケでApple Watchアプリの自爆ボタンが本体のようです。

企画書4. タンブラー作成

紹介用の配布物を作る案です。

企画書5. Fantastic Five

五軒家紹介用のサイトを作る案です。

爆発オチは偉大です。

5. 制作

色々とアイデアは出てきましたが、投票の結果、自己紹介用のWebサイトを作成することになりました。

最終的にはこのページを制作しました。

ヘッダー部分の”ABOUT”からも飛べます(僕の作業分はここだけだったりする)

6. 評価

評価を3つの視点から実施しました。

6-1. 作業の進め方について

制作中の作業について、予定していた作業が完了しているか確認しました。

膨大な「やらない」タスク群に目をつむれば、未完了なタスクがないのでここは問題なしとしました。

6-2. 企画の実現度について

完成物について、企画書のうちどこまでが実現できているかを確認しました。

今回は企画書のうち、自己紹介ページだけを作成しました。膨大な「やらない」タスク群の数をここの評価としました。

今回は、企画の実現度は高くありませんでした。

6-3. ユーザーに届けられた価値について

作成したものがどれだけの想定ユーザーに価値を届けられたか確認しました。

今回はユーザーの利用の流れのうち、Facebookから繋がる所を作成できていませんので、ユーザーはコンテンツにたどり着けません。

ユーザーに価値は届けられていないとしました。

7. 振り返り

実行してみての振り返りをKeep(継続したいこと), Problem(課題点・問題点), Try(今後挑戦したいこと)について書き出して実施しました。その後、全員で書きだしたことについて議論しました。

Keep(継続したいこと)

  • 五軒家でのスプリント実施
  • みんなで一つのものを作ることができた
  • 全員でアイデアを出し合った
  • aboutページの検証
  • Photoページの作成
  • 紹介文の完成
  • 全員を集めてモノをなにか作る
  • これを機会に五軒家のことを知る人が増えて欲しい
  • 自身も五軒家について改めて見つめなおす機会になった
  • 企画から実際に物を作るまで一連の過程を経験出来た
  • 事前の資料作成
  • みんなで何かを作る達成感を味わえた
  • メンバーでの作業
  • アイデアの蓄積
  • 離れていても作業できた

Problem(今回感じた課題)

  • 最初に企画したものが個々人の技能を考慮しないものになっていた
  • やりたいこと≠今日できること
  • ハロルドさんに届かせることができなかった
  • お金かけすぎ
  • 企画書をシンプルにできなかった
  • デザインに明るい人がいないとレイアウトが出来ない
  • 技術力の低さ
  • 技術的な課題が残った

Try

  • 五軒家フルメンバーでのスプリント
  • About, Photo, Movieのコンテンツの充実
  • 技術的な実験場の作成
  • 技術的な事項の勉強会
  • Gokennya travel movie 作成
  • 名刺のQRコードから五軒家のサイトへ誘導
  • 五軒家ページのWebのデザイン更新
  • Gokennya TwitterやFacebook
  • FacebookやTwitterといったSNSとの連携

反省会

全体を通して今回の試みについて、進め方の観点で振り返ります。

1. 時間配分について

時間配分は開始が30分遅れた他は概ね問題なしでした。午前の部で30分時間が不足したので、午後の休憩時間を削って対応しました。

企画で色々と手を動かすのは楽しいので、企画の時間をより長めにとっても良さそうです。

2. 進め方について

進行については、3点反省がありました。

反省点1. 企画をシンプルにできなかった

企画書でできあがってきたものが、複数のアイデアを組み合わせたものになって居ました。意図していたのは、アイデアを先鋭化することだったので、複数のアイデアを一枚の企画書に記すことではありませんでした。

この辺りは、企画書で更にアイデアを先鋭化させてもらうという目的を示せていなかったのかと反省しています。

反省点2. 企画書への評価の不足

企画書に対し、気にいるかどうか、想定した人に刺さるかどうかは検討しましたが、企画の実現性については評価できていませんでした。

結果、本に似た動作をするWebページをエンジニア一人がデザイナー抜きで半日で作る、という実現性に乏しい(というよりも多分かける時間の割にあわない)案になってしまいました。

反省点3. スプリントの後の作業がない

スプリントやハッカソンを実施しているオープンソースのプロジェクトでは、その日で作りきるというよりも、その場で議論して着手まで実施し、スプリント期間中に完了しなくともその後継続して開発して成功するといった経緯をたどるようです。

例1. esa – 趣味から育てたWebサービスで生きていく

例2. board(受託開発の会社が自社サービスを1年運用してきた内容・結果と今後の課題)

プロトタイプが意外と良かったこともあり、本格的に開発を進めていくことにしたものの、基本的に受託と平行して進めていたので、2013年12月に社内α版、2014年2月にクローズドβ版、5月にパブリックβ版、8月に正式リリースという形で少しずつ進めていきました。

出典は忘れてしまったのですが、何か機械学習系のプロジェクトでもそんなことをやっていた、ような。

その後の作業のスケジュール立案まで含めても良かったかもしれません。あるいは、スケジュール立案する/しないの判断をすることまでをゴールと設定したほうが良かったかも。

最後に

もともと、僕がこういったスプリントをやりたいとずっと言っていまして(3月か4月には言っていたと思います)それをようやくできました。

もちろん、僕だけでは出来なかったので、協力してくれた全員に感謝します。次はもっとうまくやる。

次回は10月開催予定なので、そこに向けてむくむくと準備します。

Reference

1. Google Design Sprint(原文)

  1. The product design sprint: setting the stage
  2. The product design sprint: understand (day 1)
  3. The product design sprint: diverge (day 2)
  4. The product design sprint: decide (day 3)
  5. The product design sprint: prototype (day 4)
  6. The product design sprint: validate (day 5)

2. Google Design Sprint(邦訳)

Google Design Sprintの記事はTHE GUILD LABSで翻訳されています

  1. デザインスプリント入門1 – Google Venturesのデザインスプリントを自分で行う方法(翻訳)
  2. デザインスプリント入門2 – スプリントに必要な6つのモノ (翻訳)
  3. デザインスプリント入門3 – 理解(1日目)(翻訳)
  4. デザインスプリント入門4 – 発散(2日目)(翻訳)

3. マーケティング

ユーザーストーリーの作成を行うために、マーケティングの理論を(図だけ)参照しました。

  1. SIPS〜来るべきソーシャルメディア時代の新しい生活者消費行動モデル概念〜
  2. AIDMA理論とは
  3. AISASにおけるコンタクトポイントについて

4. Scrum

SCRUM BOOT CAMP THE BOOKを参考にしました。

あとは過去に参加したこの辺りの勉強会とかハッカソンも参考にしました。


「Bizreach✕Cookpad✕Gunosy✕UserLocal 分析プラットホームとその技術」参加レポート

CookpadとGunosyの中の人の顔を見てみたいというミーハー根性と、やっぱりWeb業界の方々のスピード感は見習わなければいけないなあいう尊敬の念から行かざるを得なかった勉強会の参加レポートです。

connpass : Bizreach✕Cookpad✕Gunosy✕UserLocal 分析プラットホームとその技術

I. とあるディレクターのデータ分析の日常

クックパッド 伊藤さん

クックパッド

  • ユーザー数5000万人突破
  • レシピ数200万品突破

データ分析✕ディレクター✕エンジニアとの関わり

  • クックパッドのミッション : ユーザーニーズを抽象化してシンプルに解決する → 料理を楽しくする

開発フレームワーク

  • LEANスタートアップが基本
  • クックパッドでは入社したらとりあえずLEANスタートアップなどのLEANの本を輪読
  • LEANフレームワークを説明した各書籍の中で、分析は LEAN ANALYTICS に記述がある

LEAN

  1. サービス開発を実験のように仮説検証を通じて行う
  2. 検証のための最小の製品(MVP)を作る
  3. 検証する

検証するときにデータの分析が発生

サービス開発とデータ活用

  • サービス開発は、新しい価値を生み出す
  • データ活用は、データを利用してビジネスを伸ばす

データ分析

  • ダッシュボード最強。
  • KPIを設定してダッシュボードを作ってそれを眺める。

ダッシュボードを観察するときの辛さ

  • 日々の変動で一喜一憂してしまって辛い
  • スムージングしたKPIのモニタリングがオススメ(30日でスムージングしている)

機械学習(バズワード)への対応

  • Deep Learning, トピックモデル, word2vec, などなど
  • まずは足元を確認してからやる

分析技術

  1. Google Analytics : 最も有名なダッシュボード、ざっくりみたいとき
  2. Mixpanel
  3. Hakari
  4. papa : クックパッド製のダッシュボード
  5. SQL
  6. TreasureData
  7. Redshift
  8. MySQL

ディレクターとエンジニアとの関わり

ディレクターの仕事 : エンジニアの仕事を減らすこと(私見として)

情報の共有

  • Groupad : ブログみたいなクックパッド内製ツール
  • エンジニアもディレクターもみんなここに投稿している
  • ツールを導入してフォローする

技術的負債への対処

  • サービス開発すると技術的負債がついて回る
  • 新規機能を開発するのか、リファクタリングするのか判断する

データ分析のポイント

  1. 分析対象への理解
  2. 分析手法についての理解
  3. 分析結果から施策へ

1. 分析対象への理解

  • どのようにしてデータが生まれてきているのか誰もしらないことがある。
  • マスターデータなのかユーザーデータなのか
  • 行動ログデータなのか
  • トランザクティブメモリー(組織内で誰が何を知っているか)を把握することが重要

2. 分析手法についての理解

  • 問題として適切に表現すること
  • 分析手法を適切に選択すること

3. 分析結果を活かすこと

  • マーケティングシナリオ
  • 広告戦略策定
  • A/Bテスト

グロースハック事例

クックパッドの過去の事例は加藤さんのSlideshare参照

Q&A

1. ダッシュボードに表示すべきKPIはどのように選定しているのか?

  • ダッシュボード自体に誰が見ているのか計測する仕組みを導入している
  • LEAN ANALYTICSに記述がある

2. ダッシュボードをチームごとに分けているか?

  • 基板は共通にしている、その中で階層を分けている
  • 一元管理するために基板は分けていない
  • KPIの数は4つか5つ、中身はチームごとに異なる

3. 固めるべき足元とは?

  • データの環境について、社内的な整理を行うこと
  • 社内のデータが一元管理されている、必要な組織が管理している、など組織面の整理
  • 権限設定を適切に実施
  • 適切なダッシュボードの作成

4. SQLをどのように習得したのか

  • 必要に迫られてやった
  • ログの分析をする必要があったが、MySQLのDBにしかない状況があったのがきっかけ

5. 事業部ごとの整合性、進むべき方向を向いているか

  • 会社としてどのような数字を見ているかはオープンにしている
  • 定例会(毎週)で確認している

Reference

  1. MLCT(Machine Learning Casual Talk)
  2. ReBuildfm
  3. クックパッド開発者ブログ
  4. 10年戦えるデータ分析入門

II. ユーザーローカルの顧客企業のデータ分析担当者はどうサイト解析しているのか

ユーザーローカルCTO 三上さん

内容

  • どう解析しているか
  • 解析のためにどのようなインフラを構築しているか

データ分析に望まれる3つの点

  1. 社内説得に役立てる
  2. ユーザー像、改善策を知る
  3. 取得したデータを売上アップに繋げたい

必要な要件

  1. 集計処理(大規模かつ素早く)
  2. 可視化(数値だけでなくビジュアル)
  3. 蓄積データをビジネスに活用

1. 集計処理

  • 大量のデータを取得しておきたい
  • 結果をできるだけ素早く、高速に見せる

難しさ

  • この両立はとても難しい。
  • サンプリングしてデータを保存するのでは、後からデータが必要になったときどうしようもなくなってしまう。

実装方法

  • 一日一回のバッチ : 日別のユニークユーザーなど
  • 数十分に一回のバッチ : サイトからの離脱など
  • リアルタイム処理

一日一回のバッチを実装する方法

  • 最も簡単
  • 大規模ならHadoop
  • 事業担当者が待ってくれなかったりする

数十分に一回のバッチを実装する方法

  • Hadoopで作ったとき、リトライ可能にするのは難しい
  • TV CMなどのときでは10分単位だと遅い

リアルタイム処理

  • KVSなどで実装
  • 単純なカウントアップに向いているが、メモリの上限値との戦いが発生

ラムダアーキテクチャーでの解決

  • バッチレイヤーとスピードレイヤーに処理を分岐させる
  • 設計が複雑化し、システムコストが多重にかかる

実装例 : リアルタイム・ダッシュボード

  • 差分を最初に持ってくる
  • 経営者・営業にウケがいいとのこと

2. ユーザー像、改善策を知る

  • どういった人に見せるのかを把握することが重要
  • 経営者 : 短時間で全体像を把握したい
  • ディレクター : デザイナーを説得したい
  • 分析担当者 : レポート作成時間を短縮したい
  • 営業担当 : コンバージョン数が知りたい

デザイナー・ディレクター向けの可視化

  • ヒートマップで可視化
  • クリック数が多い場所
  • どこまで読まれているか

  • 表示した後に分析は別途必要

3. 取得したデータを売上アップに繋げたい

レコメンドサービスに結局繋がる場面が多い

目的から考える

  • ブログ記事に関連する記事を出す
  • サイトの回遊率を上げる

協調フィルタリング

  • 新着維持には十分な情報がない
  • 興味が近いから両方見ていたのか、たまたま目に入った時間が近いのか区別が難しい

コンテンツベース

  • 新着の記事でもレコメンド可能
  • 単語の出現回数で関連度が決まるため、関連度が擬似的なものになってしまう

人気ランキング

  • 人気のものなのである程度質も良い
  • 目を引く

Q&A

1. データを取得してから分析にかかる時間はどれだけか

  • 1時間程度

2. ヒートマップはどのような動作を反映しているのか

  • 表示されている領域
  • マウスの位置

Reference

3. AmazonRedshift✕Tableauを活用したデータ分析のススメ

ビズリーチ 工藤さん

ビズリーチ データサイエンスチームの構成

  • サービス企画部
    • データサイエンス
    • ビジネス力
    • エンジニアリング

データサイエンスチームの役割

1. 間接的な効果

  • BIツールによるデータの可視化
  • アドホックな分析

2. 直接的な効果

  • メールやweb上でのユーザーへのレコメンド
    • レコメンド用アルゴリズムの開発を実施している
  • リアルタイムな事前検知

About 400

  • KPIが400あった
  • 集計はすべてExcelで行っていた
  • 集計するだけでコストが高い(人手がかかる、DBへの負荷がかかる)

データ可視化プロジェクト

  • Amazon Redshift✕Tableau
  • Amazon Redshift : 既存のMySQLがAWS上にあった
  • Tableau : 使いやすかった

事例紹介 広告媒体別の費用対効果の可視化

  • Excelで行っていた集計作業を対象
  • コストと売上を対比できるようにした
  • Tableauをダッシュボードとして利用して可視化

事例紹介 リアルタイムな事前検知

  1. 転職意欲が低く、サイトを積極的には利用していないユーザー
    • プロジェクト中で忙しく手が出せない方も含む
  2. 急に転職意欲が高くなってきたユーザー
  3. 転職意欲が高く、既にサイト上で行動しているユーザー

このうち、急に転職意欲が高くなってきたユーザーの出現を検知したい。

処理内容

  • 行動ログを取得
  • Redshiftにためる
  • Python(pandasで前処理・正規化, NetworkX)で処理

Q&A

1. Redshiftのデーブル設計

  • MySQL(Webアプリで利用しているもの)に似せている
  • ユーザに関する個人情報は省いている

2. Streaming Insertを利用した理由

  • fluentを使ってみたかった

3. 集計単位はユーザー単位での集計だと思うが、計算量的に考えた負荷は高くないのか

  • 全員を対象にすると計算の負荷が高くなる
  • 現在はアクティブなユーザーに限って実施している

4. 比較した結果、RedshiftとTableauとしたとあったが、何を比較したのか

Databaseの選定について

  • BigQuery
  • Redshift

金額的にはBigQueryが良かったが、既存の知見が使いやすいという理由でRedshiftに。

BIツールの選定について

  • RedshiftをベースにしたときにTableauが使いやすいという事例紹介があった
  • ほぼ一択で決めた

5. Tableau以外に検討したツールの名前は

  • ClickViewのツール?

6. Tableauをエンジニア以外が触ることがあるか、苦労した点は

  • Tableauは集計単位をどんどん変えることができる、社内に広めるときには苦労しなかった
  • データの整形や入力ルールについてまとめることが非常に難しかった

7. 過去データのトランザクションも全て入れているのか、集約したデータは

  • Redshiftにはすべてのデータを入力している
  • 時系列でサマリーを作ったテーブルも作成して保持している

8. Tableauで表示されるまでの時間は?

  • ベストで3sec

9. NetworkXで解析しているグラフとは何なのか

  • ページのユーザーの回遊状況(有向グラフ)

Reference

4. Gunosyでの分析と改善

Gunosy 吉田さん (Co-Foundar)

最初期

  • Webアプリだけ
  • MySQL+Rails

アプリリリース時の分析基板

  • MySQL排除
  • fluentd, MongoDB, S3導入
  • MongoDBのMapReduceで集計
  • iPython Notebookで集計

データ多すぎ対策後での分析器版

  • MongoDB遅すぎ
  • 古いデータを消していたのでWAU算出負荷
  • Redshift(+BigQuery)
  • アドホックな分析にSpark導入
  • MongoDB排除

分析改善タスクの考え方、流れ

基本方針

  • 数字は神より正しい : 上位者の意見ではなくユーザーの数字で意思決定を行う
  • 迷ったら挑戦する : 迷ったらやってみる
  • 機会が得意なところは機会に、人間が得意なところは人間に

タスクの流れ

  1. 目標設定
  2. 仮説立案
  3. 簡易実験
  4. モデル実装・自動化

1. 目標設定

  • 改善目標となる数値を決める

2. 仮説立案

  • 仮説を上げるための仮説を立てる
  • 新しい技術やモデルがあるから飛びつく、のはNG

3. 簡易な実験

  • ルールベースや手動でもいいからユーザーに試して見る
  • ルールが記述できないのであればそれは仮説が詰め切れていない、と考える

4. モデル実装・自動化

  • ここでやっと機械学習が出てくる
  • 複雑なモデルではなく、効率のいいポイントを考える
  • サービスが変化したときに、スピード感をもって変更できるモデルを構築することが必要
    • 複雑な精緻なモデルではなく、シンプルで変更できるモデルを立てる

進め方

  • やる/やらないのジャッジはしない
    • 小規模にやってみて数値を見ながら拡大していく
  • どの数値がどのくらい上がるかはわからない、どの数値を上げたいかを見積もる
  • あたる/あたらないは八卦なので、数を打つ

分析改善の例1. 新規ユーザーの獲得

課題

  • 新規のユーザーの継続率が下がっていく
    • 新規登録後7日後、どれだけ継続しているか

仮説

  • SNSから個人の興味を得ることができなくなっているのでは
  • 過去のコンテンツから得られた特徴量がマスの人々には満足しない
    • 評価指標がアーリーアダプターに偏っていた

対策

  • SNSだけでは無理
  • アンケートを導入してカテゴリーをユーザーが入力できるように改善

分析改善の例2. コンテンツの偏り

課題

  • コンテンツの収集が偏っている

仮説

  • サービス拡大に伴いユーザー層が変化しているのでは
  • ユーザーをカテゴリ別に分別すると、得意なところととくいでないところがでてきた

対策

コンテンツをふやす
手動でテレビで流れたコンテンツを導入した

本当に必要なのかの議論

  • 分析するとき、精緻で複雑なモデルを立てたくなってしまう
  • 必要なのは、素早く検証できることなので、過度に複雑なモデルは立てない

意見交換

タスクの優先順位付けはどのようにしているのか

  • プロダクトチームがえいやでやっている部分もある

機械学習のfeatureの選定はどのように行っているのか

  • 手動で頑張った

可視化はRailsで今も行っているのか?

  • メインはRailsで現在もやっている

所感

  • 「スピード感大事」というのはデータ分析も同じ。
  • データを分析する前に、データを分析できるようにすること、そのための可視化。
  • 仮説をどう立てるか考えるのは難しい、簡単に試せること、結果から学ぶ方法で対処。
  • ビール✕ピザはやっぱり正義。
  • Deep learningはH2Oで敷居がかなり下がったのでやってみたい

  • ダッシュボード類は気になる。一部使ってるけれど、他のものも使ってみたい。Tableauとか
  1. Mixpanel
  2. Tableau

BizReachさんありがとうございました!


Appleに買われたMetaioとは何だったのか、具体的な開発画面で紹介して作業時間の供養にする

AR系の技術を一ヶ月くらいかけて勉強した内容が一瞬で利用不可能になったのでお墓の代わりにエントリーを残します。

龍一郎@技術担当です。AR系統の勉強をまたぼちぼち進めています。前回はVuforiaで次の記事を書いています。

今回目指すのは次のあたりです。

  1. インタラクティブにする。ARで表示したオブジェクトがぶつかったり。
  2. デスクトップでも動かす。
  3. オフラインで動かす。

となるとやっぱりUnity + ARシステムってなりそうです。そのようなものがどうなっているか調査しました。結果はだいたいこんな感じ。

Vuforia Metaio NyARToolkit(商用)
デスクトップ対応 不可 可能 可能?
オフライン可否 可能 可能 可能
機能の豊富さ たくさん 超絶すごい 基本マーカーっぽい
価格(概算) 5万円 50万円 120万円

NyARToolkitはGPL版もあってそれはそれで良さそうなのですが、今後ARで色々なことをやろうと思ったとき、機能の豊富さ(マーカレスとか物体認識とか)でMetaio調べてました。

で、色々動かしてみて行けそうかなと思った矢先、MetaioがAppleに買収されて使えなくなりました。

日本の販売代理店も取り扱いを中止しています。

一ヶ月くらいの作業が水泡に帰しましたがしかたがないので、かつて存在したMetaio SDKとは何だったのか、どのように開発ができたのかを残すことにします。

基本的にスクリーンショットベースで残しますが、MetaioのDevelopper Communityにリンクを貼りまくっているため、もしかしたらすぐに読めなくなってしまうかもしれないです。

Metaio+Unityのサンプルを動かす

ほとんど動作確認。

Running the Tutorials Appに従う。

0. 環境設定

  • Setting up the Development Environmentに従う
    • Configuration of Unity Editor on Windows でDirectXではなくOpenGLを有効にしている点に注意
  • Macでは不要だけれど、Windowsで開発するときには注意する必要あり

参考 : http://docs.unity3d.com/ja/current/Manual/CommandLineArguments.html

1. Unityにサンプルプロジェクトを読み込ませる

読み込ませた直後はこんな感じ

2. 実行する

Build Settingを確認して実行

3. マーカーを認識させる

実行したアプリはTutorials以下すべての機能を持っている

マーカーもここからDLできるので、動作確認に利用可能。実行するとこんな感じ。

マーカーの認識まで確認できた。

Metaioで新しいアプリを作る

この辺りから単なる動作確認じゃなくなる。
Creating new AR applicationに従い、プロジェクトを作って、Metaio Manを表示させるところまでやる。

1. プロジェクトの作成

普通に新規プロジェクトを作成、空のプロジェクトを作る
ここで特別に何かはしなかった

2. metaio SDK Unity packageの読み込み

Assets > Import Package… からmetaioSDK.unitypackageをインポートする。

フォルダ構成は自動的に出来上がる。

それぞれのフォルダの意味はわからないので後で考える。

3. User Layerの追加

右上からEditLayerを選ぶ。

こんな感じでLayer8にmetaioLayerを追加した。

4. 署名の取得

Application Signatureを追加するために、まずはApplication Signatureを取得する。

Create an application signatureに従い、下記を実行

こんな感じにアプリ名を入力すると

こんな感じに署名が生成される。

作成した署名 :

5. ARカメラの追加

再びCreating new AR applicationに従う。

  • Main Cameraを消去
  • MetaioSDKをゲームシーンに追加
  • 署名をMetaio SDKのInspectorから追加

この辺りはVuforiaと似ている(署名だけちょっと違うけれど)

この段階で実行してみることで、正しく署名が入力できたかどうかが分かる。

正しく署名が入力できていない場合、実行できない(らしい)

6. マーカーの追加

この辺りはCreating new AR applicationに従えない箇所がある(リンク切れ)ので、Migration from Qualcomm® Vuforia™ to Metaio SDK for Unityを参考に独自手順込みで行う。

Metaio Creatorを利用、しようとしたんだけれど、マーカー数が2個という制限がある。

このあたりは、設定ファイルを自力で書けば回避できそうなのであまり気にしないことにする。

6-1. パラメーターの指定

パラメーターの意味はドキュメント及びサンプルコードのコメントから翻訳する。

内容はPicture Markerに従う。

認識方式に影響するパラメーター

基本的にこの辺りはデフォルト値で良さそう。

  1. Sensor type : 何を認識するかを指定。マーカーならMarkerBasedSensorSourceを指定。
  2. SensorID : この認識方式につける名前。任意。
  3. trackingQuality : robust と fastの二択。fastのほうが早いけれど、robustでOK
  4. thresholdOffset : 画像を2値化するときの閾値。fastでは無視される。デフォルト128。
  5. numberOfSearchIterations : 認識の繰り返し回数。fastでは無視される。デフォルト3。

反応が悪かった時に、thresholdOffsetとnumberOfSearchIterationsを変更するくらい?

マーカーごとに影響するパラメーター

SensorCOS (Sensor CoOrdinate System) で、マーカーを一つ一つ追加する。
SensorCOSでは次のパラメーターをマーカー画像ごとに設定する。

  1. SensorCosID : マーカーの識別名(文字列)。他のものとかぶってはダメ。
  2. MatrixID : 特徴行列の識別子(自然数)。おそらく、他のものとかぶってはダメ。
  3. referenceImage : TrackingData_PictureMarker.xmlがある場所からの画像データの相対パス。
    • widthMM : 印刷したマーカー画像の横幅 (単位 : mm)
    • heightMM : 印刷したマーカー画像の縦幅 (単位 : mm)
    • binary : 画像データが2値データになっているかどうか。”0″のままでよい。
    • QualityThreshold : 一致度?どの程度の値なら一致しているとみなすかを指定。0.7推奨。

この辺りはMetaio Creatorを使えばよしなにしてくれる、はず。

6-2. 作成したパラメーターとマーカーの読み込み

Creating new AR applicationに従う。

Metaio Creatorを使って雛形となる設定ファイル(XML形式)を作成し、人力で編集する方針を取る。

Metaio Creatorではマーカーの登録ができる。

Metaio CreatorはARで認識する(≠表示する)マーカーを登録できる。本当はもっと多機能で、認識した跡に何をするか(Youtubeのチャンネルを開く、Twitterのアカウントを開く、とか)まで設定できるらしい。

登録したマーカーのデータをエクスポートする。Export Traking Configuration Fileを選択。

作成したzipファイルをUnityで利用する。zipファイルの中身は、マーカー画像とXMLファイルになっている。設定値に関しては上記参照のこと。

7. Unityで3Dオブジェクトを表示する

以降Unityでの作業。でもだいたいVuforiaと同じ。マーカーをUnityに読み込ませ、そこに表示する3Dオブジェクトを指定する。

また、3Dオブジェクトに何らかの動作や処理を付与したい場合(当たり判定とか)3DオブジェクトにC#スクリプトを付与したりRigid Body+Colliderとか使って色々できる。

7-1. マーカー設定ファイルの受け渡し

Unityへの受け渡しはプロジェクトのAssets/StreamingAssets以下に配置する

なお、Unityの作法として、Assets/StreamingAssetsには音楽ファイルなど、変換の必要がないものを置く。

Unity上で、作成したマーカー認識用パラメーター設定ファイル TrackingData_PictureMarker.xml をmetaioSDKに読み込ませる。

7-2. 表示する3Dオブジェクトを用意する

サンプルを動かす時とほとんど同じなので省略。

Metaioで気になったこと

metaioがUnity5以降に対応しているのかどうか

Change Logを見る限り、6.0.2以降で対応している(と主張している)

metaioでのlocal recognitionの可否

local recognitionはサーバーを利用しないクライアント側だけで成立するオブジェクト認識を言う。

Image recognition in android app without internetを見る限り出来そう。

同時に認識可能なマーカー画像の数の指定

Image Trackingでは、次の2つのパラメーターを用いて、同時に認識する画像の数を指定できる。

  • MaxObjectsToDetectPerFrame
  • MaxObjectsToTrackInParallel

Parallel Trackingの記事によると、この質問は最もよく寄せられる質問の一つ、らしい。

一方、Picture Markerではその指定を行うパラメーターが存在しない。

チラツキ発生時の対処

チラツキが発生した場合はSmoothing Fuserを参照せよ、となっている。

が、殆どのパラメーターについて、デフォルト値のままを推奨されている。

チューニングするときに参照する必要があるかもしれない。

Metaio Creatorで生成できるTrackingData.zipの役割

Unity + metaio + iOS で作るARアプリの記事中の「Unityでコンテンツを作成する」ではMetaio Creatorを利用している

Metaio Creatorから作成できるTrackingData.zipを回答してみると、次のようになっている。

このファイルのうち、画像ファイルはMetaio Creatorで指定したファイルで、Tracking XMLはImage Trackingで説明されているXMLとなっている。

というわけで、TrackingData.zipには認識する対象の画像とそのパラメーターを記したXMLが入力されている。

注意点として、書きだされたTrackingData.zipに含まれるXMLで、MaxObjectsToTrackInParallelの値が1になっている

複数のマーカーを同時に認識させる場合、値を変更する必要がありそう。

Unityにfbxファイルを読み込ませるときに失敗する

FBXファイルをUnityに読み込ませる方法はD&Dなんだけど、何故か失敗した。

原因はAssets/StreamingAssets以下に追加したせい。

別の箇所にインポートしたら大丈夫だった。

作ったTrackingData_PictureMarker.xmlのインポートに失敗する

インポートに失敗した

ERROR Dimension of the template image has been determined as 300.000000 x 450.000000, while the pixel dimension is 1064 x 1064. The aspect ratios differ too much for the tracker to work correctly.

画像ファイルと設定ファイルが不一致を起こしていただけだった。この辺りはMetaio Creatorを使うと楽。

Reference

Metaio

  1. metaio
  2. metaio Developer Portal

Metaio SDK

  1. Signature generation process in steps
  2. Create an application signature
  3. The application identifier
  4. metaio/junaio日本語フォーラム RE:同時トラッキング、同時表示について
  5. Image Tracking
  6. Picture Marker

Metaio + Android

  1. Image recognition in android app without internet

Metaio + iOS

  1. プログラミングが出来なくても簡単!ARコンテンツの作り方【実践編】
  2. iOS 7とmetaioでARアプリを作ろう | アドカレ2013 : SP #1
  3. 第4回 ARコンテンツを作ろう:ARコンテンツを作ってみる②
  4. 第6回 マーカーレスAR

Metaio + Maya

  1. Supported model formats

Metaio + Unity

  1. metaio の Tracking Configuration を外部からロードする
  2. metaioとUnity3Dの連携その2 自由なARアプリを作る

Migration from Vuforia to Metaio

  1. Migration from Qualcomm® Vuforia™ to Metaio SDK for Unity
  2. Few questions to decide if migration from vuforia to metaio platform?

Unity

  1. ゲーム開発初心者のためのUnity入門(2): Unityで3Dモデルや色、テクスチャのマテリアルを作成、変更、保存する基本&空の背景の作り方 (1/4)
  2. Unityの特殊フォルダと各々の役割
  3. UnityでSQLiteを扱う方法
  4. UnityのAssetBundleをじっくり理解する手順をまとめてみた。【アセットバンドル】
  5. Unity – Transformをコードで取得、グローバルとローカルの違い
  6. Unityで覚えるC#
  7. 【Unity】バイオハザード風の動きをするscriptとカメラについて
  8. またーりUnity3D 入門 (少しでも参考文献日本語化計画)
  9. PlayMakerで3Dキャラクター操作を作成する -前編-
  10. インターフェースを学ぶ
  11. Unityで覚えるC#

Unity Editor

  1. [Unity][Unity3d]Unityのエディタ拡張について丁寧に解説されているスライド「Extending the Unity Editor」
  2. Unity Editor上で動く自作ツールについて 〜 TIPS/豆知識を添えて 〜
  3. Editor拡張マニアクス2014
  4. 知って得するUnity エディタ拡張編

Unity, Collider

かなりハマった。

  1. 挫折しないUnity入門④ – Collider編
  2. 第05回 当たり判定とアニメーションイベントとレイヤー
  3. [Unity] Unityにおける衝突判定まとめ
  4. Unity – 衝突判定

Unity + Maya

  1. Maya Ascii (.ma) import/export into/out of Blender
  2. 3D formats
  3. 基礎練習〈その3〉fbxのインポート
  4. Unityのfbx形式のインポートについて

Maya

  1. 3Dファイルフォーマットの種類

また追記する、かも。


【名古屋】第32回iPhoneアプリ開発勉強会に参加した話

【名古屋】第32回iPhoneアプリ開発勉強会 〜Apple Watch、Swiftなど旬な話題で楽しもう!〜にまた参加したので、レポートします。

タイムテーブル

時間 発表者 内容
13:20 受付
13:30 ともやん 挨拶、勉強会について、会場案内や諸注意
13:45 全員 自己紹介大会
14:00 原知愛さん SwiftプログラミングTips
14:25 まつもとけんたさん、山平誠さん、山下佳隆さん 今から始めるWebAPI連携
14:50 休憩
15:00 稲熊さん Apple Watch体験記(仮題)
15:25 近藤秀彦さん WatchKitでApple Watchのアプリを作ってみよう
15:50 LT
16:10 全員 次回予告・写真撮影
16:15 撤収

1. SwiftプログラミングTips

原 知愛さん(@zetta1985)

Swiftとは

利点 : 取っ付き易い
欠点 : Xcodeのサポートが未熟

結論 : Swiftにはまだ触るな

言語仕様がどんどん変わるため
1年後、言語仕様が固まったら触るのもいいかも

I. varよりもlet

immutable

var : 再代入可能
let : 再代入不可(明示しなければこちら)

immutableな変数の扱いを基本としている

structure

letで宣言したstructureは書き換えが不可、特に要素の追加・自分自身の書き換えが不可。

letを使うことで、structureの状態を不変にできる

II. 関数によるデリゲート

クラスのプロパティに関数が設定できるので、関数で通知が実現できる

III. extension

extension : 既存の型を拡張できる機能

コード補完が効くようになるので便利

  • Utility methodとして
  • Factory methodとして : SKLabelNodeで何度も作るものがあったら、extensionで定義
  • 複数プロトコルの実装の分離 : どのプロトコルがどのプロパティのものだったのかわからなくなりがちなので分離

意見交換

Quick(Swiftのテストフレームワーク)の中の人曰く、もうSwiftしか書けない人がFacebookの面接に来ているらしい

2. 今から始めるWebAPI連携

まつもとけんたさん、山平誠さん、山下佳隆さん

I. WebAPI連携の大別

大きく分けて2つ

  1. サービスを利用する(MBaaS)
  2. サービスを作る(VPS/AWS/物理)

今回はサーバーを立てて、Web連携する話

II. サーバー側での実装

APIを作ってアクセスされたらJSON返す

III. 利用するライブラリ

R9HTTPRequest
SDWebImage

IV. 質疑応答

MBaaSについて

Parse

  • Key-Valueストア、DB
  • Parse SDKを利用して、継承したクラスを作って利用
  • Parse core(Javascript)を利用すると、サーバー側で処理ができる
  • Push通知も提供される、Channnel(設定したユーザーの分類)ごとに通知が可能
  • 認証(Facebook&Twitter利用)
  • レイテンシもストレスなく使えている
  • SDKが充実

Parseの実用例 Anypic

Firebase

  • GoogleのMBaaS
  • 会場では使った人が居なかった

milkcocoa

  • iOSのSDKがβ版
  • Web側で使うもの、かなあ

mBaaSを使わない理由

  1. SDKの学習コストが高い
  2. SDKのサポートがAppleから提供されるものと比較するとよくない
  3. Apple公式のCloudkitがある

3. Apple Watch体験記

稲熊さん(CamCam)

とてつもなく濃厚なMacFan談義(すみません、メモとれてませんでした)

その間にやっていたこと

前回、唐突にLTを依頼されたので、今回も何かあるんじゃないかとこんなのを当日その場で作ってました。

利用したのはreveal.jsと、前に使ったjThirdです。

DEMOの部分ではParseを動かすつもりでした。

というのも、Parseを今まで触ったことは全くなかったんですが、当日動かしてみたら動かせてしまったのです。

総括

  1. 現場でコード書いている人はやっぱりすごい
  2. mBaaSの活用は真剣に考えるべき

以上、またおじゃましたいと思います。

Reference

勉強会中に調べたものを列挙。

名古屋iPhone開発者勉強会

mBaaS

今どきのiOSのOSS

Sprite Kit

書籍紹介


写真を撮ったら予想外にいい出来だったので木にプリントアウトした話 (レビュー編)

写真を撮ったら予想外にいい出来だったので木にプリントアウトした話 (注文編)の続編です。

木に印刷したものが無事に届いたので、レポートします。

届いたもの

生活感丸出しな写真でレポートします。

封筒で届きます。

封筒自体がいい感じです。

封筒を開けると中に包みがあり…

それを開けると、印刷された写真と対面です。

裏面、もろに木の感じが伝わってきます。

印刷された板を立てるための足も付属されてきます。

感想

良かった点

存在感が段違いです。

iPadでの表示と比較すると、iPadのほうが明らかにきれいに表示されています。

一方、木に印刷した方はよく見ると木目が浮き出ていたりします。これによって質感が変わり、より強烈な存在感を醸し出しています。

残念だった点

宛先の住所が間違っていました。

海外からの送付だったので難しいのでしょう。そんな中でもきちんと配達してくれた、日本の物流は本当にすごいと思います。

最後に。

普段はディスプレイしか見ていませんが、印刷物もいいですね。印刷はとかく奥が深いなと感じました。

また、まだ流行っていないと思われるので、少し気の利いた贈り物にいいかもしれないですね。


Apple Watchは買いかを腕時計嫌いが使ってみて結論出した

AppleWatchを買って使いはじめて結構経ったので結論出します。

結論

  1. iPhoneへの通知を眺めていないと死にそうなら買うべき

  2. iPhoneを部屋の中で探しまわる人は買うべき

  3. Apple Watchをもしかしたら買っているかも、と思われそうなら買ってもいい

  4. 使い方を先に知りたいのなら、買うべきでない

  5. 腕時計が欲しいのならば腕時計を買うべき

はじめに

龍一郎@技術担当です。腕時計が積極的に嫌いなわけではないですが、腕時計を薦められても買わない生活をして数年経ってます。

いつか買いたいなあと思いつつ買わない生活を続けていたので、Apple Watch買いました。

Apple Watchでは何ができるのか

まずは大雑把にデフォルトの状態でできることを、その後アプリ導入時にできることを紹介します。

アプリを導入せずにできること

1. iPhone紛失対策

iPhoneの紛失対策として、今まで「iPhoneを探す」機能がありました。僕も何度か使っています。

でも、室内にあるのは分かっているけれど、部屋の中でどこにあるかわからなくなったときにはどうしようもないです。特に外出先の部屋の中のどこにあるかわからない場合詰んでしまいます。

そんな全世界のうっかり者向けの機能として、Apple Watchでは、近くにあるiPhoneからアラーム音が出せます!

また、どこかにおいてきてしまった場合にも、iPhoneとの接続が切れたという表示がされるので気が付きやすくなります。

2. 盤面のカスタマイズ

全世界の今日が何日で何曜日か思い出せない病の患者の強い味方となってくれます。

シンプルなデザインから…


いろいろな情報を一度に表示したデザインまで様々に選べます。

表示する内容も自分でカスタマイズ可能です。

Apple Watchでは、こんな感じに盤面の表示をカスタマイズできます。使い続けるためには結構重要な事だと思うので改めて述べました。

3. 心拍の測定

Apple Watchをつけていると、自動的に心拍の測定がなされます。

とったデータについてはiPhoneの「ヘルスケア」アプリから閲覧できます。ちょっと本題からそれますが、このアプリ、歩数とかグラフで出してくれるので面白いです。

4. その他できること

一日中バッテリ切れを起こさずに利用できます!

実測値として、13時間ほど使って残りバッテリー容量は55%でした。1日持つというのは本当みたいです。

Siriの利用や、電話、マップなども使えるみたいです。ただこの辺りの機能は使いこなせてません…。

アプリを導入してできること

アプリを導入してできることは、iPhoneのアプリだけでできることと、Apple Watch対応のアプリでできることの2つに分けられます。

ここでは、それぞれについて何ができるかを、ざっくりと紹介します。

iPhoneのアプリだけでできること

Apple Watchから、iPhoneへの通知が見られます。

メールアプリ(inboxやOutlook)を使っている人は、メールの確認を爆速でできます。また、チャットツールとも相性が良いですね。発言内容を同様に爆速で確認できます。

また、デベロッパー側にとっては通知の文面を再考する良い機会になっているのではないかと思います。

Apple Watch対応のアプリでできること

基本的にアプリの機能の一部が使えるようになっているようです。

例えば、Wunderlistでは、タスクの確認と、タスクの完了入力ができます。

なんかすごそうな機能としては、Evernoteアプリでは音声入力でノートの検索ができます。

この辺り手早くできたら、デモとしては十分見栄えがでるかもしれないです。

ですが、この辺りはまだ評価するのは尚早だと思います。結局アプリで何ができるかは、アプリが出揃ってから考えたほうがいいと思います。

最後に、結局どういうことができるのか、僕の評価を書いておきます。

Apple Watchでできることは結局何なのか

Apple Watchでは、次のジェスチャーについて、通常考えられないような意味を、自分にだけ持たせることが出来ます。

  1. 腕時計(のようななにか。以下省略)を眺める
  2. 腕時計の竜頭を回す
  3. 腕時計の盤面を撫でる
  4. 腕時計の盤面を押す

これらの行為の内、腕時計を眺める(あるいはふと見る)行為は、無意識の行為として会話中に行っても仕方がない行為として認知されています。

例として、社会人としてビジネスシーンで使えるフォーマルな腕時計の選び方の記事をとると、スマホはNGでも腕時計はOKとなっています。

腕時計を見るという仕草にiPhoneの通知を見るという、通常考えられないような意味をもたせられます。

これについて価値を見出だせるなら、Apple Watchは買いです。

例えば、SNSアプリからの通知を確認したい欲求が強く、確認できないと息が詰まる方にとってなら、腕時計を見る仕草で通知の確認が実現できるのは価値があると思います。

「結局何ができるのか」は適切な質問ではない

「Apple Watchって何ができるの?」は僕が直接受けた質問です。その質問にそのまま答えようとしたのですが、上に書いたようなちょっと無理のある回答ができあがってしまいました。

その理由を僕なりに書くと「適切な質問じゃないから」なのですが、以下に弁明として記します。

1. 自然な動作の限界

第一に、結局不自然な動作をするハメになるからです。

通知を確認する場合、自然な仕草でApple Watchの盤面を眺めた直後、ユーザーは盤面を撫でる必要に襲われます。

これは通常、頻繁にはありえない行為です。

せっかく自然な仕草でiPhoneの通知を確認できたのに、続く操作で台無しになるというオチが待ってます。

自然な動作だけでアプリの操作を完結させられないわけではないですが、何ができるかはOSとアプリの今後の発展次第でしょう。

2. 自然な動作の時間依存性

第二に、自然な仕草についても、今後は社会的に許されなくなる可能性があります。

現状、iPhoneを運転中に見るのは許されない行為です。また、運転中に意識を手元のデバイスに集中させるのはどう考えても危険な行為です。

Apple Watchを運転中に見るのは禁止されていません。また、それだけを狙い撃ちで禁止はできないと思います。腕時計を見る仕草と区別がつきにくいと想定されるためです。

しかし、運転中にApple Watchを凝視するのはどう考えても危険な行為です。iPhoneの閲覧に制限がかかるのならApple Watchについても同様の制限が課されるべき、という意見がこの先大多数を占める時が来るかもしれません。

会話中に盤面を覗く行為についても、相手との会話に集中していない証拠として、今後マナー違反であるとされるかもしれません。

現在許されるジェスチャーが今後許されなくなる可能性があるため、特にビジネスでの利用について、現時点での判断は難しいでしょう。

3. 正しいが期待されていない返答の存在

第三に、プログラムが動く基板で何ができるのかを聞くと、次のような返答が正解になってしまいます。

  • 1より大きく100より小さい素数を列挙する
  • サーバーにrm *をroot権限で実行するコマンドを送る
  • Hello, world

いずれも期待している答えとは違うはずです。

4. できないことの存在

Apple Watchのアプリではサクサクな動作が原理上出来ないところがあります。

細かい実装の話はさておき、構造上、Apple WatchはiPhoneの子機です。特に、アプリはiPhoneアプリの一部でしかありません。

Apple Watchのアプリは何かをしようとするたびに、基本的にはiPhoneとBLEでの通信を必要とします。ここがネックになっているのか、画面の描画のとき、ロード時間がiPhoneアプリに比べて長くなっています。

これは、モバイルの特性の一つとされる、起動の早さを損なっています。

Apple Watchは買いか

次の人にとっては買いです。

  • iOSアプリの開発者
  • Apple製品が大好き
  • Apple製品が大好きであることを期待されている
  • 自分にとって使えるか使えないかは他人ではなく自分で判断したい

総じて、自分がアーリーアダプターだと思うのならば、あるいはアーリーアダプターであること自体に価値を見出せる人ならば、Apple Watchは買いです。

それ以外の方は買うべきでないです。実際、装飾品として得られた評価は「ああ、新しいもの好きなのね」というだけでした。

最後に

深津貴之さんのブログから「UI考(番外編) AppleWatchについて、あまり語られてない視点」を引用します。

おそらくであるが、現段階のApple Watchの使い道については、当のAppleも明確な確信を持っていないのではないか?今回のサードアプリは単なる賑やかしであり、蓋を空けてみるとApple Watchの使い方にマッチしないものがほとんどなのではないかと予想される。

現状このとおりだと思います。また、使い方はまだ決まっていないと思います。

僕としては、誰も正解を持っていないデバイスに触れているので満足しています。

Ans. 買うな。僕は買う。

Reference

全部深津貴之さんのブログ。

  1. UI考(番外編) AppleWatchについて、あまり語られてない視点
  2. Apple Watchアプリを作るべきかUIUX評価雑感

車載スピーカーを変えたので検定した

車を買ったら流してみたい音楽のリストの中にユーロビートが入っているのは某頭文字Dの影響だと思うのです。

龍一郎です。車載スピーカーを取り替えたので、効果があったかどうか盲検して検定しました。

結論

これを

こうしました

鳴らしている音はBad Apple!! feat. nomicoです。


色々捗りそうな自分の車で捗っていない点

最近、自分の車でドライブするのにハマっていまして、毎週末はどこかにドライブに行っています。

自転車でどこかに行くのも好きですが、車だと行動範囲が更に広がるのが嬉しいですね。

また、自分の好きな曲をかけて移動できるのが特に嬉しいです。

ただ、車の中で曲を聞くと、なんだか音が潰れている感じがしていました。

路面の近くを走っているからしかたがないのかなあと思いつつも、やっぱりがまんできなかったのでスピーカーを替えました。

スピーカーの選択

DDL-R170Sにしました。

視聴した結果気に入ったのと、安売りしていたので選びました。

が。価格についてはもうちょっと調べてから行くべきでした、完全にAmazonのほうが安かったです。

テスト

同じ音源をスピーカーから流し、iPadで同じ位置から録音し、その結果を聴き比べました。

こちらが純正のスピーカーで鳴らした結果。

こちらがDDL-R170Sです。

いい音になった…ってこれだけじゃ個人的な感想以上の何でもないので、盲検試験して検定やります。

盲検化

実験は次の手順で行われました。

  1. 一台のiPadでdjay 2を用いて左右に2種類の音源を配置
  2. 被験者に「音質の良いものは2種類の音源のうちどちらか」を選ぶよう説明
  3. 音源を鳴らす順番は被験者が選択、何度でもどの順番でも聞き直すことを許可
  4. 演奏自体は験者が行い、被験者にはiPadの画面を見せない

一重盲検ですね。ちなみにn=2です。

実験結果

実験結果はこちら

音源 純正スピーカー DDL-R170S
選んだ人数 0 2

検定を行うと、純正スピーカーとDDL-R170Sに差がないという帰無仮説の元でp=0.25なので、通常用いられる基準では優位ではないですね。

考察

結果自体を見る限り、考えられる限り最良の結果が得られています。買い替えた効果があったという仮説は立てられそうです。

一方、統計的な立場からは買い替えた効果があったとは断言できない結果です。これは完全に標本数が足りてません。最低でも7人くらいは必要でしょう。

最後に

ピュアオーディオ勢怖いです

Reference


Agile Japan 2015 サテライト<名古屋>に参加した

「コード書かない系ITが薬剤師と一緒にアジャイルやってみた」って記事を書きたいのでその前段として。

龍一郎です。4/15日に開催されたAgile Japan 2015 サテライト<名古屋>に参加しました。

メンバーはIT系1名に薬剤師2名という感じ。

二人には参加をお願いしたところ快諾してくれました、ありがとうございました。

なお、当日の様子は【開催報告】Agile Japan 2015 サテライト<名古屋>にて公開されています。

プログラム

  1. 基調講演
  2. ワークショップ

基調講演の前に

  • Waterfallが基本になっている企業にも、アジャイルが導入されてきている
  • 「アジャイルの魂」という小冊子が配られた、販売中

「失敗から学ぶ」

  • 今回のメッセージ
  • やってみて、失敗から学ぶというのが有効
  • アジャイルは習得しにくいと言われるが、失敗を早期に気がつく仕掛けがある
  • 失敗や成功の体験を共有してほしい

1. 基調講演

基調講演1. アジャイル・テスティング

  • 分散したチームでテスティングを使った経験をシェア

  • 一拠点に集まっているチームはアジャイルを適用しやすい

  • 分散しているチームもある、国をまたいでグローバルに存在していたり、オフショアを導入していたり…。

利点と欠点

  • 利点 : フォローザサン
  • 欠点 : やりとりに時間がかかる、問い合わせ一回に24時間かかる、文化的な背景の違い、言語の違い

  • 他人がどのような課題を持っているかを理解することが大事

Play nice in the sandbox

  • 「職場で楽しく働く」という意味
  • シンプルなルール、砂場と同じ
  • 他人と信頼関係を気づくことが特に大事

ワークショップ : 風景を言葉で伝える

  • 言葉で全ては伝わらない!

テストでの課題

  • 待ち時間の多さ
  • 誰に聞けば正解がわかるのかわからない

沢山ある!

一般的なコミュニケーションに対する考え方

  • 全員に情報をオープンにする
  • 全員にヘッドセットで参加できるようにする

コミュニケーションツール

  1. e-mail : ブロードキャスト、口頭で話した内容のまとめ
  2. 電話
  3. メッセンジャー
  4. Web会議
  • 長所が違うので使い分けることが大事
  • 相手の状況 (天候とか、相手の調子とか)がわかることが大事

コラボレーションツール

チャットツール

マインドマップ

本を書くときに章ごとにマインドマップを共著者と書いている

ストーリーボード

カンバンの重要性

  • 誰が何をやっているのかわかる
  • 誰に何を聞けばいいのかわかる

チームビルディング

  • まずは互いを理解することが大事
  • Personal Bingoをやったりして、互いの会話のきっかけを作る

本をテストする

  • マインドマップを作成し、それがうまく機能するか見直す
  • 見直すことにより、理解が深まる

共通理解をつくる

  • 「完了」の定義が大事、人によって定義は異なる
  • 違うスキルを持つ人が三人集まって話すのが良い
  • 何かを捉えたら、それをテストとして残す
  • 書く前に話す、会話した結果を書く、書いた結果について会話する

絵を描くことの重要性

  • 知らないことについて言葉だけで説明されてもわからない
  • 絵があることで初めて質問できる
  • 質問について、テストの形で残す

テスト計画で重要なこと

  • フィードバックのサイクルを短くする
  • 依存関係を早めに取り除く、誰かの作業が終わらないとフィードバックが得られない、というのはよくない

何から始めていくべきか

  • 学ぶ組織を作る
  • 失敗から学ぶ
  • 失敗できるように、安全にする

柔軟性・気づき

  • 痛みを共有する
  • 振り返りを全員で行い、問題・気づきを共有する

信頼関係に向けて

  • 適応する : 自分のやり方を貫くのではなく、相手のやり方を受け入れる
  • 自分が心地よい場所から少し外れて、他人のやり方を見に行く、相手を理解することが大事

Q&A

  • Question : 反応返してくれる人が少ないんだけどどうしたら?
  • Answer : 日本だけじゃなく、各所で同じことを聞かれる。簡単な回答はない。相手に質問するとき、相手が間違えてもOKだという態度を示すことから始めるのがいいと思う。

基調講演2. デジタル革命にはアジャイルが効く

INDUSTRIE 4.0

  • 第4次産業革命が起きている
  • IoT, Mobile, Clowd… サイバー空間が実空間に影響を及ぼすようになった

デジタルビジネス革命

  • 基本的には創造的破壊
  • 全ての分野で本業が危なくなっている
  • カメラのフィルムが例に出される、FUJIFILMが良い例になる

デジタルビジネスの特徴

  • 競争の軸が変化する
  • 過去の新聞 : 配ったら回収できない、正確性が命
  • 現在の新聞 : 配っても変更できる、速度が命

デジタルビジネスのキーワード

  1. Social
  2. Location
  3. Mobile
  4. Cloud
  5. Sensor
  6. Bigdata
  7. Contactless Payment

センサーをつけてデータを収集するといろいろなことが可能になる

  1. TOTOの取り組み : 便器にセンサー、尿から健康診断
  2. ドイツのサッカーチームの取り組み : サッカーの練習にセンサー、

Salesforceシンポジウムで話されていること

  • セールスをデジタル化する
  • セールスマンの能力を丸裸にする
  • 能力を計測し、改善につなげる

こういったことが、実際にやられている

競争優位から、継続的イノベーションへ

  • デジタルビジネスの現場では、競争優位が簡単に崩れる
  • 良い製品を作って終わり、ではダメ。良い製品よりももっと良い製品がすぐに出てくる。
  • 常にイノベーションを起こし続けることが大事

4つの視点

1. Customer Centric

  • お客様側から見て、今欠けていることを探す
  • 方法論を確立していないと無理
  • デザインシンキングのやり方を徹底して学ぶべき (Cefil)
  • Workshopで体験。Singaporeでは国を挙げてやっている。

2. Collaboration

  • ビジネスとエンジニア、 お客様とチーム、など
  • 議論ではなく対話、考えていること・思いを伝えあい共有していく

3. Visible

  • 言葉だけじゃ無理、対話だけでも無理、可視化も必要
  • 模型を作ったり、プロトタイプを作ったりする、要件定義書よりもずっと機能する

4. Iterative

  • 改善・改善・改善
  • まだないものを作るとき、一か八かの投資はできない
  • フィードバックを受けながら、お客様に教えてもらうことが大事

Agile!

  • ビジネスの戦略において重要な視点は、アジャイルのやり方に合致する
  • Kuala Lumpurではプロジェクトマネジメントでアジャイルしか教えていない、Waterfallは教えない

Constant beta

  • 常に改善できること
  • 完成することなどあり得ない
  • アジャイルチームを社内に作成し、勉強してチームとして成熟させる、成功例を作る

これからのエンジニアに求められること

  1. 新しい取り組みによる成功事例の作成
  2. エンジニアからの社会課題の解決提案
  3. エンジニアからのビジネス提案

基調講演3. ふりかえり

  • 感想を付箋に書き出してKPT(Keep, Problem, Try)で分類

分類した結果については、【開催報告】Agile Japan 2015 サテライト<名古屋>を参照。

2. ワークショップ

ペーパークラフトで学ぶフィードバックと改善(鬼)

ペーパークラフトで橋を作成することを通じて、アジャイル(スクラム)の手法を体験しました。

作成した橋はこんな感じです。

手を動かすのはやっぱり楽しいです。

Reference

1. 基調講演

基調講演1. アジャイル・テスティング

基調講演2. デジタル革命にはアジャイルが効く

2. ワークショップ


jThirdでチルノちゃんのMMDモデルを動かした

龍一郎@技術担当です。

以前、MILKCOCOAハッカソンに参加した話で書いたことについてこんな反応を頂きました。

というわけでjThirdでチルノちゃんを動かします。

Web3Dの実行環境(jThree & jThird)

今回は、Web3Dに挑戦します。また、Web3Dを扱うためのライブラリとしてjThreeを、また開発プラットフォームとしてjThirdを利用します。

Web3Dはブラウザ上で3Dオブジェクトを表示させたり動かしたりするやつです。

この辺りの技術で有名なものは次の3つでしょうか。

  1. WebGL : 最近スマホとかでも動く
  2. FLASH : 古参
  3. Unity : 昔からブラウザ対応してましたね

今回、この中ではWebGLを利用しますが、直接扱うのは正直つらいシロモノです。

そこでMilkcocoaハッカソンで紹介いただいて使えそうだと感じたjThree&jThirdをを利用することで、開発の難易度を抑えます。

jThird

紹介文を引用すると「jThirdは作品の引用とWeb3Dでの投稿が可能なプラットフォームです」とのこと。

こんな感じにWeb3D作品が動きます。クリックすると動き出します。

製作者の一人の松田光秀さん曰く「Web3DのYoutubeを狙ってます」だそうです。この方面白い方ですね。

ここでWeb3Dの描画に利用(正確にはWeb3D作品の作成に利用)されているのがjThreeです。

jThree

jThreeはWebGLの機能をjQuery並みの手軽さで扱うためのjavascriptライブラリです。

たった3KBのコードで3DCGモデルが歌って踊ってアングルも操作できる! jQueryベースのライブラリでMMDデータを活用したWebGLコンテンツを作ろう

先ほど挙げたWeb3D作品のjavascript部分をまるっと引用するとその威力がわかります。



jThree( function( j3 ) { $( "#loading" ).remove(); j3.Trackball(); j3.MMD.sync("audio"); $("audio")[0].play(); var mode = 0; j3( "mesh" ).click( function() { mode = 1 - mode; if ( mode == 1 ) { j3( this ).attr( "geo", "#geo1" ).css( "mtlColor", "#f00" ); } else { j3( this ).attr( "geo", "#geo0" ).css( "mtlColor", "#00f" ); } } ); ( function() { j3( "mesh" ).animate( { rotateY: "+=3.14" }, 5000, arguments.callee ); } )(); }, function() { alert( "This browser does not support WebGL." ); } );

僕が別で開発した経験のあるARToolkitだと、表示までにだいたい200-500行くらい書いています。

なおかつ、それだけだと視点は動かせないし、初音ミクを召喚なんて夢のまた夢の状態なんですね…。

それが、これだけのコードで実現できるというのは本当にすごいことだと思います。

jThird & jThreeでチルノちゃんを動かす

上記の技術を使って、チルノちゃんを動かしていきます。

MMDモデルの選定

チルノちゃんはいつでもマジフェアリー。まずはモンテコア改変モデルチルノちゃんを表示します。


マジフェアリー。

注意点として、モデルのライセンスには目を通しましょう。

というのも、再配布不可だったり、MMD以外での使用が禁止されていたりするためです。

Web3Dの宿命として、モデルをサーバーにアップロードして公開する必要があるからそこも注意ですね。

jThirdの環境整備

jThirdに開発環境を用意します。とはいえ、アカウントを作成して、ログインして、アップロードして終了です。

jThird自体の利用方法については、次を参照しました。

jThird Editorの使い方

もう少し詳しく アカウントの有無で何が違うのか

jThirdの利用だけなら、アカウントを作成せずに「Anonymous Sign Up」で利用できます。

/Shareフォルダ以下に様々な方のアップロードしたファイルがあり、これを利用することで開発できちゃいます。

でも、ファイルアップロード不可です。

自分のアカウントを作成すると、次のフォルダにファイルをアップロードして利用できます。

  • /Share : 100MB
  • works/ + assets/: 100MB

好みのMMDモデルを用意しようとおもうと、アカウント作成必須ってことみたいです。

jThirdでの開発

参考にするドキュメント類

jThirdの偉い人曰く「jThirdにドキュメントはありません。」だそうです。

ですが、jThreeには備忘録がありチュートリアルが揃っているので今回はそれにそって開発します。

jThree備忘録

また、こんな感じにチュートリアル完成(かその寸前)で止まっているものが多く公開されています。

これらのソースコードを参考にすると楽そうです。

MMDモデルの読み込み

で、参考にして作りました!

一瞬喪服かと思ったけれど、テクスチャが読み込めていない感じです。

別モデルで表示してみます。motoさん作。

チルノ Ver.2.2

表示してみました。

「木曾かな?」って感じに右目が表示されてないですね。もう一つ試してみます。

カタロットさん作のモデルを試してみました。

元気な感じでマジフェアリー。

マジフェアリーなチルノちゃんがパーフェクトに表示されてくれました。

アップロードからもう一度説明

配布されているpmxファイルをjThirdプラットフォームにアップロードして呼び出していきます。

今回はチルノ(ノーマル版)を使用しました。

index.goml : GOMLの記述

GOMLでは3D空間に配置するオブジェクト類を記述します。

タグ内にMMDモデルのpmxファイルをロードして使いました。

index.html : HTMLの記述

HTMLファイルの役割はイマイチ理解できていないのですが、利用するプラグイン類を指定します。

今回は、MMDプラグイン(jThird.MMD.js)と物理エンジン(ammo.js)を利用するので指定しました。

また、音声もここで指定しました。

index.css : cssの記述

CSSは特に何もしてないです。アニメーションとか書けるみたい。

index.js : Javascriptの記述

JavascriptではjQueryとjThirdを利用して、マウスクリック時のイベントを定義します。

また、音声とMMDモデルのモーションもここで同期させました。

結果

実際に動かしているのがこちら。クリックすると音声が流れてチルノちゃんが踊ります。

これだけで動くんすね…。

ハマった箇所

とはいえこれだけでもハマりました。

最初、goml jThreeのタグを次のように書いてしまって、モデルがロードされませんでした。



<!-- MMDモデル&物理演算 --> <script src="/share/jThree/mmd/1.6/jThree.MMD.js"></script> <script src="/share/jThree/ammo/1.0/ammo.js"></script>

これはプラグインを記述する順番が逆です。よく読むとちゃんと書いてありました。

完全に不注意でした。Javascriptはこういった順序にも気をつけなきゃいけないのはまだ慣れないです。

次回予告

今回はチルノちゃんを動かすという宿題を完了させましたが、色々作りたいものはあるんです。

  1. jThird上でSlideshare的なことをやる
  2. jThird上でSlideshare的なことをやってmilkcocoaで複数端末を同期させて、ドヤリングする

このあたりやっていきたいですね。あと、これも気になります。

Reference


ダイスリーディング/「動かない」と人は病む

ダイスリーディング/「動かない」と人は病む -「動かない」人は病むー生活不活発病とは何かー

著者:大川弥生
講談社現代新書より

1. 生活不活発病とは

生活不活発病とは、病気などが原因で生活が不活発になったことにより、身体の機能が低下してしまう病気のことである。

生活が不活発になる、とは?

その人の以前の生活の状態に比べて、また一般の同世代の人と比べて、毎日の、朝から晩までの生活が不活発になるということ。普段は意識せずとも行うことのできる、生活の中で目的や意味を持って行う動作全般(屋内や屋外を歩くこと、食事、入浴、洗濯、家事、仕事など)が十分に行われていない状態を指す。

生活不活発病進行の悪循環

  1. 「動かない」(生活が不活発)ことにより生活不活発病発生
  2. 歩くことなどの生活動作が難しくなったり、疲れやすくなって、「動きにくい」ようになる
  3. ますます「動かない」ようになる
  4. 生活不活発病進行
  5. ・・・・ 最終的には、社会参加もできなくなり、「生きがい」も失われてしまう。

大切なこと

本人と家族の積極的取り組みが大事

  • 実行状況 : している活動。実生活の中で実行しているやり方。
  • 能力 : できる活動。工夫したり、がんばればできるやり方。

この二つの差を認識することが重要。

2.『補完的介護』から『よくする介護』へ

補完的介護と、目標指向的介護

補完的介護 : 手助けするだけの介護。実行状況、つまり、している活動を向上させるだけ。

本人が自発的に生活動作を行う機会がますます少なくなる。

よくするためには、現時点での不自由さだけを考えるのではなく、将来の生活・人生についての具体的な『目標』を設定し、その実現に向けて働きかけを行うことが大事。

よくする介護=目標指向的介護

作られた歩行不能

歩けるようになる可能性は十分にあったのに、適切な働きかけがされなかったために、結局日常生活を歩いて過ごせなくなった状態。3つのタイプあり。

①車いす依存型

現に歩けないわけではなく、適切な工夫や働きかけをすれば上手に歩けるようになるはずであったのに、安易に車椅子を使い続けたせいで、歩行が困難になった状態。

病院やデイケア施設で長期間過ごすと陥ることが多い。

②病気・ケガ契機型

病気やケガをきっかけに、ある程度まとまった安静状態が必要になるが、実際に必要な安静期間を超えてもなお誤った安静を取り続けた結果、生活が不活性になった状態。

③車いす自立滞留型

適切な働きかけをすれば将来は必ず、自立歩行できるはずであったのに、『とりあえず』まず車椅子を使用し、それで動き回る(車椅子自立)を優先した結果、車椅子による自立は達成したが、その先の『歩行自立』までは進まず、いわば車椅子自立状態に滞留した状態。脳卒中などの手足に不自が起こる病気でよくみられる。

歩行不能状態がつくられる原因

  1. 生活不活発病についての理解の不十分さ
  2. 日常の歩行を安定させられるような働きかけ(技術)の不十分さ
  3. 車椅子偏重の思想

3.『活動度』を意識した医療へ

安静をとること、についての指示は、内容や時間帯など具体的なことが多い。

しかしながら、安静の必要がなくなった時に『もう安静をとらなくてもいいですよ』とか『なるべく動きましょう』というように漠然とした指示しかされていないことも多い。

→ 活動度を向上させるための具体的な指導の不足。

活動度を加味した指導

  1. 安静にするなら、安静が必要な理由
  2. どういう状況になるまで安静が必要か(ex.高熱のある間は安静)
  3. 安静にしている期間の中でも、『この程度は動いても良い、むしろ動きなさい』など指標を挙げる

(ex.昼間は横にならず、最低限座っていましょう。なるべく早く普通の生活に戻るようにしなさい。歩いた方が体の回復が早いのです)

4.生活の不活化を防ぐ、遠隔介護予防

4-1.遠隔介護予防とは

電話、FAX、メールで現状を把握

4-2.遠隔介護予防に必要な心がけ

⑴さりげなく促すこと

動く目的のさりげない提案

⑵質問もアドバイスもなるべく具体的に

『最近どうしてる?』→ダメ

『今週は美術館に行った?絵の展示は見た?面白い絵はあった?図書館ではどのぐらい過ごした?面白い本はあった?疲れなかった?』→具体的に

『前よりずいぶん(時間や回数などが) ふえたじゃない!』→本人の活動範囲が拡大していることを自覚してもらい、それを一緒に喜ぶような話しかけかたも効果的

⑶季節を話題にする

生活不活発病の精神・知的面での症状として、気力がなくなり、季節の移り変わりにも無頓着になることが少なくない。

季節特有のものを話題に出して、関心を引き起こすことも重要。

⑷家での生活も大事

外出することは大事であるが、外にはかなり行っていても、家ではほとんど動いていないこともある。

これに対するチェックやアドバイスも大事。

家事をすすめてみたり。

4-3. 濃厚な関与が必要な場合もある

⑴定年になった後

仕事を生き甲斐にしてきた人は多い→生き甲斐の喪失。

生活を楽しむヒントを提供。

⑵一人暮らしになった時

積極的に生活の仕方を変えて、一人暮らしなりに充実した活発な生活を心がける

⑶病気の後

過度の安静を取らないよう、活発な生活にできるだけ早く戻るように働きかける。

⑷生活環境の変化

引越しや同居家族の変化。

⑸季節の変わり目

気候の良い時に夏・冬を考えて多めに外出するようにここ心がける。

夏でも冬でも外出しやすいような場所を探しておくことも大事。

5. 生活不活発病と、普通の病気の違い

病気の原因の違い

  • 普通の病気→病原菌、ウイルス、ケガなど、人間の『生物』としての面におけるなんらかの異常が原因
  • 生活不活発病→『生活』の変化が原因。生活が不活発になることが原因

生活が不活発になるきっかけ

①社会参加の低下

することがない環境の変化による行動の目的の喪失

  • 遠慮→同居者に対する遠慮など

  • 社会通念による関係者の遠慮など→周囲の目(社会通念)を気にして社会参加が低下

社会通念による社会参加の『自己制限』

→『年だから動き回るのは良くない』『災害時に遊ぶなんて』『近親者や友人に不幸があったのに』など周囲の目を気にして、やりたいことまでしない状態

②動作自体の『やりにくさ』

病気のため→病気のために動作自体が『やりにくく』なり、それによって『やらない』という状態

環境の悪化→災害などが起こり、道や避難所、仮設住宅などの環境が不適切なために、生活動作が『やりにくく』なり、そのために『やらない』状態

③生活動作の量的制限

病気の後→病気自体では生活動作の症状は出ないのに、病気の時は安静、という通念に縛られて、必要もないのに生活動作を自分で制限してしまう状態

介護や支援のありかた→補完的な介護や支援により、生活動作を自身で行うことが減少

生活動作自体のやりにくさ→やりにくいからしない、という量的制限 季節の影響→夏は暑く、冬は寒いため外に出ない

症状の違い

普通の病気と生活不活発病とは症状が違う。

普通の病気の症状

限られた数の心身機能の症状。風邪なら、熱、せき、のどの痛みの3つの症状。

生活不活発病の症状

生活動作の不自由さ・難しさとして現れ始める。長い道を歩くと疲れる、外が歩きにくい、立ち上がりにくい、座っているだけで疲れるなど。そして、全身の機能の低下へ。

予防と改善の方法の違い

症状が違うのと同様、予防と改善の方法も異なる。

普通の病気

薬の投与、個々の心身機能の症状の治療

生活不活発病

原因である生活の不活発化を予防・改善すること。生活のあり方を変えていくことが必要。

6.善意の支援が生活不活発病を生む例

事例 : 災害時

災害時には生活不活発病が同時多発する

災害時、生活の活発さが災害前よりも低下

  • 家の中ですることがなくなった(仮設住宅者に多い)
  • 外出の機会が減った(外出の目的の喪失)
  • 遠慮
  • 生活環境の悪化など

これらが歩行困難などの生活不活発病の症状へ繋がる。

社会参加の機会を増やす

なんでもやってあげる、というような上げ膳据え膳の支援は、生活不活発病を招くことがある。

被災者であっても『すること』をもって社会参加の機会を増やすことが、生活不活発病の予防につながる。

マイナスではなくプラスをみる支援へ

代行的・補完的な支援は慎重に考える

なんでも代わりにやってあげる、というのは被災者から『すること』を奪ってしまい、生活の不活発さを起こしてしまう危険性あり

やりがい・充実感で動く機会を設ける

支援を受ける側の人たちの『やりがい・充実感』への影響を考えることも大事。被災者が充実感を感じられるような『すること』をつくり、動く機会を設けることに役立つ支援のやり方もある。

6.『生きる』ことの構造

生活機能の3つのレベル

1.社会参加(社会レベル)

社会とは家族を含む広義のものであり、社会参加とはその中でなんらかの役割を果たすこと、楽しむこと、働くこと、家庭で役割を果たすことなど、がある。

2.生活動作(個人レベル)

生活の中で、なんらかの具体的な目的をもって行うあらゆる動作・行為。

3.心身機能(生物レベル)

体だけでなく、頭や心の働きや構造のすべて。

これら3つの関係社会参加は「目的」、生活動作はその目的を実現するための「手段」、心身機能は手段を構成する「要素」と考えることができる。

『生きる』構造と病気

通常の病気では、心身機能の異常→生活動作の制限→社会参加の低下、という因果関係となる。

生活不活発病では因果関係が、社会参加の制限→生活動作の低下→心身機能の低下、という逆の方向性を示すことが特徴的。

7. 今後のために

生活不活発病は、誰にでも起こりうる病気であることを理解し、正しい知識を持つことが大事。

予防・改善の目的の設定

生活不活発病の予防や改善について考える場合には、病気の克服を目的にするのではなく、『良い人生、充実した生きがいのある人生をつくる』ということを目的にすることが大事。

世界一の高齢社会となった現代日本社会が、世界に先駆けて実現しなければならないこと

  • 健康で活力ある長寿社会を築くこと

生活不活発病の理解や克服は、その実現のための「鍵」となるはず!

ダイスリーディングを終えて

生活不活発病という言葉や存在は、この本を読んで初めて知った。

心身機能の異常が原因となる、通常自分たちが経験している病気とは異なり、生活不活発病は、生活の質の低下が原因となり引き起こされるらしい。

しかもこの病気は高齢者に限らず、あらゆる人間に起こりうるということだ。


興味深かったのは、社会への何らかの関係を持つという活動の程度が減少することが生活不活発病を引き起こすきかっけとなる、という点である。

人と人との生き生きとした関わりが枯渇し、生きる目的をも見失いがちな現代だからこそ、この病気を知ることは重要な意味を持つのではないか、と思う。


僕は、4月から研究の場から離れ、薬剤師として新たな生活をスタートさせる。

薬剤師としての経験はなく、まだ右も左もわからない状態ではあるが、たくさんのことを学ぶ中で、現在の開局薬局のあり方、というものについて考える機会も増えることと思う。

その際には、人々の健康を増進するための薬局が出来ることは何であるか、について今回学んだ生活不活発病についての知識を絡めて、自分なりの答えを見つけられれば良いな、と考えている。

例えば、人々に生きる「目的」を与える薬局の具体像、とかね。

これについて考えることは、自分への宿題とします。

以上、「動かない」と人は病む、のメモでした。

おかぴー