このエントリは、家庭を支える技術 Advent Calendar 2014 の7日目です。

前日は @tomoko_and さんによる 我が家を支える技術とサービス #家庭を支える技術 Advent Calendar 2014 でした。

このエントリでは、我が家におけるタスク管理の変遷と、現在の運用についてお話します。

要約

最近まで リマインダー.app を使っていました。べんりでした。欲が出てきて今は Trello を使っています。色々工夫しながらやっています。なかなかいい感じです。

家族構成

夫(エンジニア; このエントリの著者)、妻(非エンジニア)、子(0歳)

リマインダー.app べんり〜時代

2012-2014年。夫婦二人とも Mac と iPhone のユーザであったことから、Mac と iOS のリマインダー.appでリストを共有していました。「蕎麦」「カレールー」「マスタードシード」のような買い物のメモや、「ダンボールを捨てる」「部屋を片付ける」「クリーニングを回収する」というというようなタスクもリストに入れてありました。

セットアップのコストが低く、シンプルで、 Mac でも iPhone でも使え、同期も迅速。大変重宝していました。

リマインダーを共有するのはライフチェンジングでした。

単にタスクが共有されるだけでなく、「これから買い物に行くから、何か欲しいものあったらリマインダーに入れておいて」みたいなこともできます。リマインダーはコミュニケーションツールと言ってもよいでしょう。

二人で一緒に買い物に出かけたときも、どちらかが iPhone を見ながらチェックしていけばよいので便利です。

また、「ハンバーグをこねている間に小麦粉が切れた」みたいな場合、一段落して手を綺麗にした頃には忘れてしまったりしますが、「小麦粉切れたからリマインダーに入れてー」みたいな感じでお願いして入力してもらうこともできます。まあ、これは Siri さんがもう少し進化すれば一人でも問題ないかもしれません。

欲がでてきた

それでも、リマインダー.appでは扱いづらいケースが出てきました。 生活をしていると、牛乳を買うよりもやや複雑なタスクに直面することがあると思います。

たとえば「インクジェットプリンターを買う」みたいなの。機種とか色とかを相談することからはじめる必要があります。どの機種だとお値段がいくら位で、どこで買うといいか、とか。

あるいは「メタルラック(大型ゴミ)を捨てる」というもの。私たちの住む地域では大型ゴミを捨てるとき、

  1. 9:00-16:30 の間に「大型ごみ収集センター」に電話して住所氏名と収集希望日を伝え、受付番号と料金を教えてもらう (そしてそれをどこかにメモする)
  2. コンビニなどで料金分の手数料シールを買う
  3. 束ねたり、ガラスは飛散防止の対策をする。手数料シールに受付番号を書いて貼り付けておく
  4. 当日朝8:30までに玄関前に出す

というような手順が必要です。これをリマインダー.appだけで管理するのはちょっと大変です。「メタルラックを捨てたい」という目的に対して、色々なタスクを作らなければならないのです。受付番号とか何円の手数料シールを何枚買うかというのもメモしておきたいですね(じゃないと忘れちゃう!)。

たぶん、もっと複雑なものもありますよね。役所に何とか届けを提出するとか。

こうなってくると、リマインダー.appだけでやり過ごすのは難しくなってきます。タスク管理にチャットというか、掲示板のようなものがくっついていてほしい、という気分になってきます。

では、何を使うとよいのでしょう。

GitHub Issues は欲しいものに近い、でもちょっと違う

GitHub Issues はイメージにかなり近いのですが、「牛乳」「にら」「にんにく」「チーズ」「豆腐」のように沢山出てくる細かいモノも「メタルラックを捨てる」と同じような粒度で同時に (軽量に) 管理したいと思うと不便なところがあります。

ほしいもの一つに対して一つずつissueをつくっていくのは、さすがにやり過ぎな気がします。見通しが悪そうです。

GitHub Issues でも issue にチェックリストをつけることができます。でも、これはちょっとニュアンスが違っています。

メタルラックのケースには、このチェックリストがよくあいます。これは、「メタルラックを捨てる」が個々のサブタスクを全て完了してはじめて完了となるタスクだからです。

