カテゴリー : TarotReport

タロット・リポートが生まれた理由(だが下書きのようだ)

以下、下書きですが、出しておきます。
究極的には自分で作る
「究極的には自分で作る」ということへの憧れみたいなものがある。それも理由だろうね。

「モノと人が1:1の時代」=作り手と使い手が同一「セルフ・ビルド」
大きくなるほどユーザーと離れる。直しが効かないとマズイ。ユーザー参加型。
「究極的には自分で作る」

時の流れと共に作り手と使い手が分離していったという話を初めて聴いたのは 2010 年のデブサミでの中埜さん(と和田さんと角谷さん)のセッションだったと記憶しています。
その後、Webエクスペリエンスを創る種 で話をした後に、黒須先生も同じことを書かれていたと知りました。
この辺から私の中ではパタン・ランゲージと HCD が「作り手と使い手の距離」という課題でゆるゆる繋がり始めました。
一方、「安藤先生UXDはインダストリアル・デザインである鈴木雄介さん「クライアント(の)ために」は手工業。産業としては原始的なありかたというのが
頭の中で手をつないでころころしているので、「究極的には自分で作る」というのはビジネスに対しては乖離がある、とも思っています。
とはいえ、作り手としては「作るコト」と純粋に向かい合う機会も欲しいですよね。
また、サーバサイドのアプリケーションエンジニアとしては(UI の方は Web デザイナーさんやコーダーさんがやっているので)「アプリケーション全体を自分で作ってみたい」という欲求もありました。
アプリケーションエンジニアにとっての外化
外化という言葉はワークショップを通じて浅野先生に教えてもらったようなもので、

自分の考えを他者に説明するために文章を書いたり、図を作ったりして理解の過程を見えるようにすること。これによってメタ認知が促進される。とりあえず「脳から出してみる」こと。

だそうです。
「頭で考えているだけ」ではダメで、図なり文章なり目に見える形として外に出してみないと「本当は考えられていない」ということです。
モデルを描いてみるとか、ブログを書いてみるとか、外化には様々な形があります。
(いわゆる)デザイナーならスケッチを描くだろうし、プログラマならコードを書くかもしれません。
ここしばらく広い意味での「デザイン」について勉強してきたのですが、「実装」に至らない「もやもや感」もありました。
それは、こう考えると納得がいきます。
アプリケーションエンジニアにとっての外化は、きっとアプリケーションを作ることだろう。
外化の手前で止まっているような感覚、エンジニア/プログラマとしては「実装」しないと消化不良があるのかもしれません。
あるいは、「エンジニア/プログラマとして本当に考える」に至っていなかったのかもしれません。
それで「一定の形」にしてみる、ということをやってみたくなったのだと思います。
協創のための独創
今回、自分の中で抜け落ちていたと自覚しているのは「コラボレーション」や「多様性」といった協創的な要素です。
「究極的には自分で作る」という指針はあったものの、一連の HCD 系ワークショップで協創の重要性は理解しているので、少し迷った点でもありました。
ただ、ワークショップに限らず業務プロジェクトでも人が集まれば良いというものでもなく、「場のファシリテーション」や「個々の資質」によって、その多様性から価値が生まれるかどうかは変わってきます。
だとすれば今回は(自分の)「個々の資質」の方を伸ばしてみようと独創することにしました。
協創へ至る道としての独創のような何か。
プログラミングは普段の仕事で行いますが、企画や UI デザインはほとんど行わないので、そこを体験しておけばコラボレーションする際のインターフェースになり得ると考えたわけです。
結果として、一人で外化したものを他者に見てもらうことで、自分に足りていない部分が鮮明に分かるという気づきもありました。
まぁ、実際は手伝ってもらったりしたので、「完全に一人で作った」わけではありませんね。
ということで、ここまでです。
後日、整理されたものが出てくることに期待したい。

広告

iOS 5でTwitter連携ができないバグを修正したタロット・リポート ver.1.1.6

複数のバグ修正を行った ver.1.1.6 をリリースしました。
App Store – タロット・リポート
tr1.1.6.jpg
バグとその原因が気になる方は続きをドーゾ。

続きを読む

