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

YCAM(山口情報芸術センター)のWebサイトリニューアル・プロジェクトでテキスト編集を担当しました

8月半ば、山口県の複合文化施設YCAM(ワイカム)/ 山口情報芸術センター」のWebサイトがリニューアルされました。

サイト全体に関わる完全リニューアルとしては2007年以来8年ぶり、一部をアップデートしたマイナー・リニューアルから数えても約4年ぶりの改修だそうです。

現在はPCブラウザから見た内容のリニューアルが完了したところですが、モバイル版のデザインも着々と進行中です。

今回のリニューアルでは、既存内容のアップデートの他、新規ページも大幅に追加されたのですが、その新規分を中心に、テキストをブラッシュアップするメンバーが必要ということで僕に声がかかり、テキストの編集・校正等を担当することになりました。

具体的な担当箇所は、以下のページ「YCAMについて(aboutus)」から下の階層で、

これらのページの役割は、「YCAMとはどんな場所なのか?」ということを伝えることです。

このブログでは、普段は僕のつたないプログラミングのコードやその過程で生じた気づきなどを書いているので、以下の内容はそれとはやや趣きが異なりますが、普段このブログで扱っている内容と重なる理念に基づく成果でもあるため、ここに記すことにしました。

本記事ではこの後もコードは一切出てきませんが、BitbucketやSlackなどのWebサービスを非エンジニア中心のプロジェクトで活用した具体的な事例、またその現場におけるプロジェクト・マネジメントに関わる話題は多めに出てきます。

目次

協業体制

今回のプロジェクトの中心メンバーは、以下の4名でした。

  • デザイナー&プロジェクトマネージャーの川角友太さん。(Alliance Port, LLC)
  • サイト構築担当のPierre-Henri Lavigneさん。(以下「ピーター」/同上)
  • YCAMのWebディレクターであり、僕らのクライアントでもある渡邉朋也さん。
  • フリーランスの編集者である私・門松宏明

制作を請け負うのは上記の川角さん&ピーターを擁するAlliance Port(アライアンス・ポート)です。

このうち、ピーターはもっぱら川角さんとコンビを組む態勢で、僕や渡邉さんとの連携は少なかったため、コアになるのは僕と渡邉さんと川角さんのトリオで、Slackにその3人用のチームを設置し、大半の連絡はSlack上のテキストチャットを通して行いました。

このチームはいわゆるリモートワークで成り立っていて、ピーターを含む4名全員が、千葉、東京、新潟、そして山口と、日本列島全体に散らばっての作業となりました。

興味深いのは、メンバー間のつながり方が微妙にアシンメトリーというか、川角さんと渡邉さんは比較的頻繁にGoogle Hangoutsを活用するのだけど、僕はHangoutsはNGで(作業環境の都合により)、またピーターと川角さんは専門的な技術に関して常時やり取りをしているけど、前述のとおり僕と渡邉さんはピーターとはほぼ連絡を取らない。そして僕は川角さんとは時々電話で話すけど、渡邉さんとは最初期の顔合わせで直接話した以外は、SlackやBitbucketのようなオンライン&テキストのみのやり取り。という、偏っているといえば偏っている、しかしそれぞれのメンバーが最も仕事をしやすい環境を維持しながらの協業でもありました。

使用ツール1: Slack, Hangouts, Bitbucket, Redmine

上記の通り、コアになる3名はSlackで連絡を取り合いました。slack.com

メールはピーターも含めて作業者間ではほぼ使用せず、その外側のメンバーを交える時にだけ稀に使用しました。
また上記の通り、僕と川角さんの間では時に電話を使用し、Alliance Portのメンバーと渡邉さんの間ではGoogle Hangoutsが使われました。www.google.com

その他、今回の作業でキーになったツールは、BitbucketとRedmineです。

Bitbucketはテキストの変更をGitの差分を通して煮詰めていく目的で、僕と渡邉さんを中心に使用開始しましたが、その後、Issue機能が画像掲示板のように使えることがわかり、これが僕ら3名の共同作業に大変有効だったため、プロジェクトの後半ではGit利用のためというより、Issueを利用するための場としてBitbucketが使われました。www.atlassian.com

