kobblog@livedoor

酒とライブな日々(?)って感じの日記でしょうか。

www.flickr.com
kobakou's photos More of kobakou's photos

(2017/03月版) 思考のインプット/整理/アウトプット:Todoist/Togglの連携が気持ち良い

2015年末から約1年経って、ワークフローが少し進化しましたので、整理してみました。

どこが変わったのかというと、Todo/TimeTrackingの部分です。前のチャートだとTodoにはWunderlistを、TimeTrackingにSlimTimerを使っていました。

が、SlimTimerだとノートPCでしか操作できず例えばPCなしで仕事している際などに取り忘れたり、振り返りができなかったりとイマイチでしたので、まずはこれをTogglに置き換えました。Togglはスマホアプリもあるので、出先でのTrack Start/Stopができ、とりあえずタイマーをスタートしておいて後でカテゴリなどを調整するなどが簡単にできます。加えて、週ごとの集計などがPCの前でなくても確認できるので、便利になりました。UIもキレイで気持ち良く使えます。

Wunderlistの方は、実はほとんど使っていない状況で、たまに長期的なTodo、いつかやりたいことをここに入れておくだけで毎日使う感じではありませんでした。いわゆる日々のTodoは紙のノートに日毎に頭の中から書き出して作業する、ということをやっていたのです。

そんななか、Togglを紹介した方から、Todoistというツールを使ってGoogle Chrome用のPluginを入れると、Todoistでタスクを管理しつつ、TodoistのUI上からTogglのタイマーをStart/Stop, そして完了したらDONEできるというシームレスな運用ができると薦められて、始めてみました。UIが統合されるだけでなく、Togglで設定したProjectとTodoistのProject名を揃えておくと自動的にProjectの振り分けも可能になるなどまるでひとつのサービスなんじゃないかというほど、非常に気が利いています。これがなかなか良くて、手放せなくなりました!! 紹介ありがとう。やはり「ツール」的サービスは、毎日使う、それによってご利益がある、というカタチで習慣化できるかが重要ですね。

さらに、せっかくなので、TodoistのTask作成、Task完了のログを IFTTT を使ってGoogle Sheetに記録するようにしてみました。本当は1シートに記録したかったのですが、標準の連携モジュールでは作成時には「CreatedAt」、完了時には「CompletedAt」しかそれぞれ選べなかったので、作成シート・完了シートの2つのシートに記録するように設定しました。

{{TaskContent}} ||| {{Project}} ||| {{CreatedAt}} ||| {{Labels}} ||| {{Priority}} ||| {{LinkToTask}}

{{TaskContent}}|||{{Project}}|||{{CompletedAt}}|||{{Labels}}|||{{Priority}}|||{{LinkToTask}}

2つのシートに分かれても、TaskのURL/IDがあるので、集計の際にも問題になることはなさそうです。

Todoistの無料版だと、タスクの集計などができないのですが、GoogleSheetsに書き出して置くことでなんとかできると思います。Projectごとでタスクの作成、完了、期間など見てみたら楽しいかもなと妄想しております。GoogleSheets (GoogleDocs) も GoogleAppScriptを使っていろいろな自動化やツール化が可能のようなので、このあたりからハンズオンしてみたいなと思っております。

Todoistでもう一つ面白いのはゲーミフィケーション的な仕掛けが入っていることです。タスクを消化しているとポイント的なものが貯まるようになっており、ちょっとうれしいです笑 こんな blog のネタもTodoにあげておいてやっつけることで多少励みになるのです。

今年も参加してきました #jawsdays 2017 @ 五反田TOCメッセ

昨年に引き続き 、今年も参加してきました JAWS DAYS 2017。今年はなんと、半ば地元の 五反田、TOCメッセでの開催!とても行きやすい会場で最高でした。丸1日参加したわけですが、私が見たセッションと感想を。自分が見たのは結果的にトークセッションが多かったかも。他のセッションはスライドまとめ記事 から復習させて頂きます!

1) エンタープライズ企業におけるAWS公式採用への挑戦〜レガシーを微笑みにかえて〜

スライド: https://speakerdeck.com/mamohacy/entapuraizuqi-ye-niokeruawszheng-shi-cai-yong-hefalsetiao-zhan-regasiwowei-xiao-minikaete

KDDIでAWSを推進されている大橋さんのお話。大きな企業の中でどうやってAWSを推進していったかという振り返りは、AWS導入だけでなく、すべてのお仕事に仕事に通じる話だなと思いました。過去の仕組みやルールをただ無視するのではなく、そのルールの意味を尊重し、分析・把握することで、信頼関係をまず築き、その上で新しいルールを構築することが大切、という学びは、このセッションの後ちょっとだけ覗いたセッション「自分と組織を「クラウド対応」にするための実践的な方法を考える」の中でも語られていたところにも通じる話でした。