iPhoneアプリをリリースするまでの3ヶ月を振り返る その3 #tarotR

開発完了後、10 月に入ってからアプリ申請などの手続き作業を始めました。
アプリ申請~リリース(3週間ほど)
アプリ以外に必要な素材は、ストア用の説明テキストやスクリーンショットなど。
これらを準備した上で、アプリ登録を行ってアーカイブをアップロードします。
2011.10.03 Company Nameの登録に迷うなう。
2011.10.04 Waiting For Review
iTunes Connect での手続き~アーカイブをアップロードを二晩に分けて作業。
結局、Company Name は WarlockReport にしました。
2011.10.09  In Review~Ready for Sale まで 3 時間ほどで移行
5 日後にレビュー、審査を経てダウンロード可能状態に。
リジェクトされる要素は無かったようで何より。
なお、この時点ではリリース日を 10/20 に指定しておいたので、App Storeには並んでいません。
それまでは、プロモーションコードを発行して友人らにテストがてら触ってもらう期間に。
2011.10.11 あー、そうだ対応せんといかん。
2011.10.13 テスト端末(を言い訳)として iOS 5 入りの iPod touch 8GB(ホワイト)を購入
2011.10.14 バージョン 1.1 を申請
この間、iPhone 4S や iOS 5 のリリースがありました。
iOS 5 では日本語変換候補の表示位置が変わったので、その対応や iOS 5 から発覚するバグ対応を行って 1.1 を申請(先にやっておきましょう)。
2011.10.20 バージョン 1.0 リリース
tr_1.0r.jpg
前日の日替わり直前(日本時間)にストアに並びました。
2011.10.21 バージョン 1.1 リリース
翌日には 1.1 がリリース。
2011.10.23 バージョン 1.1.5 を申請
2011.10.29 バージョン 1.1.5 リリース
バージョン番号の付け方が適当だったのですが、機能追加で数えると 1.1.5 は 1.2 相当。
実際に出来上がったものは、App Store でご確認下さい。
タロット・リポート(App Store)
現在は @TarotReport に報告頂いたバグを修正した 1.1.6 がレビュー待ちの状態です。
初 iPhone アプリのリリースまでの振り返りはこんなところでしょうか。
iPhoneアプリをリリースするまでの3ヶ月を振り返る その1 #tarotR
iPhoneアプリをリリースするまでの3ヶ月を振り返る その2 #tarotR
この開発に至るきっかけになった想いのようなものは、また別のエントリーで書きたいと思います。

iPhoneアプリをリリースするまでの3ヶ月を振り返る その2 #tarotR

前回の続きです。
タロット・リポートの開発も前奏曲が終わり本編へ。
プロトタイプ評価~開発完了(約1ヶ月)
あまりスクリーンショットを残していませんでしたが、8.25 時点は下のような感じ(二つの道の結果画面)。
ちょうどアジャイルサムライ DevLOVE道場 第一回萌芽の頃です。
111030.jpg
約1ヶ月でこれくらいのプロトタイプと呼べる実装が完了したので、周りの人に触ってもらいフィードバックを得ながら開発を継続するフェーズに入りました。
2011.08.25 今日のテスト結果より:もうちょっとアフォード
具体的には同僚をお昼に誘ってプロトタイプを触ってもらいました。
そこで見つけた改善点を開発にフィードバックする形です。
この日は操作に戸惑っていた記憶ありますね。
「裏になっているカードをタップすると開く」に気がつかないとか。
最終的にカードオープンは自動化されたので、結果として改善されたようにみえますが、正攻法で行くなら「裏になっているカードがそれと認識されて、かつ表を返したくなるようなデザイン」をするのかもしれません。
2011.09.05 フレンドカードの機能が実装される
このタイミングで大きな機能追加されました。
元々、Twitter 連携については占い結果をツイートする程度を考えていたのですが、時折、こーゆーイメージが頭をよぎった結果、フレンドカードが追加されました。
createFriendCard.jpg
もちろんユーザー要求も何もないので、「私が作ってみたかった」だけです。
もし、この機能を好んで使ってくれる人がいるとしたら、そこに「何か」があると思うんですよね。
今回の場合、それを「無名の質」とは呼べませんが、作り手の感覚が日々の観察によって磨かれていたとしたら、そこから生まれるものもあるのではないか、と思います。
もちろん、私がそうであったかどうかは別問題ですよ。
話が飛んで行きますが、熟練された作り手はそういう「パタン」を蓄積していて、いざという時に組み合わせて(ランゲージ化して)形にできるのではないかと考えています。
観察と経験の蓄積から生み出せる価値。
一人で出来なくても、それは「多様性」で補うことができるかもしれません。
話を戻すと、このフレンドカードの実装で開発工数が足りなくなりました(9 月中のリリースで計画していた)。
そこで、一部のお絵かきを mariko さん依頼することにしました(ここで iPad 2 を貸し出す)。