Redmineはプロジェクトの前半では使用していませんでしたが、サイトの土台が完成した後の、いわゆる「QA(Quality Assurance)期間」において、BitbucketのIssueでは対応しきれないほど微細な、かつ膨大な課題をチケット管理するために採用され、活躍しました。

使用ツール2: Googleドライブ, Googleカレンダー

この他、今回の作業に欠かせなかったツールとして、Googleドライブ、Googleカレンダーがあります。

Googleドライブはプロジェクトの最初期から設置・活用され、中でもスプレッドシートは作業の進捗を可視化する用途で終始利用されました。

具体的には、ガントチャートとカレンダーを融合したような表を僕の方で2種類作成し、用途に応じてこれを組み合わせ、日々更新し、その時点でどの作業が遅れていて、どの作業が予定どおりに進んでいるのか、ということを明らかにしながら、その認識が三者間で常に一致するよう努めました。

※実際にどのような表を作ったのか、ということについては、また時間があれば示したいと思いますが、ここでは長くなりすぎるので割愛します。

Googleカレンダーは非常に初歩的な協業ツールですが、この機会にも最後まで地味に活躍してくれました。初めは各人の公開用カレンダーを共有し合うことも考えましたが、検討の末、本プロジェクト専用のカレンダーを新たに一つ設置し、これを共有する形にしました。

プロジェクト専用のカレンダーであるため、メンバーに知らせたい内容であれば公私を問わず気軽に入れておくことができ、後述するように、これを更新の都度Slackへ流れるよう設定することにより、自分以外のメンバーが今この瞬間に何をしているのか、ということをなるべく自然に(意識せずとも当然のこととして)、把握できているようにしました。

使用ツール3: Zapier

もう一つ、大変役立ってくれたツールはZapierです。zapier.com

日本ではあまり耳にしないサービスですが、様々なサービスを繋げることに特化したハブ的なサービスで、IFTTTを知っている人であれば、そのようなものだと言えばおおよそ分かってもらえると思います。
また最近では、Yahoo! Japanが同類のサービスを出していました

今回のプロジェクトでは、様々なWebサービスから受け取った情報を、Slackの連携機能を使ってどんどん各チャンネルへ流しました。

たとえば、BitbucketはSlackが公式に用意している連携機能を用いて、コミットメッセージがpushのたびに流れてくるよう設定しました。これにより、変更内容をわざわざSlackへ報告するまでもなく、誰が何をどう更新したのかわかるようになり、そのためのやり取りを行う必要がなくなりました。

一方、RedmineGoogleカレンダーは、Slackがサポートしている連携機能だけでは同様の通知ができなかったため、その点をZapierで補いました。

Redmineについては、Zapierを使わずにSlackへ流す方法もありますが、今回使用したRedmineにおいては、環境の制約上、Zapierが必要でした。対応方法としては、今回のために設置したRedmineプロジェクトのRSSを拾って、Zapierを経由してSlackへ流すようにしました。

上記で、ピーターと川角さんの専門的な内容のやり取りに僕と渡邉さんは加わらなかった、と書きましたが、それでもチームがきちんとワークしたのは、その技術的なやり取りの大半がRedmineのチケット上で行われ、ステイタスやコメントが更新されるたびに、Zapierを経由してSlackへすべて流れてきたからだと僕は考えています。

もし、エンジニアの二人が壁の向こうで何をやっているのかわからず、その作業が進んでいるのか遅れているのかを直感的に把握できない状況であったら、制作はそれなりに困難な事態に陥っていただろうと想像します。

また、Googleカレンダーはプロジェクトの終盤に入って、Slackが公式に連携をサポートするようになったので、もしプロジェクトの最中にこの機能があれば、Zapierを使用する必要はなかったのですが、今回はギリギリ間に合わなかったため、Zapierが不可欠な役割を果たしてくれました。

なぜ複数Webサービスを使用するのか

