デザインから WordPress のテーマ作成までの自分のワークフローを見直す

他の人のワークフローで気になったこと

先に、どんなワークフローが気になったのかを書いておきます。気になったのは２点！

• いきなりテーマ作成がコーディング
• 何かしらの WordPress テーマをベースにカスタマイズで制作

「このワークフローは悪い！」というお話では一切なくて、何が気になったのかというと、そのワークフローをとることで「制作の効率化がはかれるかどうか」というのが自分の中での最大の焦点です。

単純に、効率的なワークフローを常に考えている自分にとって、自分のワークフローと比べると、この２つの方法とは違うなーと思ったからだったりもするのですが・・・

なぜ気になったのかの前提 ： 私のワークフロー

自分のおおよそのワークフローについては、WordCamp Tokyo 2015 の登壇フォローアップのエントリーに簡単にまとめてあります。

WordCamp Tokyo 2015 「仕事に対する効率化意識向上のためのgulpハンズオン」登壇フォローアップ - HAM MEDIA MEMO

ざっくり書くと、大きな流れとしては、デザイン（主に他のデザイナーが作成）→ HTML・CSS・JavaScriptを静的ファイルで実装（私の主力）→ WordPress のテンプレート化という手順を踏んでいます。

静的 HTML 制作が私の主戦場

制作フローにおいて、静的HTMLの制作を必ず入れるように進めています。

もう少し書くと、デザインは決まった形ではなく、案件ごとに全く違った形・デザインで出てくる、フルオーダー（って言うのかな？）。静的HTMLはそのままでもFTPでアップしたら使える形なのと、 gulp に静的HTMLジェネレータと組み合わせて利用。ワイヤーやデザイン段階に考慮漏れの仕様が無いかとか割と細かく確認したうえでコーディングスタートし、PCでもSPでも対応可能で、それがレスポンシブでもデバイス専用でも、どちらでも対応。そしてHTMLは部品単位で作る構成をとっているので使い回ししたり CMS 化や様々なシステムの View にも対応可能な形で納品する形式をとっています。

多くの案件では、CMS 化や様々なシステムの View は別の作業者が別途先にすすめていてるので、納品は静的HTMLの状態というケースが多い状況です。

自分の制作フローが上記のような流れとするとき、他の人がどう進めているのかが気になります。気になると書きましたが、自分のこの手順が「効率的に進められているか？」というのがそもそもの疑問の始まりです。

前提を踏まえて、再度疑問に思ったワークフローが効率的か？についてを考察してみます。

疑問１：いきなりテーマ作成がコーディング

テーマ作成のみに着目すると、作ったファイルをそのまま利用できるので、一番効率よく進められるような気がします。

• テーマ作成 = コーディング になるので無駄なフローがないぶん早い
• WordPress の構築をしながらできるので、考慮不足が発生しにくい

メリットが多そうなワークフローなのですが、なぜか自分がこの手順を採用していない現状。何故か？を思い出そうとしたのですが、思い出せない。

記憶の片隅には、何かしらこのワークフローで何かしらデメリットがあり、そしてそのデメリットのウェイトが大きかったのですが・・・現在のワークフローをとりはじめたのは、もう何年も前のことなので、そのデメリットが思い出せないのと、当時の自分と今を比べると、スキルもだいぶ変化したので当時は悩んでいたことも今では悩まくなっていたりするのか、全然思い出せないという。

なぜ自分が WordPress 案件でも、このワークフローをとっていなかったのか？もう少し整理してみます。

静的ファイル作成は無駄？

WordCamp Tokyo 2015 でハンズオン登壇した際の他のお手伝いのみなさんもとっているワークフローでした。WordPress におけるワークフローの場合、このフローのほうが多いのだろうと予想。

実際に、その際に自分のワークフローの話をしたのですが「静的に作成するのは無駄では？」という意見がでてきていました。

その時に実際に考えさせられたのですが、静的に作成したファイルから、テーマを作成する際に、テーマになることを前提とされていない場合が多く、手戻りが多いという。

テーマにあうコーディングではないと手戻り

テーマやテンプレート前提に作られていない場合は、確かに手戻りが多く発生することになるのは事実。デザイナーの多くは、先のことを考えずに作っているのではないかと思います。

しかし、前述の登壇フォローアップのエントリーでもふれていますが、繰り返し部分やテーマになることを考慮したHTMLで進められる場合は、静的HTMLを先に作っても手戻りなく進行が可能です。自分や自分の普段一緒にコーディングを行うフリーランス仲間は、少なくともこの手戻りが少ないタイプのコーディングができる人だったりします。