「豆腐」と「チーズ」と「にら」と...が欲しいケースを考えます。チェックリストに収めようとすると、「買い物にいく」みたいな issue を作ることになるでしょうか。そこに「にら」「チーズ」「豆腐」を並べたとします。まあここまではよさそう。

ここで「お気に入りの豆腐が売り切れていたので買わなかった」場合を想像してください(大変残念ですが、実際に時々ある)。どうするのがよいでしょうか。「今夜は絶対に豆腐を食べないといけない」という日でなければ、その日の買い物は完了したと言ってもよい気がします。豆腐はまたの機会に買えばいいのです。でも、issueをそのままクローズすると、今度豆腐を買うのも忘れてしまいそうです。という具合に、このようなケースは GitHub Issues のチェックリストが想定している使い方とはちょっと違うように感じます。

タスク管理のご近所さん

ちなみに、タスク管理のまわりでは、オンラインではこんなツールを使っています:

次期タスク管理システムを探す旅

リマインダー.appからの乗り換えを模索するため、いくつかの候補を見てみました。

意識していた「要件」はこんな感じです。大事そうな順に並べると:

という感じです。

少しずつ触ってみたところ、以下のような感触でした:

Basecamp

https://basecamp.com/

https://signalvnoise.com/posts/3546-how-we-the-kims-use-basecamp-at-home を見て、とても良さそうだなと思いました。そこで、一人で実際にデータを入れて並行稼動してみていました。

カレンダーと連携していたり、コメント機能もちゃんとあって、グループウェアとしてはよくできているものの、iPhone での使い勝手があまり馴染みませんでした。それに、カレンダーはカレンダー.appで共有していて、それで足りてたので、別についてこなくてもよかったのでした。

Remember The Milk

https://www.rememberthemilk.com/

自分は以前使っていたけれど、当時の印象では、どちらかというとリマインダー.appに近い印象で、タスクの上で会話できそうな感じではありませんでした。

asana

https://asana.com/

ぱっと見のUIが複雑そうで、家のタスク管理にはちょっとオーバースペックな感じがしました。

GitHub Issues

https://github.com/

iPhone からの使い勝手があまりよくありませんでした。細かいタスクを入れると、使い勝手が悪そうでした。家のタスク管理にはオーバースペックな感じもしました (使わない機能が多そう)。

Trello

https://trello.com/

要件を満たしており、使いやすい雰囲気でした。iPhone での操作性にはやや難がありましたが、まあなんとか許容出来る範囲でした。リストを沢山つくれるのがべんりでした。

現在のようす

というわけで Trello を中心にしています。実際に使いはじめるまでは気づいていなかったのですが、リストをどんどん作れてカンバン的に使えるのが思いのほかべんりでした。「やっている」状態とかを表現できるのもよい。

我が家の使い方

ボードは基本的に Housework という一つだけで、その中は現在こんな感じになっています:

リストは以下のような意味をもっています:

二つの「買い物」リスト

当初は「買い物」リスト一つだけを使っていました。しかし、このリストが長くなってしまい、日用品の買出しの際に見づらいという問題が出てきました (近所のスーパーで買い物をしているときに「インクジェットプリンターを買う」とかはどうでもいい)。そこで、「買い物(食品/日用品)」の専用レーンを別途つくりました。

ちなみに、「買い物(日用品レーン)」のすぐ横に「やった」レーンがあります。隣り合わせにしておくと、買い物中に iPhone で「やった」に移行するのが楽だったということで、この配置になりました(自分は気付いてなくて一度もとの場所に戻してしまった...)。

「掃除」リストの新運用

「掃除」リストは、気になるポイントを追加しておき、掃除したら「やった」に移すというものです。スクリーンショットもその運用時のものです。しかし、リストはなかなか空にならず、なんだかスッキリしないという問題点がありました。

考えてみれば、有限の広さの家に住んでいる私たちですから、掃除すべき箇所にも限りがあるはずです。しかも、一度掃除する必要があった場所は、時間が経てばまた掃除する必要があるはずです。