さて、このように複数のテクノロジーを駆使して業務を行う際には、「手段が目的化してはいけない」とよく言われます。とくに、そのテクノロジーが最近生み出された先進的な性格を持つ場合には、本来の目的を見失いがちにもなるかもしれません。
それでも尚、今回のように広範かつ比較的新しいWebツールを採用したのは、ひとえに「状況の見通しを良くするため」であり、上にも挙げたとおり「メンバーの認識を一致させるため」でした。

上記のうち、Googleドライブは当初から使われる予定であり、またRedmineは渡邉さんのニーズと、普段これを使用している川角さんからの提案により採用されましたが、それ以外のツールはすべて僕から使用を提案し、採用することに同意してもらいました。

とくに、SlackやBitbucketは今回の仕事を引き受ける際の「条件」とも言える重みがあり、さらには業務をメールベースではなく、チャットベースで進めることは必須の条件でもありました。

連絡をチャットベースにする利点は、投稿までのハードルがメールや電話に比べて低く、作業に取り掛かるための心的負担が軽いため、連絡事項の抜け漏れを最小限まで減らせる、という点にあります。
これは同時に、優先度の低い作業が目立ちやすくなることを意味するため、作業への集中を妨げる可能性もありますが、今回は制作期間がある程度限られていたため、「不充分な意思疎通による大きな手戻り」のような致命的な事故を発生させないためにも、小さく確実な成果を積み上げていきやすいこの方法は、目的に合致していたと思います。

また、以前にまとめた以下の事項にも注意を払いました。

メンバーの特性

様々なWebツールを駆使した今回のプロジェクトでしたが、成果を上げることができた一番の理由は、それらのツールが優れていたり、その選択が適切であったりしたこと以上に、使い手であるところの各メンバーが優秀であったことによると感じています。

今回のメンバーのうち、専門のプログラマーと言えるのはサイト構築を担当したピーターぐらいでしたが、デザイナーの川角さんも渡邉さんもコーディングのできる人で、また全員が普段からSlackを使用するなど、Webツールへの順応性も高かったため、僕からの各種ツール使用の提案に対しても「むしろその方がいい」と、前向きな姿勢で受け入れてもらうことができました。

象徴的なのは、今回使用したテキストの記法がすべてMarkdownで進められたことで、最初のミーティングの際にテキストデータの文章構造をどう伝え合うか、という話が出たとき、初めはGoogleドキュメントのWYSIWYG機能で整形しようとか、いやHTMLタグを打ってしまえばいいのでは、などの案もありましたが、どれもそれなりの手間と苦痛がかさむことが想像に難くなかったため、「本当はMarkdownが一番いいんですけどね」と、冗談めかして言ってみたら「え、普段それ使ってるので」「いや僕も」「あ、じゃあそれで」という具合にあっさり採択され、今から思えば、この時点で今回のプロジェクトの成功は約束されたようなものだったのかもしれません。

Bitbucketに関しても、元々はテキスト編集前後の差分を示しやすいことが使用の主目的であり、僕以外のメンバーはGitを使う必要はないという前提で提案しましたが、通常の業務ではとくにGitを使っていない渡邉さんの順応が思いのほか早く、途中からは渡邉さんもブラウザ経由でどんどんコミット&プッシュを行ってくれるようになり、またコミットメッセージも毎回わかりやすい適切な記述がなされたことにより、当初に思い描いていた以上の効果を発揮したと思います。

進行管理: スケジュール

今回、僕のメインの担当作業はテキストの編集でしたが、同時に進行管理・スケジュール管理のサポートも行いました。

これは僕のもう一つの仕事である『commmons: schola(コモンズ・スコラ)』というCDブックの制作における業務の中にそれがあり、「いつまでに何をしなければいけないか」、また「そのために必要なことは何か」ということを日々、失敗と改善を重ねながら考え、実践しているからで、おそらく今回のプロジェクトでもその経験を生かすことができるだろう、と思っていました。

