Monthly Archives: April 2015

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

車を買ったら流してみたい音楽のリストの中にユーロビートが入っているのは某頭文字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月から研究の場から離れ、薬剤師として新たな生活をスタートさせる。

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

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

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

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

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

おかぴー


「コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント」に参加してSlackとかポエムとかesaについて聞いてきた

龍一郎@技術担当です。

コミュニケーションツールと“持ち寄り型”プロジェクトマネジメント by DevLOVE関西に参加してきました。

最初はメモを内輪向けに書いていたのですが、なんだかんだものすごい分量になってきたので、公開します。

I. ポエム駆動開発 エンタープライズ

By こしば としあき(@bash0C7)さん
id:bash0C7の進捗 出来は上々で申し分の無い仕上がり日記

0. 忙しい人向けのA4一枚メモ

1. 背景

  • 仕事の契機を次の三種類に分類。
  1. 上から : トップダウンで降りてくる仕事
  2. 横から : 同僚・別チームから依頼される仕事
  3. 足元から : 自分たちで必要性に気がつく(天啓を受ける)仕事
  • 足元から発生する仕事が多い
  • 足元からの発生現場は、日々の会話とか、飲み会とかの会話だそう。

2. 問題点

  • 会話した内容がすぐに消えてなくなってしまう
    • せっかくいいアイデアであったとしてもそれが残せない
    • 理想的にはそれは何らかの形で残っているべき
  • ビジネス文書や技術文書にしようとすると面倒くさくて手が止まる
    • 書いている間に情熱が冷める
  • アイデアやそこに込められた熱意を何らかの形で残して共有したい解決すべき課題となったそうです。

3. 解決策 : ポエム駆動開発

ポエム駆動開発は次のようにして進む

  1. 天啓・ひらめき
  2. ポエム作成
    • とにかく思ったことを書く
    • 自分の熱量を残すことが大事
    • 「完成していないな」と思ったらWIPタグをつけてとにかく残す
  3. 反応・コメントの書き込み、フィードバック
    • 反応を残す (なくてもなかない)
    • 反応は複数行書く、くらいのルール
  4. プラン化 : スケジュール作成、ゴール設定、インセプションデッキの作成…
    • スケジュールをがっつり乗せて開発に使っている例も
  5. 決裁・承認
  6. プロジェクト開始

