つい先日リニューアルされた弊社シナップのウェブサイト、いかがでしょうか？

リニューアルにはいくつもの理由がありました。先日このブログでエンジニアの池田も書いていたように、いまや古びてしまったデザインを払拭したい、というのももちろんですし、破綻していた構造を整理し直したいというのもまたもちろん。
けれどなにより、いまシナップが自分たちの使命と考えて積極的に取り組んでいることを、ぜんぜんまったくちっとも伝えられていないんじゃないか？　というのがいちばんでした。

ウェブサイト内で繰り返しお伝えしている三つの活動、「グロース研究（成長戦略研究）」「R&D（社内研究開発）」「Social Good（社会貢献活動）」、これが、いまシナップが自己紹介として誇りを持ってお伝えしたい三つの柱です。

これもまたつい先日のことですが、SINAP Journal という小冊子をつくりました。ウェブサイトの公開とはまた違った方法でシナップの現在をお伝えしたくて、いままさに郵送や手渡しでお配りしているところです。ここでもこの三本柱をご紹介しています。

今日は、そのうちの一柱である「R&D」にまつわるお話です。

「パン」

先月、「パン」というサービスをβ版としてリリースしました。公開時のニュースリリースのとおり、R&D 活動として社内にチームを新設して企画・開発した、実験的な取り組みです（ちなみに現在、二つの R&D チームが活動しています。詳細は、シナップの自社プロジェクトについて紹介した池田の記事をどうぞ：「シナップエンジニアのおしごと紹介します。【自社プロジェクト編】」）。

パンについていちばん短く説明をすると、「電子書籍公開サービス」です。長ったらしくいうと、「まとまったストーリーのあるコンテンツを独立して体験してもらうためのビューワと、その伝搬に役立つシェアの軸足を提供するサービス」となります。
たとえば本の試し読みや、あるいは本文全部、ほか、独立したコンテンツとして楽しんでもらいたい長い文章・漫画・一連のテーマに沿った写真などなどを公開したい・広めたいと思ったとき、その助けになれるサービスを目指しています。

ちなみに、ウェブページに EPUB 電子書籍を埋め込んで表示させられる「BiB/i（ビビ）」という変わり種の EPUB ビューワがありまして、これはいまこの記事を書いている松島が社外の個人活動でつくっているオープンソースのフリーソフトウェアなのですが、パンのビューワにはこのビビを使っています。

電子書籍の国際標準フォーマットである EPUB は、ウェブ技術をベースにすることで、高い表現力とコンピュータで扱えるデータならではのアクセシビリティの両立を目指している仕様です。とはいえまだまだ表現力に課題があったり、備わったポテンシャルを生かし切れていないのが実情。「EPUB を作るのは大変」「がんばって作っても読書体験が期待を超えない」という状況が何年も続いています。
たくさんの人が、それを夢でなくするために、地道な活動とあたらしい表現の模索をつづけています。ぼくとしてもそこに貢献したい思いがあって、ビビを作っているのです。EPUB でおもしろいことができるという提案を出発点に、作るコストのかけ甲斐のある分野として広めることで、相対的にも実質的にもコストが下がってゆく前提状況をつくりたいと思っています。

シナップとしても、ビビを使ったウェブサービスの企画・開発や、ビビの導入支援・カスタマイズに、今年から本格的に取り組むことにしました。パンの開発はその実例でもあり、また、自社プロジェクトに採用して機能向上をはかり、オープンソースにフィードバック・還元しようという試みでもあります。

今後大きな方向転換もありうるひよっこサービスではありますが、ぜひご期待ください。先ほどご紹介した SINAP Journal の EPUB 版も、パンで公開中です。
これはビビの機能なんですが、下のように、どこのウェブページにも埋め込むことができます（ちなみにこの SINAP Journal、近日中に、小さい画面でも読みやすい新バージョンに差し替え予定です）（各ページのクリック／タップで、スマートフォンなどでも読みやすいレイアウトを重ねて表示するようになりました！）。

SINAP Journal Summer 2015

さて、そんなパンがどんなスタイルで開発されているのか、あわせて少しご紹介します。

パン開発チームの運営

勉強熱心なシナップは、これまでにもさまざまな分野で社内研修や輪読をおこなってきました。ここしばらくは、「リーン」のメソッドをスタッフの標準知識・スキルとすべく、読み合わせと実践に励んでいます。

今回 R&D を本格的に始めるにあたっても、『リーン・スタートアップ』や『ランニング・リーン』を大いに参考にしています。世にある未解決の課題を自分たちがなんとかできないか。ただし想定したその課題は本当に解決されたがっているのか。解決するとして求められるのはどんな機能か。仮にチームがスタートアップ企業だったら？　新サービスを開発するにあたって、大切にすべき指標はなんだろう......。クライアントワークとはちがう切り口で考え、実験してみることで、クライアントワークにも役立つ知見が得られるのを実感してきたところです。