さらに、技術的な点については具体的に実践された点含め、ガバナンス視点で何をやって何をやらなかったか、また、実際にかかった時間などが共有され、とても実践的な内容でした。導入後の社内マーケティングについても、社内の隠れイノベータを活用する、外から動かす、というのは、とても納得感があるのと同時に、それを自身で実際にやられてきた説得力・迫力を感じるセッションでした。

2) AWS SECURITY DEATH \m/ 〜セキュ鮫様からのお告げ〜 by Security-JAWS

スライド: https://speakerdeck.com/tmorinaga/jaws-days-2017-security-jawsfa-biao-zi-liao

セキュリティ周りの最近をUpdateしたくて参加。AWS Configは実はあまり知らなかったのでそこはとても参考になりました。普通にAWSで運用していたら設定しない手はないなと。

Lunch

お弁当を頂きながらのランチセッション。 MackerelでサーバーじゃなくてIoTデバイスを見える化するという事例は、ハンズオン的に、楽しそうかな〜っと。数デバイス(サーバー)は無料で使えるそうですよっ!

3) [AWS UG Singapore] Chat bots with Amazon Lex

スライド: なし

英語セッションでした。ChatUIには興味があったので、参加しました。Amazon Lex というサービスをこのセッションで知りました。Chat的UIについてはテキストや音声によるInputをどのようにハンドルするか課題になるわけですが、実行する機能と受け取るパラメータを'Intent'として定義して、その'Intent'を、どんな入力(質問文等)で呼び出すかという「例」を 'Utterance(発話、発言という意味らしい)' として登録しておくことで、いい感じに紐付けてくれるという夢のイベントハンドラーがAmazon Lex。Utteranceには、'What's your name?', 'Who are you?'とかいう感じで想定される質問を「たくさん」いれておくと機械学習のアプローチも含めてよろしくやってくれるらしい。さらに会話(セッション)を通して、変数を保持することができる仕組みも入っているらしい。まだ、そんなにうまくは行かないんだろうな、と思いつつも、誰もが、一番苦労するであろう「ビジネスとは関係のない部分」を、まとめて解決しますよというAmazonらしいアプローチに大期待。

4) 金融クラウド&FINTECH最前線。〜AWSで金融からイノベーション! 2017

スライド: なし

別の場でも拝見したことがあった渥美さんのセッション。日本の金融業界もすごい勢いで進んでいますよ、というご報告。日本においてもいわゆる「Fintech」に関連する業者を、「電子決済等代行業者」と位置づけて整理していくという動きなんだそうで、決して欧米に対して遅くれておらずしっかりキャッチアップしているというお話でした。確かに「代行業」と捉えるとなるほど理解がし易いですね。代行業を行うにあたっての「認可」のハードル等は気になるところはありますが。投資などを代行してくれる、ウェルスナビ なんかにも、興味が湧いてきました〜

5) 武闘派CIO3人が、ホンネで語るITの現実

スライド: なし

AmazonGo見てきました、という紹介があり、面白かったです。そこで感じたところは こちらの記事 にまとめてみました。なかなか古い会社を変えるには? 新規事業提案するにはどうしたら? というような会場からの質問に、結局は「プロト作ってみました。実はお客さんもいるんです」から始めないと始まらないよ、仕込みが重要です。という言葉は重たかったですーいろいろなことを、実際にモノ作って試せる時代になっているからこそ、改めてプロトタイピング起点、初期顧客起点、のビジネス提案が必要なんだなぁ。もっとちゃちゃっと作れれて、ユーザー含めて試せる技能、を身につけないとなぁ。

6) The AWS Japan Mafia トークセッション 2017

スライド: https://www.slideshare.net/YoshidaShingo/jaws-days-2017-mafia-talk

AWS Japan Mafiaとは、

スタートアップ向けのメディアをやっているbridgeさんがMobingiのシードラウンドの調達の記事の際に、AWS(やそのパートナー)を卒業して新しいチャレンジをする人たちを指して呼称したもの

http://yoshidashingo.hatenablog.com/entry/2016/03/14/103921

だそうで、、そういう意味はわからず本セッションを見たのですが、みなさんいろいろキャラがあって面白かったです。いくつもの会社の文化やチームを経験している皆さんだけに、自分のアウトプットを最大化するために「誰とやるか」をとても重視しているのだなと感じました。