そこで、「掃除」リストのカードは、掃除をしても「やった」には移さず、リストの下の方に移動する、というのを試してみることにしました。まだはじめたばかりですが、どんな感じになるでしょうね。たのしみです。

「食べる」カンバン

かつては「食べる」というリストがありましたが、近頃、冷蔵庫に付箋を貼る方式に代替されていて、使わなくなったので消してしまいました。

Trello の「買い物」リストからカード移すだけでいいし便利じゃん、と思って使っていた時期もありました。しかし、クックパッドの産地直送便を利用しているので、そこから届く野菜が漏れたり、実家から(なぜか)茹でたさつまいもやらとうもろこしを貰ったり、「買い物」リスト以外からの流入もそこそこあるということがわかってきました。

ということで、結局は冷蔵庫に付箋を貼ることになりました。生ものとか、早く食べたほうがいいものを冷蔵庫に収めたら(もしくは冷蔵庫の中で賞味期限が近いものを見つけたら)付箋に書いて扉に貼ります。「食べる」カンバンです。献立を考えるときは冷蔵庫の前で仁王立ちです。

ライフイベントのための臨時ボード

Trello 運用中に我が家は引っ越しをしました。引っ越し関連のタスクはそれだけで沢山あるので、一時的に専用のボードを作ってそこで管理していました。特に、引っ越しの直前〜直後には、日ごとに確実にこなしていかないといけないことが出てくるため、リストも日ごとに分けて運用していました。

引っ越しが終わり、諸々が収束すると臨時ボードからカードが減ってきます。そこで、残っていたタスクをリストごと普段の Housework ボードに移動し、臨時ボードを Close しました。

Trello と Slack の連携

Trello の更新は全て家庭用 Slack に流れるようにしていて、その通知を iPhone で受け取るように設定してあります。なので、タスクの状態が変わるとすぐに分かります。お互いに別々の場所にいるときでも、メッセンジャーなどで特に連絡をとらなくても、相手が買い物をしてくれていることがわかります。これで二人で別々に牛乳を買ったりしないはず。

付録: うちのボット

Slack 上では uchinobot (うちのボット) という bot が稼働していて、夜になると翌日出すべきゴミの種類を教えてくれたり、生活圏の PM 2.5 濃度が閾値を超えたらアラートを出したりしてくれたりします。 こどもに週一回で飲ませなければならないシロップがあったので、それをお知らせしてくれたりしました (もう飲ませなくていいので止めました)。

また、「すやり」と発言すると hue の電灯を寝るモードにしてくれる機能もあります。ただ、引っ越し後は調光調色なLEDシーリングライト中心の生活になったので、使われていません (hueは廊下のダウンライトに装填されていて、タイマーで時刻にあわせて3段階に調光しています)。居室のシーリングライトは全て赤外線リモコン対応なので、 IRKit を使って統合したいところです (一部実用化済)。

むすび

だいたい、こんな感じです。我が家を支えているタスク管理のお話をしました。

ちなみに我が家ではそんなに頻繁には牛乳を買いません。

次は新婚 @june29 さんが書きます。した: #家庭を支える技術

#wedding-s は、 kei さんと yuca さんの結婚パーティのこと。2013年10月19日に六本木農園で開催された。コードネームは october19

今回、幹事チームのひとりとして、パーティの開催をお手伝いさせてもらいました。 パーティについては 他のメンバーのエントリ をみてもらうのがよさそう!

チームのはなし

まず kei さん、 yuca さん。何よりお二人がこれまで過ごしてきた日々のおかげでステキな場だったのだと思うし、それをすっと包む素晴らしい会場を手配してくれて、それから多分とても忙しい時期だったと思うけれどいつも質問とか確認に光の速さで対応してくれてありがとう!

