わたしはオッサンなんで、このルールは好きじゃないんですよ。
//で始まってると、ルート相対パスと見間違えちゃうんだよね。
それに、ソースファイル上ではそのHTMLがhttpsかどうかがわからないじゃないですか。
自身のドキュメントのスキーマに準じたURIの解決に頼るのは、メンテナンス性があるとは思わないんですよね。
Googleが言ってたら正しいと思わない方がいいっすよ。あいつらは自分たちのことしか考えてないっすからね。
- ブコメでGoogleのコーディング規約の批判はGoogleに向けろって言ってる人いました。
- 大事なのは選ぶことだそうですが、スキーマの省略は選ぶべき項目だとは思いません。
- なのでわたしはそれを選んだことに苦言を呈します。

p.23、24

.editorconfigにどう書けばいいかをだな……。

p.25

HTMLのルールだとしたら、そういう開発の都合のコメントを残して納品するのはお行儀が良くないっすね。
Jadeを使う前提のようだし、Jadeコメントでの話をしてるなら別にいいんすけどね。
でもさっきからJadeのサンプルが全く出てこないからオッサン不安になってきちゃったっす。

p.26

正しいHTML

HTMLの正しさとは？
参考リンクから察するに、invalidでなければいいと思ってるなんてことはないっすよね。

p.27、28

default.cssの中身がどうなってるか知らないけど、link[rel="stylesheet"]は「そうするほか解決できない」という理由がない限り、htmlのhead要素内に書きましょうね。
あと、CSS ファイルを外部化しただけで「プレゼンテーション（スタイル）と振る舞い（スクリプト）は、ストラクチャ（マークアップ）から分離する」ことができるわけじゃないので、それも忘れずによろしくです。

p.29、30

こういうのは、文字参照で記述しなければならない記号を規定して列挙しときましょうね。

p.31

アクシビリティー（笑）さっきから誤字脱字が多いんだが。

p.32

えっとえっと……「スプレッドシートのスクショです」って説明されて、ユーザーに何がわかりますか？
「このスプレッドシートでは、年を行に、月を列した2010年から 2015年までのアクセス数の分布が表でまとめられている」くらいのコンテキストを入れていきませんか。
気遣いではなくウェブサイト製作者の責任として。
ちなみにalt属性のテキストは、コンテンツマネージャーが考えるべき範囲だと思ってます。

p.36、37

クォーテーションとかはさ、lint設定を開発に組み込む方法を紹介すべきじゃないですかね。
gulpに普通にありますよ。 https://www.npmjs.com/package/gulp-htmlhint
あと、容量の削減とかいうなら、空要素のスペースとスラッシュのことも、書いて欲しかったっす。
正直、開発ソースの容量を削減するのは無意味だと思いますけどね。

p.40

CSSの教科書

いやいや、CSS”設計の”教科書ですからね、その本。
脱字なのかな！？

p.42、43

その命名だとまだ粒度が大きくて、何を示しているのかわからないと思うのはわたしだけでしょうか。
それでどのコンポーネントなのか特定できる程度の規模のサイトなら、CSS 設計いらないんじゃないですかね。

p.44、45

セレクタの単語は、むしろ絶対に省略させないようにした方がいいと思うんですよね。
省略していいなら、省略のルールまで決めていきましょう。
教えてgooに非常にいいページがありますよ。 http://oshiete.goo.ne.jp/qa/341377.html

p.49、50

ステートの上書きまでショートハンドでまとめて書くなんてことはしませんよね？さすがに。

p.57、58

HEXの短縮は規定しなくていいと思います。
ビルドをかける前に勝手に置換されるような仕組みを入れるべきところかと。
gulpでできますし、ググれば出てきます。
ちなみに、#f00よりもredの方が1バイト少ないんですよ。
容量削減は人が思いつきでやるには不十分なのです。
そんなのはビルド時に機械がやればいい。
容量の削減を理由に人の行為に制限をかけるのが愚かな行為だと気付いてくれたらうれしいっす。

