Web制作会社の危機感から模索する新しいプロジェクト管理の方法とは〜独自のプロジェクト開発スタイル

Web制作会社H2O spaceを率いる谷口允(たにぐちまこと)さん。「Web制作現場は、いま大きな変革期にさしかかってきている」と。Webサイトは、企業にとって「おまけ」にすぎなくなってきたので、クライアント自身がいかに楽に更新や作成できるようにするかが、これからの制作会社にとっての価値なのではないか。そのためのお手伝いができるようになりたい、と熱く語られます。WordPressやkintoneそしてWIXと、自分でWebサイトやアプリを作れる便利なツールも複数生まれており、Web制作会社の次のステージを模索する動きも少なくありません。その実践者として、たにぐちさんが取り組まれているさまざまな知恵のカタチを開陳していただきました。

たにぐちさん プロフィール

「ちゃんとWeb」をコーポレートテーマに、「ちゃんと」作ることを目指したWeb制作会社H2O space(エイチツーオー・スペース)の代表取締役。
WordPressを利用したサイト制作や、スマートデバイス向けサイトの制作、PHPやJavaScriptによる開発を得意とする。また、CSS Niteや Word Campでの講演や著書などを通じ、クリエイターの育成にも力を入れている。主な著書に『動画で学ぶWordPressの学校』(KADOKAWA刊)、『よくわかるPHPの教科書』(マイナビ刊)など。kintoneエバンジェリストとしての顔も持つ。

Web:https://h2o-space.com/

開発スタイルを振り返るという視点でキャリアを伝えると

大井田:

本日はよろしくお願い致します。まずは開発スタイルを振り返るという視点でご経歴をお話いただけますか?

たにぐち:

学生時代はゲームクリエイターを目指していました。けれどもゲーム開発会社への就職はうまくいかず、システム開発会社に入社。具体的には富士ゼロックス常駐案件で大規模なウォーターフォール型の開発を経験しています。その後、インターネットプロバイダーのSo-netに転職しました。そこでは、メールマーケティング関連の開発を任されました。主担当一人とデザイナー一人みたいな小規模開発で、いまで言うアジャイルに近い感覚ではありましたね。そのころは、「アジャイル開発」という言葉もあまり知られてはいませんでしたし、ただ「このプロジェクトではウォーターフォールの方法は使えないな」くらいの感覚でした。だから、自ずと自分たちなりに工夫をして開発を進めていくことになりましたね。独立前にはC++やPerl、ASPのスキルを蓄えることになりましたが、独立後はPHPを中心に受託開発を行なっています。それも、「こうあるべき」というカタチがあったわけではなく、受託いただく企業のルールに従ったり、「もっといい方法がないかな」と試行錯誤しながら自分たちのスタイルを決めていくという感じです。いまに至るまでそこは変わっていないですね。

大井田:

独立されたのは、お若いですよね?

たにぐち:

24歳で独立しました。いまもWebサイト制作の仕事が全体の9割です。WordPressを使ったWeb制作会社として、主に大学や中小企業のWebサイト開発・更新などで慌ただしく過ごさせていただいています。制作と並行して、クリエイターの教育にも力を入れており、講演や著作など手がけてきました。数年前からWebサイト構築の仕事の潮目が変わっていくのがまざまざと見せつけられるように進んでいくのをきっかけに、もう1つの事業軸としてシステム開発に取り組みその一つの答えとしてkintoneを選択しました。WordPressとkintoneのあわせ技で、中小企業にとってのベストな解を導き出せるようにと積極的に取り組んでいます。

そして、現在の「プロジェクト管理」体制は

大井田:

kintoneのお話もたっぷりお聞きしたいところですが、今日の目的は「プロジェクト管理」でもあるので、まずはそのお話をと思います。

たにぐち:

当社の場合ですと、主役になるのはBacklogになります。これ、もうそろそろ10年くらい使い続けていることになります。Backlogを基幹に、GitHubやチャットツールと組み合せて管理をしています。ただ、チャットのやり取りなどは、コピペで転記していますから運用はなんとアナログ(!)で済ませています。Backlogを使い続けているのですが、実は何度も他のツールを試しています。浮気をするのだけど、結局戻っちゃう。

大井田:

Backlogの使いやすさってどんなところですか?

たにぐち:

ぼくの場合は、もうこれに慣れちゃってるというところが一番なのかもしれないです。コミュニケーションの部分はSlackに劣るし、ソース管理はGitHubにはかなわない、だからそもそも足し算をする前提でツールを選ぶとするなら、慣れているBacklogでいいか、となっちゃいます。これらを一括でまかなえるツールがあるといいのに、とはよく思うんですよ。もちろん、もっといい方法があるのじゃないか、とも考えますし。いまの自分たちの方法がベストだなんて思っていないですしね。

大井田:

いま、ぱっと浮かぶ「こうできたらいいのに」ってどんなことですか?

たにぐち:

Backlogはスレッド型のツールですから、以前よく比較検討したのはTrelloに代表されるかんばん型のツールとのインターフェイスの違い。インターフェイスの、と言いますが、要はプロジェクトをどう管理・運用するかという方法論の違いであるとも言える。Backlogの場合だと、タスクの整理や分類にどうしても使いづらさやわかりにくさが目立つなと感じます。期限を過ぎて、アラートが出ててもそれを無視し続けることになっていく、なんのためかわからないアラートって、Backlogのあるあるじゃないかな。

大井田:

それは、PMやPMOの管理能力にプロジェクトの成功がかかっているよ、というお話ですよね

たにぐち:

