プロジェクト憲章の導入
社内で円滑にプロジェクトを進めるために、プロジェクト憲章を導入する。
- プロジェクト名
- 背景
- 目的
- 目標
- スケジュール
- 予算
- スコープ(最終成果物)
- リスク
- ステークホルダー
この先1年で学びたいこと
もう直ぐ誕生日なので、この先1年の目標を書き留めとこう。
0. 家族の幸せ
はい。まずこれが一番。
1. プロジェクトマネジメント
人数が多いも増えたし、本当に学ばなければならないところ。
2. 設計
設計をがっつり出来るようになる。そして外部に発注したい。
3. mv*系フレームワークの完全習得
金になりそう。やってて楽しい。
4. UXデザイン
良いもの作りたいもん
こんな感じ。
Gulp と Webpack の採用基準
今日は、社内で運用しているCSSフレームワークの改善を行った。
gulp + sass + FLOCSS崩れ + Jade という構成なのだが、策定から5ヶ月ほどたって、ちょっと技術選定を見直そうかと思いたった。
webpack vs gulp
最近のOSSを見ていると、タスクランナーとしてwebpackを採用しているものが数多くなってきている。
弊社のフレームワークでは gulp をタスクランナーとして採用しており、webpackを採用してもいいのかなー？と思った。その上での考察。
gulp はタスクランナー
そもそもタスクランナーはどんな定義だっ？なのか。 ビルドツールとは違い、 「タスク」を自分で定義して、それを実行することに特化したツール って感じか。
まぁ、個々のソフトウェアの操作を タスクランナーの api を利用してタスクとして定義し、自動化するものと考えている。
webpack はビルドツール
その点、webpack はビルドツールだ。
webpack はどちらかというと browserifyと対をなすもの。
設定ファイルにエントリーポイントとアウトプットファイル、その他もろもろ定義しておくと、その通りビルドしてくれる。
どちらを選ぶか
正直、きっと今のトレンドとしては npm run script だろうが、チームスキルがまだ満たないので取り敢えず採用外。
gulp は なんだかんだ一番汎用性はあるのかなと思う。これまでの知見を得てもWeb上にいくらでも転がっているし。
その点、webpackは、結構学習コストが高いと感じた。 そもそも webpack の概念を理解するのも時間がかかりそうな気がする。
webpack で sass や jade (pugになってた) をファイルとして生成するのは、そもそもwebpack の概念にあっていないように感じた。
サイト制作においてwebpackを使うようなことはない
自社内フレームワークはあくまでもWebサイトが対象なので、gulp で事足りると判断した。わざわざコストをかけて webpack で実行する必要性は感じられなかった。
もちろん、Vue などで簡単なSPAを構築するときは今でも採用しているものはある。 あくまでまWebサイトって考えた時のこと
というわけで、まだしばらく gulp で頑張ろうと思った。
要件定義の概念共有
プロジェクトが立ちゆかない、所謂 炎上状態になるには、主に以下の領分での失敗が主ではないだろうか
- 要件定義に起因
- (広義での) 設計 に起因
- プロジェクトマネージャの裁量に起因
その中でも確率として数値化するのであればこれぐらいか。
- 50%
- 30%
- 20%
基本的に、それ以外の実作業で起こる失敗や異変は、根本的な原因は上記の3つのどれかに当てはまるはずだ。
例えば、プログラマの技量が低く、納期が遅れるということは、プロジェクトマネージャの采配ミスだ。
ビジュアルデザインの作り直しというプチ炎上状態も、要件定義が甘かったことに落ち着く。
要件定義、設計、プロマネは、プロジェクトを円滑に進行するために重大な役割をもっているはず。
ただ、うちの会社のような少人数で経験も少ない世の中の「Web制作」会社、もしくはフリーの方にとって、比較的疎かになっている工程ではないだろうか。
少人数で小規模なプロジェクトを進める場合、逆に経験則で進めた方がコストをかからないし、円滑に終わるパターンもあるかもしれない。
しかし、それはクライアントにとって最適な解ではないと思う。制作側が「なんとなく」で制作した場合、クライアントも「なんとなく」しか評価しないはずだ。
できましたの報告を受け、確認はしてみるが結局、なんとなくで許可してしまう。
小規模のプロジェクトになると、依頼内容自体もふわっとしていることが多い。
明確なゴールを数値で目標立て、クライアントに意識づけるということは、こちらから提案しなければまず伝わらないし、そもそもクライアントは要望しか持っていないのだから、こちらが要件を定義してあげなければわからない。
ここら辺はきっとどんな仕事でも共通であり、依頼側が無知なことは普通のことだ。
だからこそ、経験則でデザイン、コーディング、納品まで進めてしまうと、それはなんの役にも立たないことが多い。もしくは「Webサイトを作る」ということを勝手にこちらで要件定義しているだけ。テンプレで作るのと何も変わらない。
ここら辺の話というのは、やはりある程度経験が必要で、会社全体で共有するのが難しい。
そもそも、要件定義や設計がどんな作業をするのかということが分からないので、自分の領分内を中心に考えてしまう。
設計については経験や知識に対する依存度が高いと考えているので中々難しいが、要件定義であらば、概念を共有できるのではないかと思った。
そんな中で見つけたこの本。
読んでみて、本当にわかりやすかった。僕自身はもちろん勉強してきたつもりだったが、こんな表現で説明できることに驚いた。
次の社内勉強会で、この辺のことをやろう。
幼児教室について
今日は、可愛い愛娘の幼児教室の体験教室に行ってきた。色々疲れたのでひとり言
きっかけ
何故、幼児教室を始めようと思ったのか、ということについては、実は特にこれというものはない。
嫁さんにも、僕にとっても初めての子なので、教育という分野は未経験過ぎて何をすればわからなかった。互いの実家も飛行機の距離にあり、子育について容易に相談できる相手もいない。
そんな中、人間の脳は3歳までに80%発達するといった類の情報や、周りの家族の「スイミング始めましたー」のような報告が、僕ら夫婦の悩みの種となっていた。まるで、周りが輝いて見えて、僕らが曇って見える感覚？だった。
僕らも何か習わせるべきなのか、という焦燥感が生まれ、ちょっと考えてみようということになった。
経験をしたことがなかった
最初は嫁さんも僕も、否定的だった。保育園にも追々通わせる予定だし、今は特に必要ではないだろうとは思っていた。
しかし、いろいろ話していく上で、お互いこれまでそのような教育を親から与えられたことはなく、正直幼児教室に通わせても効果があるかないかの判断がつかないという結論に至った。
教育については「人生をかけてやりたいことを気づかせる」ということを目標にしているのだが、今の状態で却下するのは反するのではないかと思い、であれば一度受けてみようということになった。
体験教室に行った結果
僕らが行った幼児教室は、俗に言う「天才つくるぜ〜」的な右脳伸ばす系の幼児教室だった。
その内容は、圧巻した。うちの子が理解しているかどうかは関係なく、次々に教材を進めていく。
まだ言葉を喋れない娘に対して、50音から始まり暦の読み方や足し算などを歌にして進めていく。
基本、理解しているかどうかは関係なく、とにかく進めていく。逆に母親のほうが勉強になっていそうだった。
話の中では、僕が大嫌いなテレパシー的な話しが出てきたりもした。脳を鍛えれば少しは使えるようになります。もともと人間にはそのような力があります。的なやつ。
ちょっとここら辺で僕としてはテンションが下がり始めていた。果たして、これが娘にとって良い経験となるのかと訊かれると答えに困るだろう。
あとは、音楽を流して歌いながら進める場面が多かったのだが、未だにMDだった。
MDで進めているってことは、下手をすると10年ぐらい使い回し？その間教材の開発にはやらなかったの？と思った。
取り敢えず、ここはないなということで止めて、来春また別の所にいってみることに。
ただ、積み木遊びは確かにいいなと思ったので、帰りに赤ちゃん本舗により、ドイツ製の積み木を買って家に帰宅した。