そして幹事チーム。 @hmsk は言い出しっぺ係から会場とのやり取りに始まり wedding-s-messenger を開発して白手袋で iPod shuffle に焼きこんで渡すところまで、 @june29 はチームづくりからプロジェクトの進行と調整、そして司会業をまるっと、 @mamipeko さんは wedding-s-messenger のステキなガイド音声と、デザイン (紙を選びから印刷まで!) に受付をまるっと、 @tomoko_and さんも受付の段取りを中心に随所で細やかな気遣いをしてくださり。 他にもみんなで色々。

各自の役割と得意なところを押さえながら、全体としてもちゃんと進んでいくような、心強いチームでした。

自分は、というと「issue おじさん」などと呼ばれつつ、プロジェクトの GitHub issues を整理してました。当日に向けてサブスクリーンを用意したり、諸々の機材の手配して、あとは LT を。

LT のはなし

「LT のある結婚パーティ」とのことだったので、新郎新婦のお二人に「新婦の基調講演LT、新郎の結びのLT、公募LTと、新郎新婦それぞれひとりずつ招待LTでどうでしょう」みたいな提案をしていたところ、新郎に自分をそのひとりに選んでもらってしまって大変光栄ながら自演乙...という感じになりつつ、これはビシっとしないと〜と緊張感を高めておりました。

余白が狭すぎるはなし

結局、 JDK CHRONICLE のタイトルで、 @june29@darashi@kei_s の 3 人 (JDK) を中心に、仲間を巻き込みながらこれまでワーワーやってきた軌跡を、作品群を通して紹介する、という話をすることにしました。

「keiさんのいい話」とか「一緒につくった人とのエピソード」とか「なんでこの作品なの」とか「どういう想いでつくったの」とか「この作品があったからこの作品ができた」というような驚くべき話が沢山あったのだけれど、それを語るにはライトニングトークは短すぎる。ということで、出来上がった作品の話を中心に展開することにしました (裏側の "いい話" は発表資料を眺めて想像してもらったり、どこかでのんびりだらだらとお話できるといいなあ)。

驚き最大の方策

というわけで、JDK の歴史から始めて、今回幹事チームが用意した作品たちの話につなぎ、wedding-s-messenger で皆様からお預かりしたメッセージをサプライズでプレゼントする、という流れにすると綺麗なのでは、ということになりました。そこで、パーティの進行のほうも、自分のLTを新郎結びLTの直前にしてもらい、その場でプレゼントするという運びとなりました。

自分のLTでは新郎にドラを叩いてもらう段取りになっていたので、5分ぴったりでサプライズの直前(チラ見せ)まで来てドラ、そのあとプレゼントとなるようにしたいと思い、発表者メモに数ページ毎に予定通過時間をメモし、ひたすら練習して挑みました (でもちょっと時間が余っちゃった)。

楽しんでもらえてたらうれしいです。

御礼とご報告

ということで、寄せられたメッセージを iPod shuffle に焼きこみ、無事お二人にお届けできました。ご協力いただいたみなさん、ありがとうございました!

お芋おいしいです

自分は発表前はとても緊張するほうで、正直なところ緊張のあまりパーティのお料理を味わう心の余裕がなかったのですが、それでもお芋が美味かったのが特に記憶に残っているので、あのお芋は相当に美味しかったとおもいます。

おめでとう、ありがとう

おめでとうございます。お二人には夫婦ともども仲良くしてもらえて、とても、うれしいです。

そして、今回、心おきなく技術で遊びながら、ものづくりをしながら、みんなでお二人をお祝いできる機会をいただけたことに、心から感謝します。ありがとう!

どうかお幸せに!

関連エントリ

2013年の2月に一週間ほどシンガポールに行ってきたのでした。 写真は flickr に。 これから RedDotRubyConf などで訪れる方も多そうなので旅の tips 的なものを残しておきます。思い出話は直接きいてね。

無限インターネット関係

イモトのWiFI

イモトのWiFiでお馴染み(?)グローバルデータのMiFiを持って行った。色々使いづらい点もあったけれど、値段分の価値はあった。

WiFiスポット

電源

予約とか

あんまり良さげなパックを見つけられなかったので、宿と飛行機を別にとった。

お金とか

タクシーとか

ガイドブック

EZ-Link カード