p.61、62

もしかして勘違いしているんじゃないかと思ったんですが、「プロパティの終端」は、「宣言」の終端ではないですよ、一応。

p.63、64

と思ったら宣言のことを「プロパティ名」ってさ。どういうことです。

p.71

TODOでコメント書くのって、一時的なメモというか、あとでリファクタリングする前提のコメントだと思ってました。
だから、TODOで「何のためのものなのか誰が入れたのか」書かれててもどうしようもないような。

p.72、73

FLOCSSとMindBEMdingを共存させるなら、書くべきことが足りなすぎませんか。

p.73

block__element__elementは使用しない

冗長になるからやめようって思ってるなら、やめるのはいいけど、そもそもB__E__EはBEMじゃないってことを忘れないでほしいっすね。
https://en.bem.info/faq/#why-does-bem-not-recommend-using-elements-within-elements-block__elem1__elem2
「冗長になるから」じゃなくて「BEMじゃないから」やめろ、です。

p.78、79

打ち消しを減らすのは悪いことじゃないっすね。
でも、追加的なスタイルの宣言をモディファイアの仕事にさせるのは、なかなか危ないと思うんですよね。
決まったルールもなく大量にモディファイアが増えたCSSはコンポーネント管理されていると言えるんでしょうか。
再利用性？　必要になったら作り直す方が早いと思いませんか？
設計してても作り直すことになると思いますけどね。
あなたはそのプロジェクトのコンポーネントがどうスケールしていくかなんて、予測できているんですか？

p.80、81

言ってることは概ね正しいっす。でもサンプルのCSSにタイプセレクタが入っているのはツメが甘いとしか。

p.87

日本語校正を。

GoogleChromeなら変換時に右側に△マーク〜

それGoogle 日本語入力のことかな〜それともChromeにそういう機能があるのかな〜

p.96

この手の分類で上手くいくというのは幻想。試しに次の画像のファイル名を考えてみてください。
「ボタンを示すアイコンで、テキストが含まれていて、背景で使うことが想定されるもの」

コンポーネント単位で使う画像ファイルと、ページ単位で使う画像ファイルがあるのが変なんですよね。
- 管理区分が横断しているというか。
- 画像もすべてコンポーネント単位で管理すればいいわけなんですが。
  - でもあなたはきっと、同じファイルを別名で複数持っておくことを許してくれなそうだ。

p.98

※svgにすることで1つの画像でまかなえる場合はsvgを使用する

言っている意味がよくわからないです。
インライン SVGを使用してfillプロパティーなどで色のバリエーションを管理するってことでしょうか。だったらsvg ファイルとしては保持されないですが。
もしくはSVG スプライト？　スプライトならpngでよくないですか？　なんでわざわざsvg？
急にsvgが出て来て混乱しちゃう！

p.102

ここまで4回くらい読みなおしたんですけが、どうにも上澄みだけの理解しかしてないように感じるんですよね。
Jadeについては何かルールは設けないのでしょうか。
JavaScriptについては……？

そのほかにも、ライティング自体が下手すぎて、これを人に見せるのはどうなのっていう感じがしちゃいました。
誤字脱字くらいはちゃんとチェックしたほうがいいでしょうね。

ルールを設けるのは悪いことではないですが、穴があってはいけません。
- あいまいな基準や不足だらけのルールに、誰が期待できるでしょうか。
エビデンスの弱さも気になります。
コーディングルールの半分くらいはnodeプラグイン互換のlintツールでチェック可能です。

結論：いろいろ惜しいけど、よくなる余地はたくさんあるので、がんばってください。

Permalink | 記事への反応(0) | 11:26

2016-03-27

■【転載】プロジェクトマネジメント なう ＼(^O^)／

はじめに

すごく良いこと書いてあったのですが参考にしようとしたらサイトが消えいたので、魚拓から転載。

監督とは、他人が打ったホームランで金を稼ぐことだ。
by ケーシー・ステンゲル（MLB監督）

