ポートフォリオ、超ひさしぶりに更新しました！（ほんとに）

フリーランスになってから毎月何かしら作ってはいたんですが、
自分のサイトだけはず〜っと後回しでして……やっと重い腰を上げました！

気づけば2年間で50サイト超え。（サイトでは非公開のものもあります。）
「こんなにやってたのか」と自分でもちょっとびっくりです。

最近はWordPressまわりのご依頼も増えてきて、コーディング専任として良い感じに手を動かせてます。
もし「一緒にお仕事したいな〜」という方がいれば、お気軽にお声かけください(^ ^)

これからはちょっとずつ、自分の発信もがんばっていきたい…！（たぶん）

お久しぶりの更新となってしまいました。

制作実績は粛々と更新しておりましたが、それ以外はほとんど機能しておりませんでした。

一旦お仕事が落ち着いたタイミングで、ざーっと一通り再構築してみました。

今後はもう少し色々とお知らせを出したり、「自分の活動」をしていきたいなーと考えているところでございます。

アイキャッチの画像に設定したのは、新しいロゴです。ロゴの制作ってなかなか難しいですね。
今後デザインも更に勉強していく計画です。

どうぞ改めまして、よろしくお願いいたします。

本日サイトのリニューアルリリースをさせていただきました！

前回の1枚サイトよりも、少しだけ規模を拡大してのリリースとなりました！

今後皆様に喜んでいただけますよう、引き続き頑張ってまいります！

ブロックエディターは苦手意識から始まった

WordPressにGutenbergが搭載されたとき、「うわ、見た目が全然変わった…」と戸惑ったのが最初の印象だった。クラシックエディターに慣れていた私にとって、ドラッグ＆ドロップで動くUIは“自由すぎて不安”だった。

その頃から私は、カスタムフィールド（ACF）を使って、項目をガチガチに管理するスタイルにハマっていった。テキスト、画像、チェックボックス…それぞれの意味を明確にして、出力も整える。なんとなく「正しい管理」をしている気になれていた。

ACFの安心感と、ブロックエディターの曖昧さ

ACFだと「この項目を入れれば表示される」「入れなければ非表示」というのが明確になる。構造を意識してサイトを組み立てたい私にとって、それはとても心地よかった。

一方で、ブロックエディターは“何でもできてしまう”。その自由度が逆に設計を難しくしてると感じていた。クライアントが自由にレイアウトできるのは便利だけど、崩れやすいし、メンテのときに「この表示どこで編集するんだっけ？」となりがちだった。

じゃあ、今はどうしてるか

今の私は、「誰が更新するか」によって判断を分けている。

1. 自分しか触らないならブロックエディターでもいい。
2. クライアントに触ってもらうなら、ACFで制限をかけた方がミスが起きにくい。

つまり、どちらかを否定するんじゃなくて、ケースバイケースで選ぶようにしている。

最後に思うこと

正直、ブロックエディターの進化は目覚ましいし、できることもどんどん増えている。でも私にとっては「構造が読めて、出力もコントロールできる」ACFの方が、まだまだ手放せない。

今後、フルサイト編集の流れがもっと進んだら、また考え方も変わるかもしれないけど、今のところ私は「カスタムフィールド派」として、うまくブロックエディターと距離をとってやっている。

カスタム投稿タイプとの出会い

最初にカスタム投稿タイプという言葉を聞いたとき、「なにそれ？」というのが正直な感想だった。投稿と固定ページの違いさえ曖昧だった当時の私にとって、それはまさに未知の機能だった。

でも実務でテーマを作るようになって、「あれ？これ投稿でやるにはちょっと無理があるな」と思う場面が出てきた。たとえば「お知らせ」と「ブログ」、さらに「スタッフ紹介」まで全部投稿でやろうとすると、管理画面がゴチャつくし、テンプレートの出し分けも面倒になってくる。

そのとき初めて「カスタム投稿タイプって便利かも」と思った。

