この記事では、ウェブメディアづくりにおけるエンジニアの仕事実例をご紹介。非技術者とともにメディアをつくりあげていく中で、アイデアや企画をどうシステム要件に落としていったのか。プロジェクト概要とともにそのおもしろさの一端が伝わればうれしいです。
実例として取り上げるプロジェクトは、a-worksがことし3月にリリースした新メディア「TAL（Things And Life）」。
さまざまな人の「実際に使っているモノ」を紹介し、メディアと読み手が価値観を共有したい、とのコンセプトでスタートしたウェブメディアです。
どんな経緯で「TAL」の企画ができたのか、詳しくはアイデアを形に！ゼロからメディアをつくる方法【企画編】で紹介していますが、今回はその【実装編】をお届けします。
【企画編より、TALリリース前半までのあらすじ】
部署会議で新しいウェブメディアを作ることが決定（2020年2月）→コンセプトをブラッシュアップし、デザインやメディアの方向性が決定（2〜7月）→グッドタイミングでエンジニアのフラポさんが外部パートナー（業務委託）としてジョイン、企画の実装に向け走り出す（8月〜）
対談メンバーは以下の4名。
- エンジニア（外部パートナー）のフラポさん
- プロジェクトリーダーのコヤナギさん
- デザイナー兼、開発との橋渡し役を担当したナナさん
- 元エンジニアの部長、モモさん
クリエイターからの「こんなメディアが作りたい！」の声を受けたエンジニアは、実際にどのように開発へと落としこんでいくのか？
まずは、TALリリースまでのプロセスを例に、その仕事内容を時系列に見ていきましょう。
■ 企画内容を把握し、実装に向けスタート
■ 動き出す前のすり合わせが超大事
■ 企画チームと開発会社の仲介役として
■ 企画を叶えるためのデータ構築。リリース後の運用も考えた提案を
■ 技術も大事だけど想像力も必要
■ プロジェクト全体にかかわるおもしろさ
企画内容を把握し、実装に向けスタート
ーーフラポさんはTALリリースのためにa-worksにジョインしたわけではないんですよね。
フラポ：タイミングとしてはたまたまですね。a-worksとは別の案件でつながりがあったんですけど、野山社長から外部ブレーンを探していると聞いて、おもしろい会社だから何か手伝えたらいいなと思って手を上げました。
【補足メモ】a-worksにおける業務委託メンバーの関わり方
フラポさんは、正社員ではなく業務委託メンバーとしてa-worksにジョインしてくれました。MMG（メディアマーケティンググループ。クリエイティブやメディア事業を担当する部署）では、所属する13人のうち、約半数が業務委託メンバー。それぞれ特技を持つプロフェッショナルとしてa-worksを支えてくれています。 一般的に「業務委託」というと、決められた範囲・要件の仕事をこなすことが多いようですが、a-worksでは、総会や合宿に参加したり、事業について対等に話し合ったりと、正社員と同じ目線で働いています。（そんな社風が好きだと言ってくれる方たちだから実現できています。感謝！）
モモ：まさに渡りに船のタイミングでしたね。ラッキーでした（笑）
ーーTALのコンセプトや方向性などの共有はスムーズでしたか？
ナナ：同時期にジョインしてくれたパートナーのライターさんたちと一緒にキックオフミーティングを開いて、これまでの経緯やコンセプトを共有させていただいたんですよね。
フラポ：すでにデザインのプロトタイプができていたので驚きました。ふだんは、企画だけがあってあとはヒアリングを重ねて想像力を働かせながらカタチにしていくケースが少なくないので。コンセプトを聞いてすぐに、おもしろそうな企画だと思いましたね。
コヤナギ：僕はプロジェクト全体を管理する立場なのですが、企画や記事制作に注力する必要があったので、開発のほうはフラポさんとナナちゃんに一任することにしました。あのタイミングでフラポさんが来てくれていなかったら、TALはまだできてなかったかもしれないですね…。
ーー企画内容を把握したのち、実装に向けてどのように進めていったんでしょうか。
フラポ：開発についてはなにも決まっていない状態でしたので、まずは要件を決める必要がありました。コヤナギさんからは、はじめはウェブメディアとしてスタートし、ゆくゆくはSNS化させたいという希望があったので、まずはその点について話し合いました。というのも、SNS化を見据えて構築するかどうかで、工数も金額もまったく変わってきてしまうんですね。また、SNS化を前提とするならば、会員限定機能の内容や想定している会員数などもインフラ面やDB設計に織り込んでおかなければいけません。
そうした背景もあり、オープンソースや外部のサービスを含めて、どんな方法での構築が適切なのかを検証することからスタートしました。SNSとして利用できるCMSを試したりもしてみましたが、今後の運用面なども考え、最終的にはWordPressで構築することにしました。
コヤナギ：もともとはSNS化を前提としたメディアではあるんですけど、最初からその仕組みを構築するとなると完全に予算オーバー。まずは集客できる状態をつくり、読者がしっかり付いてからSNS化します、としたほうが自然な流れなので、そうした方向性を共有させていただきました。
ーーちなみにですが、WordPressのほかにはどんなものを検証されたんですか。
フラポ：ひとつめは、DrupalというCMSです。WordPressと同じくオープンソースのシステムなんですが、コンテンツ管理から訪問者管理、ショッピング機能など、利用できる性能の幅がかなり広いんですね。メールアドレスとパスワードで会員登録をしてログインできる機能もあり、それをカスタマイズすればSNSのような見せ方も可能だと考えました。
ただ、実際に検証してみると、コンテンツ制作においてはTALの設計とあまり合っていないと感じたので見送ることになりました。あとはCMSとしては古いなと（笑）
また、SNS化を検討する段階ではFirebaseの活用も考えていました。FirebaseはGoogleが提供している、アプリ開発を前提としたモバイルプラットフォームです。SNS化の場合にスマホのアプリも作ることを考えたときに、Firebaseを使えば認証の仕組みやプッシュ通知などが簡単に実装できるので、あとあとスムーズだなと思って検討をしてみました。
当初、Firerbaseはけっこうアリかなと思ったんですけど、記事を公開するためにはベースにWordPressなどのCMSを使うほうが、機能面でも開発効率の面でもメリットがあって。そうなると、WordPressが持っているユーザの権限管理の機能とFirerbaseの認証の機能をつなぐ必要がある。しかし調べてみたところあまり前例がないやり方だったため、初期の段階から検証の手間がかなり必要だと予想されました。そうした検証を踏まえて、開発費や工数的にも現段階では現実的ではないと判断し、結果としてシンプルにWordpressでの開発に至りました。
動き出す前のすり合わせが超大事
ーー要件を決める際に重視するポイントはなんでしょうか。
フラポ：どの企画にも言えることですが、要望を全部叶えたいならばゼロからつくるしかないんですよね。ただそのぶん、時間もお金もたくさん必要になります。でもほとんどの場合は時間も予算も制限があるので、クリエイティブからあがってきた企画を実装するときには、「なにを残してなにを諦めるか」というように、どこをどうトレードオフしていくかを考えます。
コヤナギ：この段階での企画やデザインは、開発度外視の「やりたいこと全部入り」の状態だったので、そこから現実的な方法を考えていただきました。
フラポ：どんな仕様だったらこの企画を叶えるのにいちばんベターかを考えると同時に、企画者側の優先順位も確認します。「ぜったいにこの機能がほしいんだ」というものがあれば、それを軸にして考えますね。
ナナ：仕様が決まるまでに、フラポさんから何度も確認をいただいて。飛んできた質問をコヤナギさんに確認して、またフラポさんに返して…という作業を繰り返しながら、要件を設定していただきました。
開発側にかかわる経験がはじめてだったのでなにが正解なのかわからず、はじめは探りながら回答をしていて（苦笑）でもフラポさんはいつも答えやすいように聞いてきてくれていたので、すごく助かりましたね。
フラポ：開発が動き出してからの変更を避けるためには、すり合わせはとても重要です。TALのプロジェクトはスムーズに進めることができましたが、企画と開発が対立してしまうプロジェクトは珍しくありません。
そうならないためには、相手がわかる言葉で、こちらの事情をしっかりと伝えることが大切かなと。丁寧な説明を受けて「そっちの都合なんて知らないよ」っていう人はそうそういないと思うので。
企画チームと開発会社の仲介役として
モモ：TALの実装にあたっては、フラポさんがかかわってくれることになったとはいえ内部のリソースだけではまわりそうにないなと。そこで、フラポさんに開発会社の選定をお願いしました。
ーー開発会社はどのような基準で選ばれたんですか？
フラポ：まずは実績ですね。あとは、会社のノリやテイストがa-worksのMMGと合うかというところも重要でした（笑）
コヤナギ：ヘイシャはノリが独特ですからね。
フラポ：開発会社とひとことで言っても会社のタイプはさまざまで。しっかり作り込んだ仕様にのっとってカッチリつくってくれる会社もありますし、ざっくりある程度まとまっていればとりあえず着手しますよっていう会社もありますし。
モモ：a-worksに合ってるのは完全に後者ですね（笑）
フラポ：そうですね（笑）要件がまだ決まってない部分は想像して頑張ります、途中で変わったら言ってくださいとおっしゃってくれて心強かったです。会社の雰囲気もa-worksに合ってるなと思いました。
ただ、ウェブサイトの実装だけであれば今回のように相性を重視した選び方でいいと思いますが、お金や個人情報を扱う場合は開発会社の選び方も変わってきます。サイトの特性を考慮して選ぶことが大切ですね。
ーー企画と開発の仲介役として心がけていたことはなんでしょうか。
フラポ：サイトの意図や、企画者であるコヤナギさんが実現したいことはなんだろうと想像することでしょうか。デザイン上にあるこのボタンやこの機能は、きっとこういう意味で設置してるんだろうなと想像して仮提案をつくり、ひとつずつ確認していきました。
ナナ：やり取りをする中で、説明せずともすごく理解してくれていると感じるシーンが多々ありました。また、進捗管理がすごく丁寧で細かったのも印象的でした。
ーーやはり、エンジニアは性格が細かいほうが有利なんでしょうか？
フラポ：そうですね、けっこう大事な要素かもしれません（笑）
そうして、2021年3月にTALがリリース。ここからは、プロジェクトのポイントとエンジニアの仕事について深堀りしていきます。
企画を叶えるためのデータ構築。リリース後の運用も考えた提案を
ーーTALの実装にあたって、気を配ったポイントはありますか。
フラポ：先ほども少し触れましたが、WordPressを選択した大きな理由のひとつに「運用のしやすさ」があります。ウェブメディアはつくって終わり、というものではないので、管理者の利便性も考えて要件を考える必要があると思います。
フラポ：そうした事情を踏まえてWordPressを選択しましたが、データの作り方には少し工夫が必要でした。というのも、TALの記事の見せ方は通常のメディアとは少し違っていて、
- モノ（商品）を紹介する記事からレビュアー（人）のページに飛ぶ
- レビュアーごとに記事を検索する
というように、ひとつの記事が複数方向からつながる仕組みを作る必要がありました。
フルスクラッチで開発する場合であれば、それぞれの情報をデータベースのテーブルに持ち、それぞれのテーブルにリレーションを貼るのが普通だと思います。でもWordPress自体はそういうデータの持ち方をする設計では作られていないんですね。将来このメディアが大きく育ったときに、ページの表示速度や追加機能が求められる可能性を考えると、一般的な方法でリレーションを貼っておきたいというのが、エンジニアとしての心情でした。
でもその方法を選んだ場合、通常のWordpressとは違うデータ構造になるため、システムにそこまで詳しくない人が運用するときに保守が難しくなってしまう。ですので、それらを天秤にかけて考えた結果、なるべく通常のWordPressのデータの持ち方や仕組みと乖離がないように開発を進めました。
ーー管理側がシステムにめちゃくちゃ詳しい場合は、違う提案をしていた可能性も？
フラポ：あると思います。そういう場合は、多少マニアックな仕様でも運用が可能だと思うので。WordPressはやはり世界でいちばん使われているCMSですし、慣れている方が多いのはメリットとして大きかったですね。
技術も大事だけど想像力も必要
ーーTALにおけるフラポさんの立ち回りをおうかがいし、コミュニケーションを積極的に取っている点が印象的でした。
フラポ：目の前の依頼に対して「これはできる」「できない」を提示したり、相手の言葉から、きっとこういうことがやりたいんだろうなと想像して動くことは、エンジニアでなくともビジネスにおける最低限のスキルかなと思います。
ーー提案できる環境とそうでない環境の違いはありますか？
フラポ：参画するプロジェクトはもちろん、所属している会社やクライアントによって変わってきますよね。キッチリと決められた仕様にのっとって実装していく仕事も必要不可欠ですし、そうした作業が好きだという方も多いと思います。
僕は、自分からさまざまな提案をしていくほうが仕事をおもしろがれるタイプ。どちらがいい悪いではなく、相性や向き不向きなのだと思います。
また、提案にあたっては、必ずしも新しい技術を提案するばかりが是ではないと考えています。TALのシステムにWordPressを選んだように、公開後の管理者の使い勝手も重要なポイント。ウェブはつくって終わりではないので、運営体制や管理者のレベルによって、臨機応変に考えられるエンジニアでありたいですね。
