機能が問題を解決するんじゃない。
機能を考えるじゃなくて、解決したい問題が自然と解かれる有様、新秩序(?)、新構造を想像し、それを今とのギャップを把握し、移行させる道筋を考える。
機能が問題を解決するんじゃない。
機能を考えるじゃなくて、解決したい問題が自然と解かれる有様、新秩序(?)、新構造を想像し、それを今とのギャップを把握し、移行させる道筋を考える。
有名なサービス同士を連携させる/APIを翻訳する/連動させる。既存のプレイヤーにくっつく作戦。
書き込み、写真、アクティビティ、電子メール、とにかく何かしらのエンティティ的なものを保存するサービスが結構出そろっている。そして覇権も争っている。
人の持ち時間は限定されている、というのがこの原理の源泉。ゆえに、取り得る路線は、
ーーー
恵比寿方面に沈む夕日。
コーヒーショップにて鞄からiPadを取り出す時のなんともいえぬ気恥ずかしさ(所詮、気のせいなんだけど)を克服したら、一気に便利になりました。逆に、iPhone(3G)がお荷物気味になってます。
という原則にしてます。
ipad→外部仕様→(インターフェース)←内部処理←mac book pro
みたいな棲み分け。
iPadを推してるサイトが少ない気がするので、何かしようかな。そして足りないピースが見つかったらそのアプリをピンポイントで作って補っていく、とかね。
この2週間以内くらいに、twitterかtumblrかどこかで見た。
そして2週間後の今、わざわざblogに書くくらい胸の中に残っている言葉です。
これ以外にもうひとつ、最近の経験をもとに自分なりに得たネタがあるんだけど、今は書きにくい。
そういうネタを持っていて、でも諸事情で公表しない人はとても多い。誰かがそれをオフレコで言ったら「俺も」「俺も」という展開になる。
(ちょっと飛躍あり)
ということは、世に出てる論評の類はそれら以外のものであり、世論調査なんかも含めて大した重要な内容じゃないってことかもよ。
ドキュメントを書いていると、文章にtodoやらレビューの記録を対応させる必要があります。ページ数や行番号などで対応付けし、リストは別途Excelに書くことが殆どでした。ディスプレイにWordとExcelを開いてレビューをし、各自が結局同じような目立つ箇所のコメントに集中してしまいレビューの効率が半減していました。
ノートPC(mac book pro)とiPadでの使い勝手が結構よくて、ピコピコ使って書いています。特にiPadを縦に持って書いている時は考えることや書くことに没頭していました。
「いかん、時間を使いすぎたか?」
ドキュメントを書くことがoutputになっているタスクをやっているときに、書き手にとって有用なフィードバックとはなんだろうか?
plan → do → see
候補?
「いや、そうではない、使った時間量ではないか」
取りかかる前に、だいたいの所要時間を見積もったり見積もらなかったりしますが、どっちのケースであっても書き終えた時に、「いったい何分使ったか」というのをフィードバックしておくと、時間見積もりの判断に役立つデータが頭の中に徐々に蓄積されるんじゃないか、と。
テレビゲーム類が実現しているプレイヤーへのフィードバックも参考にしました。
音や振動や手触りなど視覚以外の表現は今の時点ではないな、と切り捨て。
要件
ここまで列挙したときに、iPad画面上部に表示されている時計と充電量の表示が目に入りました。
これに、itunesで曲を再生しているときの残時間表示を組み合わせて、初期バージョンとしてこのようなUIにしました。
最初はもっとグラフィカルな感じかと思ったのです。単純化しているうちにLinuxのwgetコマンドやらyumコマンドでの進行状況表示がこのようなテキスト表示であり、しかもそれで結構十分役立ってるということを思いだして、このようなテキストにしました。
1つのドキュメントを書いたり修正するごとのフィードバックがこのタイマー。
そしてそれらを集積したものを1日分まとめてみれば、1日の振り返り。1ヶ月なら現時点での自分の傾向の把握などなど。フィードバックの最小単位がこのタイマーというわけです。
ちょっとしたギミックにすぎないちゃちなおもちゃのようにも見えます。そういうようなちょっとした機能はあれこれ付けたくなる誘惑もすごくあります。でも、これは違うと今の時点では思ってます。
仕事時間を短くするには、時間の使い方が圧倒的な優先順位になってるわけです。
遠回りして考えるとモチベーション云々、等が出てくるかもしれませせんが、遠回りせずにそこに切りこむ一歩目がこういうことだと思うのです。
仕様書に書いた仕様と、実装と、仕様に対応したブラックボックステスト用のデータ(inputとoutputのセット)、テストの実行状況を追跡表示するための、開発用CI(continuous integration:継続的インテグレーション)ツールのスクリーンショットです。
従来のCIツールだとソース、ビルド、テストのサイクルだったのが、これだともう一歩(いや、二歩?)手前の設計工程も込みで、仕様の追跡、影響範囲の特定が出来ます。
開発ドキュメントには、次の2系統が含まれます。
後工程になっていくほど、後者の割合が増えていきます。。後者にかかる工数(というよりも、所要期間)を短縮することで、縦糸である前者と、横糸である後者を高いレベルで織りなすための「設計」の正味の質を上げることで、実行時のパフォーマンス向上、設計の明瞭さ向上、実装量の削減、類似システムへの仕様、設計レベルでの展開率の向上を狙いとしています。
susatadahiro