そんなこんなで、丸一日のほんとに充実したイベントでした〜

トーハクxアイデアソンで、UXデザインの際の視点の大切さを再認識

東京国立博物館が主催する「訪日外国人客の記憶に残る日本文化体験とは?〜ICTは博物館で何ができるのか?〜」というアイデアソン、「トーハクxアイデアソン」の成果発表会を見て来ました。

なかなかチャレンジングなアイデアソンだったようで、応募者は土曜日の朝に集合、初対面の参加者とオリエン含めて1日缶詰でアイデアを練り上げ、日曜日の昼から発表というものでした。チームは6人ずつ5チームで、計30名が参加したようでした。仕事でもこういった「アイデアを発想して、まとめて、提案」みたいな場がありますが、やはり集中力って重要なんだろうなと感じました。短期間かつメンバーも初対面というなかで、すばらしい発表だったと思います。きっと、チームメンバーもそれぞれの思いや提案を持って集まったなか、この短期間で1つのアイデアに集約して、それを資料にして、発表して、、と、、たいへんなチーム作業だったと想像しました。

発表会には、ファシリテータのさとなおさん、審査員として、サシャさん、橋本麻里さん、東大 暦本さん、副館長 松本さんが登場しました。橋本さんは、私は初めて拝見したのですが、日本美術のライターさんだそうですが、非常に聡明そうな話し方でとても印象的でした。

そんな提案の中で最優秀を取ったアイデアは、やはり他の4つとはひと味違った、すばらしいアイデアでした。どこが素晴らしかったのかというと、、

  • 観光客は、展示物を通じて「日本の文化、生活や背景・歴史を知りたい」
  • でも旅行中は「時間がなく」さらに、いくら情報があっても短い時間では「情報過多で疲れてしまう」
  • 結果として、本来見たかった、そしてトーハクが見せたかった「展示物」を見た気がしない というトレードオフが課題と分析していた
  • その中で、訪日外国人観光客の、博物館での体験を、「前、中、後」と分解して分析できている。その結果、「中(博物館で作品を見るタイミング)」では、トーハクならではの「実物を見る」という体験に集中させ、「後」の体験を改善することでトータルの体験を良くしている提案だった
  • 更に「中」での体験でも、展示物を見ているタイミングに加え、「休憩中」というどちらかというと「後」のタイミングもあぶり出して、「休憩中」に提供できる体験も提案していた

発表会の提案をネタに(といっては失礼ですが)、その後のファシリテータ、審査員、会場からの質問を含めた議論はさらに面白かったです。

最優秀の提案は、特に自分の旅行体験にもしっくり来たので非常に「刺さった」のですが、他にもサシャさんからは、子ども連れの方が博物館・美術館に鑑賞できない、という課題がでたりと、ひとえに訪日外国人観光客、といっても、どこの国の人なのか、どういった状況の人なのか、でさまざまな課題があるんだなぁと再認識させられました。次点となった提案での発表では、そういった「ペルソナ」を明確に定義しているすばらしい発表もありました。

5つのうち、4つの発表が「VR/AR」的なものに偏ってしまったのはちょっと残念でした。確かに外国人なのでもっと視覚的にサポートできないか、という発想はすばらしいとは思いますが、今回のアイデアソンでは似通ったりに見えてしまって損してしまったと思います。そんな中で暦本さんからは、まだまだ「オーディオガイド」にもやるべきことがあるんじゃないか。一方的に説明を流すのではなく、位置情報・視点・AI等を活用することで、その場で本当に興味をもった作品に的確に、最小限に情報を提供する「バーチャル学芸員」などできないか、といった提案もありました。欲しい!

また、アイデアソン参加者からは、で「トーハクはどーしたいの?ICTとか本当に使いたいの?」といった本質的な質問もでて来ました。トーハクのビジョンやミッションとICTというhowがマッチしているのかという違和感だったと思います。そこに対して副館長松本さんからは、「実はそこに悩んでいて、今回のアイデアソンにも繋がった」というような本音をいただけ、企業や組織として、こういったオープンな議論の大切さ、期待しているところに対しても、興味深かったです。

ちなみに、東京国立博物館は「トーハク」っていうんですね。私は、トーハクの常設展示はまだ見たことがなかったのですが、このイベントをきっかけに、見に来たいと思いました。


AmazonGoは「接客」の価値を徹底的に排したモデル

昨日、JAWS DAYS 2017に参加してきたのですが、そこで、AmazonGoを見てきた人の話を聞いたので思ったことを整理してみます。