このうち、主に1〜3を扱うためにesa(https://esa.io/)を導入

4. やったこと・やってないこと

やったこと

  1. ツールの意図の説明
    • このツールで何を意図しているのか
    • そもそもポエムとは何なのか、何故必要なのか
  2. 自分が理想の利用者として振る舞う
  3. 意図と違う利用の黙認
    • 自分の意図しない使い方をしてもOK

やってないこと

  1. 詳細なルールの作成
  2. カテゴリーの作成

過度な整理はユーザーにとって負担

5. 結果

  • 天啓・熱い議論が残るようになってきた (100人規模で、ポエムは20-30件/day程度)

6. 意見交換

声の大きな人問題

  • 偉い人が書くと、それについて同意を残したくなる
  • 偉い人が否定すると、もうどうにもならなくなる

このような現象が起こりにくい風土が必要かもしれない

書く人の固定化問題

  • ポエムを書く人はめっちゃ書く
  • ポエムを書かない人は全く書かない、たまに完成度の高い力作を投下する

どちらも個性として考え、許容

7. Afternotes

esaの導入検討

  • esa使おうとしたけれど高い : ¥500 / mo
  • つらい

ポエム駆動開発

Reference

II. ストック型+フロー型ツールの導入で社内を巻き込んだ話 : ストック型編

By 白石 尚也さん

0. 忙しい人向けのA4一枚メモ

1. 背景

2. 問題

  1. 新しいこと、誰もしらないことへのチャレンジが続くため、ハマりやすい
    • 自分がハマったところは他の人もハマるはず
  2. 案件が常に複数ある (5-7件、10人チーム)
  3. 品質の追求から、特定の人が高負荷になる、負荷が集中しやすい
    • 負荷が集中している人は見えるようにしたい

3. 解決策 : ドキュメントツールの導入

メジャーなドキュメント管理ツール3種類を導入し、試行して評価した

Qiita:Team

  • 利点 : 機能が多い、実現したいことは大抵出来る
  • 欠点 : 記事が探しにくい

esa

  • 利点 : 見た目がいい、かわいい、デザイナーからの評価はいい
  • 欠点 : 英語前提(WIPって何、とか)カテゴリーやタグで苦労する

DockBase

  • 利点 : シンプル・分かりやすい・探しやすい
  • 欠点 : 特になし (最後に使ったので慣れているのもあり)

結論 : DocBaseに決定

  • 「共有したい」というのは「探しやすさ」で解決

4. やったこと

4-1. リーダーの説得

  • 少人数でテスト
  • データが集まってくる→みんな使い出す
  • 使っているという事実を集めて説得

4-2. メンバーの説得

「何を書いていいかわからない」問題

  • なんでもいいから書いたら共有
    • ちょっとした打ち合わせの決定事項
    • 日報
    • 調べたところ
    • 思うところ
  • 暗黙知を徹底的に排除する

  • 日報で負荷を書くことで、誰に負荷がかかっているかを共有

「書く時間がない」問題

  • 特別に何かを作成するのではなく、普段から書いたものを共有するというやり方

5. Afternotes

「書く時間がない」問題の別解

  • 打ち合わせでは前準備が必要

    • 目的の明確化 : 何を決めたいのか、作りたいのか
    • 決定事項の明確化・確認 : 誰が、何を、いつまでに、を具体的に再確認
  • これらに書ける時間は必要なものとして認識されているので、成果物を共有すれば良い

DocBase

  • 現在無料だけれど、今後は有料

    • Team Gokennyaの規模(4名)だと、¥2,500 / moになる。結構する。
  • 無料のうちにたくさん使うのもいいけれど…。

  • 軽量Wikiの用意もありかもしれない : Tiddlywikiみたいなやつ

Reference

III. ストック型+フロー型ツールの導入で社内を巻き込んだ話 : フロー型編

松尾 浩志さん

0. 忙しい人向けのA4一枚メモ

1. 背景

  • コミュニケーションツールとして、メール+Skypeを利用
  • Skypeがあまり仕事向きじゃない
    • メッセージが個人に閉じてしまう
    • 部屋が会話のたびに乱立する

2. 問題

  1. オープンな場所に情報が集まらない
  2. 気軽に質問できる場所がない

3. 解決策 : Slackの導入

  • 全員参加ルーム有り
  • 外部連携を使い、すべての情報をSlackに集める (タイムライン的に情報を把握)

4. 結果

  1. タイムライン的に情報が集まる
  2. ChatOps : Hubotで色々情報を収集

5. やったこと・工夫

5-1. チャットツールの展開戦略

  • 小さく始めて多数派にアプローチする
  • 新しいもの好きに向けてアプローチして、多数派を巻き込んでいく

5-2. Botを利用したチャットルームの雰囲気作り

  • なごませるためにBotを利用
  • 様々なキーワードに反応するようにして、利用しやすい雰囲気を作る

5-3. チャットツールの利用法 : たらい回し戦略

  • 質問しても、それを知っている人が見ているとは限らない問題
  • 回答されていない質問が多いと空気が悪くなる

  • たらい回し戦略 : 分からない問題について、誰かを名指しして再質問する戦略

  • ふわっと質問すると、質問を誰かが盥回ししてくれて、適切な人まで届けてくれる場にする

6. 課題

  1. ログが流れて消えていってしまう : 有料版なら残るけれど高い
  2. 公開チャンネルよりも、DMが利用される : 情報を公開したいがまだ個人に閉じてしまっている

7. Afternotes

7-1. 社外との利用問題

  • チーム全員で使うほうがSlackの価値が出てくるが、チームの中には社外の人がいる場合も
  • 社外の人にアカウントを発行して使ってもらって解決している

References

今後のアクション

得られたものをどう活用するか

I. ポエム駆動開発 エンタープライズから

  • 企画案の作成プロセス改善
    • 企画案は完成形を提示するものではなく、反応を見ながら育てるものという考え方
    • ポエム駆動開発の導入検討

II. ストック型+フロー型ツールの導入で社内を巻き込んだ話 : ストッグ型編

  • Tumblrで色々やろうとしていることは間違っていない感じ
    • アイデアの共有にはまだ至っていない
  • ドキュメントベースの導入検討 : esa, DocBase, Qiita:Team, etc…
    • ナレッジベースは常に考える必要がありそう
  • 自分がうまく使い続ける必要あり
    • 使っていない人のところに行って広める必要あり?
  • Markdownはみんな使えて欲しいので教える・広める

III. ストック型+フロー型ツールの導入で社内を巻き込んだ話 : フロー型編

  • 「すべての情報を流す」というのは、方向性としては間違っていない感じ
  • 組織の外の人に利用してもらうというのは考えてなかったので今後やる

IV. ワークショップ

  • バージョン管理、プロジェクト管理、ドキュメントベースの準備
  • 非エンジニア向けのプロジェクト管理として、Backlogの導入検討
  • esaとかDocBaseとか使ってみたいので価格含めて検討
  • ツールはたくさん使っても、使っていけるのならOK。沢山あることが悪じゃない。

最後に

大阪日帰り。たこ焼きは食べられなかったです。

JJCLIP#20 葉酸を摂ると脳卒中を予防できるのでしょうか?

まさひろ@メディカル担当です.
薬剤師のジャーナルクラブ開催のお知らせでございます.

平成27年度第1回薬剤師のジャーナルクラブ開催のお知らせ

開催日時:平成27年4月12日(日曜日)
■午後20時45分頃 仮配信
■午後21時00分頃 本配信
なお配信時間は90分を予定しております.

※ツイキャス配信はこちらから→http://twitcasting.tv/89089314

ツイキャス司会進行は、精神科薬剤師くわばらひでのり@89089314先生です.
ご不明な点などありましたら, 薬剤師のジャーナルクラブFacebookページから、又はtwitterアカウント@pharmasahiroまでご連絡いただけると幸いです.

[症例19:葉酸を摂ると脳卒中を予防できるのでしょうか?]
【仮想症例シナリオ】
あなたは, とある保険薬局に勤める新人薬剤師さんです.
国家試験にも無事合格し, 4月から第一志望の薬局で働くことができて, 気分も季節通り晴れやかです.
新人研修を受けつつ, 店舗での基本業務もすぐに身についたあなたは, 他の新人薬剤師よりも一足早く服薬指導ができるようになりました.
すると, 初めて担当することになった, 60代の男性高血圧患者さんから, いきなり次のような質問を受けました.

「なぁなぁ, 葉酸のサプリメントを摂ると脳卒中とかが減ってがええんやって噂を聞いたんだけど, それって本当なのかな?」

(…わからない!)

すぐには返答できずに困ったあなた.
とりあえず次回までに調べておきますとその場をしのいだものの,
先輩薬剤師に聞いても納得できる返答が得られず, もやもやして焦りだけが募ります.

「そういえば, 学校の授業でEBMについての授業を受けた時に, PubMedを使って論文を調べるとよいって習ったよな…???」

学部時代に学んだことを思い出しながら, PubMedで自分で情報を得ようと悪戦苦闘するあなた.
すると, 運良く次の論文を見つけることができたので, 早速, 見よう見まねで読んでみることにしました.

[文献タイトルと出典]
Efficacy of Folic Acid Therapy in Primary Prevention of Stroke Among Adults With Hypertension in China: The CSPPT Randomized Clinical Trial.
Huo Y, et al.
JAMA. 2015 Mar 15. doi: 10.1001/jama.2015.2274.
Pubmed : http://www.ncbi.nlm.nih.gov/pubmed/25771069
PDF → 全文フリーで手に入りますが, あらかじめJAMAへの無料会員登録が必要になります.

[使用するワークシート]
ランダム化比較試験を10分で吟味するポイント:
http://2.bp.blogspot.com/-clIkBOVVGfk/UjW8olB-HiI/AAAAAAAAAIg/5UQ8DGNRZl0/s1600/RCT10%E5%88%86.png
@syuichiao先生のブログより)


