機能が問題を解決するんじゃない。

機能を考えるじゃなくて、解決したい問題が自然と解かれる有様、新秩序(?)、新構造を想像し、それを今とのギャップを把握し、移行させる道筋を考える。

リレーション役、アタッチメント役のサービスばかりを徹底して作る、というのはどうだろうか。

有名なサービス同士を連携させる/APIを翻訳する/連動させる。既存のプレイヤーにくっつく作戦。

理由:エンティティ的なシステムが多いから。

書き込み、写真、アクティビティ、電子メール、とにかく何かしらのエンティティ的なものを保存するサービスが結構出そろっている。そして覇権も争っている。

原理:一人の人間が日常的に頻繁に使うサービス数は増えない

人の持ち時間は限定されている、というのがこの原理の源泉。ゆえに、取り得る路線は、

  • 既存のプレイヤーを押しのけて自分の席を確保する。
    • 写真/画像サービスのように、入れ替え期に差し掛かったっぽいサービス分野で挑む。
    • 入れ替え期に差し掛かってないサービスは強力。
  • 「日常的には使わない」という線を狙う。

リレーション役とアタッチメント役の共通点は既存のサービスと接続することが必須という点。

  • リレーション役はバッファ機能などで、→キャッシュ役→エンティティのデータストア役に進出するかも。
  • アタッチメント役は分析のようなプロセッシング役に進出するかも。

まとめ:推敲せずに上から順に考えながら書いたのだけど、最後の2行がちょっと意外でした。最初の役割と進化系の役割の組み合わせが逆っぽい感じがする。

ーーー

sunset

恵比寿方面に沈む夕日。

  • コンビニの飲み物の棚も、なんだか似たようなものばかりで、買わないことも多々あります。お菓子もわりとそう。
  • よしお菓子を買うぞ、と小銭を財布に入れて行った時もUターンしたり。
  • あと、プライベートブランドで大量の種類が陳列されてるときも結構買う気がしない。よく見るといろんな種類のお菓子があるんだけど、ぱっと見そうは見えないんだよね。
  • そういえば、ファイルサーバのファイルや、メーラーのメールも見た目はそんな感じだな。

大事な補足。大事なので最初にもってきました。

コーヒーショップにて鞄からiPadを取り出す時のなんともいえぬ気恥ずかしさ(所詮、気のせいなんだけど)を克服したら、一気に便利になりました。逆に、iPhone(3G)がお荷物気味になってます。

設計をipad上で、実装をmac book pro上で。

  1. その日にやる内容をiPad上で書き出し、ある程度まで設計を進めてます。
  2. iPad上では絵は描かないです。イメージしきって、それを文章に表現してます。
  3. mac book proを使うのは決まった内容を実装していく段階だけ。

という原則にしてます。

ipad→外部仕様→(インターフェース)←内部処理←mac book pro

みたいな棲み分け。

iPad推進しようかな

iPadを推してるサイトが少ない気がするので、何かしようかな。そして足りないピースが見つかったらそのアプリをピンポイントで作って補っていく、とかね。

シーンの違い

ノートPC

  • それを使うためにイスに座り、ロックインして使う。
  • わりと、余計なサイトにアクセスしやすい。それをする敷居が低い。

iPad

  • ソファーに座ったり、コーヒーを飲みながら使う。
  • 使ってる最中に、ほっぽり出せる。とりあえず茶を飲んで考えを整理する。
  • itunesで音楽を再生して、ちゃぶ台にほっぽり出しておく。そして背伸びしたりストレッチしたり。
  • 下の左右を両手で持ち、縦型に使う。キーボードは両親指を使う。正確に打ちたいときは右人差し指一本で。必要十分な速度で打てる。

この2週間以内くらいに、twitterかtumblrかどこかで見た。

そして2週間後の今、わざわざblogに書くくらい胸の中に残っている言葉です。

これ以外にもうひとつ、最近の経験をもとに自分なりに得たネタがあるんだけど、今は書きにくい。

そういうネタを持っていて、でも諸事情で公表しない人はとても多い。誰かがそれをオフレコで言ったら「俺も」「俺も」という展開になる。

(ちょっと飛躍あり)

ということは、世に出てる論評の類はそれら以外のものであり、世論調査なんかも含めて大した重要な内容じゃないってことかもよ。

inline-link2

今までのやり方