ポリシー

やるからには圧倒的な当事者意識と絶対に成功させるという気迫を持つ。
全てのメンバーが目的・段取りのわからない仕事をしない／させない。
プロジェクトの成功には、短期的な成功と中長期的な成功がある。両方を意識する。
プロジェクトの短期的な成功は、お客さんを満足させることと利益をあげること。
プロジェクトの中長期的な成功は、リーダーとメンバーが成長し、また一緒に仕事をしたいなと思い合うこと。
リーダーとメンバーがフラットでオープンな関係を築けなかったプロジェクトは中長期的には失敗する。
メンバーの強みを見つけて伸ばすことに注力する。その強みを持ち寄ってチームで仕事をするイメージ。
一つとして同じプロジェクトはない。どれだけ成功体験を積み重ねて実績のある方法論を確立しても、常に考えて工夫して改善し続けよう。常識という思考停止をしてはいけない。
人は一人一人別人であり仕事に対するスタンスは様々だが、ほとんどの人にとって仕事はあくまで生活の手段であり、生活のイベントより大切な仕事のタスクなんてないと考える。
リソース（ヒト・モノ・カネ・タイム）が十分に足りてるプロジェクトなんてめったにない。それでも工夫と仕組みでなんとかするのがマネジメントの醍醐味。
業務システムの開発でどんだけ失敗しても人は死なない。気楽にやろう。最も大切なのは人の心。なるべく楽しくやろう。
リーダーシップやマネジメントは効果の見えづらいものだが、人の集まりである組織には絶対に必要なもの。誰にも理解されなくても淡々とやるべし。

働・学・遊・美をミックスしましょう
by 川瀬武志（コンサルタント）

フラット＆オープン

リーダー、サブリーダー、メンバーはたんなる役割であり、対等に仕事を譲り合い奪い合う関係である。
役割に関係なくお互いになんでも言い合えるフラットでオープンな関係を作ることが最も大切。
リーダー自身が自由で本音な発言をすることでしかフラットな関係は作れない。
全ての情報を全てのメンバーにオープンに。基本的にはメール・メッセージは常に全てのメンバー宛に。
情報連携はできるかぎり速やかに。リーダーとメンバーの情報格差は百害あって一利なし。オープンにできないことはやましいことである。
チーム内に何してるかわからない人がいたり、一部の人しか知らない事情があると、とても雰囲気が悪くなる。
見積り・計画・スケジューリング・アサインは全員参加で。

門限なんかできたら私が一番困る。幼稚園の子どもではあるまいし。
by 仰木彬（NPB監督）

スピード＆フレキシビリティ

やってみないとわからないことの方が圧倒的に多い。トライ＆エラー＆リスケを繰り返す。スモールスタート＆リスケジュール。
考えてもしかたないことやわからないことを考えない。下手に予測するより聞いたり試したりする方が速い。
早く失敗することは遅く失敗することよりも何倍もよいことである。
スピードとクォリティは反比例する。どんな要求にもまずは素早く対応する。
リーダーは自分の作業に集中していてもメンバーからのアクションにはすぐ応える。「今いいですか？」の答えは常に「YES」。メンバーを待たせてはいけない。

明確なのは、楽しく笑顔が生まれる環境ほど、物事は成功しやすいということだ。我々はそういった環境を作り出そうとしている。
by ジョセップ・グアルディオラ（サッカー監督）

スケジューリング

