• 61de0ae83f653c8d70db516674a16817?s=80&d=mm

    Changes from shinyamatsuyama

    shinyamatsuyama - about 5 years ago (Jul 14, 2014, 12:03 AM)
    誤字の修正。
  • Changes rejected Closed
      Looks like something's not quite right here.. We've been notified of the issue, and will get back to you soon.
      document
      # dotplace18
      ## 「書き手のためのプル・リクエスト」

       「読むことが書くこと」である情報サービスでは、文字通りユーザーがある記事を読んだ後に書くことが促されるものであると考えられます。このコンセプトを満たすためのまだ見ぬ機能を考えてみましょう。

       前回、分散バージョン管理システムからGithubに至るフォーク概念の変遷を見てきました。後者は、書籍でいえばWikiを使う代わりにGitを使ったオープン出版のかたち、とでも呼べるもので、基本的に元のプロジェクトから派生することを許容しながらも、元のプロジェクトに対する改善をフィードバックすることが推奨されるモデルであることを見てきました。
       Githubでは、あるプロジェクトをフォークした人が本家に改善を提案する時、プル・リクエスト(pull request)を送ります。プル(pull)とは、リモートに登録された新規の差分ファイルを自身の作業環境にダウンロードして統合するというGitの基本的な機能を指します。プル・リクエストを送るということはつまり、「自分はこんな改善を行ってみたんだけど、もし有意義だと思ってくれるならぜひ本家に統合してくださいね」というコミュニケーションです(こういう柔らかい感じの時もあれば、「バグだらけで使えないから、修正したので早くプルしろください」的なニュアンスの場合もあります)。
       プル・リクエストはだから、ただの「こうしたら良いと思うけど、どう?」という字面の提案ではなく、実際にソースコードを改変したものを提案する、という実体を伴った提案であると言えます。この差異は非常に重要です。「言うは易し、行うは難し」ではないですが、意見やアイデアを伝えるだけではなく、実際に当事者になって手を動かしてみた提案の方が情報としても価値が高いからです。そしてフィードバックを受ける側からしても、相手が自分と同じ地平に立った上での提案、つまり、「専ら読み手」ではなく「書き手でもある読み手」からのフィードバックの方が協同作業であることを実感しやすく、ありがたみがあると思います。
       それでは「読むことが書くこと」となる文章を対象としたサービスを考える場合に、プル・リクエストの概念を導入してみるとどうでしょう。いくつかのケースが考えられると思いますが、いくつか順に書き出していきます。最初に思いつくものとしては、次のようなものです。

       ・校正のやりとりを支援する文書バージョン管理システム
       すでに存在している、最も専門的に「読むことが書くこと」につながっている作業形態は著者と編集者のあいだで行われる原稿の校正作業ではないでしょうか。特に一冊の本を校正していく場合には濃密なコミュニケーションが取り交わされます。
       僕は今後は校正作業のゲラは紙に印刷したものではなくGithubで行えれば良いのに、といつも思っています。なぜなら、紙に印刷したものは物理的に管理せねばならず、初校から第二校、第三校と続けるような場合には、各バージョンを行き来することだけでも大変です。(それと漢字をほとんど手書きできないという筆者のレベルの低さという別の理由もあるのですが…)
       ただし、Githubを校正用に使いこなすには、日々プラグラミングでGithubのお作法に慣れているなら人間ならまだしも、使い慣れていない場合の学習コストは非常に高いと思われます。それではより簡便に使い始められるWikiを、以前見てきたオープン出版の事例のように使うのが良いかというと、それも違うのではないかと思います。Wikiは元のバージョンを変更すると最新バージョンが上書きされてしまうので、当事者同士で同意が取れていない更新が行われてしまうと混乱の原因となります。なので、管理者による高度なモデレーションと参加者による高度なリテラシーの双方が求められます。このようにヒューマンエラーが発生しやすいアーキテクチャよりも、もともとヒューマンエラーが入り込みにくい設計を考える方が大事です。
       こう考えてみると、一般利用が可能なGithubやBitbucketなどのウェブ型分散バージョン管理サービスのAPIを利用して独自のインタフェースに基づいたサービス設計を行うのが良さそうです。また、Wikiの場合は不特定多数の人間が参加できることが前提の設計になっています。もちろんパスワードやログイン設定などで参加者を限定することは可能ですが、設計の思想背景として大人数の参加に耐えるという目的のもと進化してきたことからも、この著者と編集者をつなげるクローズドなサービスというのは独自の発展を遂げられる可能性があるように思います。

       と、ここまで独自の発想に沿って考えを膨らましてきましたが、実はPenflipという名前の「書き手のためのGithub」を標榜するウェブサービスがアメリカはロサンゼルスのエンジニアによって開発されていることをこの時点で発見してしまいました。とはいえ、このようなことはITの世界では日常茶飯事。同じように思えるアイデアでも、背景が違えば実現する価値も異なってくるものです。とはいえ無視するのももったいないので、次回はPenflipを実際に使ってみた上での考察を行ってみます。

      ※今回の原稿を書きながらの思いつきですが、実験的にこの記事をPenflipに上げてみたので、興味のある読者はPenflip上で筆者にプル・リクエストを送るなどして絡んで頂ければ嬉しいです。ツッコミを入れづらい文章だとは思いますが、ご批判ご指摘なんでもウェルカムです。
       ※ 今回書き始めたプロフェッショナルユースのGit型校正作業システムですが、万が一ご要望がありましたら筆者の経営する会社で協業させて頂くことも可能ですので、いつでもご連絡ください。