AmazonGoでの買い物の流れは以下だそうです

  • スマホに専用アプリを入れて会員登録・支払い情報の必要
  • 入店時にアプリが発行する2次元バーコードをゲートに提示して、自分とアプリを紐付ける
  • 後はお客自身が自由に商品をピックアップして持ち帰るだけ
  • 商品の補充は店員がやるが、その店員は接客はやらない
  • なお、店内の天井には、黒いセンサー類が入っていると思われるボックスが1mおきくらいで設置されているらしい

AmazonGoの価値は「万引きによるロスをゼロ」にすること。そのために「接客コストをゼロ」にする

  • その他のセルフレジシステムでも、ショッピングカゴと持ち帰りバックの重さを計測したり、レジまわりをサポートのための人員を配置するなどしてコストを掛けているが、そこをAmazonGoとしてはすべて「店員レス」に降って、センサーやアプリに投資をしている
  • 店舗での接客を無くすために、Refund(返品・返金)といった機能もアプリに実装されており、品物はお客様の責任で廃棄してもらうことにしている
  • 徹底的なお客との信頼モデルで成り立っているが、接客(=人手)を廃し、すべてをデータ化することによって、信頼関係をデータで保証している。逆にいえば信頼関係が崩れた客は利用ができなくなる

今どうしても必要と思われている、もしくは価値があると思われていることを完全に廃したとき、どういうビジネスモデルが描けるか、という、発想の転換の練習になりそうです。

iCloudを使ったMacとiPhoneのWi-Fi設定同期は便利なんだけど、、

同じAppleIDでMacとiPhoneを使っていると、 (iCloud Key Chainで?) Wi-Fiの設定等が同期されて、同じWi-Fiにつなぐのにいちいち設定をやり直す必要がなくて便利なのですが、ちょっと困ったことが。

例えば、私はauに契約しているのですが、iPhoneだけでau_Wi-Fiが使えるのですが、その設定がMacにも同期されてしまい、Macもau_Wi-Fiにつなごうとしてしまうのです。その逆なAccess Pointもあったりします。

wifisetting

このあたりってどうなっているんだろう。期待動作としては一度勝手に同期するのだが、同期がいやなAPは削除すれば、その端末からだけは設定が削除される、というのが期待なのですが。MacからAPの設定を削除した時のメッセージを見た感じ、完全に同期されるように見えます。

wifisetting2

GoogleSpreadSheetとGASの組み合わせは、UIとデータベースを備えた簡易ウェブサービスだったと実感

日時ベースでリソース管理をする必要がありました。具体的には、作業用の共有PCがあるのですが、それを利用する人がPCの台数よりも多いため、多すぎる場合は日程を調整しなければいけなかったのです。各自使いたい時間帯を宣言して、同じ時間帯でリソースが不足していたら別途調整する、ということをしていたのですがなかなか足りているか数えるのがメンドウでして、、、何かカレンダー的なものとかで管理できないかなと探してみたのですが、結局 GoogleDocs の SpreadSheet を共有して、それで管理することにしました。一番柔軟でニーズに対して簡単に対応できそうだったからです。

さらに良かったのがGAS(Google App Script)でした。GoogleDocs上のドキュメントには、GASというScriptを使って動作を自動化することができます。例えば、変更があったらグラフをRefreshするとか、通知を送るとかです。スケジュールを指定して、定期的に実行して結果をSpreadSheetに書き込むなんてこともできます。

例えば、これは変更時、領域に応じて変更日時をセルに書き込むというもの。このスクリプトを データが更新されたら、実行、といった感じで設定できます。

結局、私がやったのは、SpreadSheetでいわゆる予定表的な表を作り、各自が予定をUpdateして、結果、リソースが足りなくなっていたら、Slackにその旨Postしてお知らせする、ということです。SpreadSheetが入力・閲覧用のUIになっている、ということも面白いなと思いました。今回は使っていないですが、API(Post等)でデータを送信して、SpreadSheetにその内容を記録したり、取得したりすることも簡単に可能なようです。(Slackから Slack cmdを使ってSheetの情報を取得なんてこともうれしいかも)

Google Sheets

つまり、GoogleDoscは、WebAPIのInterfaceを持てるDatabaseであり、さらにFrontendのUIを兼ね備えた、ウェブサービスのSaaSだったのです。これだけ気軽に使えるといろいろな場面でちょっとした共有データを使った作業をhackできそうです。

改めてGoogleDocsとGASを使ってちょっと感動いたしました。

訪問者数

    Archives
    Categories
    記事検索
    Recent Comments
    Recent Trackbacks
    twitter
    • ライブドアブログ