2thp.jpg
mariko さん(の予想図)。

某所でペイント(Windows の)で描かれていた絵を見て、無名の質を感じたので依頼しました。
最終的には「女教皇」「恋人」「正義」「吊られた男」「星」「審判」「世界」を描いてもらいました。
「星」とか「世界」とかスタンド使いとしては重要なアルカナですね。
2011.09.09 評価 2 回目
「発話思考法+プロトコル分析」の実施も考えたのですが、ランチついでに軽く触ってもらうだけでも、十分効果がありました(改善点は見つかる)。
簡易オブザベーションという感じですね。
あと、NE比を出してみるという手もありますが、今回に限っては見ていれば分かるレベルでした。
参考リンク
 プロトコル分析 | 情報デザイン研究室
 NHN Japanでオブザベーション・ワークショップ | 情報デザイン研究室
 NE比 | 情報デザイン研究室
もちろん、各手法を行って改善を施せば、よりアプリに磨きがかかるのは間違いないでしょう。
2011.09.14 快心のフィードバックを得たので、これを反映させます
現在の「タロット占い」のフローが、ここでほぼ確定。
それまではいちいちタップ回数が多かった(作っていると慣れて気がつかなくなる)ので、改めて他者評価が大事だなと認識しました。
一方、リリース版では占いとしての「雰囲気」や「情緒」の足りなさを感じた方もいると思います。
これは想定利用シーン、というか自分の利用状況が「通勤中」とか「混雑した電車内」だったからです。
もし、本当に占いを求めてるユーザーを想定して作るなら、本職の占い師さんの言葉やカード捌きを観察して得たものをアプリに反映させるところでしょう。
リリース後に少し触ってもらった中に、たまたまタロット占いに詳しい方がいまして、その方の話を聴くだけでも(そういう方向性で作るとしたら)参考になることが多かったです。
ここで、デザインあるいは企画を生業にする人は自分の中にどれだけ引き出しをもっているかが大事で、もしプロジェクト領域に対する引き出しが少ないと思ったら、迷わず引き出しを持っている人にあたってみるのが正攻法なのかなと想像しました。
よくよく考えると業務 SE も「顧客」というその業務についての引き出しを持っている人と組むことでより善い仕事ができるのだろうし、Web サービスやゲームのプログラマやエンジニアにも同じことが言えるでしょう。
自分の専門領域があるとして、それを活かすには必ず別の領域との接触が必要になる。
その「インターフェース」を通じた「コミュニケーション」が「価値」を生み出す。
今回の開発を通じてこの辺が「言葉でなく心で理解」できたような気がします。
2011.09.26 お絵かき受け取り完了(iPad 2 の帰還)
「桜と空の組み合わせで『無敵』なんですね」
正しい選択をしたと確信したこの瞬間。
ここから残りのカードを描いたり、アプリアイコンなどを作成したりした上、アプリに取り込んで開発完了。
こうしてみると、iOS アプリはプロトタイプを端末に入れて持ち運べるという点で、開発中でもユーザーからのフィードバックを得やすいという特性がありますね(Android もそうかもしれません)。
Web サービスや業務システムと比べると圧倒的にそうだと思います。
改善のしやすさが、品質向上や価値提供のしやすさに繋がるとすると、スマホ以降ではアプリが超えなければならない「一定のクオリティ」のラインも上がっているのでしょう。
ちなみに、プロトタイプを含めた開発期間中は、毎朝、社内カフェで同僚がレビューしてくれていました。
その同僚の代表作 : ハッピー銀行!(App Store)
振り返ってみると、一人で作っているようで、そうではないんですよね。
究極的には自分で作る」(この件はまた別のエントリーで)といっても、自分にとってしっくりくるモノ(価値)も他者から気づかされることがありました。
「多様性」や「協創」が持つ価値についても(見かけ上)「独創」することで改めて理解できたと思っています。
SECI モデルじゃあないですけど、「協創」と「独創」を行き来する黄金の回転もあるのかもしれません。
協創へ至る道としての独創のような何か。
今回のアプリ開発は、これらの検証としての性格もありました。
また、純粋な HCD 手法やプロセスは使っていませんが、知っているだけでも手助けになることを再確認できました。
問題解決の引き出しとして持っていて損は無いでしょう。
つづき ⇒ iPhoneアプリをリリースするまでの3ヶ月を振り返る その3 #tarotR

