コンポーネントライブラリは、ボタンやフォームといった部品を、実装済みの状態でまとめておく仕組みです。新しいページを作るとき、既存の部品を組み合わせれば済むため、制作の速度が上がります。
ただし作ること自体は難しくありません。難しいのは維持することです。使われずに放置されたライブラリは、実際のサイトと乖離していきます。乖離すると誰も参照しなくなり、結局その場で新しく作られます。
この記事では、効果が出る条件、既製のものを使う判断、作る前に決めること、そして発注時に確認すべき点を整理します。
この記事でわかること
・作ることより、維持することが難しい
・効果が出るのは、ページを継続的に追加する場合
・既製のものを使う判断もある
・作る前に、更新する人と手順を決める
・実際のサイトと乖離すると使われなくなる
・発注側は、引き継げるかを確認する
作ることより維持することが難しい
ライブラリが機能しなくなる原因は、ほとんどが維持されないことです。
| 起きること | 原因 | 結果 |
|---|---|---|
| 実際のサイトと見た目が違う | サイト側だけ変更した | 参照されなくなる |
| 使い方が分からない | 説明がない | その場で作られる |
| 部品が足りない | 追加されない | 個別に実装される |
| 古い部品が残る | 整理されない | どれが正しいか不明 |
特に多いのは、急ぎの案件でサイト側だけ直し、ライブラリを更新しないパターンです。これが数回続くと乖離が固定化し、ライブラリは使われなくなります。
機能しなくなる原因は、維持されないこと。
サイト側だけ直す運用が続くと、乖離が固定化する。
効果が出るのは継続的に追加する場合
投資に見合うかは、今後どれだけページを追加するかで決まります。
| 状況 | 効果 | 判断 |
|---|---|---|
| 定期的にページを追加する | 高い | 作る価値がある |
| 複数のサイトで共通の部品を使う | 高い | 作る価値がある |
| 担当者が複数いる | 高い | 品質のばらつきを防げる |
| 公開後ほとんど追加しない | 低い | 作らなくてよい |
| 1人で全て作る | 低い | 本人の記憶で足りる |
ページを追加しないサイトでは、ライブラリを作っても使う機会がありません。制作費が上がるだけになります。
今後のページ追加の見込みで判断する。
追加しないサイトでは、使う機会自体がない。
既製のものを使う判断もある
自社専用のものを作る以外に、既に公開されている部品群を使う選択肢があります。
| 方法 | 初期の手間 | 見た目の自由度 | 維持の負担 |
|---|---|---|---|
| 自社で作る | 大きい | 高い | 自社で負う |
| 既製のものを使う | 小さい | 制約がある | 提供元が更新する |
| 既製のものを調整する | 中程度 | 中程度 | 調整分は自社で負う |
ブランドとしての見た目にこだわりが強くない場合、既製のものを使うほうが早く安くなります。ただし他社と似た見た目になること、提供元の方針変更に影響されることは前提になります。
作るか買うかの判断は業務システムは作るか、買うか|既製で足りる条件と、作る判断の分岐点の考え方が応用できます。
見た目のこだわりが強くなければ、既製のものが早い。
他社と似ること、提供元の方針に影響されることが前提。
作る前に決めること
着手する前に、次の項目を決めてください。これらが曖昧なまま作ると、維持されません。
- 誰が更新するか(担当者と、その人が離れた場合の代替)
- どのタイミングで更新するか(案件のたび、定期など)
- サイト側だけ変更してよい場合はあるか
- 部品を追加する基準(何回使われたら部品にするか)
- 使わなくなった部品を削除する手順
- 説明をどこに、どの粒度で書くか
特に3つ目が重要です。急ぎの案件でサイト側だけ直すことを認めるなら、後でライブラリへ反映する手順まで決めておく必要があります。
更新する人と、更新のタイミングを先に決める。
サイト側だけ直した場合の反映手順まで決めておく。
説明がないと使われない
部品が用意されていても、使い方が分からなければ、その場で作られます。
- どのような場面で使う部品かを書く
- 似た部品がある場合、使い分けの基準を書く
- 変更してよい箇所と、変更してはいけない箇所を示す
- 実際の表示例を置く
- 使ってはいけない例も示す
使い分けの基準がないと、担当者ごとに判断が変わります。結果として、同じ場面で違う部品が使われ、一貫性が崩れます。
一貫性が崩れる原因はUIの一貫性はなぜ成果に効くのか|崩れる原因と、揃えるべき範囲を参照してください。
使い方の説明がないと、その場で作られる。
使い分けの基準がないと、担当者ごとに判断が変わる。
発注側は引き継げるかを確認する
制作を外部に依頼する場合、ライブラリの扱いを契約時に確認してください。
| 確認項目 | 確認しない場合 |
|---|---|
| データと実装の所有者 | 変更時に引き継げない |
| 使用している外部の部品 | 利用条件が引き継げない |
| 説明の有無と場所 | 次の担当者が使えない |
| 更新の依頼にかかる費用 | 維持費が想定外になる |
| 自社で更新できる範囲 | 毎回依頼が必要になる |
ライブラリがあること自体は、引き継げることを意味しません。説明がなければ、次の制作会社は結局作り直します。契約時の確認事項はデザイン制作会社の選び方|見積り比較で確認すべきポイントを参照してください。
あること自体は、引き継げることを意味しない。
所有者と説明の有無を、契約時に確認する。
小さく始めて増やす
最初から網羅しようとすると、公開が遅れ、使われない部品も増えます。
- 実際に複数箇所で使われている要素を数える
- 3回以上使われているものだけを部品にする
- 使う場面と使い分けの基準を書く
- 新しいページを作る際、既存で足りるか確認する
- 足りない場合のみ追加し、その都度説明を書く
使用回数を基準にすると、必要なものだけが残ります。予想で作った部品は使われないことが多く、管理の対象が増えるだけです。
実際に複数回使われている要素だけを部品にする。
予想で作った部品は使われないことが多い。
他の要素との順序
デザインの各要素には依存関係があり、決める順序が結果を左右します。この要素が全体のどこに位置するかはWebデザインの構成要素はどの順で決めるかを参照してください。
よくある失敗
作って終わりにする
維持されないと、実際のサイトと乖離します。更新の担当と手順を決めてください。
ページを追加しないサイトで作る
使う機会がありません。今後の追加の見込みで判断してください。
説明を書かない
使い方が分からず、その場で作られます。使い分けの基準まで書いてください。
最初から網羅しようとする
公開が遅れ、使われない部品が増えます。使用回数を基準に絞ってください。
引き継ぎの前提を確認しない
あること自体は引き継げることを意味しません。所有者と説明の有無を確認してください。
よくある質問
デザイン側の部品と実装側の部品は分けるべきですか
対応関係が説明できる状態が理想です。完全に一致させることは難しいため、どのデザイン部品がどの実装部品に対応するかを記録してください。デザイン側の判断はデザインの部品化はどこまでやるべきか|更新の手間と初期工数の分岐点を参照してください。
どのくらいの規模から必要ですか
ページ数より、追加の頻度で判断してください。10ページでも毎月追加するなら効果が出ますし、50ページでも追加しないなら使う機会がありません。
既製のものを使うと他社と似ませんか
似る可能性はあります。ただし部品そのものより、配色、書体、写真、文章のほうが印象に影響します。既製の部品を使いつつ、これらで差をつける方法があります。
維持できなくなった場合はどうすべきですか
乖離が大きい状態で残すより、現状のサイトに合わせて作り直すか、使用を止めるかを判断してください。誤った内容が参照される状態が最も問題です。
分類の枠組みは必要ですか
規模によります。部品数が少なければ、一覧できる状態で足ります。増えてきた段階で分類を検討してください。考え方はアトミックデザインは導入すべきか|粒度で分ける考え方と、合わない場合を参照してください。
まとめ
コンポーネントライブラリは、ボタンやフォームといった部品を実装済みの状態でまとめておく仕組みです。新しいページを作るとき既存の部品を組み合わせれば済むため、制作の速度と一貫性が上がります。ただし作ること自体は難しくなく、難しいのは維持することです。
機能しなくなる原因は、ほとんどが維持されないことにあります。特に多いのは、急ぎの案件でサイト側だけを直し、ライブラリを更新しないパターンです。これが数回続くと乖離が固定化し、誰も参照しなくなります。したがって着手する前に、誰が、どのタイミングで更新するか、そしてサイト側だけ変更した場合にどう反映するかまで決めておく必要があります。
また、部品が用意されていても使い方が分からなければ、その場で新しく作られます。どのような場面で使うか、似た部品がある場合の使い分けの基準まで書いてください。着手の仕方としては、最初から網羅しようとせず、実際に3回以上使われている要素だけを部品にする進め方が現実的です。予想で作った部品は使われないことが多く、管理の対象が増えるだけになります。
当社ではホームページ制作において、運用を前提とした構築をご提案しています。既存サイトの整理はお問い合わせよりご相談ください。