サービシンク名村さんにプロジェクト管理道を訊く〜不動産業界特化型ディレクターとして全国区に活躍中!

不動産業界に特化したWeb開発会社であるサービシンクの名村さんをお訪ねしました。
「サービシンク」という社名は「サービスを考えぬく=Service+Think」だそうです。
不動産業界は、そもそも広告費用が大きく、広告なくしては成立しない業界である一方、不動産業法や業界慣習・文化、専門用語をきちんと理解できていなければ成果を生むWebサイトは作れないのだ、と戦略的に業界特化型となった背景を説明されています。その一方で「不動産業界の不透明さをどうにかしたい」と語られるのです。この言葉に象徴されるように熱い言葉があふれるインタビューになりました。


名村さんプロフィール

大学2年生の96年からWeb制作集団ネイムヴィレッジ(この名前は「名村」をそのまま英語化したもの)を主催。
大学卒業までに100社ほどのサイト制作の企画、ディレクション、デザイン、Perl開発、マークアップに携わる。同時に学生時代から俳優・声優になるために養成所にも通うが、大学卒業を機に俳優修業を本格的に開始するため上京をする。

2000年からは、俳優修業の傍らで不動産検索サイトHOME’Sを運営している株式会社ライフル(旧ネクスト)に合流。
同時期にプロの声優としても活動していたが「30歳までに声優として喰えなかったら諦める」という父親との約束があり、自分の才能に見切りをつけ廃業。
05年からは他の制作会社に合流し取締役などを歴任し、不動産業界のサイト制作のディレクションからフロント実装を担当する。
10年1月12日、ネイムヴィレッジを法人化した株式会社サービシンクを立ち上げ、代表取締役に就任。不動産業界に特化したサイト制作のプロデュース、ディレクションに取り組み、現在に至る。
著書:
『Webブランディングの入門教科書』『変革期のウェブ』(ともに毎日コミュニケーションズ刊)

サービシンクのプロジェクト開発体制は

大井田:

今回のインタビューは、実は以前インタビューさせていただいた谷口さんからのご縁で実現しました。つくづく、仕事というのは人のつながりだなと感じる次第です。早速ですが、御社のやられているプロジェクトのご紹介をいただけますか? 不動産のWebサイト、Webシステムと言っても実に多様なものが存在すると思います。

名村:

おかげさまで会社設立以来ずっと順調に事業成長していまして、創業直後からお付き合いさせていただいているデベロッパー様などはもう8年のおつきあいになります。プロジェクトとしても、インフラからアプリケーションの開発、さらに都度都度いただく保守メンテのような案件も含めて、現在では2チームに分けて動かしているというものがあります。年間で数千万もの規模になるプロジェクトになっていますよ。チームを分けたというのは、異なるWebサイトが2つというご理解で大丈夫です。そのチームは、ちょうど5人ずつに分かれていますね。
ちなみに、現在の社内体制としては、ディレクターが6人、デザイナーが2人、マークアップエンジニアが2人、エンジニアが6人、その他6、7人ですね。このメンバーで、担当プロジェクトをそれぞれアサインして動いています。

開発手法ということで考えると、このデベロッパー様のプロジェクトはウォータフォール型になることもあるし、なんとなくアジャイルになることもあるという曖昧な感じでもあります。この案件もそうですが、プロジェクトそのものは言わば延々と続いていくものでもあります。数時間で終わるような1タスクが終わってもさらに新しいタスクが待っていて、常に複数のタスクが存在してる。ただ、全体としては、ウォータフォール型のプロジェクトになっているのが現実かなとは、業界的にも感じていますね。
そこは、特に最近悩みながら進んでいるところでもあり、今回のお話は私にとっても勉強になるかなと思いました。

大井田:

その悩まれるというか考えられているポイントは、どういうものなんでしょうか

名村:

一番大事にしているのは、制作側の都合でお客さまのビジネス速度を止めないことです。お客さまと我々との密な連携のもとで進めないと危ないものについてはきちんと仕様書も作成して進めます。ですが、お客さま側の一担当者だけしか使わないものなどは、ミスがあっては困るものの速度優先でどんどんやっていくと、クライアントにも社内でも共有されています。
機能改修のようなものの頻度も多いのですよ。