管理と出力の分離が、こんなに楽だとは

私は整理整頓が得意なタイプではない。でも、カスタム投稿タイプを使うと、投稿の種類ごとに管理画面を分けられるから、情報がスッと頭に入ってくる。

クライアントにとってもそれは同じで、「この情報はどこから編集すればいいんですか？」と聞かれにくくなるのも実感している。

そしてテンプレート側でも、投稿タイプごとにクエリを書けるから、無駄に条件分岐を書きまくらなくて済む。これはコーディング時のストレスがだいぶ減る。

「なくてもできる」は、「あるともっと楽になる」の裏返し

昔は「わざわざカスタム投稿タイプを使わなくても、カテゴリ分けでいけるんじゃ？」と思っていた。たしかに、そういう構成でも動くことは動く。でも、それって「ちょっと使いづらいけどまあ我慢する」みたいな状態だったんだと、今は思う。

カスタム投稿タイプって、導入ハードルはちょっとあるけど、一度覚えてしまえば構造化が圧倒的にしやすくなる。設計の段階で「これは分けておいた方がよさそうだな」と判断できるかどうかが、サイト全体の保守性に効いてくる。

結局のところ、私はどう使ってる？

私はオリジナルテーマを組むとき、「これは繰り返しが出そうだな」「投稿と混ざると違和感あるな」と思ったら、だいたいカスタム投稿タイプを使う。例を挙げるなら、コラム、制作実績、スタッフ紹介、FAQ、教室情報…こういうものは全部分けている。

結果、テンプレート構成がシンプルになり、メンテも楽になる。要は「あとから自分が楽できる仕組み」にしている。

コーディングを学び始めたころ、「この書き方で合ってるのかな…？」とずっと不安を感じていました。
HTMLやCSSを書いていても、動くことは動く。でも「このクラスの付け方って適切？」「もっと良い書き方があるのかも？」といった細かい疑問がモヤモヤと残ってしまう。

自己流になっていく怖さ

独学で進めていると、コードの正しさを確認する手段が限られていて、どうしても「自己流」に偏ってしまいがちです。
最初は教材通りにやっていても、次第に「なんとなくこうすれば動くから」と書いてしまうように…。

見えてきた選択肢：「コードチェックの外注」

そこで最近になって考え始めたのが「コードチェックの外注」でした。
つまり、現場経験のある人に自分のコードをレビューしてもらうという選択肢。

正直、最初はちょっと怖かったです。自分のコードを見せるなんて恥ずかしいし、ダメ出しされるのって勇気がいります。

実際は思っていたよりハードルは低かった

でも調べてみると、クラウドソーシングやココナラなどで、リーズナブルな価格（1,000〜3,000円くらい）でレビューをしてくれる方が意外と多いことに気づきました。
「レビュー受付中」といった形でフリーランスの方が出品しているのをよく見かけます。

レビューの内容も、コードの可読性、構造のクセ、命名の工夫など、具体的で学びが多いという声が多いです。

外注する前にやっておきたい準備

実際に外注する前に、これは準備しておいた方がいいなと思ったのが以下の点です：

1. ZIPでコード一式をまとめる
2. 見てほしいポイントを明確に伝える（例：HTML構造、命名、レスポンシブ対応）
3. 制作の目的を簡単に説明（例：ポートフォリオ用／模写練習 など）

これらを用意することで、レビューする側も状況がつかみやすくなるし、自分自身の頭の中も整理できます。

「自信がないからこそ、頼ってみる」が正解かも

結局、「自信がないから依頼できない」じゃなくて、「自信がない今だからこそ、プロの意見をもらう」という方が、結果的に成長スピードが早くなる気がしています。

まだ私は外注をしたばかりというわけではないんですが、今まさに「やってみよう」と思えてきたところ。
もし、この記事を読んでくれた誰かが同じような不安を感じていたら、「一歩踏み出してみると、意外といいかもよ」と伝えたいです。