去年を振り返って

しかし、いろんな出来事があった年でした。

春まではある業種に特化したデザイン事務所にフロントエンドエンジニアとして出向していて、春からはある大企業のWEBのデザイン・開発を受けもつ会社にフロントエンドエンジニアとして出向することが決まっていました。

そんな大事な時期に腰を骨折してしまい（正確には圧迫骨折というものらしいです）、次の出向先には、初っ端から休暇を頂くことになってしまいました・・・

• コンビニ行くにもタクシーを呼ばなければならない・・・なんて生活はもう二度とないんだろうな（いや、そうでありたい）
• 一番の難関は横断歩道。壁などに手を付くこともできないので信号が変わる前に果たして渡りきれるのか・・・

そんな生活が続けど、ある程度良くなった時点で出向先に赴かなければならない（生活を守るためにも）。
結局、半年とちょっとしかそのデザイン・開発会社のお手伝いをすることができなかったんだけど、この約半年間にすごく成長できたと思う。
成長もそうだけど、考え方？視点？を変えれるきっかけになれたと思う。

この２社とお付き合いするまで、ずーっとフリーランスという形をとっていて、特にどこかに属すこともしなかった。
屋号を持ち、お客様とも継続的な関係を持ち、共に発展を話しながらやるべきことをやり、満足しきらないように技術向上も常日頃考える。

「お客様との継続的な関係」

これが築けていたのも自分たちが独自で開発したCMS（コンテンツ・マネジメント・システム）があったから。も、一つの理由だと思う。

お客様に「大」「小」を付けるつもりは全くないが、いわゆる「大企業」とのプロジェクトに関わったことは過去に２〜３回くらいだと思う。

関わるお客様やプロジェクトは、大体、地場産業であったり、同期の友人・知人が起こした会社やショップが主。
デザインの出戻り等は普通にあるけど、「ウェブサイト自体をどう構築する」ということで議論することは無く、それらはこちらマターであった理由も、その独自開発のCMSのおかげなんだろう。

お客様の誰が「CMSから吐き出されるHTMLに疑問を持つのだろう？」が普通だった。
もっとも、「こんなデザインで、こんな構造でウェブサイトを構築しよう。」の確約の元にテンプレートを開発するから、なるべくしてなる。

そこが自分の不得意分野を構築した理由だった。

自分の癖ということなんだろうけど、

• やるならフルスクラッチで開発する（厳密にはCMSの機能を借りるのでそうとも言えない）。
• なんで他人が作った機能を使う必要があるの？
  例として、jQueryとかカルーセル用のライブラリとか・・・
• 複数人での開発ではないため、Gitなどを使う必要がなかった。
• 上述した理由もあり、node.jsとかwebpackとか・・・わざわざコンパイルして云々・・・とかに携わる必要がなかった。

挙げればキリがないんだろうけどね・・・

もうひとつ、フルスクラッチしたからといってそれが請求額になるわけでもない。でも、そうしてしまう・・・
自分向けライブラリを作るのは楽しいし、勉強にもなる。

何より（料理で例えると）、「誰かの味じゃない！」と胸を張れる。

もう一つは納品の仕方。

（一概には言えないけど）CMSで更新作業を行えば、その場で公開される。

もし、文章が間違ってたりしてたら、「はい。こちらで直しておくね。」もしくは折角CMSを導入しているんだから、お客様側で行える。
等、考えられる。

プレビュー段階を踏む。という（ある程度）大規模なプロジェクトではないことがほとんどだったため。

それでは、納品物は何？

に、なってくる。
と、言うより、「そうなるよね」という考え方を教えてもらった。

差分ファイル

それこそが納品物であり、それらを作るためのデザインだったり、それらの実装がそう。

では、CMSで更新作業を実行してしまうとどうなるんだろう？

何を持って「差分ファイル」と決めれるか。
それは、作業工程のログで説明できるのであれば問題ないんだろうけど、そんなことしながらデザインや実装作業なんてしていられない。

更新後に特定できるものの一つは「サーバー上のファイルのタイムスタンプ」だろう。

例えば、「１ページ追加する」という依頼を請けたとすると、以下が作業範囲になる。

• そのページのデザイン（既存のテンプレートで賄えるのであれば不要）
• そのページを構成するテンプレートの開発。それに伴うスクリプトやスタイルシートの実装（既存のテンプレートで賄えるのであれば不要）
• そのページで使用する写真やバナー等の素材作成作業
• そのページの記事そのものの投稿作業
• もちろん、必要であれば、取材や撮影なども含まれる。

それらを元に更新作業をしたとすると、

• 追加（もしくは更新した）ページのファイルそのもの
• そのページを内包するカテゴリーページ（あるのであれば）
• トップページ（更新情報等があるのであれば）
• スクリプト（追加機能等があるのであれば）
• スタイルシート（追加したスタイル定義があるのであれば）
• サイトマップ、もしくはsitemap.xml
• 追加した画像等のファイル

最低限、これらのファイルのタイムスタンプは更新されます。

やはり、これではタイムスタンプの更新されたものを「はい、納品物は下記になります。」と、動的にリストアップすることはできない。