日々リスケする。プロジェクトの初日に完璧なスケジュールが引けるはずがない。実態と乖離した変化しないスケジュールは失敗の素。
スケジュールはCCPMに準拠したやり方で管理する。これが現状の把握と未来の計画が最もやりやすいやり方。
1. 個別のタスクにはバッファを積まずに最短期間とする。
2. フェーズ毎にプロジェクト全体のバッファを持たせ、人単位で管理する。
3. スケジュールには全てのタスクと人単位のバッファを掲載する。
4. 個別のタスクの長さは、日々、現状に合わせて変更する。（常にオンスケ状態になる。）
5. プロジェクトの状況把握はバッファの消費率とメンバーの稼働状態で判断する。
スケジュールとWBSは似て異なるもの。スケジュールは見易さと扱い易さが命。メンバーが手元にスケジュールを持っていないプロジェクトは失敗する。
どの時点でもどれだけ未確定なことがあっても、実際に全体のスケジュールを引いて実名でアサインしてリソースの過不足を確認することは大切。
リソースの状況に関わらず必ずやるべきことと、リソースから逆算してやれる範囲でやることを区別すること。
重要であること／ないこと・緊急であること／ないことのマトリックスを意識する。
スケジュールを変更する時は必ず担当者と話して一緒に考えること。
森を見ずに木に手をつけてはいけない。木を見ずに森を見積もってはいけない。

計画は役に立たないが、計画することは不可欠だ。
by ドワイト・D・アイゼンハワー（第34代アメリカ大統領）

アサイン

一人一人の特徴や好みに合ったアサインをすることはとても重要。
メンバーがちょっと頑張ればできるくらいのちょうど良い質量の仕事を担当させることが理想。
全てのメンバーが自分の役割と他人の役割に納得できるようになるまで見直す。
プロジェクト期間中に成長したり変化するメンバーもいる。最後まで柔軟に変更する。
経験年数や業務知識よりも、頭の良さや心の強さや柔軟さを重視する。前者は変わるけど、後者はほとんど変わらない。
ダメな人をイイ人の上につけない。年齢や役職を無視する。新人が入社初日から旧人より仕事ができることもある。
「どんな仕事でも長時間かけても平気」「面白い仕事なら長時間かけても平気」「どんな仕事でも長時間は嫌」という仕事に対するタイプを意識する。
アサインに関してチームとメンバーの利益が一致しないことはよくある。ありのままをメンバーに話して一緒に考える。
いったん良いチームができたら同じチームで様々な仕事をしていくのが理想。（とても難しいけど。）
本人がその役割を好きかどうかはとても大切。
適切なアサインができたら、チームと個人に明確に責任を持たせ、信頼し、任せる。
各カテゴリのチーム内の権威が自然にチームリーダーをするのが望ましい。
適材を適所に。それが全て。適材がいなければ始めてはいけない。
下流工程は人数さえそろえば誰でもいいというのは大きな間違い。また、レビュイーとレビュアーの比率には要注意。
少数精鋭がベスト。できる人を入れることとできない人を入れないことは同じこと。「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ。」（ブルックスの法則）

人を最もダメにするのは「全体像」を見せずに「部分的なこと」をずっとさせること。
これ続けてると何も考える力のない指示待ち人間ができあがる。こわいこわい。
by 外尾悦郎（スペイン、バルセロナのサグラダ・ファミリア主任彫刻家）

プライド

全ての人には美意識や価値観やプライドやこだわりがある。それをできるかぎり尊重し傷つけないようにする。
人が一生懸命に話をしてる時にはなるべくさえぎらない。ため息をついたりしない。
「ダメじゃーん」と言った方ががんばる人もいるし、「よくできました」と言った方ががんばれる人もいる。
いったん優秀さを信頼した人には、どーんと仕事を任せて長い目で見る。
ほめる時はみんなの前で、注意する時は一対一で。
短期的な効率よりもやる人の気持ちを優先する場面も多い。
踏んだ人はすぐに忘れても、踏まれた人はその痛みをいつまでも覚えいている。リーダー・マネージャーは常に踏む側。

腹が立ったら自分にあたれ、悔しかったら自分を磨け。
by 村上春樹（小説家）

コミュニケーション

