読者です 読者をやめる 読者になる 読者になる

森理 麟(moririring)のプログラマブログ

ゲームプログラマ森理 麟がのプログラムの話題を中心に書くブログです。

第3回RxTstudy その4 @tksmdさんの「Backlog の開発で大事にしていること」 #RxTstudy

勉強会 Redmine

実は期待していなかったセッション

次は@tksmdさんの「Backlog の開発で大事にしていること」。

…非常に申し訳ないのですが、全く期待していなかったセッションでした。

ところが、ところが、始まってみると、とんでもなかったです。

以前読んだ、はてな@jkondoさんのTEDxTokyoに参加して、と全く同じ気持ちだったので引用してみます。

最初にこのイベントのご招待を頂いた時は、TEDのことをあまりよく知らなくて、
「なんなんだろう?」「仕事に役立つのかな?」などと思っていたのですが、
実際に行ってみると、仕事に役立つのかどうかなどという表面的な事を考えていた自分が恥ずかしくなりました。

言葉ではなく心で分かっていたこと

これは僕にとってこれ以上無いぐらい有意義で、素晴らしいセッションでした。

特に僕が長いことこだわり続けて、ロジックではなく、心で分かっていたことを、言葉で説明してもらえました。

自分の抽象概念に具体性を与えてもらえる。これはもう、本当に、本当に、幸せなことです。

僕の心酔する河合隼雄さんの本を読んだ時もこの感覚の連続でした。

まさかのシンクロニシティ

なんと、ちょうど書き始めていたブログと全く同じタイトルがプレゼン資料にキーワードに出ました。

これには、はにかむような、込みあげるような嬉しさがありました。

僕にとってのこのスピーチは、発見だけでなく深い共感がありました。

プレゼンの本質は、内容を理解させることではなく、情熱を共感させることだと思います。

思わずつぶやいた一言

このセッションではbacklogの機能説明や技術説明は殆どありませんでした。

それよりも説明したのは、作り手のこだわり、つまりスピリッツの部分でした。

にも関わらず僕が思わずつぶやいた一言にこのセッションの凄さが集約されていると思います。

「backlog使いたくなってきた!」

終わった後、感動と共感を伝えに話しかけに行き、懇親会でも話す約束をしました。

togetterの2012/2/4 第3回 #RxTstudy まとめ(2)本編から抜粋

経歴:2005年、IPA未踏ソフトに採択「Tuigwaa」を開発。2008年- Choistudy の運営、2010年からBacklogに携わっている

Backlogのはじまり:2004年社内リリース、2006年ベータ版リリース、2007年正式サービス開始、2011年末海外版リリース

今日は、個々の機能紹介、他ツールとの比較、技術的なあれこれはお話しないとのこと

開発で大事にしていること、Backlog開発チームのチームビルディングにも触れます

.@daipresents のエントリ http://t.co/4KDKFGGz #RxTstudy

ユーザの要望、自分たちの要望、トレンド についてディスカッション→機能シーズ→マイルストーンに落としていく

開発の流れ:モック→レビュー→デザイン→レビュー(戻ることもある)→プロト→→本開発→リリース

モック:目標はどういうものを造りたいのかというイメージを共有すること。この段階でアイデアをじゃんじゃん出すこと。

プロトタイプ:不確定要素が多い場合(使ってみないと判断がつかない)は利用者を内部に限定して実環境にリリースすることもある!

プロトタイプはChrome Extensionで造っている。何が良いかというと、基本JSとHTMLだけで作れる点

+DOMの操作をプラグインからできる。新しいことを覚える必要がほとんどなくできる。実環境にリリースしなくても自分たちで使える。

レビューの視点(モック):「問題を解決するか」? →開発している機能が、裏側にある問題にちゃんとアプローチしているか。
/データの流れ、情報の見せ方、トレンド

フィードバック:議論しながら見せ方を変えてモックをたくさん作る。

レビューの視点(デザイン):「Backlogらしさ」見ていて楽しいか、直観的に操作できるか、プロダクトとしての統一感

デザイナーにフィードバックするときは断定的な答え、リクエストを出さない

レビューの視点(仕上げ):「違和感がないか」 分岐が複雑なときは「8割」を優先。シンプルに使うために必要な判断。
/操作の気持ちよさ:UIのレスポンスのタイミング/文言・表現、適切な表現か?

ここまでが、Backlog開発で思いが強いところ。ここからは本題「大事にしていること」

社内で共有しているスローガン「チームではたらく、すべての人に。Backlog」

ITSは分散環境だったり、先端的な働き方をサポートするツールだと思っている。開発者でない人にもこれらのツールの素晴らしさを伝えたい

大事にしていること1:「使う人の感情」『仕事を楽しくやって何が悪いの?』日常的に使うツールだから、楽しく使ってもらいたい

たとえばステータスの色変化。赤→安心感のある緑にする。バーンダウンチャートで安心ラインまで落ちたときに、
「○○さんのがんばりです!」といったメッセージを出す。

チケット一覧のページは、縦幅に余白を大きくとっている。ユーザの気持ちにゆとりを持ってもらうために。

作り手の遊び心:楽しさを伝えることで、ツールのファンを増やす!ログイン画面に仕込んでいるので試してみてください

LEGO Serious Play http://t.co/rMclIuZz #RxTstudy

プロセスを規定しない:仕事にあわせてツールを使う。それには、機能を全体的にわかりやすく保つ必要がある

要望の背景を考える:ex:「サブタスク」要望は強いが、「親子」という言葉から想起させる概念が幅広いため、安易に導入に踏み切れない。

絵文字・アイコン:「文字化→入力するのは実はストレスフルな行為!」コミュニケーションギャップを埋めるための工夫

「誰のためのデザイン?」はエンジニアにもオススメの一冊

UIの細部:おもてなしの心を持って作る

チームビルディング:ストレングス・ファインダーを使っている。/年表を共有して、バックグラウンドを共有する。/朝会・KPTやってます/

ユーザとの対話:年1回程度ユーザの集いを開催。多くの視点を得ることにより、焦点を定めていく。プロダクト開発は探索的

コラボレーションの四つの要素(チームがいい状態の時の特徴):1.ゴールを共有している 2.オープンマインド(何でも言い合える)
3.強みを補完できている 4.全体感を持ってゴールに向かっている

ツールはどこを手助けできるか?前述の1,3はITS以外のプラスアルファで補う必要がある

実現したいこと:楽しく、気持ちよく、目標に向かって仕事ができる!