ホーム > blog
  • 話題のAIのChatGPTを利用してみたら、なんだかとてもすごくて、驚きました。

    アドベントカレンダーも5日目となり、だんだんネタが無くなってきましたので、昨今の流行りを取り入れてみたところ、すごくびっくりしました。

    Webに関わる人なら、なんとなく最近見聞きしたことがあると思います、なにかしら文章を入れるとそれに対する文章をサクッとAIが作成してくれるシステム。 ChatGPTを使ってみた結果です。見出しのテキストを入れると、ほんの数秒で下記のように返ってきました。

    WordPressでタイトルと本文を表示するPHPのソースコード

    <?php
    if ( have_posts() ) :
      while ( have_posts() ) : the_post();
    ?>
    
    <h1><?php the_title(); ?></h1>
    <div><?php the_content(); ?></div>
    
    <?php
      endwhile;
    endif;
    ?>

    WordPressの関数を利用してhoge.cssとfuga.jsを読み込む

    <?php
    function my_scripts() {
      wp_enqueue_style( 'hoge', get_template_directory_uri() . '/hoge.css' );
      wp_enqueue_script( 'fuga', get_template_directory_uri() . '/fuga.js' );
    }
    add_action( 'wp_enqueue_scripts', 'my_scripts' );
    ?>

    WordPressのカスタム投稿タイプとしてslugをmeganeにして、ラベルが眼鏡を作成

    <?php
    function create_post_type() {
      register_post_type( 'megane',
        array(
          'labels' => array(
            'name' => __( '眼鏡' ),
            'singular_name' => __( '眼鏡' )
          ),
          'public' => true,
          'has_archive' => true,
        )
      );
    }
    add_action( 'init', 'create_post_type' );
    ?>
    

    投稿タイプのスラッグがhogeの中より、最新の3件を取得するサブクエリ

    <?php
    $args = array(
      'post_type' => 'hoge',
      'posts_per_page' => 3,
      'orderby' => 'date',
      'order' => 'DESC'
    );
    $query = new WP_Query( $args );
    if ( $query->have_posts() ) :
      while ( $query->have_posts() ) : $query->the_post();
        the_title();
      endwhile;
    endif;
    ?>
    

    投稿タイプのスラッグがhogeの中より、カスタム分類のtaxonomyがfugaのなかでtermがpiyoで、カスタムフィールドのkeyがevent_dateの中の日付の順で最新の3件を取得するサブクエリ

    <?php
    $args = array(
      'post_type' => 'hoge',
      'posts_per_page' => 3,
      'tax_query' => array(
        array(
          'taxonomy' => 'fuga',
          'field' => 'slug',
          'terms' => 'piyo'
        )
      ),
      'meta_key' => 'event_date',
      'orderby' => 'meta_value',
      'order' => 'DESC'
    );
    $query = new WP_Query( $args );
    if ( $query->have_posts() ) :
      while ( $query->have_posts() ) : $query->the_post();
        the_title();
      endwhile;
    endif;
    ?>
    

    WordPressの記事において、該当するカテゴリーをリンクなしのラベルだけでリストとして表示

    <?php
    $categories = get_the_category();
    foreach ( $categories as $category ) {
      echo $category->name . ' ';
    }
    ?>
    

    たいへんだ!!!

    なんて良い精度なのでしょう。多少修正する必要はあるかもですが、大体あってます。しかも日本語で質問して、日本語で答えてくれてます。しかもコードだけじゃなくて、前後に概要も説明してくれてます。

    えー!!ちょっとなんの気なしに試しただけだったんですが、随分とすごいことになってました。ちょっと前にGitHub Copilotとかの話がでてきた。ぐらいに思っていたのですが。これはもうあれですね。近い将来対話式で大抵のプログラムを使う方はできちゃうのかもしれませんね。

    色々言われていたのは、知ってたのですが。いままさに体感しました。これはすごい。これ使ったほうが、色々早く出来ますね。

    いやーすごい。

  • URLを貼り付けてもらうためにする努力

    今日は、この記事は #Backlogアドベントカレンダー2022 by #JBUG の12月4日分の記事として書いています。

    さて、上記のテキストもそうなのですが、該当ページへのURLがありますね。この “URLの貼り付け” こそがこの記事の主題になります。そして、Backlogの課題テンプレートを利用すると良さそう。というお話です。

    URLがコメントに有ると、とても助かります。

    突然ですが、メールにしろ、チャットにしろ、議事録にしろ、課題管理ツール内でのコメントでも、コミュニケーションする場合に、どこかの内容に言及することは多いです。そんなときに該当のURLが有るのと無いのでは、全く仕事の進みが全く異なります。たとえば

    ボタンを押しても、送信されません。至急修正願います。

    こういう、修正要望があった場合に、まず作業者は「どのボタンなのかを特定する。」作業から実施します。しかも至急と入っているので、ザワザワしますし、私の場合は「出来るなら早く修正したほうがいい案件なんだな。」と認識して動きます。

    この際に、

    • 不具合の背景
    • どこから遷移して、どのような状態で、どこをクリックしたら、どうなったのか。
    • 利用しているデバイス情報
    • ログインの有無
    • 検証ツールでのエラーの有無

    などなど色々記述が有れば有るだけ有り難いです。しかし、私の普段のクライアントワークでは、プログラミングなどとは全く関わりのない仕事をされる方と一緒にプロジェクトをすすめる機会が多いため、それほど多くは期待できませんし、お願いすることが難しいです。そんな中、比較的簡単に多くの情報が得られるのがURLを貼り付けることだと考えています。

    ただ、このURLをコメントと一緒に貼り付ける。という行為が常に出来る人は、多くありません。もし「普段からURLを貼り付けているよ。」という方は、とても素敵な方です。普段から気にしていただいて、ありがとうございます。

    そして、「え。そうなの?しらなかった。」という方はぜひぜひ、URLを今後貼り付けてみて下さい。少なくとも私は喜びます。

    URLがコメントにない理由

    いろいろ考えたのですが、貼り付けてもらえない理由として以下を考えました。

    • URLを貼り付けると、その後の作業がスムーズに進むことを知らない
    • 気が付かなかったから
    • 忘れていたから
    • 不要だと思ったから
    • 面倒だったから

    上の方が無意識で。下に行くに従って判断した上でURLを貼り付けない。となっているのですが、多くの場合、無意識的にURLが貼り付けられないパターンが有ると思います。

    無意識はその言葉の通り無意識なので、なかなかお願いしても実施されないことが多いです。実際私も、こんなにURLが大切!と言ってるのに、貼り付けてないケース有ると思います。そこで、チームの人にURLを貼り付けてもらうために、私がやってる方法です。

    ひとまず自分はなるべく忘れずに頑張る

    まずは自分がやらないと話になりませんので、なるべくURLを貼り付けます。無意識にでも出来るぐらい、とにかくURLを貼り付けます。

    「URLがあると、仕事がしやすいなあ。」と感じる人が増えれば増えるほど、互いの使徒語がしやすくなるはずなので。昭和的な表現かもですが背中を見せる。良いお手本になることを心がける。といった感じですね。

    人のコメントにもURLを貼り付ける

    これはちょっと、嫌な感じかもしれません。でも、そのコメントから作業を始める場合に、何度もURLを調べることになるのは全体にとっても良くないので、コメントを追記する形で、URLを貼っておきます。

    ありがとうございます。このURLの部分であってますか? https://hogehoge.com/fuga

    可能であれば今後、こういった形でURLを貼り付けていただけると有り難いです。

    とか、

    これから作業を進めます。該当のURLは以下のとおりです
    – https://hogehoge.com/fuga
    – https://hogehoge.com/piyo

    なら自然でしょうか。

    私のスタンスとしては、URLを貼り付けるのを強制したいわけではなく、うまくURLをはりつけることが、プロジェクトやチームのメンバーに広まって、作業の効率があがればいいあな。ぐらいなので、こういう感じになります。あくまでもお願いですね。

    あんまりURLを指摘するあまり、URL警察のようになってしまって、メンバーがコメントを書くことさえも億劫になってしまう。となるとまったくもって本末転倒なので、このぐらいにしています。

    課題テンプレートを使う

    はい、ここでやっとBacklogです。これはBacklogのスタンダードプラン以上を利用いただいている人だけ限定にはなるのですが、課題テンプレートが使えます。

    課題を書く際に、予め設定されたテンプレートが入力枠に表示され、ある程度の強制力を仕組みとして持たせることが出来ます。

    最近使っているのは、こんなテンプレートです(markdown記法をスペース全体で採用しています。)

    # 該当URL
    
    # 概要

    これを設定しておくと、課題を書くときにはこのようになります。

    シンプルですが、割と効果的でURLを貼り付けてもらえる可能性が高まった実感があります。

    そもそもURLが無い場合もある

    例えばメールのスレッドでしょうか。何回もメールでやり取りをしたり、以前のメールでのやりとりの中の一部のコメントを参照したい場合になどには、該当箇所にURLが存在しないケースが多いと思うので、URLを貼り付けることが難しいですね。

    こんな場合には、引用のテキストを書くなり、その部分をキャプチャ画像を切り取ったりして、共有することになります。これはこれで手間がかかりますね。

    しかし、最近のチャットツールや課題管理ツールなどであれば、そのコメント毎にURLあります。もちろんBacklogにも課題のURLもありますし、コメント毎にもURLがあります。

    コメントの日付部分をクリックすればアドレスバーに該当のコメントのURLが出ますし、・・・のアイコンからURLをコピーすることも可能です。

    URLを貼り付ける。という面でも、メール以外のツールを使うメリットがありますね。メールだけで仕事をするよりも、Backlogなどのツールを使ったほうが効率があがりやすいですよ。というお話が有ると思いますが、これはまたいつかの機会に。

    URLだけを貼り付けるほうがわかりやすい場合もある

    この記事を見て、「なるほど了解、じゃあ今度からはリンクを設定するようにしよう。」という方、ありがとうございます。ただここも相談させて下さい。リンクにするかURLのまま貼り付けるかという内容です。

    このリンクは実はWikipediaに飛ぶようにしています。そして、リンク先に飛んでから「あ、そういう意味なの?」となった人も少なからずいるはずです。

    次にURLを貼り付ける形にしてみます。

    どうでしょうか。リンクをクリックするまでもなく、wikipediaのリンクであるということがURLからわかります。このことから、今クリックすべき内容かどうかが判断できやすくなります。

    URLのドメインなどから、取得できる情報は割と多くて、もちろんケースバイケースとなりますが。URLはシンプルにURLとして貼り付けてもらえると良い気がしています。

    URLを貼り付けてくれる人が増えますように

    ということで、この投稿を終えましょう。色々言いましたが、

    • URLが情報に有ると嬉しいです。
    • URLがコメント毎に存在するツールを使うと楽に実施できるので良いです。
    • BacklogとBacklogの課題テンプレートがおすすめです!

    以上、4日目のアドベントカレンダーでした。最後まで読んでくださってありがとうございます。私自身の#自分アドベントカレンダー_めがねとしても続いています。どうぞ明日以降もよろしくお願いいたします。

  • snow_monkey_template_part_render_template-partsを利用し、色んな所に 😩 を表示する

    サッカー日本代表、決勝トーナメント進出おめでとうございます!! 🎉 しっかり見てしまって、今頃とても眠いです。こういう時事ネタを入れられるのもアドベントカレンダーらしいかなと思っています。

    そして今日の記事です。昨日の 「snow monkeyのフィルターを使ったカスタマイズでよく利用するもの 」の続きをお届けします。今回はsnow_monkey_template_part_render_template-parts を利用したものです.

    では、いってみましょう! オナシャース。

    色んな所に😩を出す

    一覧ページ

    /**
     * 一覧の画像に重なる分類の最後に😩
     *
     * @param string $html 中身の内容.
     */
    function megane_entry_summary_term( $html ) {
    	$html = str_replace( '</span>', '😩</span>', $html );
    	return $html;
    }
    add_filter( 'snow_monkey_template_part_render_template-parts/loop/entry-summary/term/term', 'megane_entry_summary_term', 10, 3 );

    /**
     * 一覧の記事タイトルの最後に😩
     *
     * @param string $html 中身の内容.
     */
    function megane_entry_summary_title( $html ) {
    	$html = str_replace( '</h3>', '😩</h3>', $html );
    	return $html;
    }
    add_filter( 'snow_monkey_template_part_render_template-parts/loop/entry-summary/title/title', 'megane_entry_summary_title', 10, 3 );
    /**
     * 一覧の抜粋分の最後に😩
     *
     * @param string $html 中身の内容.
     */
    function megane_entry_summary_content( $html ) {
    	$html = str_replace( '</div>', '😩</div>', $html );
    	return $html;
    }
    add_filter( 'snow_monkey_template_part_render_template-parts/loop/entry-summary/content/content', 'megane_entry_summary_content', 10, 3 );
    /**
     * 一覧のメタの最初に😩
     *
     * @param string $html 中身の内容.
     */
    function megane_entry_summary_meta( $html ) {
    	$html = str_replace( 'c-meta__item--author">', 'c-meta__item--author">😩', $html );
    	$html = str_replace( 'c-meta__item--published">', 'c-meta__item--published">😩', $html );
    	$html = str_replace( 'c-meta__item--categories">', 'c-meta__item--categories">😩', $html );
    	return $html;
    }
    add_filter( 'snow_monkey_template_part_render_template-parts/loop/entry-summary/meta/meta', 'megane_entry_summary_meta', 10, 3 );

    詳細ページ

    /**
     * 詳細のタイトルの最後に😩
     *
     * @param string $html 中身の内容.
     */
    function megane_entry_header( $html ) {
    	$html = str_replace( '</h1>', '😩</h1>', $html );
    	return $html;
    }
    add_filter( 'snow_monkey_template_part_render_template-parts/content/entry/header/header', 'megane_entry_header', 10, 3 );
    /**
     * 詳細のタイトル下のメタのそれぞれの最初に😩
     *
     * @param string $html 中身の内容.
     */
    function megane_entry_content_meta( $html ) {
    	$html = str_replace( 'c-meta__item--author">', 'c-meta__item--author">😩', $html );
    	$html = str_replace( 'c-meta__item--published">', 'c-meta__item--published">😩', $html );
    	$html = str_replace( 'c-meta__item--categories">', 'c-meta__item--categories">😩', $html );
    	return $html;
    }
    add_filter( 'snow_monkey_template_part_render_template-parts/content/entry-meta', 'megane_entry_content_meta', 10, 3 );
    /**
     * 詳細のコンテンツ下のプロフィールボックスに😩
     *
     * @param string $html 中身の内容.
     */
    function megane_profile_box( $html ) {
    	$html = str_replace( '</h2>', '😩</h2>', $html );
    	return $html;
    }
    add_filter( 'snow_monkey_template_part_render_template-parts/common/profile-box', 'megane_profile_box', 10, 3 );
    
    /**
     * 詳細のコンテンツ下の次前のナビゲーションに😩
     *
     * @param string $html 中身の内容.
     */
    function megane_prev_next_nav( $html ) {
    	$html = str_replace( 'c-prev-next-nav__item-label">', 'c-prev-next-nav__item-label">😩', $html );
    	$html = str_replace( 'c-prev-next-nav__item-title">', 'c-prev-next-nav__item-title">😩', $html );
    	return $html;
    }
    add_filter( 'snow_monkey_template_part_render_template-parts/content/prev-next-nav', 'megane_prev_next_nav', 10, 3 );

    足すだけでなく、フックに掛かっているものを外す場合

    /**
     * 詳細のタイトル下のメタをすべて取り外す
     */
    function megane_remove_entry_summary_meta() {
    	remove_action( 'snow_monkey_entry_meta_items', 'snow_monkey_entry_meta_items_published', 10 );
    	remove_action( 'snow_monkey_entry_meta_items', 'snow_monkey_entry_meta_items_modified', 20 );
    	remove_action( 'snow_monkey_entry_meta_items', 'snow_monkey_entry_meta_items_author', 30 );
    	remove_action( 'snow_monkey_entry_meta_items', 'snow_monkey_entry_meta_items_categories', 40 );
    }
    add_action( 'snow_monkey_entry_meta_items', 'megane_remove_entry_summary_meta', 9 );
    

    フックの中身を空で返す

    /**
     * フックの部分をごっそり削除する場合
     */
    add_filter( 'フックの場所', '__return_false' );

    というわけで、個人的によく使いそうなところをメモも兼ねて一覧しました。それぞれの箇所において、ただ 😩 をつけただけですが。

    実際には、例えば特定のタグにclassを動的な条件でつけて見栄えを変えたり、付近にカスタムフィールドから取得した情報を付与したり、いろんな事をしてます。

    https://twitter.com/inc2734/status/1598510102516236288

    と作者のキタジマさんも言ってくれてる通り、これらのフックを利用してカスタマイズすることで、基本的なフレームワークとしての外観や出力の継続的なサポートをSnow Monkeyに任せつつ、必要な部分だけをカスタマイズしてサイトを作っていく手法が最近は気に入ってます。

    ありがたい限りですね。


    今日も無事に書けました!! 明日からは休みなので気が抜けて、飛んでしまいそうです。いやいや頑張れ私。明日も続きます!!

  • snow monkeyのフィルターを使ったカスタマイズでよく利用するもの

    Snow Monkey / unitone Advent Calendar 2022の二日目の記事としてお送りします。

    My Snow Monkeyプラグインを利用してSnow Monkeyをカスタマイズしますね。そのときにadd_action関連なら、HAPPY SNOW MONKEY | 100%GPL有料WordPressテーマ Snow Monkeyの非公式カスタマイズデモサイト を参考にするのがいいとも思います。

    いつも大変お世話になってます。昨日のアドベントカレンダー初日の記事もおすすめです。Snow Monkeyを使ったウェブサイト制作チップス2022

    じゃあ、この記事は何か?というとadd_filterを利用したカスタマイズで、よく使うものを集めました。フィルターフックについてはこちらをご覧ください。 add_filter() | Function | WordPress Developer Resources

    では、早速参りましょう!

    theme_mod_関連を利用したカスタマイズ

    こちらは、主にカスタマイザーから設定できるレイアウトの変更について紹介しています。「じゃあ、カスタマイザーでいいじゃん?」となるかもですが。色んな事情があります。

    例えば特定のカテゴリーとその子のカテゴリーだけ、レイアウトを変更したいとか。ログインしてるユーザーの権限でレイアウトを変えたいとか。なにかしらの条件でレイアウトが変えたい場合があるわけです。そのときにはこちらを利用してます。

    ヘッダーは全体の theme_mod_header-potition とPC用の theme_mod_header-potition-lgで設定します。

    /**
     * ヘッダーのレイアウト変更
     *
     * @param string $setting レイアウトのセッティング
     * sticky : 上部固定
     * sticky-overlay : オーバレイ(上部固定)
     * sticky-overlay-colored : オーバーレイ(上部固定 / スクロール時背景白)
     * overlay : オーバレイ
     * '' : ノーマル.
     */
    function megane_header_layout( $setting ) {
    	$setting = 'sticky-overlay';
    	return $setting;
    }
    // SP用.
    add_filter( 'theme_mod_header-potition', 'megane_header_layout' );
    // PC用.
    add_filter( 'theme_mod_header-potition-lg', 'megane_header_layout' );

    ページ自体のレイアウトはこちら。レイアウトの名前を今回一覧にしたのは、ワタシ的に今後使いやすそうです。

    /**
     * レイアウトを変更
     *
     * @param string $setting レイアウトのセッティング
     * blank-content : ランディングページ(ヘッダー・フッターあり)
     * blank : ランディングページ
     * blank-slim : ランディングページ(スリム幅)
     * one-column : 1カラム
     * left-sidebar : 左サイドバー
     * one-column-slim : 1カラム(スリム幅)
     * one-column-full : フル幅
     * right-sidebar : 右サイドバー.
     */
    function megane_layout_setting( $setting ) {
    	$setting = 'one-column';
    	return $setting;
    }
    add_filter( 'snow_monkey_layout', 'megane_layout_setting' );
    

    snow_monkey_get_template_part_args_を利用したカスタマイズ

    snow_monkey_get_template_part_args_hoge を利用すると、設定をサクッと変更できます。これで事足ることもわりとありますね。

    ハンバーガーメニューの下の文字をカスタマイズします、なくしたいときは空でかえします。

    /**
     * ヘッダーのハンバーガーナビの文字を変更
     *
     * @param array $args ハンバーガーボタンの設定.
     */
    function megane_hamburger_btn( $args ) {
    	$args['vars']['_label'] = '👓';
    	return $args;
    }
    
    add_filter( 'snow_monkey_get_template_part_args_template-parts/header/hamburger-btn', 'megane_hamburger_btn' );

    カテゴリー毎に特定のヘッダー画像と文字を入れたいなどの場合はこちら。文字と背景画像を設定します。

    /**
     * アーカイブのヘッダー中身を変更する
     *
     * @param array $args ヘッダーのアイキャッチ部分の設定.
     */
    function megane_page_header_arg( $args ) {
    	$args['vars']['_title'] = '👓';
    	$args['vars']['_image'] = '<img src="' . MY_SNOW_MONKEY_URL . '/dist/img/something.png" alt="something">';
    	return $args;
    }
    
    add_filter( 'snow_monkey_get_template_part_args_template-parts/common/page-header', 'megane_page_header_arg', 10, 3 );

    次前のリンクを同カテゴリに絞る

    /**
     * 下部の次前の記事へのリンクを同じカテゴリーのみに限定する
     *
     * @param array $args 次前の設定.
     */
    function megane_prev_next_nav( $args ) {
    	$args['vars']['_in_same_term'] = true;
    	return $args;
    }
    add_filter( 'snow_monkey_get_template_part_args_template-parts/content/prev-next-nav', 'megane_prev_next_nav' );

    アイキャッチのサイズを変更する。
    カテゴリごとに、レイアウトが違うときなどは、最適なサイズを選ぶほうが表示が軽くなったりしていいですよね。

    /**
     * 一覧のアイキャッチのサイズをthumbnailに変更
     *
     * @param array $args 次前の設定.
     */
    function megane_archive_thumbnail_size( $args ) {
    	$args['vars']['_thumbnail_size'] = 'thumbnail';
    	return $args;
    }
    add_filter( 'snow_monkey_get_template_part_args_template-parts/loop/entry-summary/figure/figure', 'megane_archive_thumbnail_size', 10, 3 );

    404の文言を変更する。

    /**
     * 404のメッセージ変更
     *
     * @param array $args は404で表示される文言.
     */
    function megane_404_message( $args ) {
    	$args['vars']['_message'] = 'お探しのページは見つかりませんでした。';
    	return $args;
    }
    add_filter( 'snow_monkey_get_template_part_args_template-parts/content/entry/content/404', 'megane_404_message', 10, 3 );

    というわけで、本日はここまでです。

    おそらくこれまでにカスタマイズされたことのある人は、あれ?一番良く使うはずの snow_monkey_template_part_render_template-parts の例は?となったはずです。

    それはまた次回!まだまだアドベントカレンダー期間は続きますからね。きっとどこかでかくと思います。ではまた明日。

    とりあえず二日連続で書けてよかったです。

    いま、改めて調べたら、色々書いてあるものがあったので、こちらも参考に

  • タクソノミーとタームの覚え方。長いほうがタクソノミー

    WordPressにはカスタム分類という機能があり、デフォルトで投稿が持っているカテゴリーとタグの他に分類を任意に追加可能です。

    これら分類を元に条件分岐をする関数に

    is_tax があります。

    パラメータについて、以下のようになっています。

    • 第一引数
      • $taxonomy
    • 第二引数
      • $term

    分類には親と子のような概念があり、$taxonomyが親で、$termが子なのですが。これがなかなか直感的に覚えられませんでした。

    そこで、Twitterで聞いてみたところ

    https://twitter.com/megane9988/status/1594697158762328064

    わかる。っちゃあ、わかるんですが。直感的かなあ?

    となりまして、色々考えたところ。

    直感的に文字の長いほうが短いのをぐるっと囲めるから親!

    ということで覚えられました。

    イメージ的にはこんな感じです。

    個人的には大変気に入っております。

    ちなみにhas_termという今の記事がその分類を持ってるかどうかを判別する関数もあるのですが、こちらは

    • 第一引数
      • $term
    • 第二引数
      • $taxonomy

    となっておりis_taxと順序が逆なので要注意です。うっかりするとずっとfalseが返ってきますよ。

    というわけで今日から始まりました自分だけアドベントカレンダー。明日に続きます!続けられますように。




  • 終わりの会について

    こんばんわ!弊社ではフルリモートワークが3年ぐらい続いています。皆様の会社ではいかがでしょうか。そもそもリモートワークできないという職種の方にはすいません。今回はリモートワークをされている方に向けた記事となります。

    リモートワークで問題として取り上げられやすい、「質問したいけど、できない」、「雑談が難しい」、「ついつい働きすぎてしまう問題」といった問題の解決に多少なりとも貢献している弊社の取り組みに終わりの会があります。それをご紹介します。

    mgnで行う終わりの会の概要

    弊社基本の働く時間が10:30AM-7:30PMで、終わりの会は6:30PMぐらいから準備して、6:40PMぐらいからはじまります。終わりの会は、基本全員参加で、日替わりで司会をSlackのBotがランダムで選出し、司会担当の進行で進みます。一人ずつ、今日の小話と、今日の作業としてやったことを話します。

    小話について

    まず小話。これは昨今のリモートワークにおいて、不足しがちな雑談を生み出すきっかけになっている気がします。昨日見たアニメでも、今日の晩御飯でも、気になった記事でも、何でも良いので少し話してもらいます。聞いてるメンバーはそのままzoomでリアクションしたり、zoomのチャットを使ってコメントしたりしてます。いろんなトピックが聞けるので楽しいです。

    小話は人によっては、なかなかプレッシャーかもしれませんから、無いなら無いでOKとしています。それでも小話をしているのは狙いが少しあります。アドリブ力を身につけてもらうということです。リモートのミーティングなどにおいて急に「xxさんは、なにか意見ありますか?」とかって振られることありますよね。そういうときにちゃんと話せる力は、大切な力の一つだと考えていて、普段から練習してないと、なかなかできないと思います。それが少しでも小話でトレーニングできるかなと考えています。司会が毎日変わるのもそのトレーニングの一環です。

    今日の作業報告について

    今日の作業では、共有しているチームのNotionに書いてもらってる、それぞれ個人の課題より、今日やったことなどを、画面共有してもらいながら話してもらいます。毎日進捗を聞けるので、遅れたり進んでたり、互いに忙しさが認識できるようにしています。また、解らないことについても、「誰か知ってる人いますか?」 と聞いたり、誰かが助けたりできます。

    画面共有しながら話をするというのも、リモートでの打ち合わせにおける必須スキルの一つと考えていて、それのトレーニングも兼ねています。

    仕事を終える区切りとなる

    現在弊社では大体10人ぐらい在籍しているので、全体で30分-40分ぐらい終わりの会をしてます。終わりの会がおわったら、ひとまず今日の仕事は終わりということになります。一旦区切りがつくので、働きすぎるということを防ぐことにも役立っていると感じています。

    どうやって時間を捻出するか

    毎日30−40分時間をとるのは難しい。と感じられるかもですが、こういった時間が取れて且つ、仕事がうまく回っているのが、良いことだと考えているので、そうできるように先にこの時間をとっておくことから初めて、結果3年ぐらい続いているので、弊社では大丈夫でした。

    勿論忙しい日には、時短バージョンとして、それぞれ、一言づつ言って終わる場合や終わりの会自体をスキップすることもあります。

    同様の方法で週3日休みを、月に2回、各人に設けているのですが、それもなんとかなっています。ので、先に時間をとっておくのはいい方法だと思います。このあたりはまた別の記事で。

    弊社の終わりの会の取り組みのご紹介でした。まだまだ始まったばかりのリモートワークなので、リモートワーク自体がちょっとした工夫で、今よりもっと良くなるような気がしています。うちではこうしてるよー的な取り組みがあればぜひTwitterなどで教えて下さい。

    最後までお読みいただき、ありがとうございました!

  • フルサイト編集用のテーマを自作してみた感想

    あけましておめでとうございます。2022年もどうぞよろしくおねがいいたします。さて、早速ですが、本題です。このサイトのテーマをWordPress5.9よりいよいよ本格的に導入されるフルサイト編集に対応したテーマに作り直してみました。

    フルサイト編集とは?

    平たく言うと、これまでPHPを編集しないと難しかったヘッダーやフッター、ループを利用した情報の取得と表示などが、WordPressのブロックエディターを利用して編集できるようになる仕組みです。くわしくはこちらを読んで頂くのが良いと思います。

    出来たもの

    今ご覧いただいているサイトです。今後も編集していくと思いますが、こちらに最新版をGitで管理していくつもりなので、気になる人はご覧ください。(ロゴの設定などは直接テーマ上で設定しているので、そのままの他サイトでの利用はちょっと難しいです。)

    なるべく、シンプルにわかりやすくしたかったので、テンプレートもテンプレートパーツも必要最低限に作りました。

    テンプレート

    テンプレートパーツ

    全部HTMLのファイルになる

    上記を見ていただければわかると思うのですが、テンプレートはHTMLにて保存します。これまでのようにPHPでのファイルはfunctions.phpのみとなり、テンプレートでは利用しないようです。

    じゃあ、どうやってDBから情報を取り出すのか?というと、これらもブロックから取得します。

    動的に取得できるブロック

    たとえば、この記事の表示にも利用している singular.html では、以下のようにブロックを並べてテンプレートを作っています。パンくずのみプラグインによる提供ですが、それ以外は、全てコアのものだけを利用しました。

    • Yoast Breadcrumbs
      • Yoast SEOプラグインが提供するパンくず用のブロック
    • 投稿タイトル
    • 投稿日
    • 投稿カテゴリー
    • Post Author
    • 投稿タグ
    • 投稿コンテンツ
    • 前の記事
    • 次の記事

    ということで、シンプルなブログのようなものは、現段階でも問題なく形にできそうなだなーという印象です。

    足りないものはカスタムブロックを自作するということになるのですが、おそらくそれも今後利用者が増えるにあたって。基本的なところは十分にカバーされるように充実していくのだろうなーと感じました。

    どうやって作っていくのか?

    実際に作る場合は、ハンドブックを見ながら手を動かすのがいいと思います。私もそうしました。

    その時の私の作業まとめはこちらにあるので、よろしければ、合わせてご覧ください。

    作業の中でのトピックスをお伝えします。

    theme.jsonで共通設定を行う

    サイト幅、フォント、文字サイズなどはtheme.jsonに設定しておくと、色んな所で使えるので便利そうです。例えば文字サイズについていくつか追加したのですが、結果として、右パネルから各ブロックごとに追加した文字サイズを選べるようになりました。

    その他にも、こちらで設定は色々できそうです。今後もいろいろ試したり、他のテーマを参考にしたりしたいですね。

    試しながら作りながら、テーマづくり

    見たまま作業できるのがブロックエディターの良いところですが、それがそのままテーマづくりに活かせます。ほとんどCSSを書かずに大体のレイアウトや必要な要素が設定できるので、それを元に後からCSSを追加する行程が良いかと感じました。

    なんせ、そのまま作れるので、ブロックエディターの操作が上手な人で、ブロックをたくさん知ってたり、ブロックパターンとしての組み合わせの知識が多くなると、テーマが素早く作れそうに感じました。

    そもそもなのですが、ブロックエディターから出力される各ブロックのコメントを含めた内容をテンプレートに書いていくことになるので、ブロックエディターを使わずに、これまで利用してきたエディター(VS Codeなど)を利用してコーディングしようとすると、かえって覚えないといけないことが多くなりそうです。なので、ブロックエディター上で作業をすすめるのが良さそうです。

    記事下部の次前の出力のレイアウトなどを変えた時

    出来たものをエクスポートすると、ファイルになるので、Gitなどでのファイル管理は可能です。

    ナビゲーションブロックが結構すごい

    メインナビゲーションに使っているブロックは、画面幅に応じてハンバーガーメニューとなり、階層的をもたせると、マウスホバーでそれを表示させるなど、細かな機能が最初からついています。気が利いていますね。とりあえずこれで十分に感じました。

    作ってみて、感じたこと

    この全く新しいテーマの制作方法にあわせた、いろんなテーマやブロックが出てくると考えられます。そうすると本当に簡単にテーマが作れるようになるので、Webサイトの本当の目的である集客や売上の向上などに時間を多く取れるようになるなと思いました。

    あったらいいなーと思ったブロック

    すでにコンテンツ内で利用できるブロックとしてはあっても、フルサイト編集時にテンプレート側では使えなかったりするブロックもありそうなので、思いつくままですが以下のようなものがあると便利そうだと感じました。

    • SNSのシェアボタン
    • 更新日
    • カスタムフィールドの表示
      • サブタイトルを出力するとかありそう
    • ハンバーガーメニューのかっこいいの
    • 関連記事
    • 著者プロフィール
    • 目次

    細かいところを実装しようと思うとカスタムブロックを作れる技術があったほうがよさそう

    テンプレート側ではショートコードブロックが使えないっぽいので、そのあたりカスタムブロックをつくる技術は必要になりそうですね。

    5.9のリリース段階でこんなに色々できるのは、とてもすごいなーと思います。私もなにかしら、コントリビュートできたらいいなーと感じました。

    今後もとても楽しみです。

  • 制作会社さんから、デザイン支給あり、かつクラシックエディター前提でのWordPressサイトのコーディング・組み込みを依頼された場合にどうするかを考える

    こちらは WP ZoomUP Advent Calendar 2021 の記事として書いています。ちょうどコチラのつぶやきがあり、自分ならどうするかなーと考えました。

    私は断然ブロックエディターがおすすめ

    まず前提ですが、私はクラシックエディターよりもブロックエディターのほうが便利で使いやすく、今後使い続けることを考えてもブロックエディターを選んだほうが良いと考えています。また最近はほぼ、ブロックエディターでサイトを作っています。

    なので、クラシックエディターよりブロックエディターがおすすめですよ。という進言をすると思います。ただ。そんなにシンプルでなく、いろいろ考えるところが沢山ありそうです。

    質問文から想像する本プロジェクト

    商流(座組)について

    「制作会社さんから、デザイン支給あり」ということで、こちらの案件の商流は以下になっていると想像できます。

    エンドクライアント ↔ 制作会社 ↔ 自分

    制作会社さんのブロックエディターへの理解度

    また、「クラシックエディター前提」というワードがあるので、おそらく制作会社さんは、ブロックエディターの経験があまりない。もしくはクラシックエディターに慣れている。もしくは、今回のプロジェクトがサイトのリニューアルで、これまでクラシックエディターで保存されていた記事が沢山ある。といった、クラシックエディターをあえて選ぶ理由がありそうに思われます。

    ブロックエディターを利用した制作フローの場合、ある程度ブロックの特性にあわせてデザインを組んだほうが、後々使いやすいものになります。これは、ブロックエディターだとデザインに自由度がなくなると言っているわけではありません。もちろんデザインを自由に変更もできるのですが、たとえばフロントページにおいて、セクションごとの並び替えを行ったり、間にバナーを追加するといったことが、テーマのPHP編集でなく、ブロックエディター側からできた方が、クライアントさんであとから操作できる幅が広がるわけです。そういった特性を理解してデザインが作られていると、なお良いですね。

    ただ、ブロックエディターをあまり考慮されないで作られたデザインの場合は、ブロックエディターの良さが、活かしきれない場合もでてくることでしょう。

    ブロックエディターを使うことで生まれる工数について

    WordPressでは、納品後にも保守が必要なので、保守も含めて制作会社さんが対応する予定で、またクラシックエディターに使い慣れているという場合に、制作会社さんだけの工数を考えると、ブロックエディターは使わないという判断になる可能性もありそうです。

    また、最終的にクライアントとのやり取りがあるので、デザイン的であったり、システム的に修正を制作会社さん側で請けられる可能性が高いです。そのときにカスタムブロックなどを導入していると、修正方法が分からないといったことも起きそうです。

    これまでにクライアントさんがクラシックエディターになれている場合には、なぜブロックエディターを利用するのか、どのように使うのか。ということを説明する必要も出てきます。

    このように、それでもブロックエディターを利用するとした場合には、それ相応のコストが掛かるということになります。もともとのクライアントさんからのオーダーが「あまり費用がかけられないので、いつもどおりでお願いします!」といった内容だと、そもそもこういったコストが掛けられないというケースもあると思います。

    プロジェクトにおけるパワーバランス

    さらに言うと、請負における上流から下流へのパワーバランスもあると思います。クラシックエディター前提ということでオーダーがあるので、そのまま作っていれば、上記のような工数や、このような疑問、悩みというのは生まれませんし、説得する必要もなくなります。

    それでもブロックエディターをオススメしたい理由

    とはいえ、よくクラシックエディターかブロックエディターかの選択の際にお話するのですが、いま初めてWordPressを触る人にとって、両方のエディターが並べられて好きな方を選んでくださいと言われたら、殆どの方はブロックエディターを気に入ってくださると思います。

    また、今後のWordPressの開発の方向を考えると、様々な便利な機能はブロックエディター側で開発が多くされることでしょう。

    以上の内容で、制作時にそれぞれの人にコストが掛かったとしても、最終的にきっと便利になるブロックエディターを進めたいという姿勢はお伝えしたいところです。

    できることならみんなで相談して決めたい

    できることならクライアントさんも含めて3社で、ビジュアルエディターを導入することのメリットとデメリットを共有した上で、どちらかに落ち着けるといいかなと思います。

    最終的に判断いただくのは、クライアントさんですし、今回の商流だと、制作会社さんでもあると思います。

    というわけで、どっち付かずな結論ですが、最終的に費用を出してくださるのはクライアントさんなので、制作者として、WordPress的目線ではコチラが良いですよという提案をお伝えし、その上でクライアントさんが納得いただく判断をいただければ、それが一番良いかなと思いました。