デメリット = 手間になることはないか？

先にいろいろとメリットを考えてみたのですが、記憶にものこっていたように、メリット以上のデメリットから採用していなかったため、いきなりテーマ作成においての手間やデメリットになりうることについても考えてみようと思います。

ざっと思いつくところを上げると以下の点。

• 開発環境の用意の手間
• 固定ページ作成やカスタム投稿など、管理画面の投稿が必要となる（= 静的に進めるより手間）

開発環境の用意は手間？

今となっては、VCCW や Wocker など自分でも活用可能な便利ツールが豊富なので、それほど手間にならずにローカルの開発環境は用意できるのと、それをプレビューすることも可能になることは理解しています。

この点が思いついたとして挙げてみたのですが、自分にとってはデメリットではない状況だったりしますが、サーバー用意や環境用意が得意でない人にとって、この当たりは過去も今も課題になっていると思います。しかし、いきなり構築するにしても、静的HTMLファイルが前提にしても、どっちにしろ WordPress の構築には必要なことなので、この点は手間であっても、必要不可欠なことになっているため、手間という程のものではなさそうです。

固定ページなどの管理画面入力が前提のページは手間

開発環境の用意のほう大きな問題にならないとすると、今一番問題になりそうなのが、この固定ページの作成なのかなと思います。コーディング時のフローで管理画面の登録フローがはいってしまうのはワークフローは、確実に手間になるのではないかと。

トップや一覧、記事の詳細などはダミーの汎用的な内容を登録しておくことで進められます。固定ページも、汎用的な形式のスタイルのみでデザインされているような場合は、汎用モジュールのHTMLを登録しておくことで確認が簡易にとれるのはわかります。

しかし、固定ページは各ページ固有にデザインを当てるケースも少なくなかったりするので、その場合は専用のマークアップをページに登録したうえでスタイルを当てる作業が発生するので、HTMLの反映の手間が発生してしまいます。

マークアップとそこに当てるスタイルに自信があって、手戻りも少なく確認もスムーズ！なんてスキルの人は問題ないのでしょうけど、私は一発でもしくは少ない回数でマークアップもスタイルも完璧に仕上げるのが苦手なほうなので、このワークフローを前提としてしまうと、固定ページなどの管理画面の登録が前提になってしまうワークフローをとってしまうと、効率的に進めることができない状態が発生してしまいます。

中間まとめ

自分たちのワークフローと比べた際に、デザイン → いきなりテーマ作成がコーディング というワークフローは、今の自分たちのスキルからすると採用価値ありなワークフローになってはいそうというのが、振り返りでわかりました。

しかし、管理画面の登録を挟んでしまう作業は発生してしまう場合は、明らかな時間ロスになるというのは問題なので、現状の結論としては、やはり静的HTMLを先行して作るほうが、自分たちにとってはメリットが大きそうということがわかりました。

みなさんのワークフローはいかがでしょうか？

さて、次の疑問に移りたいと思います。

疑問２：何かしらの WordPress テーマをベースにカスタマイズで制作

疑問１だけかなと思ったのですが、疑問１を考えるにあたって、そもそも いきなりテーマ作成といえども２パターン存在するだろうなと。

テーマの作成において

• 何もないところからスタート（フルスクラッチ）
• 既存や自作のテーマを利用してスタート

先ほどの中間のまとめでは、前者の「何もないところからスタート」が前提として考えていました。

既存のテーマを利用？

この発想がなぜか自分の中にありませんでした。様々なデザインに対応できるテーマであれば活用しない手はないのですが、そこにかける学習コストよりも手を動かして、これまでの自分たちの成果物を活用して進めるほうが、効率的だと判断しているためです。

しかし、ここまでの Advent Calendar を書いている人の内容をみると、テーマについての内容もいくつかあるので、それらを活用するような場合もあるのだと気づきました。

ダッシュボードから更新できる国産レスポンシブ WordPress テーマ を紹介 ‹ nuuno

初めて子テーマ作って公式ディレクトリに申請した~WordPress Advent Calendar 2015~ | Snaplog

ノンプログラマーのためのカンタンWordPressテーマ作成入門　〜子テーマでテーマ作成＆カスタマイズ〜

デザインの再現が効率的にできるか、親テーマのスタイルを利用して作る場合はいろいろと課題（スタイルの上書きとか）しなければなーとか思っていたのですが、そもそもインポートしないで、いちから作ればスタイルを上書きせずとも作っていけるのかなとも思ったりもしています。

余談：制作側でない場合

WordPress を利用する人は制作者だけでないという前提もわすれてしまっていたのですが、以下のエントリーを読んでハッとしました。