桜咲く晴れやかな季節, 皆様いかがお過ごしでしょうか?

新しい年度を迎えても, こちらJJCLIPはいつもと変わらず,
けれども今まで以上に「手軽に, 楽しく, EBM実践のための学びの場を提供する」ことに
尽力したいと思っております.

さて, 本年度第一回目の抄読会はサプリメント!
「胡散臭い」としか思っていないそこのあなた(そして僕),
今一度, その”効果”なるものをしっかりと「定量化」できるようになってみませんか?

今回は新年度最初ということで, 初心に戻ってRCTの基本のキから改めて解説を交えつつ抄読会を進めてゆく予定です.
これまでにJJCLIPの配信を聴いたことのある方々,
是非とも, 「まだ聴いたことがない」「EBMを学んでみたいけれどどうすればいいのかわからない」と思っている, 周りの方々にお声をかけていただけないでしょうか?もっともっと, 仲間を増やしてゆきたいのです. 仲間を増やしてゆきましょう.

一人でも多くの薬剤師、登録販売者、薬学生、もしくは医療従事者その候補生の方々が、EBM実践のための学習の敷居を下げられるよう善処いたします.

いつものように, 放送中に頂くコメントへは随時お答えさせていただきます.
皆様にとって, 貴重で愉しい抄読会となれるよう鋭意努力いたします.

