プロジェクトマネージャー（以下PM）のchakiです。
プロジェクト進める中で、技術的なフィジビリ確認を行うことがあると思います。 言葉は聞くけど、どのタイミングで、誰がどこまでやるものなのか・・。
今回は私が実際に行ったフィジビリ確認をご紹介していきます。
フィジビリティ確認とは？
あるアイデアや計画が実現可能であるか、事前に確認や検証を行うプロセスのことです。日本語では「実現可能性の確認」とも言います。
フィジビリ確認を行うことで、後でできなかったとならないようにします。また正しい見積もりを算出でき、アサインリソースの期間や費用を明確にすることができます。
ビジネス要件
- ホームページの中に、SEO対策の読み物コンテンツを新規導入する
- コンテンツ作成にはCMSを利用し、運用側だけで記事コンテンツを公開できるようにする
- ホーム＞読み物コンテンツトップ＞大カテゴリページ＞小カテゴリページ＞記事詳細ページの構成で設計する
microCMSを導入
ホームページに利用できるCMSを開発ベンダーが選定。セキュリティ要件と費用からmicroCMSに決定しました。
microCMSはAPIベースのヘッドレスCMS
ヘッドレスCMSはヘッド（表示面）がなく、APIによってコンテンツを配信するのが特徴。 従来のCMSはコンテンツの管理に加えて、表示面がセットになっています。ヘッドレスCMSはコンテンツをAPIから取得しサイトやアプリ内の任意の箇所のみCMS化が可能です。
引用：microCMSのサイトより
開発にフィジビリ確認を依頼したが課題発生
企画を開発ベンダーに伝えたところ、選定したCMSを利用してデモンストレーションが行われました。しかし、企画が想像していたCMSの使い方と乖離するもので、以下イメージで提案を受けることに。
・・・うーん、、伝わりますかね？
- h1、画像、h2、説明文、画像、h3、説明文、画像など、入稿フィールドがそれぞれたくさん設定されている
- 入稿フィールドの出力先が固定されている
- コンテンツ管理とデザイン管理が切り離されている
まとめると、以下のような乖離が発生していました。
| 観点 | ビジネス側 | 開発側 | 乖離 |
|---|---|---|---|
| 誰でもCMSから記事編集できる | 期待していた | 想定していた | 乖離なし |
| 記事ごとに柔軟性をもてる （h2,h3の位置や数を変更できる） |
期待していた | 想定してなかった😯 | 🔥乖離 |
| コーディングなしでデザインを変更できる | 期待していた | できないと当初から想定していた | 🔥乖離 |
ビジネス側の期待と、エンジニアの提供手段の間で乖離が起きていました。この乖離を埋めるため、予定にはないGoodpatchによるフィジビリ確認を行う流れになりました。
ビジネス側と開発側で適宜打ち合わせの場を設け、十分に会話をしていたのに、どうしてお互いに気づけなかったのか。その思いが強くこの記事を書くことにしました。
フィジビリ確認の観点と、その結果
1. 運用面
| チェック項目 | 観点と結果 |
|---|---|
| CMS環境の複数設定 | 読み物コンテンツが2つ必要なため、それぞれにCMS環境を分けられるか。管理導線が混在しないか。 CMS対応可 |
| カテゴリ追加の反映 | 大カテゴリ・小カテゴリを追加した際、トップページやカテゴリページに自動で反映されるか。 CMS対応不可、実装で実現 |
| カテゴリごとの記事表示制御 | カテゴリに紐づく記事が0件の場合、カテゴリごと非表示にする機能が存在するか。 CMS対応不可、実装で実現 |
| 記事表示数の制御 | トップ・カテゴリページなどで表示する記事数を管理画面から変更できるか。 CMS対応不可、実装で実現 |
| 入稿者・承認者の権限設定 | 記事の作成者と公開承認者の役割を分けて設定できるか。 CMS対応可 |
| 記事の公開予約 | 記事の公開予約設定ができるか。 CMS対応可 |
| 記事の一時非公開機能 | 公開済み記事を一時的に非表示にできるか（キャンペーン終了時など）。CMSでワンクリックで対応できるか。 CMS対応可 |
| 更新履歴の確認機能 | 編集履歴が残り、誰がいつ何を更新したか確認できる。ミス時のロールバックが可能か。 CMS対応可 |
| タグ管理の柔軟性 | カテゴリと別にタグを設け、横断的な記事整理・回遊が可能か。 CMS対応可 |
| 動的コンテンツの差し込み位置確認 | 動的コンテンツの表示エリアがどこなのか、運用者が把握する機能があるか。 CMS・実装で対応不可、運用マニュアルで制御 |
2. デザイン・UI面
| チェック項目 | 観点と結果 |
|---|---|
| NoImageのデザイン制御 | サムネイル未設定時に、デザインに馴染むNoImageを表示できるか（複数パターンも対応可能か）。 CMS対応不可、実装で実現 |
| パンくず表示制御 | トップ＞大カテゴリ＞小カテゴリ＞記事 という階層を自動でパンくずとして出力できるか。 CMS対応不可、実装で実現 |
| 写真のスクエア表示 | 画像入稿時に自動トリミング・表示比率の制御が可能か。 CMS対応不可、実装で実現 |
| PC/SP別表示制御 | デバイスに応じたデザイン制御が可能か（レイアウト切り替えなど）。 CMS対応不可、実装で実現 |
| カスタムCSS/JSの設置余地 | 独自のデザイン・インタラクションを実現するため、任意のCSS/JSを設置できるか。 CMS対応可 |
| 固定コンテンツ設定 | CMS全体の下部などに、EC導線などを固定表示できるか。運用者が差し替え可能か。 CMS対応不可、実装で実現 |
3. 入稿・編集機能面
| チェック項目 | 観点と結果 |
|---|---|
| 記事要素の表示制御 | 表示する要素（写真・カテゴリ名・タイトル・更新日など）を管理画面で制御可能か。 CMS対応可 |
| 並び順の制御 | 記事の並び順を「更新日順」などで並び替えられるか（自動取得が理想）。 CMS対応不可、実装で実現 |
| 目次の自動生成 | 見出し（h1/h2/h3など）から自動的に目次を生成できるか。 CMS対応不可、実装で実現 |
| 見出し設定の制御 | h1を除くh2〜h4の見出しが自由に設定できるか。 CMS対応可 |
| 装飾制限 | 太字はOK、斜体・取り消し線・下線はNGなど、スタイルルールを制御できるか。 CMS対応可 |
| 動画埋め込み | YouTubeなどの動画埋め込みが可能か。 CMS対応可 |
| リッチテキスト構造のカスタマイズ性 | 引用・リスト・表などの要素を適切な構造で入稿・表示できるか。 CMS対応可 |
| 監修者欄の設定 | 記事ごとに監修者情報の有無を設定できるか。 CMS対応不可、実装で実現 |
| 入力必須項目の設定 | タイトル・説明・カテゴリなどを必須に設定でき、他にも柔軟に追加可能か。 CMS対応可 |
| 入稿画面のUI/UX | 入稿時に迷わず、最小工数で記事が作成できるUI設計になっているか。 CMS対応可 |
4. SEO・URL面
| チェック項目 | 観点と結果 |
|---|---|
| SEOメタ情報の設定 | title / description / canonical をデフォルト設定＋ページ単位で上書き可能か。 CMS対応可 |
| パーマリンクの設定 | ページごとに任意のURLを設置できるか。 CMS対応可 |
| 階段構成のURL設定 | URLはカテゴリ階層表示できるか。 CMS対応不可、実装で実現 |
| 記事のURL設定 | 記事はカテゴリ配下ではなくarticle配下に集約表示できるか。 CMS対応不可、実装で実現 |
落とし所と行った工夫の紹介
結果、CMSと画面の関係はこのように設定しました。
大きな方向性として、入力フィールドが多いと自由に記事コンテンツをつくることが困難になってしまうので、極力編集自由度が高いものにしようと考えました。
1. 運用面
| チェック項目 | 観点と結果 |
|---|---|
| CMS対応可 CMS環境の複数設定 |
読み物コンテンツが2つ必要なため、それぞれにCMS環境を分けられるか。管理導線が混在しないか。 アクセスするCMSのURLは1つでOK。左端のアイコンでコンテンツ群を切り替えることができる。  |
| CMS対応不可、実装で実現 カテゴリ追加の反映 |
トップページにカテゴリは自動的に追加されないので、大カテゴリ名は増やさない想定でUIを設計。 |
| CMS対応不可、実装で実現 カテゴリごとの記事表示制御 |
トップ・カテゴリページで表示する記事数は管理画面から制御できなかったので、4記事表示で折り返すようにUIを設計。最大は12記事を表示。 |
| CMS対応可 入稿者・承認者の権限設定 |
記事の作成者と公開承認者の役割を分けて設定できる。 |
| CMS対応可 更新履歴の確認機能 |
編集履歴が残り、誰がいつ何を更新したか確認できる。ミス時のロールバックできる。 |
2. デザイン・UI面
| チェック項目 | 観点と結果 |
|---|---|
| CMS対応不可、実装で実現 NoImageのデザイン制御 | サムネイル未設定時に、デザインに馴染むNoImageを表示する機能はありませんでした。よってフロント開発で実装していただきました。 |
| CMS対応不可、実装で実現 パンくず表示制御 | トップ＞大カテゴリ＞小カテゴリ＞記事 という階層を自動でパンくずとして出力できる機能はありませんでした。よってフロント開発で実装していただきました。 |
| CMS対応不可、実装で実現 写真のスクエア表示 | 画像入稿時に自動トリミング・表示比率の制御する機能はありませんでした。アップロード時に縦横サイズを指定した上で入稿する制御はあったので、この機能を利用することと、フロントコーディングでmax-widthを指定する形で実装しました。 |
| CMS対応可 カスタムCSS/JSの設置余地 | 独自のデザイン・インタラクションを実現するため、任意のCSS/JSを設置するカスタムclassを利用しました。 |
3. 入稿・編集機能面
| チェック項目 | 観点と結果 |
|---|---|
| CMS対応不可、実装で実現 目次の自動生成 | 記事内に、運用が自由に編集できるリッチエディタを設置。その記事のh2とh3をシステムで抽出し、目次を自動的につくる方式を採用しました。 |
| CMS対応可 見出し設定の制御 装飾制限 | 編集自由度が高いと赤文字・青文字・好き勝手なコンテンツ挿入が行われてしまい、サービス表現の崩れにも繋がる。そこで、リッチエディタで利用できる機能に制限をかけることにしました。これで好きな色や下線や斜体を使わせないように制御を実施。またh1を除くh2〜h4の見出しが自由に運用者が選べるように設定。 |
| CMS対応可 入力必須項目の設定 | 各入力フィールドは必須にするか、重複設定、文字の長さを制御する機能があるので活用しました。 |
4. SEO・URL面
| チェック項目 | 観点と結果 |
|---|---|
| CMS対応可 パーマリンクの設定 | パーマリンクの機能は存在しませんでしたが、CanonicalはコンテンツIDの機能を流用し、好きな文字列をビジネス側が設定できるように。 |
| CMS対応不可、実装で実現 階層構造のURL設定 | URLはカテゴリ階層が表示されるように実装し、カテゴリをCMSで追加すると自動的にURLも生成されるように実装。 - siteDomain/contentsName/カテゴリL/カテゴリM/01 |
| CMS対応不可、実装で実現 記事のURL設定 | 記事はカテゴリ配下ではなくarticle配下に集約表示されるように実装。 - siteDomain/contentsName/コンテンツID |
おわりに
開発側が良かれと考えていたこと、ビジネス側がWordPressありきで考えていた運用イメージ、それぞれすれ違いがありました。今回は上記の方法で良い着地点を見つけられました。前提条件や知識・スキルレベルが異なるので乖離が生まれるのは当然です。話しているのにどうも伝わっていない・・両者の意図を汲み取り、1つのゴールに導く役目を果たすことができました。
補足までに。 今回は「技術フィジビリ確認」をきっかけに本記事を作成しましたが、詳しく調べるとフィジビリ確認は5種類あることがわかりました。次回からはビジネス的フィジビリ、運用フィジビリ、スケジュールフィジビリをもっと意識してクライアントワークに取り組みたいと思います。
| 観点 | 内容の例 |
|---|---|
| 技術的フィジビリティ | 実装可能な技術が存在するか、自社の技術力で実現できるか |
| ビジネス的フィジビリティ | 市場ニーズがあるか、採算が取れるか、ビジネスモデルが成立するか |
| 運用・体制面のフィジビリティ | 運用に必要な人材・体制が整えられるか |
| 法的・契約的フィジビリティ | 法律や契約に抵触しないか、クリアできる要件か |
| スケジュール的フィジビリティ | 期限内に実現可能か、リソースが足りているか |
general editor：@inininin-design