そうですね、まさに。当社でも、自分を含め2名のディレクターがBacklogの「そうじ」をきめ細かく行なうことでその解決を図るようにしています。ツールによる自動化とはまだまだ距離がある話です。もちろん、タスク登録のルールや管理上の約束事は決めていますし、新規タスク登録もそれぞれの担当者に任せられるようにしていますが、ディレクターが管理してないと、ツールだけではうまく回っていかないことは何度も実証済みですね。うまく回らないということは、そもそもツールを使う意味が無いという逆転現象も発生します。

大井田:

スタッフさんはリモートが中心だと伺っています。ミーティングなどはどうされていますか?

たにぐち:

定期的に、週次で行なったりということはしていないですが、プロジェクトごとに、マイルストーンごとにとか随時ネットミーティングを開催しています。外部のクリエーターさんとのコミュニケーションには、気をつけています。社内でやるべきところは社内だけで済ませられるように。

大井田:

Backlogだと、バーンダウンチャートの表現がきれいなのが気になるわけですが、活用できていますか?

たにぐち:

ああ(笑)、一時期使おうとしたことがあるのですが、調整ができないと使えないので。いまはまったく使っていません。どうしてもチャートで確認したいときは、むしろスプレッドシートに転載して、そちらで表示させて確認するなんてこともしてますね。ガントチャート機能だけだと、MSプロジェクトを試したこともありました。いろいろ試したい性格なんですよ。

「プロジェクト管理ツール」に関する記事はこちら

Backlogを使うにあたっての小さいけれど効果抜群の独自ルール

大井田:

では、ここからは、具体的に工夫なさっているポイントを紹介いただけますか?

たにぐち:

Backlogへのプロジェクトを登録する際には、「クライアントさんが参加するもの」「クライアントさんが参加されないもの」の2つを登録します。クライアントさんのリクエストに対して、ディレクターがそのリクエストを「参加されていない」スレッドにコピーして転載するなんてプロセスを加えています。この目的は、実作業するクリエイターとクライアントさんとの齟齬を回避すること。
もう一つは、各プロジェクトに「連絡板」というタスクを必ず加えるようにしていること。クライアントさんに適切な課題に書き込んでもらったりを強制するのが難しいと解ったので、とりあえず「連絡板」に何でも書いてもらえたら、ディレクターが適切に処理しますよと言う仕組みです。クライアントさんのリクエストはわかりやすくなるし、この方法でプロジェクトの停滞を防ぐことになりました。

大井田:

シンプルな考え方ですけど、さすがな工夫ですね

たにぐち:

また、ウチではBacklogのドキュメント機能はあまり使いません。Google ドライブで代替しているので参照先を記述していく方法にしていますね。
さらに、kintoneももちろん使っているので、各プロジェクトを登録する際にkintone側でも同様な登録をします。kintoneでは原価計算をできるようにしています。
だから、無くてはならないものを挙げると、Backlog、kintone、Messengerということになります。
余談ですけれども、チャットワークはあまり積極的に使わないたちでして。Slackも同様です。ぼくの場合は、Gmailなどメールがまだまだ重要なんです。

大井田:

たにぐちさんのところだと、プロジェクトメンバーは最大で何人規模にまでになるのですか?

たにぐち:

案件として、200万円くらいまでものをという志向もあるので、20人規模というものは手掛けないですし、ディレクター、デザイナー、エディター、コーダーなどで4、5人が当社の標準的なプロジェクト規模です。

Web制作会社としての社会的な価値発揮を考え続けること

大井田:

開発スタイルとしての完成形ってどんな展望ですか

たにぐち:

Web制作会社としての社会的な価値発揮ということを考え続けています。実際に、優秀なフリーランスさんが減ってきたという感覚もありますし、Web制作会社としての仕事の領域も変わっていかなくてはならないだろうと思うのです。だから、開発のスタイルそのものももっと変わっていいのだろうなと。
クライアントさん自らがどんどん自分たちでできるようになっていって、その良きアドバイザーになることができないかという考えがあります。

というのも、もともとkintoneに魅力を感じたのもそうした思考からです。kintoneはただのデータベース。カスタマイズの自由さがとても面白い。もともと当社では個人情報を扱うような開発案件はお断りする傾向にあったのですが、kintoneに取り組むようになったことで、kintoneに格納するのであればセキュリティ面でも安心できるので案件としてご提案できるようにもなりました。

いま、WIXの研究をしているんですよ。このツールで、クライアントさん自身がデザインとインターフェイスを自ら完成に導けるのではないかと思っています。これにkintoneを組み合わせて、データを扱えるように提案したいですね。

取材を終えて

取材の過程で驚いたのは、たにぐちさんは非常にたくさんのツールの経験者だということでした。プロジェクト管理についても、記事では紹介していないですが、asanaとかJIRAとかの名前もあがりました。kintoneに進まれる際にも、セールスフォースやファイルメーカーと比較検討されたそうです。

「Web制作会社として働くのは、もうぎりぎり」という言葉も飛び出しましたが、既に新しい方向性に進み始めておられます。谷口さんのアイデア満載の開発スタイルは、同じ制作パーソンには勇気を与えるものになるのではないかと思います。今回は必ずしもスクラム開発そのものではありませんが、Web開発プロジェクトに悩む方々のなかには、たにぐちさんに似た携わり方をされている人たちも多いのではないでしょうか。

TeamHackersでは、これから数回にわたってスクラム開発事例を個社インタビューを通してご紹介していきます。引き続き、ご購読をよろしくお願いいたします。

事例に学ぶ

愚者は経験に学び、賢者は歴史に学ぶと言います。ビジネスについても同じことが言えるでしょう。
他の企業の戦略や取り組みを分析し、そこから抽出した要素を組織に取り入れてみることで、あなたのビジネスを成功に導く鍵が見つかるかもしれません。

詳細を確認する

この記事が気に入ったら
いいね!しよう

最新情報をお届けします

同じタグのついた記事

同じカテゴリの記事