上述のGoogleスプレッドシートで作成した進行管理表はその一つの表れであり、「自分たちはどこに向かっているのか」「今はその過程の中のどこにいるのか」という、いわば「現在地の確認」を、一日に何度も、しつこいぐらいに行いました。

進行管理: コミュニケーション

また、前述のとおり、僕らはたしかに恵まれすぎるほど恵まれたメンバーにより構成されていましたが、それでも不完全な人間同士であることからは逃れられないため、めいめいが好きに過ごしていれば良いということはありません。

とくに怖いのは、「言わなくてもわかってくれるだろう」とか、「自分はやるべきことをやったのだから、失敗したらそれは相手のせいだ」とかいう風に、不充分な働きかけで物事を済ませようとすることによって生じてしまうミスです。

「察し」や「空気読み」は、日本人の得意種目と言われがちですが、協業の場でこれを活用すれば、大半は浅薄な責任のなすりつけ合いに帰着すると思えますし、僕自身は常々、「言わなくてもわかってくれ」という態度は無責任な人間による失敗の言い訳に過ぎないと考えているので、プロジェクトの成功を目的とするかぎりは、どんなに当たり前のことでも可能なかぎり言語化・テキスト化して、それらの記録を通して意思を伝え合うように努めました。

時には、ややセンシティブな、口にするか迷うような否定的な意見を伝えざるを得ないこともありますが、もしそれを避ければ、後になってその数倍の負債が返ってくる可能性が残るため、伝えるべきことは率直に伝えながら、しかし目的は相手の気持を傷つけることではないこと、また結果的に傷つけてしまっても、それを上回る肯定的な関係を継続するよう心がけました。

結果的に、これはメンバーそれぞれが柔軟かつ逞しい自己を持っていたおかげだとも思いますが、我々はお互いの率直な意見にも耐えられるだけの信頼を、各人による専門的な作業の積み重ねとその成果を通して、厚くしていくことができたと思います。

まとめ

今回のプロジェクトを通して、チームが成功を収めるために必要なことは、お互いの顔色をうかがいながら、メンバーの意見をコントロールし合うことではなく、「共通の目標を見ること」だとあらためて感じました。

高い目標に向かう中、幾多のリスクを取りながら、深い信頼とともに最後まで走りきりつつあることを誇りに思いますし、このような先進的で、自由な空気に満ちた現場に関わることが出来て、幸運だったと感じています。

メインの作業者である川角さん、ピーター、渡邉さんに対してはもちろんのこと、その周りで業務を支えてくれた関係各位に心から感謝します。

また、今後このサイトを閲覧される皆さん、そしてYCAMを直接訪れるすべての方に、このような形で関われることを嬉しく思います。どうか楽しんでください。www.ycam.jp

補遺1

YCAMと言えば、坂本龍一さんとの関わりも深い施設ですが、今回僕に声がかかった直接的なきっかけは、僕がscholaで坂本さんと仕事をしているからではなく、2008年に大谷能生さん(批評家・音楽家)と出版した『大谷能生フランス革命』という本を、YCAMの渡邉さんが読んでいたこと、そしてまた、YCAMのWebサイト制作を数年来担当しているAlliance Portが同書のブックデザインを担当していたこと、またさらに、それ以前から僕がAlliance Port(の、とくに共同創業者である@yamatoさん)と懇意であったことなどが主な理由としてあり、偶然といえば偶然、必然といえば必然のような流れで今回の協業に至りました。www.amazon.co.jp

補遺2

今回担当したページのうち、どの部分にどのような苦労があったか、そしてそれをどのように乗り越えたか、といったことも記したかったのですが、だいぶ長くなってしまったので、それについてはまた機会のあるときに。
しかし何をおいても、YCAMインターラボのスタッフ紹介のページはどれも見応えがあるので、ここで優先的に推薦しておきます。美しく先鋭的な写真(by Gottingham)と、渡邉さんが各スタッフへのインタビューを通してまとめたユニークな文章の数々をぜひお楽しみください。(以下のページ下方、またはメニュー右側の「スタッフ紹介」をクリックするとスタッフ一覧まで移動します)