「できない」がチームを作る

チームを作って何かするときに大切なのは、「できない」ことの把握なのだと思う。誰もがたぶん、何らかの「できる」を持ち寄ってチームを作る。「できる」はもちろん大切だけれど、お互いの「できない」を共有することで、個人の集まりははじめて、チームとしての機能を獲得できる。

神経内科は怖かった

今いる施設にはいろんな患者さんが紹介されて、自分の手に負える患者さんもいるけれど、もちろんそうでない患者さんも多い。特に神経内科方面の症状を訴える患者さんが紹介されて、頭部の画像診断で、少なくとも素人目には明らかな問題がない場合には、うちの施設ではほとんど「お手上げ」になってしまう。

県内には神経内科を標榜する施設がいくつかあって、大学にはもちろん医局があるし、外来を持っている施設も、神経の専門を掲げている施設もあるのだけれど、「こんな患者さんがいるのですが、診療していただけないでしょうか?」なんてお願いすると、「僕にはそれが、どうしても神経疾患には聞こえないんですけれど?」とか、電話の対応が怖かった。

どこの施設も、看板こそ神経内科ではあるけれど、たとえばベッドがごくわずかしかないだとか、その人は虚血が専門で変性疾患は不得手であったりだとか、それぞれに固有の「できない」を持っていて、それが理解できるのに結局5年ぐらいを要した。

断られた昔、もうこの県内では「断る」ことでしか患者さんを専門施設に送り届けることはできないんじゃないかと考えていたのだけれど、「できない」がある程度分かるようになってから、ようやくたぶん、病院同士の連携というものが、強引にでも回せるようになってきた。

10徳ナイフは難しい

無人島に持って行く」という条件を付けると、素人は10徳ナイフを選択して、登山のプロは、たぶんシンプルで丈夫なナイフを選ぶ。

10徳ナイフには様々な機能が備わっているけれど、たいていの機能は、ナイフがあれば事足りる。はさみがなくても紙は切れるし、缶切りがなくても、ナイフの刃が十分に丈夫であれば、たいていの場合用が足りてしまう。ナイフには「できないこと」があまりないから、結果として10徳ナイフは、「不便な単機能ナイフ」として酷使された結果、壊れてしまう。

たくさんの機能を持った道具を使いこなすのは難しい。10徳ナイフには様々な「できる」が備わっている代わり、ある状況においてどの「できる」が最もふさわしいものなのか、ユーザーは自分で考えないといけない。「できる」の範囲は案外広くて、判断はしばしば重たい。単機能で丈夫な何かを工夫するのと、多機能の道具を使いこなすのと、漠然とした使いやすさは、機能の数に逆比例することが多い。

「できない」で連携する

警察が人質交渉を行う際には、「交渉人」と「指揮官」とがチームを組む。チームには「交渉人は判断を行わない」、「指揮官は交渉を行わない」という原則があって、お互いに「ない」を持ち合うことで、チームには優れた連携が備わるんだという。

「ある」を使って同じことを目指すと、「交渉人は交渉を行う」こととなり、「指揮官は判断を行う」という、ありきたりな分業ができあがる。ところがこのルールで交渉に臨んでしまうと、ならば交渉人が判断を求められたときに、どうしてそれができないのか、あるいは逆に、指揮官自らが、相手からの交渉を求められたときに、どうしてそれを断れないのか、分業のポリシーからはそれを説明できないから、チームは混乱して、ルールでは混乱を収拾できなくなってしまう。

同じことは複数の道具を使う際にも言える。この道具はこのことができない、この道具はこのことができないという具合に、「ない」を使った道具の連携に失敗すると、それは「使い勝手の悪い十徳ナイフ」になってしまう。

たとえばスイスアーミーナイフの虫眼鏡は丸くデザインされていて、厚ぼったい。「レンズは刺したり切ったりできないし、隙間をこじることもできないよ」というメッセージがデザインに込められていて、迷わない。キリは細くて華奢で、たいていは握りの真ん中から立ち上がるように作られていて、あれをナイフの代わりにするのは難しい。

多機能ナイフはそうすることで、小さな刃をキリの代わりに使われて折れてしまったり、レンズで隙間をこじ開けようとして割れてしまったりといったトラブルを回避している。同時に「できない」をデザインに組み込むことで、ユーザーはたぶん、機能の重複から来る迷いが減って、たくさんの機能を持った道具を、いくらかでも使いやすく感じることができるのだと思う。

ネットサービスはどうなのか

たとえばTwitter にできることはシンプルで、とにかく字数制限がついた書き込みをひたすらに重ねていくこと以外、ユーザーには何もできない。検索も今ひとつ当てにならないし、過去ログを掘るのも難しいのに、Twitter を、あたかも自分の日記みたいに使う人はけっこういる。

blog サービスを自分のホームページとして使っている人は多い。基本的には日記帳だから、記事はどうしたって時系列に並ぶことになるけれど、「2100年」みたいな未来の日付でページを作って、その記事をホームページの看板のように使っている人も多い。

コミュニティを作りたい、自分の日記に看板を出したい、何かを販売してみたい、日記を書いて発信したい、様々な機能を最初から全部提供できるサービスはたしかに便利なのだけれど、機能の数と使い勝手は逆比例して、ユーザーは迷うのではないかと思う。

たとえばULOG のサービスには、「ブログ」と「日記」、「チャット」と「コメント」というものが、それぞれ独立した機能として備わっていて、どれも同じぐらいに高機能で、たぶん「できない」ことがない。これは長所でもあるのだろうけれど、逆に言うといくつもの機能を使い分けて、お互いを連携させる動機を生まない。Web の記事には「題名」と「日付」、「本文」、「URL」という役割が備わっているけれど、それぞれに「できない」を付加すると、使い分けと連携が容易になるのだと思う。

たとえばこんな実装はどうなんだろうか?

  • 「ブログ」は題名をつけることができるけれど、日付を記録することができない。サーバーサイド、ユーザーサイドで日付を管理するとはできるにせよ、読者の側から、少なくともサービスの内部からは、それが書かれた日付を知ることができない
  • 日記は逆に、自動的に日付が記載される反面、題名をつけることができない。題名が必要な、時間軸を超えた記述については、必然的にブログを選ばないといけない。日記はその代わり、日付でサービスを横断することができて、その日に書かれた日記を串刺し検索することができる
  • チャットには文字列を記載できるけれど、パーマリンクが付加できない。ユーザーサイドにはログが残るにせよ、読者の側から見て、過去ログを掘ることはできても、特定のつぶやきに対してコメントを残したり、そこだけをURLとして切り出して、他のサービスで引用したりすることはできない
  • コメントには日付とURL、引用先文章の題名が付記されるけれど、文章のトップには常に誰かの書いた文章がくる。自分の言葉だけ、単体としてのコメントというのはありえない

お互いの機能がじゃんけんのように 3すくみ、4すくみになった構造をしていると、使い分けの動機が生まれて、単なる高機能ではない、多機能ならではの論拠になるような気がする。「できない」の実装はその代わり、今度は機能を削ることになるから、今までできたことがどうしてできなくなるのか、それを使いにくいと感覚する人が出るかもしれない。