大井田:

その業務の流れってどのようなものなんですか? 概ね想像もできそうですが

名村:

要件そのものの打ち合わせができたら、ワイヤーフレームを作成して、要件定義(仕様書)を確定させて、モックが必要な場合はモックも作って、その後HTML化するというごくごく一般的な流れですね。

大井田:

そのクライアントさんとの窓口はディレクターの方がされるわけですよね? その際にチケットを切っていくようなツール、あるいはクライアントさんとの情報共有ツールはどんなツールを使っていますか?

名村:

そこは完全に使い分けをしています。社内では、Redmineの一択。実は、過去にはRedmineだけではなくTrackを使っていたこともありましたが、いまは使っていません。一方、クライアントさんとの共有は、Backlogにしています。エンジニア仕様のRedmineだとクライアントさんにとっては使いにくいものでしかないので、どうしてもBacklogを選択することになります。したがって、ディレクターは、同じタスクをその2ツールに登録をしたり、ステイタスを変えたりしなきゃいけない状態になっているのは悩ましい。わかってるんですけど、これはもうずっとそのままになっています。

新しいプロジェクト管理ツールが登場してくると、もちろん興味もあるのですが、例えばRedmineからの移行ツールなどがないと切り替えはできないのですね。先にお話したデベロッパー様の案件などは8年分の経緯がそこに蓄積されていて社内資産にもなっていますから、ここは大事なポイントなんです。
ただし、私自身ずっとディレクターをやっているので、不便なことを不便のまま慣れていくということは認めたくないことでもあります。以前Trackを使っていた時、クライアント用にBacklogに同様のものを記述しなきゃいけない。ただ、両者のwiki記法が異なっている、その書き換えが面倒でTrackのチケットの内容をBacklog用に変換できるブックマークレットを自作していました。そういう仕組みづくりはそもそも好きなんですよ。

大井田:

ブックマークレットとは、少し懐かしい響きですが、、、やはりアイデアマンなんですね。

プロジェクト管理と呼ばれるものについて思うこと

大井田:

他のツールや、他にこんな取り組みをしたなどという事例はありますか

名村:

弊社は今年新しいサービスを始める計画なのですが、そのプロジェクトではTrelloを使い始めました。あるベンダーさんとの提携プロジェクトでもあるので、そのベンダーさんからのご提案で使うことになった次第です。社内のディレクターからも「一度使ってみたかった」という声もあがり、ちょうどよかったかな、なんて思っています。
また、あるマネージャーには「かんばん」手法を試してもらいました。ホワイトボードも設置して試しましたが、彼のキャラクターに合ってなかったので頓挫しました。これでわかったのは、手法そのものじゃなくて、プロジェクトは人と人なんだという実感でした。うまくいってほしかったんですけどね。結果、これも宿題です。

Redmineについても、社内的には特殊なプラグインを加えていたり、運用に特別な工夫をしたりということはあえて避けることにしています。と言うのも、お伝えした通り、

  • 長期プロジェクトが多い
  • タスク(チケット)にイレギュラーが多い


などが当たり前となっているので、変則的な進行が常体化していて特殊仕様がすぐに陳腐化して使えなくなります。ここは、まさに業界的な課題というか事情なのかもしれません。

ということは逆に、プロジェクト管理ツールを活用して、プロジェクトをうまく回すためのコツというのは、この業界的にも重要なスキルになってくるかもしれませんよね。

大井田:

そのために、何か考えておられることもあるのでしょうか

名村:

社内リソースをプロジェクト管理のカスタマイズのために割くということは、いまの段階では考えられなくて、ただ今後社内の規模の拡大に備えておくためにはそろそろ本格的に動き始めなきゃな、とはずっと思っています。
理想としては、コミュニケーションツールとしてのSlack、管理機能本体のRedmine、ソース管理・デプロイ管理のGitあるいはGitLabを一つのツールで集約できること。いまはデプロイが済んだ段階で、Slack上で「完了」報告し、Redmineのステイタスを「完了」に変更し、という手順で、デプロイに至るまでのフローも追いかけるのが面倒になっています。これが、一つのツールで完結できるようになればまさに理想的です。