食べ物とか

活動時に携行するとよいもの

はじめに

ソ〜シャルコ〜ディング全盛の現代において、地獄のミサワの女に惚れさす名言集 からシチュエーションに応じて適切な画像を素早く貼り付けることのできるエンジニアは常に一目置かれる存在です。

horesa.se は「貼りたい」と思った瞬間から貼り付けが完了するまでの時間を最小化することで、あなたの惚れさせソーシャルコーディングライフを強力にサポートします。

まずは触ってみてください: horesa.se

チーム

今回は

の布陣でつくりました。 PS3 で大森、蒲田、札幌を結んで、相変わらずの楽しい開発でした。

恒例の記念撮影:

裏側の話

ソースコードが darashi/horesa.se にありますので、ご覧ください。

フロントエンド

Ember.js

Ember.js を使いました。

レイテンシを抑えるため、最初にデータをまとめて読み込んでクライアント側だけで検索する実装にしました。

horesa.seEmber.js で書かれた小さく、かつ実用的な(toy example ではない)サービスなので、動くサンプルとしてもお楽しみいただけるかもしれません (パッチお待ちしています)。

Ember.js それ自体はとてもおもしろいフレームワークで、わかってくると楽しく触れるのですが、外界との接続、たとえば Social widgets との相性がよくなかったり、jQuery の animation との相性がよくなかったり、ZeroClipboard との連携が...などなど、色々と苦労はありました。

GitHub Pages

サーバサイドに動的な処理が不要なように作ったので、データ及びコードはすべて GitHub Pages に置いています。

ZeroClipboard

クリップボードにコピーする部分に ZeroClipboard を使ったのですが、色々と制約が多く、かなり苦労しました。ただ、これは ZeroClipboard のせいというより、そもそも Adobe Flash movie を使ってクリップボードにコピーさせるということ自体が素直ではないということに依りそうです。技術的な制約の下 ZeroClipboard はよくできていると思います。

バックエンド

惚れさせ男子データベース

データには 惚れさせ男子データベース を使っています (じつは horesa.se のバックエンドとして使うために開始されたプロジェクト)。

ソ〜シャルの力で本文データも拡充されつつあり、2012-10-07 21:30 現在では、全体の 32.3% の本文が入力されています。

データの更新

Rake タスク で fetch してきて、前処理をして、 horesa.se のリポジトリに入れることでデータを更新します。

歴史

背後にこんな流れを感じました。

バタフライ・エフェクトっぽくてとてもいい。ソ〜シャル!

まとめ

惚れさせソ〜シャルコ〜ディングを強力に支援する horesa.se を作りました。 Ember.js を使い、 GitHub Pages に deploy しています。

超高速な惚れさせ貼り付け体験を提供します。

惚れさせ男子データベース を使っています。データの拡充にご協力ください。ソ〜シャル。

プロダクトの背後に歴史あり。

お楽しみください。

(カチャカチャカチャ…) (ッターン!)

札幌Ruby会議2012 の会期が終わりました。

Kaigi に関わるすべてのみなさんに深く感謝します。

ありがとう。ありがとう。

Kaigi は始まり、そして終わる

今回色々とつらいことが多すぎて、始まる直前まで正直 Kaigi はもう懲り懲りだと思っていました。

それでも、参加者がぞろぞろやってくると自然と Kaigi は始まるし、みんな楽しそうにしてるし、相変わらずよいものですねえ。

そして、終わる。ちゃんと、終わる。

膝に矢を受けてしまってな

そういう空気にやられて、またやっちゃうのかもしれません。でも少し冷静になったほうがいい。

「かー実行委員つれーわー、全然発表みられなくてつれーわー」というのも情けない話なのですが、穏やかな気持ちできちんと見られた発表が殆どなくて、よくなかった。 お話してみたいと思っていた人にも自分から声をかけられなくて。 当日スタッフのみなさんともあまりお話できなかった。 余裕が、なかったです。 折角の機会だったのに。 もっと RubyKaigi を楽しめたらよかった。

「こうなってほしい」と思っていることを、自分がきちんと実践できないのはよくない。