フォロー検索でフレンドカードが作りやすくなったタロット・リポート ver.1.1.5 #tarotR

タロット・リポート ver.1.1.5 がリリースされました。
111029a.jpg
機能的な追加はひとつです。
Twitter のユーザー名で検索して特定のフォローのフレンドカードを作成できるようになりました。
以下で操作手順を説明しておきます。
まず、タブバーの「フレンドカード」から「フォローから作成する」を選択して、フォロー読み込みの画面を表示させます。
111029b.jpg
次に検索バーにフォローのユーザー名(@〜)を入力します(@ はなくて OK)。
入力は大文字でも小文字でも構いません。
入力すると下に「@〜で検索する」と表示されるので、そこかキーボード右下の「Search」をタップします。
111029c.jpg
すると、Twitterのユーザー検索APIを利用してフォローの情報を取得し、フレンドカードを作成します。
111029d.jpg
これまでは、フォローを読み込まない限りフレンドカードが作成できず、フォロー数が多い方の場合、大変手間のかかる「作業」になっていました。
ユーザー名の完全一致は必要ですが、ある程度の改善はできた思いますので気になっていた方は使ってみて下さい。
フレンドカードを作成した後は「Tweetする」で Mention 付きで知らせることもできるので、スタンド(またはペルソナ)使いっぽい人に伝えてみるのも良いでしょう。
111029e.jpg

…で、お前さんは App Store のレビューを書く気はあるのかの?
いやならやめてもいいんじゃぞ。
別に他の道がないわけじゃなかろう。

iPhoneアプリをリリースするまでの3ヶ月を振り返る その1 #tarotR

世の中には 初心者でも2週間でiPhoneアプリが作れちゃうTitanium Mobile というものがあるそうですが、タロット・リポートのリリースまでには約3ヶ月かかりました。
111027.jpg
開発期間でいうと約2ヶ月。
開発においては「遠回りでも自分だけのなじむ道」を進むのが良いと僕の経験は語っているので、スピードは意識していませんでした。
ただ、あまり長過ぎてもダレてしまうので、やる時は「然るべき期間」(謎)を設定してほいた方が良いと思います。
リリースして1週間経ちましたので、この3ヶ月をざっと振り返ってみようと思います。
興味のある方は続きをご覧下さい。

続きを読む

タロット・リポート ver.1.1 をリリースしました #tarotR

1.0 リリース直後ですが、タロット・リポート ver 1.1 をリリースしました。
裏話をすると ver.1.0 は 10/9 に審査が通過して Ready for Sale になっていました。
この状態でプロモーションコードを利用して友人らに最終チェックがてら触ってもらっていたので、App Store には出していませんでした。
同時期に iOS 5 のリリースがあり、一部不具合を発見したので、それを修正したのが今回の ver.1.1 になります(10/14 申請)。
当初設定していた販売日が 10/20 で、ver.1.1 がギリギリ間に合わなかった形になります。
ともあれ、これで iOS 5 での不具合も解消されたので、ver.1.0 をダウンロードされた方は是非、アップデートをお願いします。
タロット・リポート ver.1.1(App Store)
では、簡単に ver.1.1 の紹介を。
111021.jpg

続きを読む