本記事のタイトルについて
There is more to life than increasing its speed.
人生には、速度を上げることよりもたくさん大切なことがある。
マハトマ・ガンディー - 宗教家
インドの宗教家 マハトマ・ガンディーの言葉に上記のようなものがあります。
本記事のタイトルである「Snow Monkey でも、制作速度を上げることよりたくさん大切なことはある」は、その名言をオマージュしました。
ガンジーの名言は、本記事の内容には全くこれっぽっちも関係ないです。
自己紹介
- 譜乃謡 詩哥 (Futai Shiica)
- 当ウェブサイトの総合管理者です。Snow Monkey 歴は 半年ほど。バーチャル美少女。
- Kmix39 - Kmical Lights
- エンジニアサークル「Kmical Lights」所属。当ウェブサイトのシステム開発の協力者。Snow Monkey 歴は、数年と長め。バーチャル美少女。
- 言ノ葉 テナ
- 元ウェブライター。構成作家。Snow Monkey 歴は、1 年半ほど。
3 人の出会いは、関西ウェブエンジニアのリモート飲み会。
ご注意
前年 (2020 年) のアドベントカレンダーで執筆した記事が「とにかく長い」と言われました。しかし、本記事はもっと長くなってしまっています。
制作速度を上げること とは…
例えば、アドベントカレンダーの記事のようにクリスマス時期に公開しなければならないウェブサイトがあったとする。それを、お正月に公開してしまうのは大問題になる。避けなければならないことだったりするよね?
他にも、現在運営をしているウェブサイトで突然のイベント中止などを公開することがあった場合なども同様ですね。その告知ページを作るのにモタモタしてしまっては告知のタイミングを見逃してしまい、大損害に繋がってしまうことにもなってしまう可能性もありますね。
ウェブサイトで公開までの期間を減らすことは、上記のように円滑にウェブサイトを運営する方法の 1 つと考えられています。それには、どうすれば良いでしょうか？
1 つ考えられることは「制作速度を上げること」です。ウェブサイトを制作されているクリエイターにとっても、制作速度を上げることは非常に重要です。制作速度が上がることでも依頼を多く受けられるようになるからです。
しかし、制作速度を上げるためには何をどうすれば良いのでしょうか? まずはその点から考えていきたいと思います。
制作速度を上げる には…
WordPress × Snow Monkey だけでも、大きく制作速度を上げることができますよね?
うん。可能と思う。
今の WordPress はコードを書かずにページを生成できるブロックの仕組みがあるし、Snow Monkey もその仕組みを支える為に用意されているブロックがすごく多い。なので、それらを利用してほとんど HTML や CSS と言ったコードを書かずに制作するだけでも、しっかりとしたウェブサイトとして公開できる。ページ構成を考えることと、画像や文章を用意することだけに集中できる点から、コードを書く制作時間を大幅にカットできる。結果的に制作速度は上がる。
ですが、機能が用意されていても、それを使いこなせることが重要ですよね? 使いこなせなければ、制作速度は上がりませんよね?
もちろん。機能を使いこなせると凄いことが短時間でできるようになるけど、逆に使いこなせてないと、すごく時間が掛かってしまう残念な結果になる。
他にも、使い続けていなくて再度使用したいと思った時に、やり方を覚えていなくて時間が掛かってしまうこともあるし、アップデートがされていて以前の使い方の通りできなくなっていたりとか。
そうですねー。使わない機能は解らないし、使い続けていないとすごく忘れやすいです。また、アップデートで変更されたことを知らないと、以前の操作方法で制作を進めようとして混乱してしまうこともありますね。
そのことから、制作速度を上げる為に考えられることをまとめてみます。
- 経験を積む
- 新しく経験することや何度も繰り返すことで、作業に慣れることができます。その結果、効率が上がり、制作速度が向上するでしょう。
- 使いやすい材料・道具を選ぶ
- 適材適所と言う言葉の通り、適した材料・道具を適した場所で使うことで、効率が上がるでしょう。「弘法筆を選ばず」と言いますが、この諺は正しく道具を扱うためにもあるのです。
- 材料・道具の状態を知る
- 材料や道具と言うのは、腐ったり新しくなったり状態が変化します。常に状態を管理し、使用する際は最善のパフォーマンスで使用すれば、制作速度も向上するでしょう。
の 3 点が重要になるのだと思いました。
制作速度を上げる方法や、制作速度を上げることも大事と言うことが、だいたい理解できましたね。
制作速度を上げることよりも大切なこと
……しかし、制作速度だけを上げるだけで、良いウェブサイトを制作可能になったと言えるのでしょうか?
公開 ≠ 目的
まず、ウェブサイトと言うのは公開するのが目的でしょうか? 何故、ウェブサイトを公開したいのか考えてみましょう。
Snow Monkey のテーマを全くカスタマイズもせずに公開してみよう。ほぼ、真っ白なサイト が表示されるのみだと思う。その状態を目的と言える人は居ないと思う。
ペイントアプリで言えば、新しく開いたキャンバス。何も用意されていない状態に閲覧者の心は揺さぶられない。
そうですね。ウェブサイトと言うのは、自分が表現したいコンテンツを公開する手段ですものね。そして、Snow Monkey のテーマ自体で、それを事前に用意されることは決して無いでしょう。表現したいコンテンツ自体は、制作される方がご自身で用意するしかありません。
ウェブサイトを公開する目的は、
- 自分の作品・意見を広めたい
- 集客したい
- 利益を上げたい
…他にも様々な理由が存在しているはずです。そして、ウェブサイトと言うのは、その目的を達成させる手段の 1 つです。
目的を達成するために向き合うこと
依頼された方と向き合う
さて、Snow Monkey やウェブサイトを制作されるのは、目的を達成させる手段であると話が進みました。
依頼者のやりたい表現や目的を理解して、目標を定めること。Snow Monkey を使用して、自分ができることや、できないことを判断しながら、依頼者のやりたい表現と目標を達成できるカタチに制作をスムーズに進める必要があるはずですが、果たしてどう進行するのが良いのでしょうか?
それは、意外と難易度が高いことだと思う。たびたび紹介されている「Snow Monkey を使用して制作する案件フロー」を参考にしたりして、実際に自分がやりやすい流れを見つけたり、依頼者と向き合い続けて話すことが重要と思う。そして、依頼者も「全部任せる」としないこと。
依頼者と親密に向かい合って相談するのが重要ですね。制作速度は下がる可能性がありますが、良いウェブサイトを制作するには必要かもしれません。
Snow Monkey は用意されたブロックを組み立てるだけでも魅力的に映るテーマですから、そこは見落としやすい点だと考えています。制作を依頼した方は、ウェブサイトについて素人の場合もあります。ただ綺麗に見えるだけの目的を達成できないウェブサイトであっても、魅力的に見えさせてしまうかもしれません。ですが、しっかりと向き合えば目的を達成させるための目標を定めるのは難しいことではありません。
なら、Snow Monkey の今のアップデート報告に関して向き合ってみた意見を書いてみようかな…。
slack では、お知らせチャンネルにあるからサポートフォーラムの新規スレッド通知とゴチャゴチャに届いてしまっているし、公式サイトからはサブスクリションしてないと見られない。何がどう変わっていったのかを後から調べることに関して、アップデート報告って全く機能していない気がしてる。
それはただのディスり……。
正直に思った言いにくいことを言っているだけなんだけど……。
この場合の判断には困りますね……。
もし、依頼で「ウェブサイトで集客上げたいと思っているのですが」って言われても、ウェブサイトで集客の増加が見込めない場合に「ウェブサイトと言う手段では、あなたのやりたいことに対して集客を増やせる見込みはありません」と伝えることも依頼者と向き合っていると言えますから。否定意見も 100% 悪いこととは言えません。
勝手なイメージを投げつけてきて、「この通り制作してくれ」とか「こう言うのが欲しい。とりあえずこうなれば良いから自由にやってください」って言う依頼者が時々居るけど、それも間違い。
依頼者自身も向き合わなければ、プロジェクトは成功しませんね。二人三脚で取り組むことも大切なことだと思います。
自身の実力に向き合う
さて、Snow Monkey にはサポートフォーラムがある。
そのサポートフォーラムでは過去に何でも質問で聞いてきて、仕事対応を代わりにして欲しいかのような状態になっていたこともある。よく読むと、「依頼されたけれど自分ではどうしようもないから代わりにコードを書いてくれ」と言うような内容だった。または仕事レベルの 1 からサポートをお願いされているようなのもあったことがある。
自分の実力以上のことを設定してしまった場合ですね…。依頼者と向き合うのも重要ですが、自分の実力と向き合うことを完全に忘れてしまってはいけませんよね。
どうすれば目的を達成できるか解らなくなって、目標を定められなくなる。結果、制作速度も下がる。
なので、目標は自分の実力に向き合いながら定める必要がある。
常にアンテナを張り続けること
サポートフォーラムには日々、新しい質問が来る。引き出しが作れていく。そうして、やりたいことの答えがすぐに解る状態になっていく……。
それはエンジニア気質な人だけできることでは?
いや、デザイナーでも誰でもできることだよ。
Snow Monkey のサポートフォーラムに対する引き出し作りなら「前にこう言う質問あって、こう言う答え方されていたなー」程度でできると思う。引き出しと言う言い方もあれば、アンテナを張ると言う言い方もある。中身まで覚えておく必要はなくて、どこを引いたら求めている答えがあるのか解る状態にしておくだけでも良い。「Snow Monkey ってこう言うこともできるんだ」って覚えておくだけでも OK。
Snow Monkey に関連したアンテナの張り方 (引き出しの作り方) には
- サポートフォーラムで、既存のスレッドから同じような悩みが無いか探す
- Snow Monkey で制作されているサイトなどを見て、構造を分析してみる
- WordPress や Snow Monkey のアップデート情報を知る
- WordPress 関係のイベントにも参加してみる
- 最近のウェブサイトについての流行やトレンドカラーを知る
- 依頼者の業界について分析をする
- 依頼者が発信するウェブサイトのユーザー層に対する分析をする
- 流行りのサムネイルのデザイン傾向も分析する
- 画像加工アプリや動画編集アプリの新機能を知り、試しておく
などが挙げられます。
張って終わりじゃなくて、アンテナの状態を最新にするのも必要だけど。
そうすると、何ができるか・できるようになったのか判断材料が、常に最新になる。だから「以前はできなかったけど、今ならできる」って考えが構築される。
そうなれば、依頼者に「以前は難しかったんですが、今だとこう言うことができるようになったので、やりませんか? こう言うことができると、こう言うカタチでの集客増加も見込めます」って提案もできる。依頼者の目的が、より良いカタチで実現に近づけられる。また「これができるなら、これもしたいな」って要望点が生まれる場合もある。それらの意見をまとめてサポートを受けたくなったらサポートフォーラムにも書くことで、情報や意見交換も行われる。結果的に Snow Monkey を成長させることにも繋がるかもしれない。
最後の方の、画像加工アプリや動画編集アプリの新機能を試すことは、道具のより便利な使い方を知れますね。結果的には、制作速度を上げることにも繋がりそうですね。
適材適所に使用すること
Snow Monkey を依頼者が求めている目的を達成させる道具として使う場合は、どう言う風に使っていくのが効果的なのでしょう?
難しいねー…。何も考えずにウェブサイトを制作するだけでは集客を増やすことは難しいし。それは Snow Monkey を使用しているか、していないかだけの問題ではなくて、どんなシステムを使っていても言えること。その目的を達成させるのに効果的なデザインや構成についての知識や、実際にそういった目的を達成させたウェブサイトの制作経験なども必要になってくるのでは?
Snow Monkey なら、そのために 類人猿[2] などのサービスを検討するのも良いかもしれない。ウェブ制作企業の経験と実績でその目的に応じたブロックパターンが作られているので、ある程度の判断材料にもなるはず。
なるほど。型が合えば、制作速度も上げられますね。
しかし、Snow Monkey などで用意された機能を使うにしても、すべてのパターンで最善となるとは限らないから注意は必要。
例えば、「お問い合わせを受け付けたい」となった場合。Snow Monkey を使用されている多くのユーザーなら Snow Monkey Forms[3] を使用するのを考えるかもしれない。私も過去にいくつか設置してウェブサイトを制作したけど、お問い合わせフォームと言うのが、現在ほとんど廃れてきていて、お問い合わせの機会を減少させるマイナスの要因にもなっていると言われていると知ってからは使うことがなくなった。
マイナスの要因になるんですか!?
そう言うデータや場合もあるってだけ。すべてがそうじゃない。だけど、実際にメールアドレスが SNS などのサービスを認証するだけに利用するものってなっている若い世代も増えてきている。それに Twitter や LINE でお問い合わせするサービスもすごく増えてきているでしょ? 宅配便の再配達や配達状況の確認が、いつの間にかウェブサイトや電話じゃなく LINE でドライバーと直接連絡できるようになっていたりしなかった?
実際に、とある企業のデータでは 1 件のお問い合わせに対して解決に繋がった時間を分析した結果、次のように記載されています。
- お問い合わせフォーム
- 5 日以上。お問い合わせの確認から返信までの間隔が非常に長いのが原因。
- 直接のメール送信
- お問い合わせフォームと同様に 4 〜 5 日。1 通 1 通の連絡の間隔が非常に長いのが原因。
- 電話応対
- 3 日間。何度も掛け直しが必要となったり、折り返し電話に出られなかったりなどが原因。
- Twitter や LINE などの SNS での担当者とのダイレクトメッセージ
- ほとんどのケースが即日。通知からの反応とスマートフォンでの返信のしやすさが解決までの速度を向上している。
ユーザー層やサービスの質にもよるから、お問い合わせの方法は数パターン用意すると良いかもしれない。
なるほど。既に Twitter や LINE などを使っているようなユーザー層をターゲットにされている場合であれば、お問い合わせフォームを新規で生成しなくて良いですね。
依頼者から「お問合せフォームが欲しい」と言われた場合に、「Snow Monkey なら Snow Monkey Forms あるので制作可能」 → 「Snow Monkey Forms を導入します」とする前に一度、お問い合わせを実際にしてくれるユーザー層か、お問い合わせフォームを生成するならどのように生成すれば入力をしていただけるか考える必要がありますね。
実際、お問い合わせフォームの維持や対応も結構なコストになるから、必要がなければ無理に生成しなくて良いと思う。
Snow Monkey や WordPress を使用し、実績が数件しかないのに関わらず「集客力の最大効果」とよく言って、宣伝している駆け出しエンジニアは、何故かお問い合わせフォームを付けたがる。何でだろうね…。
最大効果の集客力を出せるのであれば、その駆け出しエンジニアの方はそのウェブサイトで、もっと稼げているはずでしょう……。そして、その宣伝文句を言っているのが Twitter の呟きと言うのは何の冗談なのでしょう（笑）
駆け出しエンジニアや Snow Monkey Forms をディスる内容にもなってるように思えますが……。
いやいや。ディスしていないよ。お問い合わせフォームを使うなってことでもない。
実際に、お問い合わせフォームは新型コロナの感染増加前まではものすごく有効だった。ここ 1 〜 2 年でリモートワークが原因で、宅配便が増加した。結果、再配達や感染防止の一環としても、そう言うスムーズな相互連絡のシステムが急激に求められるようになった。人との接触を避けるためもあるだろうけど。それでお問い合わせの対応速度がスムーズな SNS などを利用したお問い合わせ対応ケースが全世界で爆発的に増えたんだ。
もし、返信までの時間が数日掛かっても良いとか、しっかりとした文章でお問い合わせをしたいとか、そう言う場合ならお問合せフォームは以前と同じように非常に有効だよ。本当に求めている人はお問い合わせが大変でも、お問い合わせしてくる。
何でも、適材適所が大事ですね。
ウェブサイト運営者の本音は、 Snow Monkey とかどうでも良い?
ウェブサイトの制作を依頼した方、もしくはウェブサイト運営者からしたら、Snow Monkey を使うかどうかなんて言うのは、本当はどうでも良いこととも言えたりする…。
どうでも良いなんて言うのは語弊があるかもしれませんね。キタジマタカシ[4] 氏に失礼。
いえ、ウェブサイトは手段ですから。ウェブサイト運営者が本当に望んでいるのが WordPress でも Snow Monkey でも無いと考えた上での言葉ですよね。
目的を達成させる為の手段・道具として、WordPress を選択しただけとも言えますね? もし、Movable Type や EC Cube と言った WordPress とは異なるウェブサイト制作のシステムが、制作の依頼者から見て WordPress より使いやすいシステムであれば、そちらを選択されるはずです。使いにくい道具をすすんで使用する人は居ません。また、より便利な道具が誕生すれば、そちらを使用するように選択する場合もあります。
オールマイティに使える万能ツールなんて、ウェブサイト制作をするのに存在しません。
Snow Monkey のキャッチフレーズ… どんな味付けにも染まる…… (ボソッ)
そのボソリは、完全にディスって言っていますよね…?
例えば、お刺身や卵かけご飯、ほとんどの料理に合う醤油があったとしても、ねるねるねるね × 醤油 をして食したいですか?
ねるねるねるね × 醤油 で例えてくるのはやめよう…。不味すぎるから。その組み合わせは絶対に合わない。
Snow Monkey のキャッチフレーズは、「どんな味付けにも染まる」から始まりますが、同時に 「WordPress テーマ」で終わっています。WordPress テーマであることも正しく伝えているキャッチフレーズですね。ですから、同時に「WordPress で達成できないことには、染まりません」と言われているんじゃないでしょうか?
WordPress でできないことを Snow Monkey でやろうとするのは、適材適所と言えません。
テーマ とは、まさに Theme であること
- テーマ
- ギリシア語 tithenai または théma (θέμα) がすべての語源とされる。その後はドイツ語の Thema に由来し、英語圏で Theme (/θi:m/) と似た言葉で伝わる。作品の主題、または中心となる題目を指す。研究論文や小説などにおいては、物語の主軸となる部分から取り上げられることが多い。
ウェブサイトでは個々のウェブページと主軸になるパーツとして、1990年代後半から認識されていたようです。ですので、 WordPress を使用したウェブサイト制作であっても、制作したいウェブサイトの主題や目的に合わせてテーマを選択することも大切なことの 1 つかもしれません。
"Low Code" と "NoCode" について考える
「すべての人に満足される存在は、存在できるのか?」と言う問題を知っていますか?
知っています。
「存在してほしくないと 1 人が望めば、その存在は存在できない」…と言うやつだね…。
すべての人に満足されるテーマにするのは無理かもしれませんが、Snow Monkey はそれに近いキャッチフレーズを掲げているように、それを目指されていますし、そうなっていこうと言う取り組みもされていますよね。
どのような取り組みをしているか考えてみましょうか?
うん。
コードを書かなくても豊富なブロックでウェブサイトを構築できるから、NoCodeだし、
また、コード書くとしてCSS は FLOCSS[7] を採用していることで、構造化も理解りやすい。かつ、かなりのカスタマイズに対応できる定義も予め用意されている。だから、スタイルを書く量も非常に少なくて済む。PHP でコードを書く場合でも、豊富に用意されたフックに対して、豊富に用意されているライブラリの処理を書き換えるだけで済むから、LowCode だと言える。実際にサポートフォーラムで回答されているような My Snow Monkey に書いてカスタマイズ対応するコードでも少ないコード量だし。
どちらの開発スタイルにも適用できるような設計になってる。ただし、My Snow Monkey は注意が必要。
サポートフォーラムで回答されているコードには、フックやスタイルで解決しているパターンがあるけど、理解せずにコピー＆ペーストされ続けると膨大なコード量に膨れ上がってしまった My Snow Monkey になる。そうなったものは、ゴチャゴチャと混ぜて書かれたスパゲッティなファイルになっていることも多い。実際に対応を引き継いだ Snow Monkey で制作されたウェブサイトの My Snow Monkey をみた時には、かなり解読コストを必要とした。
1 ファイルに CSS 書式やフックの PHP コードをゴチャゴチャと記述されているのは、せっかくの可読性を失くしてしまっていましたね。WordPress も Snow Monkey も ウェブサイトも変化していくものですので、作って終わりじゃないですね。なので、可読性を維持し続けるのは重要なことと考えられます。NoCode や LowCode と言ったところでも、それを支えているコードはしっかり有って、それは面倒を見続けなければならないでしょう。
一切カスタマイズをし続けずに Snow Monkey でウェブサイトを運営し続けるなんてことはないから、ウェブサイト制作をする以上はコードと向き合わなくちゃいけない。My Snow Monkey をメンテナンスできる程度の技量は必要で、サポートを受けたとしても、その回答のコードを理解する力を持ち続けなければならないから。
それを踏まえれば、ウェブサイト制作者にとって、NoCode か LowCode と言うのは関係ないかもしれない。コードは必ず書く必要があるから。ずっとコードを書かなくて良いのは制作依頼者だけと言えそう。
「脱 WordPress」も、選択の 1 つなこと
ここまでの話を踏まえると、アンテナを張り続けたり、適材適所に使えるように維持したり、大変なことばかりですね。
すごく大変だと思う。Snow Monkey は基本的に解らない部分はサポートフォーラムで聞いてくださいって体制だから。あんまり情報をアウトプットする人が居なかった。ここ数年で Happy Snow Monkey や、その他多くのブログが情報を発信し出して、サポートフォーラム外でも整理された情報を収集できるようになってきた。GitHub のフック一覧もそうだけど、元々フック情報もそれが理由できちんと整理されていなかった。まあ、あそこに記述したフックの幾つかは、古い仕様の説明のままになってるんだけど。
修正されないんですか?
時間が無い。いつ変更された仕様とか、調べるのが面倒くさい。さっきも言った通り、過去のアップデート報告が見にくい今の状況で、それを調査するのは、すごく時間を使う。それに、私はその機能も使っていないから、私には一銭の足しにもなりゃしないのでそんなことにダラダラ時間を浪費したくない。
うわー……。
そう思うよねぇ…。わざと酷い言い方してみたけどね。でもね、そう言う人が居るってことよ。
それに、実際やってみると本当に好きじゃないとできないことだからねぇ……。
数年前なら β 版を入れたり、全部のフックを試して、実際に不具合報告だとかしてたからできたけど。それは Snow Monkey を使って制作をする為の、アンテナを張る行為であり、道具の使い方の確認でもあったのもある。だから、ついでの付加価値としてやる時間があった。好きだからできたって言うのが大きな理由の 1 つ。
飽きたら別のことに時間を使う方が有意義ですし、好きを維持するのは難しいですからね。
そう。「技術の海は広い。無駄にその島に居続ける暇は無い」って、エンジニア言葉にもある。それに、アンテナを張るのは自分自身。入ってくる情報の数が多いと、捌ききれない。要らなくなったところからアンテナは外していくのも必要。次から次へと張り続けるのは、某映画のセリフで例えるとすれば【理解の許容量】と言うのを簡単に超えてしまって、逆に引き出そうとしても入ってきた情報の精査とかもできず、引き出せない状態になってしまうか間違った情報を引き出してしまうだけ。
WordPress と Snow Monkey のアンテナに対して、入ってくる情報の量ってどう思う?
多いと思います。開発に関しては、調べても調べても追い付かないくらいでしょう? 常にずっと流れてくるくらいの量だと思えますね。
開発に関する情報や意見の速度は、すごく速いよね。そして、そこからの対応コストも非常に大きい。キタジマタカシだって Snow Monkey の開発で WordPress の対応コストがこの頃はかなり増えていて WordPress のアップデートがある度に、その対応が掛かりっきりになってしまっているようなことを発言していた。
WordPress の 1 機能であるブロックエディターのことだけでも、相当の時間を掛けられていますよね。本当に大変ですね。
ここで言いたいことは、WordPress の対応も本来なら難しいんだよ…ってこと。Snow Monkey ってテーマがそれをほとんどテーマの方で対応し続けてくれているから、ユーザーはノーコードで最新の WordPress で何も問題なく使用できているってだけ。実際、そう言ったテーマが無ければ、超絶大変なことをしなければならない。実際は、技術的コストの点だけで言えば WordPress も 脱 WordPress も変わらないどころか、WordPress の方が難しい。
エンジニアからすれば、本来どちらも難しいと言うことですね?
その辺りは、別の人もかなり言っていることでもあるから割愛するけど、言語コストや技術コストと言ったエンジニア視線だけでを見ると最近の WordPress は、それで制作や対応をするには負担が大きい…。
シェア率が高い、競争相手が多い、技術的コストが高いのに WordPress を勉強しますって駆け出しエンジニアが居るのは、Snow Monkey みたいなテーマが WordPress の複雑な部分を考えなくて済むようにしてくれているから。
駆け出しエンジニアが WordPress を勉強したいと言うのはシェア率のデータや、メジャーなシステムに多い【情報量の利点】の影響もあると思います。
情報量が多すぎるのも決して良いことだらけじゃないのにね。場合によっては、書かれていることもバラバラなことを言っているし。新機能を受け入れられていない人には逆なことが書かれる。例えば、ブロックエディターとクラシックエディターの時なんて良い例だよ。
情報に振り回されやすくなるデメリットですね。
それは Snow Monkey なら起こりにくいことだけれどね。 Snow Monkey は、子テーマを使わない独自のやり方になっているから。情報の取得先の範囲は、先ほど言ったように基本はサポートフォーラムで聞けなので、サポートフォーラムだけにも絞れる。それに、情報をフィルタリングしなくても、キタジマタカシも補足や情報の修正をしてくれているので、収集した情報はほぼ正しい。「Snow Monkey の情報はここで得られるぞ」って言う公式のリンクなどで情報を発信しているウェブサイトへの導線もあるから、緩く広くアンテナも張りやすい。
バラバラなことを書かれにくいのは Snow Monkey の利点ですねー。 WordPress は有名なシステムの反面、アフィリエイトブログの多さによる弊害も大きすぎですから……。例えば、WordPress 関連のウェブサイトを見ているといつの間にか何処でも広告が出てくる 100%GPL でないテーマを売りつけている某企業……
某企業ね…。
しかし、実際に Snow Monkey で制作する場合でも、サポートを受けられるような制作範囲を超えようとすれば、すぐにどうすれば良いのか路頭に迷う。
Snow Monkey も含めて、WordPress のテーマと言うのは、思っている以上に基本的なウェブサイトを制作するためだけのシンプルな機能しか用意されていない。もちろん、それが悪いなんて言えない。「テーマに何を求めてるんだ?」って話になる。
だから、そこはプラグインの役割になる。であれば、他の WordPress プラグインを導入してみたりすれば解決するかもしれない。なら、他のプラグインについて試してみる必要がある。目的に達せられるプラグインが存在しないか調べてみたり、その使い方を調べたり、様々なことを自分で解決しないといけない。その調査コストや技術コストって、当然大きい。
そうですね。プラグインも道具の一部だから、当然、それを使い続けていくために切磋琢磨しなければなりません。コストは大きいですよね。
そう言うのがすごく大変だったこともあり、WordPress の制作依頼って保守料金が高いケースもあった。
コロナ禍でもあって色々やっていくのが困難となった飲食店が「毎月、支払っている料金が高いのでウェブサイトを閉じたい」と言う相談から、それなら、WordPress を使わずに保守するコストを減らすなどの目的をもって、1 年前に脱 WordPress について真剣に考えてみた。
コロナの影響だったんですね?
逆引きゴリラ[10] のことですね?
そう。当時は GatsbyJS の関連書籍や紹介記事も多かったので、誰でも、言語を理解して、書籍を読んで、サンプルコードを応用してコードを組むだけでも簡単に簡易的なブログを構築できた。これくらいなら技術コストも低い。実際にウェブサイトも制作できた。
しかし、問題があった。まず、ビルド時間がすごく長い。記事を増やすと倍々に膨らんでいった。結果、記事を増やすには改修がすごく掛かることになった。調べる技術コストが高くなりすぎた。
同時に、書籍や日本語で書かれたリファレンスが最新アップデートに対応されていかないので、その後のアップデートに対応するために公式リファレンスを見ていくと、リファレンスも整備されてなくて実際にコードを読まないと駄目だった問題もあった。使用しているライブラリとの互換性の問題もあって、アップデートしたらライブラリの方がエラーを出すように崩壊したとか。
何だか、すごい酷いことになってしまっていますね。WordPress で言う「アップデートしたらウェブサイトが壊れました」みたいな感じです? 何が原因か解りません状態ですね…。
そんな感じ。WordPress でもそう言った問題コストは変わらないのかもね。
対応能力が無いとアップデート対応って難しい。
WordPress は、勉強会やコミュニティの支えで、ドキュメントなどが最新の情報に整備されていますよね。
コミュニティにすごく支えられているよね。交流会・勉強会を開催される人や、動画やブログで情報を発信する人も多い。書籍もよく最新バージョンに対応されている。最新の事項が理解できる環境を用意されていて素晴らしいよね。
普通の技術テクノロジーって専門書籍ってほとんど出ないのに。有ったとしても、古いバージョンで役に立たない場合が多いんだよね……。
その部分は WordPress の方がコストが低そうですね。
最近では、ほとんどの技術テクノロジーでコミュニティを作っている傾向があるので、最新の情報に更新されやすくなっているから、将来的にはコミュニティの支えでどのような技術テクノロジーでも新しい情報を入手しやすくなっていくとは思う。
脱 WordPress は少しずつしやすくなっていると?
Next.js も Remix も、どちらもすごい進化ですよね。
進化しすぎてるよね。リアルタイム系の更新ライブラリも増えたのも、刺さった理由の 1 つって聞いた。実際に試してみたら、ウェブサイトの情報をリアルタイムに更新しやすくなっていて、すごく便利なんだよな。我々みたいな VR ・メタバース空間で遊んでいる人からしたら、VR 空間上でオーバーレイ表示させて、リアルタイムに更新情報を収集したい時にすごく便利だし。VR やっていても地震通知が見れる(笑)
リアルタイムに情報を知りたいとか、繋がりが注目されている現在だからこそ、そう言う技術テクノロジーの進化ってエンジニアからすごく期待されているから WordPress 以外に視線を向けることも増えたんだと思う。
エンジニアには WordPress 外に期待もあると言うことですね?
しかし、脱 WordPress の記事を収集してみると、WordPress に対して「シェア率は落ちてない」などと言っている記事ばかりが出ていたのもありますね。脱 WordPress に対して否定的な意見の記事も検索上位に多いです。
それが、ウェブデザイナーの方や営業関係者がシェア率のデータを武器に語られているんですね。しかし、本当に、そのシェア率のデータは CMS と、ウェブサイトの率だと言うことを認識しているんでしょうか…。
ふむふむ?
Twitter。
そう言われていますよね。1 つ 1 つの呟きが、個別の URL に割り当てられており、別のウェブページとしてカウントできるのが理由だからです。
そこで、シェア率のデータです。ウェブサイトというのはウェブページの集合体なので、レンタルのブログサービスなどのカウント数は ウェブサイトで言えば 1 ではないかと言われているんです。
…データの見方が変わることをぶち込んできたなあ……。
また、実際には CMS を持っているウェブサイトも CMS であると公表されているウェブシステムから統計されたデータ割合から取られているデータなので、全世界の CMS の何割なのかも公表されていない分は除外されているそうです。ですから、データの質を完全に信じてしまうのも迂闊だと思っています。
あのデータは WordPress で営業するには使えるデータですが、だからと言って脱 WordPress を否定することに使用できるデータではありません。
脱 WordPress に関してはそれぞれの感じ方もあるけれど、脱 WordPress に対してデータを利用して反論してくるのは確かにやめて欲しくなる。
高度なウェブサイトの制作となると、WordPress で制作するのも脱 WordPress も難しさは変わらないのにね。
例え、自分が開発していなくても WordPress や Snow Monkey は常にアップデート更新がされ、安心して安定に使えるって思ってんだろうね。自分以外の誰かが、自分とは関係なく開発してくれていると思いながら使用し続けているんだろうね。それって間違いだと早めに認識して欲しい。WordPress や Snow Monkey を使用するのであれば、要望提出や不具合報告とかが必要なことと解って欲しい。何故かと言えば、不具合報告や要望と言った意見交換をすることで成長しているオープンソースだから。なので、サポートフォーラムで意見交換して成長させてくださいってお願いしたい。
すべてを自分で技術開発しているシステムなんて絶対にない。他人が開発した何らかのシステムは必ず使用されている。
だから、脱 WordPress や 脱 Snow Monkey でもライブラリを使って開発したりするから、ライブラリに不具合や要望があれば、それを報告したりするのも必要。その部分は一緒。要望提出と不具合報告と言う部分だけで考えれば、どちらも負担コストは変わらないかも。
当ウェブサイトもライブラリを非常に使うことで開発ができていますね。もちろん、各ライブラリの不具合報告なども行なっています。結果的に制作速度も上がっています。
しかし、技術と言うのは日々進化しているので、目的を達成させる最適な手段も日々変化していますからね。
今の WordPress では難しくても、将来的に WordPress で簡単にできる様になる可能性もあります。その時は WordPress が最適解になるかもしれませんね。
当ウェブサイトも複数人同時執筆をしていますが、将来的に WordPress で複数人が同時にページ編集をできるようになれば、そうなる可能性も高いですね。
少しだけ、現在の時点での当ウェブサイトの技術を紹介しましょう。
ベースには Next.js を使用しています。また記事の執筆記法も今後のシステムの移行を考えて markdown に統一しています。 API の処理を行う部分はすべてライブラリと GraphQL を使用して開発コストを下げました。執筆後から公開の環境は、ほぼ GitHub Action で自動化しています。しかし、それが将来でも最適な手段かは分かりません。
案件用に開発した機能を無理矢理繋いでアドベントカレンダー記事を公開する為に１週間ほどで組み立てただけなので、まだ改善しないと正式運営は難しいくらいクオリティーは低いです。しかし、基の機能も半月ほどで開発しているので基本部分の制作は1ヶ月半ほどで可能だと思います。
ほぼ多くの部分で、React を使用していることで、WordPress のカスタムブロックを開発するのと言語習得コストはほとんど同じかと思いますし、Next.js は examples が非常に多く公開されているので、そこから実装したい機能のコードを選んで組み立てるだけでもこれくらいはできるんで学習の難易度も非常に優しい。
examples を見るだけでも React の学習になりますし、面白いですよね。WordPress のカスタムブロックなどは React で開発可能ですから、場合によって、カスタムブロックを開発する学習能力も向上できるキッカケとなります。より学習コストを低くできる可能性もありますね。
例えば、目次機能は tocbot と言うライブラリを使用しており、目次を付けたい要素に対して下記のようなソースコードを数行記述するだけでも実装が可能です。
import tocbot from 'tocbot'
const router = useRouter()
// スクロールのオフセット量(px)
const offset = 92
const handleRouteChange = () => {
// Router 状態によって、目次を破棄する
tocbot.destroy()
router.events.off('routeChangeStart', handleRouteChange)
}
useEffect(() => {
tocbot.init({
tocSelector: '.toc', // 目次を表示したいクラス要素名
contentSelector: '.article-container', // 目次を取得するルート DOM のクラス要素名
headingSelector: 'h1, h2, h3, h4, h5, h6', // 目次のリンク先とする DOM の要素グループ
hasInnerContainers: true,
positionFixedClass: 'is-position-fixed',
headingsOffset: offset,
scrollSmooth: true,
scrollSmoothDuration: 256,
scrollSmoothOffset: -offset,
collapseDepth: 4,
onClick: function () {
if (setIsShowSlide) {
setIsShowSlide(false)
}
},
})
router.events.on('routeChangeStart', handleRouteChange)
}, [router.asPath])
tocbot も React 製なので、ブロックエディターや Full Site Editing の部分にも同じようなコードで目次機能を組み込むことが可能です。もちろん、Snow Monkey でも、このように tocbot を使用する処理を記述してウィジェット化させたカスタムブロックを用意すれば、脱キタジマライブラリの新しい目次ウィジェットを開発をすることが可能です。キタジマライブラリの目次機能では難しいカスタマイズ動作を容易に可能になります。
実際に脱キタジマライブラリ版の目次ウィジェットなどのやり方は本記事で割愛しますが、要望が多ければ、別記事を後日書くので感想を交えて要望でもしてください。
1 つ 1 つをカスタム Hooks も利用して、コンポーネントに分解しているので、ほとんどコードを変えることなく、WordPress の Full Site Editing や カスタムブロックの実装にも応用できる。
CSS のスタイルは Tailwind CSS、記事の文章は markdown を markdown-it と言うライブラリで拡張をしている形式になっています。殆どが既存のオープンソースを利用したローコードです。
Tailwind CSS を使用している主な理由は、パターンに合わせて classnames を新規のスタイルクラスを作らなくて済むことと、スタイルシートの往復がなくなるので非常に楽だから。クラス名を 1 つ 1 つ考えて付けて scss にそのスタイルを記述する手間がなくなる。
デベロッパーツールで HTML を読むだけで直感的に何のスタイルが当たっているか判断できるのも理由の 1 つ。
このコードを見て「うわ、難しい」と思われたのであれば、これからの WordPress にも同様の感想を抱くかもしれないですねー。ブロックエディターのカスタムブロックを構成しているコードも React や Typescript と言った言語フレームワークが使用されており、将来的な WordPress ではそう言ったコード量が増加していくと予想できます。
Full Site Editing が進むにつれて、これからの WordPress ではこう言った PHP でも HTML でもないコード部分が増えていくと思うからね。
だから、ウェブサイト制作を、WordPress を使用していても、脱 WordPress でしていても、コスト、この場合は、言語習得コストや技術コストや情報収集コスト。そう言った部分は同じか、少し低いくらいかになっていくって感じるんだよね。それでも「WordPress は簡単」って言う人は勘違いをしているか、WordPress を チョットデキル[15] 人か。これからも誰かが作ったテーマやプラグインを使い続けていく人か。どちらにしても、簡単ではないと思うんだよな。
まとめると、エンジニア視線で見れば「WordPress × Snow Monkey」も「脱 WordPress × 脱 Snow Monkey」も、そんな変わらないことって考えで良いです?
むしろ、脱 WordPress とか WordPress とか完全に別れてるわけじゃないんだよね。脱 WordPress でやっていることは WordPress にも応用できるし、WordPress でやっていることも 脱 WordPress で使えることができるから。
Snow Monkey や WordPress が難しいと思ったら、WordPress から離れたことをしたら「こう言うことなのか」って理解が進むこともあるし。そこで学習してまた戻ってきたら違った視線で Snow Monkey を見ることもできるんだよ。それもすごく面白いことなんだよね。
そもそも、WordPress でやっていようが 脱 WordPress でやっていようが、 真剣に取り組んでいれば、同じくらい簡単なこと で、真剣に取り組まなければ、同じくらい難しいこと だし。脱 WordPress を難しいと思わずに、1 度挑戦してみるのも大切なことかもね。
使用しているユーザーだからできること
上記でも書いていることの様に、Snow Monkey も要望提出や不具合報告をしなければ、ほとんど成長しない。ともに成長させられるのは サポートフォーラムを利用して要望提出や不具合報告が可能な Snow Monkey ユーザーの特典でもある。
β 版などが提供されれば、安定版まで待つよりも、β 版を使用してみて不具合が存在しないか確認してみる方が良いですね。安定版であっても、自分以外の問題になるかもしれない不具合や要望を書いてみたりすると、より良い成長するかもしれません。
サポートフォーラムを使用できる権利であること
脱 WordPress では、相談をしても解決に繋がるのが難しいなどの問題がありますが、Snow Monkey のサポートフォーラムでは、ほとんどの問題が「テーマの設定を変更すること」「フックを使用したカスタマイズ」「スタイルをカスタマイズ」の 3 つの方法で解決されていますよね?
他には、「別のプラグインを入れること」くらいかな。
そうですね。そして、Snow Monkey のサポートフォーラムは、他のサポートサービスなどとは少し異なっているように思えます。
それは、サポートで解決させる方法が統一されていると言うことです。Snow Monkey は My Snow Monkey を使用してカスタマイズすることに統合しています。そうしていることで、現在のスムーズな回答と対応ができる姿勢が作られているように思えました。回答したい人が My Snow Monkey に「こう言う風に書いてください」と言えばサポートが可能になっていますし、回答されたコードは My Snow Monkey にコピー＆ペーストするくらいで簡単に対応できるようになっています。何を処理しているか理解しなくても組み込めるようになっていて素晴らしいんじゃないでしょうか?
サポートフォーラムでサポート範囲を広く対応するのは難しい問題ですが、非常に上手くサポートする方法を統一できているなと思います。
現在は、サポートフォーラムについての誤解もかなり解けているのも良くなったよね。
Snow Monkey のサブスクリプションで得られる特典の 1 つは、サポートフォーラムでサポートしてもらう権利ではなく、サポートフォーラムを使用できる権利 なのをきちんと理解しているユーザーが多い。
サポートフォーラムでサポートしてもらう権利ではなく、サポートフォーラムを使用できる権利 ですか?
そう。これってだいぶ前からミートアップでも声を大にして言っていることだったんだよ。駆け出しエンジニアの中には「Snow Monkey ならサポートフォーラムでサポート受けられるから」と、Snow Monkey を選んでいる人も居たし、そう言う紹介をしていた人も居たから。
確かに、サポートフォーラムを使うことでサポートは受けられるけど、サポートを受ける "だけ" の権利ではないってのを以前、公式で説明されている。
一時期、少しサポートしてもらう為にサポートフォーラムに書き続けるユーザーが増えた。それもあってか、Snow Monkey 公式で あまりに利用状態が酷い場合は、サポートフォーラムの利用権利を一時的に剥奪する ようなこともきちんと言われたことがあった。実際に剥奪された人が居るか不明だけども、注意はした方が良い。
以前、Kmix39 さんも「Snow Monkey なら、サポートフォーラムでサポートを受けられる」って紹介していませんでした?
あー、うん。その頃はキタジマタカシがほぼ全てのスレッドに返信していたのもあって本当にサポートを受けられるだけってイメージが強かったから。でも、その後に Snow Monkey ミートアップなどが開かれた結果、代わりに返信をし始めてサポートフォーラムのイメージを変える人が出てきた。そして、権利と言う形に変わった。それは、Snow Monkey サポートフォーラムは、ユーザーなら、誰でも意見を言ったり、情報を共有したり、回答をしたりできる場であるから。サポートを受けることが特典であるのも間違いではないだろうけど、勘違いはしてはいけないよね。
そして、権利である = 自分が解る回答や意見もして大丈夫ってことでもある。
キタジマタカシは、本気度がある意見には本気で返事をしてくれる男でもあるから。Snow Monkey をより良くできそうなことなら、ガンガン意見を投げつけあう方がワクワクしてくれるタイプと思う。その姿勢はこれからも変わらないと思う。……しらんけど。キタジマタカシ本人の意見をお待ちしております……。
Snow Monkey サポートフォーラムも色々なことがあったんですねー。
アピールポイントを作れること
うん。色々あったね。今となっては回答して楽しかった時期もあった。道具を使い続けるためにやっていたことだけど。結果として、Snow Monkey をより知ることもできて勉強にもなったし、また Snow Monkey をより良く一緒に成長させれたと思っている。それに回答することが自信にもなってたかもね。「俺、こんなに Snow Monkey の質問に回答できるほど Snow Monkey を知っていけてるのなー…」って言う。
同じように、回答している駆け出しエンジニアの実績や自信になると良いですよね。「俺、Snow Monkey のサポート回答できるくらい知ってるんですよ」とアピールできれば恩恵を得れますね。いいねの数もそう言ったものを表すのには有効活用できそうですね。
下手な「自称・最大の集客力ウェブサイト」より、よほどアピールポイントになりそうです（笑）
サポート ≠ 仕事代行なこと、 日々改善すること
中にはイライラしたスレッドもあったよ……? 私がサポートフォーラムで返信対応したら、聞いて終わりにして、その質問者が依頼者からサポートフォーラムで聞いた対応のコードを入れた程度で多額な別料金をサポート依頼料として取っていたりしたんだよね。お前、大した対応してねーだろって…。その対応料金を払った依頼者から後に聞けたんだけどね…。結果的に、質問してきた本人も含めて全員の気持ちがマイナスになる結果になった。
サポートフォーラムで返信してくれるユーザーを減らすような行為をして自分も苦しむから、そう言う行為だけは絶対にやめとけって言いたい。何かあったらすぐに、返信をするユーザーはやる気を失くす。私は二度と回答する気がなくなった……。サポートフォーラムって返事をしようが一切金銭をもらってないし、恩恵などもないまま、一度やる気を失くしたら戻ることはほぼない。
しかし、サポートフォーラムで求めた回答で対応料金を取るのはダメなことでしょうか?
「こう言うことをしたいと思う」って相談すること自体を悪くは言いたくない。しかし、自分で全く解決もせずに、ただ答えだけを求め、聞いて終わりと言う、完全に他人任せの行為をして依頼者の目的を達せるとは思わない。
そう言う行為は、仕事をする人の対応の仕方としても、Snow Monkey のサービス継続にとっても、どちらにもマイナスですね。
使っている道具の状態を悪化させるのは使用者全体を苦しめることにもなる。もちろん、本人も。
先ほども書いた通り、そう言う人こそ、自分自身で依頼者の目的を対応できるか、対応しているか、対応を継続できるかと言うのに向き合って欲しいよね。
毎回のようにサポートフォーラムですべて聞くような質問をされながら「案件依頼、お待ちしています」って言うウェブサイトを公開・運営されている人も居た。「この状態で本当に仕事を受けようとしているのか?」とか疑問だった。案件受けた後にも、何かある度に、すぐにサポートフォーラムに質問してくるんじゃないかって…。
そうやって次から次へとサポートを受け続けて、 My Snow Monkey を膨らますだけ膨らまして、ゴチャゴチャさせて、自分で My Snow Monkey をコントロールできない状態にしてしまって、最後には苦しむだけになってしまう。
まずは自分で解決しようとせずに、次から次へとサポート質問をし続け他人のコードやアドバイスを受けるだけで自分から学ぼうと言う姿勢もないとか、アンテナも張らずに他人のコードやアドバイスを受けるだけで、自分から学ぼうと言う姿勢もないのであれば、ウェブサイト制作者としての姿勢が無いし、そもそも向いているなんて絶対に言えない。それで制作されたウェブサイトを実績にして「案件依頼、お待ちしています」って書くのもすべて舐め腐っているだろと。そういう人に大切なことは、別の業種を目指すことだぞと声を大にして言ってもいいんじゃないかな。
他人が公開した「Snow Monkey を使用して制作する案件フロー」に沿って、案件を進めている人も居ますけど、その流れをそのまま考えも無しに進めてみるのも良くないでしょうね。実際にその目的を達成させる手段として沿っているか再度考える必要があるでしょう。
駆け出しエンジニアが「自分も真似て、案件を取りたいと思います。」って意見を言っているけれど、他人が成功した方法や流れがそのまま自分の案件に当てはめたところでスムーズにいくとは限らない。良い部分を真似て、制作フローについても日々自分で改善していくのが大切なことだろうね。
最後に
文章が進むにつれて、本題から遠ざかっていく内容だった本記事ですが、ようやく終点です。いかがだったでしょうか?
ガンジーが助走つけて殴るレベル で、長い記事になってしまった…。
……ガンジーの話から始まった本記事でしたね。
さて、制作スピードを上げること以外に大切なことは、見つかりましたでしょうか? 本記事は、まとめは御座いません。閲覧者がどう感じて何を大切なこととしたか、その気持ちに委ねます。
それでは、最後まで読んでいただき、ありがとうございました。
2022 年もよろしくお願いします。
ご意見・ご感想について
ご意見・ご感想について
いくつかの方法があります。
- Snow Monkey コミュニティなどで書く (Kmix39 が対応します)
- #wpsnowmonkey のハッシュタグを付けて Twitter で呟く(所属メンバー全員が見ます)
- Twitter で 譜乃謡 詩哥 にダイレクトメッセージを送信する (譜乃謡 詩哥 が対応します)
アドベントカレンダー (Advent calendar) は、クリスマスまでの期間に日数を数えるために使用されるカレンダー。それにちなみウェブサイト上では 12 月 1 日 から 25 日 まで 1 日 に 1 つずつ、みんなで記事を投稿する Advent Calendar がイベント開催されています。本記事はそのイベントの 1 つである「Snow Monkey アドベントカレンダー」の 18 日目の投稿記事です。参照: https://adventar.org/calendars/7036 ↩︎
Snow Monkey を数クリックでビジネスサイトに進化させるブロックパターンなどのサービス。 参考: https://rui-jin-en.com ↩︎
Snow Monkey を開発している長崎出身の
変人エンジニアです。 ↩︎既に多くの機能が組み込まれた形になっており、実際に書くコード量が少ない状態。または実際に書くコード量を大幅に削減すること。 ↩︎
画面操作のみで、機能が充実したウェブシステムを作ることができるサービスの総称。またはコードを書かずにアプリケーションを開発すること。 ↩︎
CSS 構成案の１つです。参照: https://github.com/hiloki/flocss ↩︎
Static Site Generator (静的サイトジェネレーター) ↩︎
React をベースに開発されている SSG 専用のフレームワーク。 ↩︎
GatsbyJS の勉強も兼ねて、Snow Monkey のフック説明用に制作したサイト。参考: https://reverse-gorilla.netlify.app ↩︎
React をベースにしたフロントエンドフレームワーク。参考: https://nextjs.org ↩︎
React をベースとした新世代のフルスタックフレームワーク。参考: https://remix.run ↩︎
Visual Studio Code。Microsoft が提供・開発している、統合ツールを備えた強力で軽量な無料コードエディター。 ↩︎
VS Code で共同編集、共同デバッグ、音声通話、仲間とのチャット、ターミナルの共有、サーバー、コメントの参照などが可能な機能。参照: https://visualstudio.microsoft.com/ja/services/live-share/ ↩︎
Linux の生みの親であるとある T シャツに書かれていた文言から生まれたネタ言葉。同じ製品を自分でも 1 から作れるという意味。または開発者本人。 ↩︎