いまは、一つのチケットを完了するのはディレクターしかできませんが、デプロイの連絡はクライアントさんと共有するBacklogからしか行なわれないというようなフローであったりします。かつ、Backlogのタスク終了はクライアントさん権限だったり。
ここがキレイにまとまったら言うことないですね。
ビジネス的にも、Backlogのタスク完了していること=納品でもありますから、おいそれとは手を付けられないという事情です。

大井田:

その理想像が見えてくるまでのプロセスって

名村:

スケジュール管理とタスク管理だけで考えたほうがわかりやすかったな、という実感はありますよね。コミュニケーションツールやマイルストーンを考えるところから悩みが始まったみたいな

大井田:

そういえば、Web制作会社さんだとExcelでスケジュールを一元管理してます、みたいなお話も多いのですが、御社もそういう時期がありましたか

名村:

Excelでガントチャートをひくマクロは自分で書いて使ってたことがありましたが、それで一元管理をするということはしてこなかったですね。創業当時だと、OmniPlanを使ってたことはありました。でも、その当時からBackLogは出てきていましたから使い始めていましたよ。それ考えると、やはり長い、、、
10人規模になると、Excelでの管理は無理があります。2、3人で数ヶ月のプロジェクトなら、そっちのほうが楽かとは思いますけど。それでも、クライアントはいまでもExcelが好きですよね。実際に、よく言われますよ。

結局は「働き方」や「社内カルチャー」について悩むことなんじゃないか

大井田:

リモートメンバーがいないのですよね?

名村:

個人情報の扱いも含んでいますので、基本的にリモートでの作業は考えられないです。社内メンバーからもリモート勤務の要望はないです。また、私個人の考えとしても、まだリモートワークの環境準備できていないと感じています。
評価がとても難しいですよね。みなさん、どうしてるんだろうと思っています。

大井田:

弊社にも北海道で働くリモート社員がいます。彼の場合は、毎日の定期的なリモートMtgや四半期ごとに東京に来てもらってコミュニケーションをするように心掛けています。具体的に彼の専任プロジェクトというものも存在しますが、プロジェクトの成果物だけで評価するということにはしていません。

名村:

「納期、間に合いませんでした」ということが一番心配なんですよ。恥ずかしい話ですが、弊社で過去に実際にあったので。コミュニケーションを取っていても結果としてそういうことでは評価できないな、と。「頑張ってます」ということでは評価できないと言いますか。
なので「その責任を誰が負うのか?」ということを徹底して社員にインプットしています。

大井田:

つまり、そこはツールに任せるのではなく上司たるものがきちんと見るべきだということですか? なにか、アラートを発信させる工夫などはあります?

名村:

属人化してると言っていいでしょうね。いまのところは、それが弊社のカルチャーでもあるかもしれません。

大井田:

少し戻りますが、工数管理はRedmineでされているということですか

名村:

その通りです。これも、そもそも工数=作業時間でこれが積み上がっていくことで見積金額、請求金額も変わってしまいますから、きっちり時間計算もしています。
仮に、3日=24時間で見積もりしていたものが、「残業含めてなんとか3日で終わりました」という報告が上がって来た場合、結果的には、24時間ではなく30時間だったという結果を受けて、その作業の振り返りはきっちり詰めておくようにしています。なぜ、24時間で終わらなかったのか、と。30時間は3日じゃないよ、と。原因がクライアント側の指示なのか、エンジニア自身の見積もりなのかの原因がはっきりしておかないと、次の改善ができないので、そこは大事にしています。

それで、さっきの責任ということなのですが、会社のカルチャーとしては「上意下達」で徹底していると思っています。これは「責任」と「指揮命令系統」の話で、責任所在をはっきりさせたい、ということです。たとえば何かのプログラムが意図通りにできていなかった。この場合、指示が明確じゃなかったのか、プログラムの作りが間違えていたのか。指示が不明確だった場合、当然部下には一切責任を押し付けないこと。「部下の当初の設計に対して上司がアドバイスの元、部下が修正をしていた結果、実は間違えていた」といった場合、「まぁ・・・どっちにも責任があるよね」みたいになりますが、これをするのが一番良くないことと考えているからです。この場合100%上司の責任ですから。