最後の最後にまた撤収も上手にできなくて、すっかりしょぼくれて打ち上げに向かいました。

あれから5年経った

でも。そこで、ちょっと、なんか、もう、そういうことがまるっとどうでも良くなるような出来事があったのでした。

当日スタッフとして参加していた @tanaka51 が、自分が 日本Ruby会議2007 で初めて当日スタッフとして参加したときに感じたようなことを、話してくれました。

当日スタッフとして参加できて、とても良かった。でもそれまでに実行委員が準備してきたから、自分がそういう体験をできたんだと思う、というような感じのこと。 勝手に自分の言葉として聞いてしまったので違っているかもしれないけれど・・・。と、いうのも・・・

僕が、日本Ruby会議2007の翌日、思い出深い秋葉原のアイカフェで書いたエントリ We are nice. - RubyKaigi2007 に当時の自分の言葉が残されています(なんと瑞々しい!)。

RubyKaigi2007 on Rails。実行委員の皆さんはもっとずっと前から着々と準備を進めてきていて、自分はそのレールの上で動かせてもらえたのだと思っています。この日に至るまでに自分には見えていなかった沢山の大変なことがあって、それを一つずつ解決してきていたのだろうなと。だからこそ美味しいところを味わわせてもらえたのだろうなと。本当に有り難いことです。そして、もし可能ならば何かそういう部分でも力になっていければと思いました。

5年かかりましたが、ちゃんと、一周できたみたいです。よかった。

改めて読むと、こんなことも書いてある。

東京はとっても刺激的。大好きな札幌でもこんな幸せな体験ができる日が来るといいなぁ。なんて思ったりもして。

ちゃんとできてたみたい。しかも札幌で。

救われたなあと思いました。

今回自分に至らない点が多くて、色々迷惑をかけてしまいました。

たくさん助けてもらいました。

ありがとう。ありがとう。

膝に矢を受けた感はあるので、もし次があるのなら、そして許されるなら、「矢面」から一歩後ろに下がって、またやりなおすのがいいかもなあと思いました。たとえば Things を Done にする人として。

宿題のはなし

今回、発表をしました。これは実は 日本Ruby会議2011 の打ち上げでもらった宿題でした。

中華を食べながら(美味しかった!) @takai さんと @adzuki34 さんにもらった宿題。 「@darashi が発表してるのをみたい」って言ってくれたのでした。

「自分に心から話したいことができたらその時にやります、それができるように日々を過ごしたい」というようなことを答えた気がします。だいぶ酔っ払ってたけど。

その後 LT とか短めの発表をする機会は何度かあったけど、30分の枠で話したのはそれ以来はじめてのこと。 だから、今回は自分にとって特別な機会でした。

「よかった」って言ってもらえて、うれしかったです。 僕の中のヒーロ達にも声をかけてもらえてうれしかったし、心強く感じました。 やってよかった。

今回のテーマについては、まだ先があるなあと感じていて、これからも折にふれて考えていきたいです。

あ、でも「カンファレンスの運営と発表を同時にやらない」という自分ルールを破ってしまったのはやっぱりよくなかったかも。 札幌Ruby会議02 のあとから気をつけていて、でもまたやってしまって、その想いを強くしました。

「気をまわすリソース」は自分が想像する以上に少なくて、あっという間に枯渇してしまうのでした。そうなるとろくな事がない。

We coded. We shipped.

@shyouhei さんが1日目のセッション開始前に Kaigi Subscreen に Github 絵文字が出ないか試していて、 :smile: が画面に表示されてしまったのでついカッとなってパッチを書きました。 パッチはできたのだけれど、2日目のセッション開始までにはレビューしてもらってデプロイまでする時間は取れなかったので、そのままリモートブランチで寝かせていました。

そうこうしているうちに @takai さんの LT でまた絵文字が出てきたみたいでいよいよ悔しくなって懇親会に向かうタクシーのなかで @june29 とペアデプロイしました。

ちょっとだけど、会期中にちゃんと We Code. できてよかった。