チーム全体で話す。数人で話す。一対一で話す。それを上手に使い分けること。
状況によって話がぶれないようにする。相手によって話を変えてはいけない。
常にメンバー全員の気持ちを知っておくことは大切。定期的に一対一で話すなど。
常に明るく楽しく。仕事に負の感情を持ち込まない雰囲気を作ることが大切。
必要な話を必要なレベルで必要な人にする。相手が望んでない話を理解できないレベルでしてもムダ。
神経質な人にはおおらかに、おおらかな人には神経質に、楽観的な人には悲観的に、悲観的な人には楽観的に。
仕事でミスした人に「ミスしただろ！」と怒っても百害あって一利なし。原因や対応や予防策などを一緒に考えることが重要。
人や仕事をなめてると感じられるメンバーを見つけた時だけは厳しく。なめられてもなめてもダメ。
仕事も遊びも類友ではあるが、できるかぎり負の影響が出ないようにする。また、類友とそうでない人の意思疎通の差は要注意。
議論の対立は失敗ではない。対立を敵視すると自由な議論ができない。
沈黙を同意と思ってはいけない。多くの場合、沈黙とともに問題が潜在化する。明確なYES以外は全てNOと受け取る。
全てのステークホルダーと良い関係を築き、明示的・暗黙的な期待を察知してコントロールすることを心がける。
人と人との問題は徹底的に話し合うしか解決の道はない。感情のぶつかりを恐がってはいけない。

ミスした選手に「ミスしただろ」と言ったり責めてもしかたない。本人が一番わかってる。
by ピクシー（サッカー監督）

クォリティ

目的、内容、責任の所在、〆切、優先度、質重視かスピード重視かなどは常に明確に。曖昧さを徹底的に排除する。
どんだけ簡単な話でも箇条書きや表や図にして考え、人と議論する時にはどんだけ簡単なものでも良いので必ずなんらかの紙を用意する。
必要のない冗長性を排除する。ルーティーンワークについては、できる限り何も考えずに簡単にまわる仕組みを作ること。
成果物・タスクの粒度に注意する。一つ一つが大きいと数が減って管理しやすい。小さいと数は増えるが柔軟にアサインできたりする。
問題を相談する時は、根本原因を明確にした上で選択肢を洗い出し、最終的な自分の意志を持って臨む。
最新の問題が最優先ではない。最古の問題が最優先でもない。発生順と優先順位に関係はない。
目に見える成果物だけではなく、段取りや、会議や、議論などの質を意識する。
頑張りや心がけではなく工夫と仕組みで救う。

神は細部に宿る。
by ミース・ファン・デル・ローエ（建築家）

コスト

なにかを作るコストとそれを利用するコストのバランスには細心の注意を払う。
〆切ぎりぎりに慌ててやるのが一番コストが低い。意識的に上手に利用すること。
メンバーの作業を遮る度に生産性はどんどん落ちていく。
だらだらした会議は諸悪の根源。会議のコストは莫大であることを常に意識する。
短期的に生産性を上げる方法はない。プレッシャーをかけても思考は速くならない。過度の残業（短期を除く）は生産性を落とす。
費用的なコストだけではなく精神的・身体的なコストを意識する。サービス残業は費用的なコストをメンバーの精神的・身体的なコストに転嫁している。
全ての仕事を全力でやってはいけない。（そんなことしてたら家に帰れない。）重要度に応じてコスト配分すること。

放っておくと会議の時間の九十五％は「コメントの交換」に使われている。
これを「明確化のための質問」「代替案の提示」「リクエスト」の三つだけに絞ると面白いほど会議が前進する。
by 大橋禅太郎（コンサルタント）

リスク

フラット＆オープンの実現が最大のリスク管理（メンバーからのアラート頼み）である。
契約前にできる限りリスクを洗い出して契約に反映する。契約後にリスクを洗い出しても手遅れ。
問題が起きた時は、暫定対処をした後に何度も「なぜ」を繰り返して根本的な原因に到達するまで対処しない。
知らないことが問題になることより、知っているつもりで誤解していることが問題になることの方が圧倒的に多い。
リソースが足りなければリーダーは無力。それを闇雲に根性で埋めようとするリーダー・マネージャーが最大のリスク。
リスクのない仕事はない。リスクがあることが当たり前。リスクがなければマネジメントなんぞいらない。