それでは, ネットの世界で皆様とお会いできることを心待ちにしております.

薬剤師のジャーナルクラブ(Japanese Journal Club for Clinical Pharmacists:JJCLIP)とは、薬剤師がEBMを実践するための学びの場を提供するSNSコミュニティです.現在は@89089314先生、@syuichiao先生、そしてわたくし@pharmasahiroの3名をコアメンバーとして運営しております.


Milkcocoaハッカソンに参加した話

龍一郎@技術担当です。Milkcocoaを使ってiOSアプリを開発しようと試みたのでレポート。

milkcocoaでアプリを作ろうと試みた経緯

昨年末から “アプリ作るって言ったけれどバックエンド作りたくない病” に罹患してまして。

Node.jsとか勉強すべきなのかなあとか考えていたんですが、それならBaaS使えばいいんじゃないかと。

で、たまたま見かけたMilkcocoaがイベントを開催していたので思わず参加しました。

http://mlkcca.connpass.com/event/12332/

端的に言って、BaaS使ってみたかったんですよね。

BaaSはまだ戦国時代だったのか、まとめ。(執筆中)

このイベントで仕入れた知識をiOSのアプリ開発に使えたらいいなあと思ってました。

参加して感じたこと

驚いた。

  1. Javascriptだこれー!?
  2. jThirdってなんか面白そうだなあ → Webアプリだこれー!?
  3. iOSのSDKって無いんですか → あります(未公開)

最近Firefox OSといいWeb系の技術ばっかりやっているような気がするので、一度腰を据えてやるべきかもしれない。

ハッカソンの目標設定

とはいえなにか作ろう、ってことでSDKの仕様聞いてみました。

これ何ができるんです?
SENDイベントが実装されてますよ
(あ、送るだけなのかー)

こんな感じの会話から、目標を次の2つに定めました。

  1. Webアプリから送信したメッセージをiOS側で受け取る
  2. UILocalNotificationを使って通知を出す

通知の実装って、クライアント側とサーバー側両方用意しなきゃいけない上に、サーバー側は正規の証明書を用意しなきゃいけなかったりして結構面倒なんですよね。

これができると、milkcocoaをiOSへの通知用サーバーとして使えるので、APNS通知用サーバーが不要になってすっごくいい感じ。

設計・実現方法検討

不可能っぽいことに挑むって決めてしまったので、ここで時間をつかいました。

1. Webアプリから送信したメッセージをiOS側で受け取る方法について

ここを30分くらい悩みましたが、Webアプリでならもうできてるわけです。

サンプルとして作成するアプリにチャットアプリがあるので、これでどう考えても送受信できてる。

http://chat.mlkcca-app.com/

っていうことは、iOSでWebアプリを実行できればOKです。

