機能はシンプルに、サポートコストを小さく
サイドフィードの赤松さんがお話をするというので、またアカデメディアに参加してきました。今回のアカデメディアのテーマは「LifeHack」。その中でも「GTD」について、百式の田口さんとサイドフィードの赤松さんがプレゼンをされていました。
プレゼン資料は後日公開されるというのであまりメモはとっていませんが、私がメモしたところを書き出しておきます。
check*padの開発思想
1. メタファーを持つ
2. ライバルを持つ
3. 何が削れるか?が設計思想
バージョンアップで機能削減することもあり。
4. 自分の問題を解決 = 自分で使う
自分で使いたいものじゃないと説得力がない。
5. 運用コストの最小化
サポートは大変。ユーザ同士のインタラクション機能を排除して、サポート対象を機能面に絞る。タグ機能とかもってのほか。
赤松さんの製品リリースに必要なこと
1. CxP: Concept x Product
Conceptはアイデアを言葉で表現、Productはユーザの視点から見えるもの。Conceptは変わらないけど、Productはリリースしてからユーザの反応で変わるものだと。
2. Make it Simple
機能を増やすことはいいことではない。機能を増やしてユーザが増えても、コンセプトを理解できないユーザが増えるのでサポートが大変になる。
3. Release Framework
リリースの手順をテンプレート化する。
とりあえず、どちらも「機能はシンプルに、サポートコストを小さく」という共通点がありました。
ところで上のメモの内容はGTDと関係ないよね?って思われるかもしれませんが、実はGTDとは「Gassyuku Tte Douyo?」の略だということが判明したのです。正しくは、GTD?。あと開発合宿のフレームワークとして3つのものを挙げられていたんですけど、一つはjkondoでもう一つが24時間温泉で、あと1個思い出せません。(あとで書く。)
(追記)
あと1個はプロトタイプ・レビュー・ミーティングでした。(あとで書いた。)
コメントを残す