自分の不得意分野だったことが理解できたなら

話は戻るけど、
去年の冬間近、身体が思うようにならず、実家のある鳥取県に一時的に帰って療養することに。

そう、いざ、長期休暇！

好きな時間に、好きなことを思う存分できる！

まずは、おさらいから

約半年間で身についたことを忘れないように

Git

請負のプロジェクトではなく、個人的に進めているプロジェクト。例えば、CMSのバージョンアップ、スクリプトのコンポーネントなど・・・
そういうものを片っ端からGitと連携し、当日作業した部分（※１）を、コミット時のコメントに残せるようになることが大事なんだと。
あとは、iPad Proとも連携させてみた。

※１：１日分の作業ともなれば「スライダーのスクリプトを実装した」「記事ページのテンプレートを構築した」「●●部分のスタイルシートを変更した」などなど、とても一言コメントでは言い表せない作業ログになってしまうので、「部分」ごとにGitにコミットすることを心がける。＝どのファイルに対して手を加えたのかを認識できている。

あっ、iPad Proで編集することもあるので、Git漏れは厳禁です！（とも、教えられました・・・（汗）

CSS

SCSSは、もともと使っていたけど、ようは、そこまでしっかりとした考えで使ってなかったのだと思う。

例えば、関数を使ってみるとか。継承を使ってみるとか。

いくつか、有用な関数も出来てきているので、何かのタイミングで公開します！

あ、もうひとつBEM（例としてこちら）
これに関しては、実はまだ抵抗あったりする。
理解はできているんだけど、単純にクラス名がカッコ悪いのと、Modifierを連結させるのが嫌い。
他にもFLOCSSなど、いろんな書き方が提唱されているけど、なんとなく嫌い（笑：すみません

だからといって、コンポーネント的な書き方は、SPA（例としてこちら）で、セクションごとに似たり寄ったりした機能でもセクションごとのデザインに歩み寄ることはあると思う。その場合、上書きしていくと「どこが？」ってなることも少なくはない。

個人的には、Modifierは、すべてスクリプトから制御したい。

でも、チームワークとしてはBEMを取り入れることの意義は理解しています。（あっ、これも教えてもらいましたね・・・（汗）

JavaScript

現時点では、これが一番重要なんだろうな。

もともと、Lingo言語から入って、ActionScript言語（特にVersion 3）が好きだったので、クラスという概念を構築していくのが得意だった。
当時のJavaScriptには不満しかなく、あまり好きではなかったけど、必要だったので、上述した通りフルスクラッチできるようにもなれた。簡単だったからね！
それでも、毎回開発してしまうのは、状態変化をきちんと管理できるようなものを作るには不向きだったからなんだと思う。
すべてを内包するようなスクリプトをいちいち読み込んでいられない。という気持ちもあった。
実際、スクリプトとして動く以上、そのファイル自体の大きさでも問題があることにも出会ったこともあった。

技術向上という名目のため、Prototype.jsやらjQueryなど、ある程度は勉強した。
それでも、「これは必要だ！」と思ったことは一度もない。

そして、現時点。

ECMA Scriptの現段階は有用になりそうだ。
でも、どうなんだろう？クラス構造にしたらプロパティ宣言の仕方が変わる。
結局、Object.prototypeを使うことと変わりがないのでは？

さぁ、思い出せ自分！
無駄とは何か

以前、Vue.jsで構築されるプロジェクトに携われることができた。
「なんと無駄な！」的な思いもあったけど、「知れてよかった」の方が大きい。
初めてのwebpack、vue-cliなどを使った環境構築。そこに戸惑いはしたけど、内容は所謂JavaScript。文法の違いはあるだろうけど。

それを知れてよかった。

React、Angular・・・色々あっても、結局はJavaScript。文法が変わり、それらをトランスパイルしてくれれば、現状のブラウザ状況に併せてくれる。
Babel、ありがたいこっちゃ。

なので、積極的にwebpack環境を構築し、自前ライブラリを作るのは今の自分の仕事になってる。
コンパイルの必要のないバージョンも同時に書いてみるのも、これも勉強。

結論、無駄とは単純化できるものには、互いの理解の共有もあるだろうし、労力の削減にもなる。
なんだろう。
それをどう捉えるかはまだ決めきれていない。

なんとなく

ここまで書いてみると、アンチCMS派に思えるけど・・・

それはそれです。

PHPだって、バージョンアップを重ねて、Laravelに代表されるようなDI手法も一般的になってきて、ますますWEBサービスを開発するにはもってこいだと思う。
そういえば、その出向先でPHPを使うこと云々という議題があった。（ダメとは言ってない）
そこだけは、なぜだったんだろう？と今も考える。

一番の「あっ」は、Raspberry PIにまで手を出したことかな。

そのラズパイを使ってWifi内Gitサーバーまで作ってやったわ！わっはっは！

ならば今年は

去年から水面下で進めていた自分たちの「オオオ オー」を法人化すること。

もちろん、CMSも売り続けるけど、もっとWEBサービスを作りたい。それをリリースし続けたい。

今年も、何かしらこういう活動に携われれば光栄だ。