幸いにも、iOSにはUIWebViewがあるので、これにHTML+JavascriptをぶっこめばOKっぽい。

1+2. Webアプリから通知を出す方法について

必要なのは、「UIWebViewでJavascriptを実行して、iOSの端末固有の機能を使う方法」です。

正直、Apache Cordovaしか思いつかなかったのでこれを採用。

問題は開発環境も開発経験もないことくらい。

Cordovaの開発環境作成

というわけで突貫で開発環境作成。

Homebrewあればなんとかなると思っていたんですが、甘かった。

Install Cordova

基本的には公式に従います。ターミナルからnpmで実施。

$ sudo npm install -g cordova
$ npm update -g npm update -g npm

Create project

Helloworldという名前のプロジェクトをつくる。

$ cordova create hello com.example.hello "HelloWorld"
$ cd hello
$ cordova platform add ios
$ cordova prepare              # or "cordova build"

あとはFinderからプロジェクトファイルをいじればOK。

iOS Platform Guide

実行するとこんなのが立ち上がります。

ビルド&実行

ここからあまり詳しくないのでTwitterとかでホント教えてください。

色々編集したら、ターミナルからコマンドでビルド。

$ cordova build
$ cordova run ios

Xcodeだけで完結するいい方法があると信じてます。

CordovaからiOSに通知

ここで大ハマリして結局どうやるかわからなかったです。

理想

  1. ローカル通知用のプラグインCordova Local-Notification Pluginを追加!
  2. プロジェクトでビルド時にプラグインを利用するように 設定!
  3. 完了。

現実

動かせませんでした…。

勘違いポイント1. iOSのPush通知について

iOSのPush通知は、iOS Simulatorでは動作しません。

ちゃんと押さえておこう iOS の Push通知を利用する時の注意点

とはいえ、ローカル通知なら動作するはず!APNSサーバーと通信しないし!

でも動作しませんでした。あるぇ〜!?

勘違いポイント2. プラグインの追加方法

CordovaではiOS固有の機能を使うために、プラグインの導入が必要です。

って読みました。でも、これ結局導入方法がわからなかったです…。

色々なものに普段から手を出しておくべきでした。

出来上がったもの

結局、WebアプリからCordovaで動かしたWebアプリで、iOS固有の機能を使わずに通知だけさせるようなものを作りました。

左側のチャットで文字を入力すると、milkcocoa経由でメッセージが通知されます。

感想戦

誰かが大切だって言っていますし、振り返ります。

milkcocoaについて

触ってみて、良かったところもイマイチなところも両方ありました。

良かったところ

  1. DB設計なし
  2. サーバー側アプリの構築なし
  3. APIの設計なし

この状態でクライアントがいきなり作成できるのは本当に楽です。正直、感動しました。mBaaSすごい。

プロトタイプの作成時には活きてきそうです。

イマイチだったところ

まだβなのでとやかく言っても仕方ないのですが、安定性はまだまだこれからみたいです。

実際、エラーを何度か吐いてました。

でもきっちりエンジニアが回避策を提示するあたりさすがでした。

WebアプリからiOS固有の機能を使う方法

今回はCordova使おうとして見事にこけましたが、他にもいくつかあります。

その中でも特に有名なものは、これです!WKWebView

iOS8から標準で使えるやつですね!

あれ、素直にCordova使わないでいけば普通にできたんじゃ…。そのうちやってみます。

milkcocoaSDKでサーバーからの通知を受け取る方法

SENDイベントで通知できますよ
!?

ソースコード

Githubで公開しました。

Ryuichirou/testCordova

余計なファイル多いうえに、多分単体では実行できないですが…。

次回予告

  1. jThirdでチルノちゃん動かす
  2. WKWebKitを使って、milkcocoaを通知サーバーとして動かす(リベンジ)

そのうちやります。

reference

沢山参考にさせていただいたのでご紹介。

ほとんどの時間をドキュメント読む&探すのに費やしていたような気がします。

milkcocoa

cordova

cordova 公式

cordova local notification

milkcocoa + cordova

iOS

node-webkit

Sencha Touch + cordova

Javascript, HTML, CSS