たとえば、よく晴れた日曜日の朝に戦争がはじまる。
by 「ケッヘル」（中山可穂）

リーダーシップ

「いいからやれ！」というのは通用しないし、それを言う人もそれで動く人も信用してはいけない。
正直に誠実に。自分のミスは素直に認める。公平にはできないけどできるかぎり公正でありたい。
リーダーだけは結果責任。正しくても結果がダメなら意味がない。
常に問題や誤りが起きるのが当たり前。要件も見積りも常に変化するのが当たり前。問題や誤りや変化に対応することがリーダーの最も大切な仕事。
過度の残業の発生はマネジメントの失敗をメンバーに救ってもらっているということ。残業は悪ということを徹底する。
平和だったらリーダーはヒマなのが正しい。メンバーが忙しくなる頃にはリーダーの仕事のほとんどは終わってるはず。
リーダーの笑顔は義務。加えて絶対にくじけない胆力。いつでもヒマで上機嫌が理想。
どれだけオープン＆フラットを実現しても、管理者は同僚ではないし純粋なチームの一員にはなれない。これはしかたない。
メンバーからの信頼は絶対に一朝一夕には得られない。長期間にわたる日々の積み重ねでしか得られない。
個人の評価は難しく苦しいことが多いが、厳しく明白に成果の差をしっかり反映するように努力すること。
問題が起きた時には必ず先頭に立って矢面に立つ。絶対に逃げてはいけない。結果が伴わなくともその姿勢がチームの雰囲気をよくする。
外部からの雑音を遮断することは難しい。一つ一つ理論的に検証してメンバーと共有する。
旧来の悪習は自分以降の代には持ち越さないという強い意志を持つ。
リーダーの成功は優秀なメンバーに支えられている。常に感謝の気持ちを忘れない。
北風ではなく太陽でいよう。

重要なことは、正しいか、間違いかではない。うまくいくか、いかないかです。
マネジメントとは、そのようなものです。
by ピーター・F・ドラッカー（マネジメントの神様）

その他

数値はたんなる道具であり、現場の判断の材料であったり後を追うもの。数値を計測・記録する事務作業はマネジメントの本質ではない。
ウソはあらゆる面でものすごくコストの高い最悪の手段。
夕会は人気がない。朝会か午後会で。
人は変化を憎悪することが多いし、変化への基本的な反応は論理的なものではなく情緒的なものであることが多い。
ハラスメント系の問題は何もしなければ絶対に見つからない。発見するための仕組みを用意すること。
ストレスやプレッシャーは逃げると追いかけてくるけど立ち向かうと逃げていく。でもしんどい時は相談してね。

やってみせ　言って聞かせて　させてみて　ほめてやらねば　人は動かじ
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず
やっている、姿を感謝で見守って、信頼せねば、人は実らず
by 山本五十六（連合艦隊司令長官）

クロージング

評価や反省は厳しくごまかしなく。それが最も本人のためになる。
反省会は必須。記憶が定かなうちに他者も交えて反省・改善をしないとせっかくの経験がムダになる。
反省会で、全員がオープンにフラットに悪い部分も含めて相互を評価し合えたら、そのチームはうまくいったということ。
全ての項目が○な人はいないし×な人もいない。固有のミスや特定のカテゴリで人を評価しない。全期間を通したトータルで評価する。
打ち上げは必ずやる。絶対にやる。やる。

あなたに幸運の女神が微笑んだのであれば、プロジェクトは無事に完了し、幸せになれます。とてもとても幸せになれます。多くの人々は、自分では何の失敗もしていないのに、ここまで到達することができないのです。豪勢な夜を計画してください。どんちゃん騒ぎをして散財してください。そして、その時のことをいつまでも語り継げるようにしてください。
by 「アート・オブ・プロジェクトマネジメント」