仕事で使ったことがない人のWordPress – ちえなび

Webの業界にはいる前の自分・・・大学時代の自分なのですが、その頃の自分も、ブログサービスのテンプレートから自由に選んで、自分でいろいろとカスタマイズを試みたものです。非ITの人にとっては、カスタマイズしやすいテーマとか、わかりやすいテーマ、最初からあれこれ機能が備わっているテーマのほうが手間も少なく進められますしね。

しかし、Webの制作側にいる現在、デザイン関係なしに進められる案件の場合を除いて、テーマにオリジナルのデザイン・機能を盛り込めるかどうかが重要ですよね。

だからこそ、今回、ワークフローについてを悩み、他の人がデザイン・機能を実現するためにどのように進めているのか興味が出てしまったキッカケになっているので。

親テーマとして活用

余談を挟んでしまったあとですが、この項目で一番考えさせられたのは キタジマさん(@inc2734) の以下のエントリー

私はなぜ Habakiri を作ろうと思ったのか – Habakiri

Habakiri は単体で使用するテーマではなく、子テーマ利用が前提のテーマとして開発しています。なので一般的なテーマと違い、子テーマがストレス無く効率的に作れるか、また、アップデートの影響を子テーマに与えないようにできるか、というのがポイント...

引用元：私はなぜ Habakiri を作ろうと思ったのか – Habakiri

デザインの再現性だけ考えたら何かしらのテーマを利用しないほうが早いとか思っていたのですが、このエントリーを読んで、親テーマとか設定回りなどについて、公式に登録されているテーマとかそのテーマの機能を活用するように構築できるワークフローにしていくほうが早いなということにも気づかせてもらえました。

デザインデータから WordPree のテーマ作成が納品という案件においては、自分たちのワークフローでも、まだまだ考えたり改善していくほうが効率化に繋がることが多いようです。

静的HTML作成時から子テーマ利用を前提にしてみる？

まだ子テーマの利用前提で、静的HTMLを作成したりしてこなかったのですが、静的HTMLを作成するにしてもしないとしてでもどちらでも、子テーマとして作り始めるというワークフローをしてみたことがないため、現状の今後の課題になりそうです。

結局静的HTMLは作成前提？

ここは、WordPress のテーマ作成だけでない場合もあることなどを考えても、自分たちの得意としている効率的なワークフローはこのまま活用していっても問題なさそうというのが、これを書いていて改めて思うようになったので、またしばらくは現状のワークフローは変わらなそうです。

ただし、静的HTMLを作成するにしても、ワークフローの細かい部分については今後も様々な部分で見直しをはかろうと思っています。例えばローカル環境の用意の方法とか、「え？まだMAMPで消耗してんの？」と言われたような部分の改良などなど。

さらに言うと、デザインファイルをもらうデザイナーやディレクターとの連携ややり取り回りだったり、システムやCMSが自分たちでないプログラマーがいる場合の連携だったり、いろいろなところでも日々改善を模索していくことは変わらないでしょう。

皆さんのワークフローは？

ダラダラと書いてしまったのですが、みなさんのワークフローはどのようにして進めていますか？それは効率的ですか？自分はこうやって進めている！とかこれのほうが効率的！など、ぜひご意見もらえたら嬉しいです。

今後のワークフローも視野に？

最後に、井村さんのブログの最後に余談で書かれていたことですが

しかし仮に管理画面以外のクライアントアプリで投稿するユーザが一般化するのであれば、特に管理画面側のプラグインはあり方をだいぶ変えないと使われる環境が少なくなるのは間違い無さそう。

プラグインも今までのようにUIまで完備するのではなくAPIだけ用意するスタイルに変化していくのかなーともやもや考えております。

引用元：WordPressプラグインを作るのが辛い話 – ファンタラクティブ株式会社

プラグインだけでなくて、テーマ作成のワークフローにおいても、このあたりは変る可能性があるのではないかと思ったりしております。

しかし、この先に変る可能性を考えても、テーマ作成については変る可能性があったとしても、自分たちのとっている静的HTMLコーディングを挟むワークフローは変わらずに続けていけそうだなと、思ったり。

むしろ、APIでデータを取ってきて表示ができることが前提となれば、静的HTMLのコーディングだけでもまだまだ十分に戦っていけるなというのを感じています。ただし、JavaScriptやAPIの取得回りの技術に関しては、もっと知識やスキルを伸ばさないといけないなという課題もありますし、さらに言うとセキュリティ回りもありますので、勉強もまだまだしていく必要がありますね。