最近のパンチームは、とくにインタビューに力を入れています。
自分たちの想定した課題が、使ってほしいユーザにとっても本当に課題なのか。その課題を解決するために想定したサービスは、本当に解決になるのか。まずは実際に高品質な本をつくるプロである編集者さんにご意見を伺いたいと考えて、ここ数週間は沢山の方々にご協力いただき、お伺いしてインタビューしてきました。
実際にインタビューさせていただくと、自分たちの思い過ごしや勘違い・独りよがりにも気づかされ、また、自信を持って注力すべき部分もはっきりしてきます。実践することで知識が経験になる、というと標語じみていますが本当で、机上の空論を実際に確認する機会があると、たとえそこで気づいたのが「この想定は間違いだった。考えなおすべき」ということだったとしても、確かな学びを足場にして前に進むことができます。

もうひとつ、今回の記事を依頼されるきっかけになった取り組みがあります。

てづくりかんばん

シナップでは毎朝全員で社内の掃除をしているのですが、その後、パンチームの３人（エンジニアの池田、デザイナの久保田、そして松島）はみんなからも見えるスタンディングデスクに集まって、小さなミーティングをしています。そのときいつも屏風のように段ボール板を立ててそれを拝んでいるので、多少目立っていたのでしょう。「あれにからめてパンチームのことを書いてください」と頼まれたのでした。

この段ボール屏風はいわゆる「かんばん」というやつで、各人の中規模タスクを把握するために採用してみました。ひとくちにかんばんといっても、目的やプロジェクトの規模によって、管理するレベルにはいろいろな精度・粒度・深度があります。パンチームが採用したのは、もっともルールがゆるやかおおざっぱな部類のものです。

1. 資源ゴミとして重ねてあった段ボールを切ってボードを作ります。
2. そこに各人それぞれの色の付箋紙に自分のタスクを書いて貼り付けます。
3. 付箋紙を移動させることで「予定タスクのプール（バックログ）」「対応中のタスク」「完了したタスク」という三段階を表示しています。

R&D チームは二週間単位のサイクルで動くことにしているので、「この二週間の大目標はこれ。必達のタスクはこれ」というのも決めてあります。その大目標も、プリンタから抜いてきた A4 コピー用紙にサインペンで大書し、かんばんに貼り付けておきます。

そもそもは「自分が何をすべきなのか忘れる」「優先順位に混乱する」「誰の何の完了を待って自分が動くのか・誰の何を自分が待たせているのか、わからなくなる」......といったプロジェクト迷子の防止のために始めたものです。なお、できるかぎりチープなかんじでやろうという話になったのは、たとえば高機能なチケット管理システムできっちりやろうとするとスピードも落ちるし、せっかくの自主的なプロジェクトなのに業務感を強める可能性のある仕組みは取り入れたくなかったからです。ビビの開発者としていちおうチームリーダということになっているぼくとしても、自分以外のタスクも含めて俯瞰するのに重宝しています。

これもやってみるといろいろわかってくるもので、たとえば「どこまで細分化して付箋にするか基準が欲しい」「同じ大きさの付箋で並べるとタスクの重さの差がわかりづらい」となれば「１枚◯時間くらいのタスクということにしてみよう」「小さいタスクは半分に切ってみよう」と決めて、仕組み化をやり過ぎない程度に日々手を加えながら使っています。......こんなの、ことさら書くほどのことではないんですが、ただ、手作りのボードに手書きの紙を貼って動かして、というのは、タスクにアイコン以上の実体を与える感じもして、完了することにカタルシスがありますね。

毎朝このかんばんを前に10分くらい話したら、カンバンの写真を撮って締める、というのが朝の行事です。いつでも状況が表示されているダッシュボードを前に、こまごました事項を共有する場を、短いサイクルで持ち続ける。これは、パンチームのようなフラットで少人数な編成にとって、機動力の維持に好影響があるような気がしています。
ちなみに、初期はもう一枚ボードを用意してあり、そちらでは、曜日と午前午後のマス目に付箋を貼ることで「水曜日の午後は、パンに関連した作業を行う予定である」というのを共有していました。デザインから実装へ、といったパスを組み立てやすいかと考えたのですが、メンバーはいずれもパン専任ではなく、クライアントワークを優先すると R&D の予定を精密に立てるのは無理だとわかったので、こちらのボードは使うのをやめてしまいました。

社内では最近、他のプロジェクトでも短サイクル・短時間のスタンドアップミーティングを採用することが増えてきました。プロジェクトごとに工夫されていて「なるほど」と思うこともあるので、参考にしあっていければいいなと思います。『ランニング・リーン』にもかんばんを採用する例があって、そこではもっとマイルストーンが細分化されていました。プロジェクトの規模や段階、メンバの構成などにあわせ、調整して採用するのがよさそうです。段ボールを切って手書きでやるのが、個人的にはおすすめですよ！

今回はこんなところで失礼します。パンを始めシナップのあたらしい取り組みや、震災からずっとつづけている支援活動など、今後もどうかご注目をお願いいたします。