ディレクターの指示が明確じゃなかったらディレクターの責任、あるいは進捗管理がうまくできなかったPMである私の責任。部下には一切責任を押し付けないこと。
もう一言加えておくと、モチベーションは会社が与えるものでなくて自分自身が作るものだ、という伝え方をしています。これも会社のカルチャーとして重要なところだと思っています。

大井田:

少し「働き方」とか勤怠制度のところにも突っ込んでしまいますが、というのも「プロジェクト管理」というのは直線的にどうしてもそういうところにつながっていくものでもあります。

名村:

はい、先ほども「上意下達」なんて言葉を使いましたが、始業時間も朝は9時半から絶対で、遅刻は厳禁です。ルーズさとは無縁なカルチャーになっていますね。出勤と退勤時のあいさつをはっきり言う、というのも社内ルールとしては厳しく決めてます。あいさつについては、中途入社してきたエンジニアが「この会社はみんながきちんとあいさつを返してくれるのでうれしい」なんて入社1ヶ月後の感想を伝えてきたときには、驚きましたね。そんなものかなって、、、彼はもともと転職の理由が「前職では、会社の人があいさつをしても一切返してくれない」というものだったので。

大井田:

御社は今後社員を増やされる計画なのですよね

名村:

2020年までには社員50名体制にすることを決めています。今年も10名の新卒採用を計画しているので、いまは人事がピリピリしていますよ。
こちらはまさに、人事の問題で教育をどうしようかという話ですね。私自身も多くの機会でセミナー講師をさせていただいており、いろいろなことをお話させていただいておりますので、外部で話したセミナーを社内でもおこなう機会を設けています。

単純に、働きがいのある会社にしたいと強く思っていまして、社内制度としては充分誇れる体制ができていると自負しています。毎月の残業は平均で22時間くらい/人になっていますが、自社の責任における納品遅延などは一切ありません。
さきほどもモチベーションづくりは会社ではなくて個人による、と言っていますが、会社とは装置なので個人は会社を利用すればいい。その時、一個人、人それぞれの価値がなんなのかを追求して欲しい。それが会社の底上げにもなりますからね。時代が厳しい方にどんどん進むので、若い社員にはそういう意識を持って成長していって欲しいのです。私からはそのための種まきはしていると思ってます。
ただ、今後さらに社員が増えていく過程で、いまの弊社のカルチャーも変わるべきところもあるだろうと思いますし、それはそれで楽しみなんですよね。

大井田:

弊社は、約10名の会社ですが、やはり規模の拡大は考えていますので、追いかけていきたいです。
今日はどうもありがとうございました。

取材を終えて

実は、今回のサービシンクさんは同じビルに同居する者同士。
とはいえ、いままで交流はありませんでした。取り持っていただいたのは、本企画にご協力いただいた谷口さん。

不動産業界特化の制作会社、とお聞きして最初に想像したのは、おそらく多くの人にも一番想像できそうな不動産仲介の営業さんたちの印象。ビシっとスーツを決めて、みたいな。かつ、それなりに年季も入っている方だから貫禄も、、、という想像のもとにお会いすることになりましたが、写真の通りの出で立ちでした。

でも、その言葉は熱かったです。改めて確信することができたのは、「プロジェクト管理ツール」の機能の一つひとつが会社のカルチャーや各種制度と地続きにあるということでした。
名村さん、ありがとうございました。ご紹介いただいた、谷口さんにも改めて感謝申し上げます。

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

最新情報をチェックしよう!
>TeamHackで、タスク管理を驚くほどラクに。

TeamHackで、タスク管理を驚くほどラクに。

TeamHackは、タスク管理とチャットが同時にできる「業務コミュニケーションのしやすさ」に特化したオンラインワークスペースです。コミュニケーションツールとタスク管理ツールを行ったり来たりして、二重に管理の手間がかかる問題をスッキリ解決します。

CTR IMG