ドキュメントを書いていると、文章にtodoやらレビューの記録を対応させる必要があります。ページ数や行番号などで対応付けし、リストは別途Excelに書くことが殆どでした。ディスプレイにWordとExcelを開いてレビューをし、各自が結局同じような目立つ箇所のコメントに集中してしまいレビューの効率が半減していました。

ねらいとメリット

  1. 対応付けの手間自体を大幅に減らす。
  2. 修正箇所などの分布を実際のドキュメントに当てはめて見てみることで、抜け漏れに気づきやすくなる。
  3. 要件定義書では、書かれた内容がテスト項目に全て展開されているか?そのテスト項目はどれか?という対応付けが格段にわかりやすくなります。色表示をONにした状態で抽出の色が付いていない段落にはテスト項目が無いことが一目でわかるからです。以前なら同様のことを蛍光マーカーを使って満遍なくレビューをやる方法があった等聞いたことがあります。

議事録をいつものフォーマットで書くだけで、宿題の把握、リスト化が並行して終わります。

  1. 議事録はプレーンなテキストで書くことに落ち着く場合がほとんどかと思います。例えば、[宿題]m月n日までにxxxを完成させる。といった内容を箇条書きにしていくつも書きます。そうするとアプリ側で自動で宿題リストへと登録されます。議事録のページを見れば、議事録単位での宿題進展状況がわかりますし、一覧になっているリストのほうで宿題を進行していっても内容は常に同期されます。いつものようなスタイルでテキストを書いていくだけで、作業が並行して進みます。

inline-link1

文中のテキストをリストに登録する2通りの方法

  • 行頭に[todo]や[]、[task]、[review]、[宿題]といったものを付けて書くと、対応した登録ボタンが表示されます。よくメールなどのテキストで書くスタイルです。
  • もっと簡易にする場合は、該当箇所をマウスで選択すると、その文章が画面右側に表示されます。その状態で登録ボタンを押すとその場所がダイレクトにリストへ登録されます。

editor_timer

ノートPC(mac book pro)とiPadでの使い勝手が結構よくて、ピコピコ使って書いています。特にiPadを縦に持って書いている時は考えることや書くことに没頭していました。

「いかん、時間を使いすぎたか?」

書き手に有用なフィードバックとは何か?

ドキュメントを書くことがoutputになっているタスクをやっているときに、書き手にとって有用なフィードバックとはなんだろうか?

plan → do → see

  • doはドキュメントを書いている時。
  • seeでは何をフィードバックしたらいいのだろうか。

候補?

  • 書いたページ数?
  • 文字数?
  • 進んだ設計の量?(設計仕事の時)

ドキュメントを書くのに使った時間量をフィードバックする。

「いや、そうではない、使った時間量ではないか」

取りかかる前に、だいたいの所要時間を見積もったり見積もらなかったりしますが、どっちのケースであっても書き終えた時に、「いったい何分使ったか」というのをフィードバックしておくと、時間見積もりの判断に役立つデータが頭の中に徐々に蓄積されるんじゃないか、と。

テレビゲームが行っているプレイヤーへの小まめなフィードバック

テレビゲーム類が実現しているプレイヤーへのフィードバックも参考にしました。

  • このくらいの速さで走って飛んだら、どのくらいの距離を飛べるか
  • 滞空時間はどのくらいか
    • 必ずしも秒数のように数値として表示されるわけではなくて、体感リズム?での時間だったりする。

どう表現するか

音や振動や手触りなど視覚以外の表現は今の時点ではないな、と切り捨て。

要件

  • 書いている仕事自体の注意力を消費しない。
    • 文字を読むことが加わると、注意力の消費が大きい。
  • 見たいときに見られること。

ここまで列挙したときに、iPad画面上部に表示されている時計と充電量の表示が目に入りました。

これに、itunesで曲を再生しているときの残時間表示を組み合わせて、初期バージョンとしてこのようなUIにしました。

テキスト表示で十分

最初はもっとグラフィカルな感じかと思ったのです。単純化しているうちにLinuxのwgetコマンドやらyumコマンドでの進行状況表示がこのようなテキスト表示であり、しかもそれで結構十分役立ってるということを思いだして、このようなテキストにしました。

フィードバックの最小単位、という位置づけ

1つのドキュメントを書いたり修正するごとのフィードバックがこのタイマー。

そしてそれらを集積したものを1日分まとめてみれば、1日の振り返り。1ヶ月なら現時点での自分の傾向の把握などなど。フィードバックの最小単位がこのタイマーというわけです。

感想

ちょっとしたギミックにすぎないちゃちなおもちゃのようにも見えます。そういうようなちょっとした機能はあれこれ付けたくなる誘惑もすごくあります。でも、これは違うと今の時点では思ってます。

人のもっとも重要なリソースは時間です。

仕事時間を短くするには、時間の使い方が圧倒的な優先順位になってるわけです。

遠回りして考えるとモチベーション云々、等が出てくるかもしれませせんが、遠回りせずにそこに切りこむ一歩目がこういうことだと思うのです。

設計工程をも対象に取り込んだCIツール

仕様書に書いた仕様と、実装と、仕様に対応したブラックボックステスト用のデータ(inputとoutputのセット)、テストの実行状況を追跡表示するための、開発用CI(continuous integration:継続的インテグレーション)ツールのスクリーンショットです。

従来のCIツールだとソース、ビルド、テストのサイクルだったのが、これだともう一歩(いや、二歩?)手前の設計工程も込みで、仕様の追跡、影響範囲の特定が出来ます。

ねらい:設計の継続的な質向上によって、稼働システムの質向上(性能、実装量の削減)、設計自体の展開率を上げることでの工数の大幅な削減

開発ドキュメントには、次の2系統が含まれます。

  1. 縦糸:ストーリーとして語る部分
  2. 横糸:スペックとして非文学的(?)に記述する部分

後工程になっていくほど、後者の割合が増えていきます。。後者にかかる工数(というよりも、所要期間)を短縮することで、縦糸である前者と、横糸である後者を高いレベルで織りなすための「設計」の正味の質を上げることで、実行時のパフォーマンス向上、設計の明瞭さ向上、実装量の削減、類似システムへの仕様、設計レベルでの展開率の向上を狙いとしています。

効果

  • 設計の最終成果物はテストデータ(input)と期待されるoutputデータのセットであることを仕様の関連付けから認識せざるを得ないため、設計段階での仕様のパターン漏れや、データとしての表現可否を設計工程にて認識しやすくなります。
  • 後工程のドキュメント(ソースを含む)に、その内容を展開されていない記述は機械的に把握できるので、実装漏れを実装段階で自動的に把握することができます。
  • 問題の発生した仕様が具体的にピンポイントで追跡できるので、仕様自体の記述の仕方や、仕様と処理の対応のさせ方など、設計作業自体を具体的に改善するデータとなります。
  • 実際に参照の多いドキュメントが何であるか、の具体的な把握により、効果の高いドキュメントへの工数再配分や効果的な提供時期、執筆レベルの把握の精度向上に役立ちます。
  • 報告のための打ち合わせ時間の削減により、実際の対策案検討に割り当てる時間を増やすことが可能となります。


recall

  • 従来
    • 攻撃力10ポイント/時間の弓矢で100時間連続攻撃している。
    • 方向:プロジェクトマネジメントの能力を上げ、命中精度を上げる。
      • 要件定義の精度
      • 設計の精度
      • コントロールのための作業の精度
      • その他
  • 進むべき方向
    • 攻撃力100ポイント/時間の銃で正味10時間攻撃して、同様のダメージを与える。
  • 良くない方向に欲張った場合
    • 攻撃力1000ポイント/時間のミサイルを作るが、動く標的に当たらない。
  • 考えたこと
    • 100時間打ち続けるためには、補給等も含めて全体が常に滞留なく流れていなくちゃいけない。
      • ゆえに、成功のためには調整というマネジメントの能力が最重要だと考えてしまう。
      • 中にいる時間が長いほど、その調整で問題が起こっているように思える。
      • 調整力の向上では精度は上がるが、精度は100%以上にはならない。頭打ちになる(なってる)。
    • 総時間が減らさない限り不確実性が許容値を上回ったままである。
    • 弓もたしかに強いが、銃や大砲やらの系統を開発してる国が来たら、火力で圧倒されちゃう。
  • 時間を減らすためにすること
    • 略。今度書くかも。
  • システム開発において攻撃力とは何を指すか?
    • 略。今度書くかも。
twitter
    follow me on Twitter
    プロフィール

    susatadahiro

    • ライブドアブログ