読書や本 に関する投稿を表示しています

OKR 本を読んだメモ

OKR 本を読んだ。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法 | クリスティーナ・ウォドキー, 及川 卓也(解説), 二木 夢子 |本 | 通販 | Amazon

 

とくに OKR ってなんぞやというあたりにだけ絞ってメモった。

  • OKR = Objective + KeyResult
    • Objective
      • 魅力的で人を鼓舞するようなものを 1 つ設定する
      • 時間的な制約をつける(1Qずつ、3か月くらいがおすすめ)
      • それぞれの Objective は独立したものにする
        • 別部署がやらなかったんでこっちも無理でした、みたいのはナシ
      • 具体的な数字が出るようなものは KR になるので設定しないほうが良い
    • KeyResult
      • 具体的な数字としての結果を 2 ~ 4 つほど設定する
      • 数字として測れるものなら何でもよい
      • Objective の状態、結果になるために、何の数字がどうなっていたらいいか
      • この数字は成功率が50%くらい、めっちゃ頑張って達成するぞ!というストレッチゴールにする必要がある
  • OKR は階層的に紐づいていく
    • 会社としての OKR があって
    • その KeyResult に紐づく形で部門の OKR があって
    • その KeyResult に紐づく形でチームの OKR があって
    • その KeyResult に紐づく形で個人の OKR があって
  • OKR は毎週確認する
    • 日常的な業務をあれこれやっていると絶対忘れる
    • 必ず振り返りをして、方向性を直し、 OKR というゴールを目指すようにする
    • 4つのマトリックスに分けて OKR を毎週確認するのがおすすめ
      • 今週の優先事項
        • 優先事項によって OKR が進むかを考える
      • 今後 4 週間で起こる重要なこと
        • 予定に備えられるようにする
      • OKR の自信度状況
        • 成功率がどんなもんだろうか?みたいなもの
      • 健康・健全性指標
        • 目標に向かって進むが健全なために守ることを 2 つくらいあげる
    • 金曜日に進んでいる感を味わうこと
      • 各チームの今週の見せられるものを見せる
        • こんな顧客と契約した、こんなものを作った、…etc
  • 機能別かプロダクト別か
    • 組織としては機能別になっていることが多いと思うが、 OKR はプロダクト別に設定したほうが良い
    • 階層型の話と合わせると、プロダクトチームの OKR → 機能ごとの OKR → 個人 OKR という構造が良い
    • プロダクト別のチームで業務が進んでいくため
  • OKR を初めてやろうとすると失敗するのがありがちなのでリスクを減らしておく
    • 1 つのチームで導入する
    • 1 つのプロジェクトで導入する

所感とか

  • OKR それ自体はそんなに難しくないフレームワークっぽい。
  • 機能別かプロダクト別かって話は面白くて、個人 OKR になったときはどっちも盛り込むような方向が良いように思う
    • 例えば~~~って考えてみるとこういう感じ?
      • Objective
        • XXプロジェクトにおいて最前線で戦えるようになる
      • KeyResult
        • XXプロジェクトにおいて3つ以上のリリースをする
          • プロダクトに対応したKR
        • リリースされるもののうち3つ以上のレビューを担当する
          • プロダクト・機能(エンジニア面)に対応したKR
        • 次フェーズで必要になるライブラリについて予習し、チーム全体に教えられるようにする
          • 教えられるようにする → 勉強会/ハンズオンを3回実施する みたいなほうがいいかな
          • 機能(エンジニア面)に対応したKR
  • 以前、ちょっと大きめの開発でこの日に絶対リリースするぞ!ってやってたときがあって。
    • そのときは個々人で何ができるかーみたいのをなんとなく考えてやってて
    • っていうのが整理したら OKR やんって思った。
  • 評価って枠組みで考えると、OKR自体はプラスの評価に使うべきだなあって気持ち
    • なんとなくやっててもKRは達成できない
    • 考えて、動いて、一定チャレンジングにやっていく
    • だから飛躍するかもしれないし、もしかしたら失敗してしまうかもしれない
    • 失敗してもサイクル回してやっていこう💪

いじょ

CSS 設計の教科書 を読み終わった

「 CSS 設計の強化を読みました」って言ってたけどめっちゃ途中で止まっていたので完走しました。

前の記事
CSS設計の教科書を読んだ@途中まで | ごみばこいん Blog

読んだ本
Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 | 谷 拓樹 |本 | 通販 | Amazon

コンポーネント設計の実践

コンポーネントをどのように作るか。

コンポーネントを作るタイミングの問題。始めからあらゆる事態を想定してコンポーネントを作っていくことは困難であり、そんなところにパワーを使いすぎてはいけない。早すぎる最適化は悪の根源。 "YAGNI" (You ain't gonna need it.) = いらないものをつくらない。

"Rule of Three" はそれを解決するための 1 つの案。たとえば「3回繰り返すものがでてきたらコンポーネント化する」あるいは「別の3プロジェクトでも使うならコンポーネント化する」といった意識を持つのがよい。

粒度感の問題もある。ここについては、プログラミングにおける原理原則がCSSにおいても適用できることに着目し、「単一責任の原則」「開放・閉鎖の原則」などを意識するとよい。そもそも OOCSS ではオブジェクト指向プログラミングの考え方を CSS に取り入れた。

この章にはこの後、本の中では「コンポーネントの設計・実装パターン」としてボタンや見出しなど、筆者の経験上こうすることが多い、が書かれている。実際に1から作るとき、これを試してみるとよさげたん。

CSS プリプロセッサを用いた設計と管理

SMACSS や MCSS にはカテゴリやレイヤーといったルールが設けられていることを既に学んだ。これらを CSS の書き方の上でキレイに整えて書いていくことはなかなか大変。
そこで Sass を使うのがよい。Sass によってルールの構造化、使い回しなどが容易にできる。

Sass: Syntactically Awesome Style Sheets

コンポーネントの運用に必要なツール

コンポーネントを作る上で・・・。そもそも CSS を書く上でコメントを書くことは非常に大事。どんなところに提供されるルールなのか、なぜそういう書き方をしているのか、どのようなコンポーネント単位なのか。

CSS 設計をしたり、何かしらのルールを設けたのであれば、そのルールを文章化していくことが必要。全体の設計のやり方、細かいルール、ガイドラインといったことを記載するのがよい。なにせその CSS は他の人が受け継いでいくのだから。

どのようなコンポーネントがあるか、どんなクラスをつけるとどんな見た目になるか、といったスタイルガイド、パターンライブラリがあると、開発時に非常に便利になる。ある一定の決まりにそってコメントを記述すると自動で生成できるツールもあるので、活用するべし。
紹介されていたのはこれ。

KSS · Knyle Style Sheets
StyleDocco
thomasdavis/kaleistyleguide web サイトが終了しているようです。。

そのほか CSS 開発の効率を上げるために次のようなツールが紹介されていた。

  • csslint // 正しく書かれているか
  • stylestats // CSSの指標について数値化
  • autoprefixer // -webkit- などの自動付与
  • csscomb // 記述の並び替え、フォーマット
  • csso // 構造の最適化
  • Grunt, gulp // タスクランナー

Web Components の可能性

ここまで CSSの設計、ルール化によって壊れにくい、戦いやすいCSSが出来るようになった。しかし、それでも壊れる可能性は高い。それをこれからの未来に解決するための案が W3C で進められている Web Components という仕様だ。

Web Components は 4 つの技術から成り立つ。

  • Templates
    • マークアップと CSS を内包できる
  • Custom Elements
    • 独自の要素を定義できる
  • Shadow DOM
    • 隠蔽された DOM を作成できる
    • Templates と Custom Elements を組み合わせることで影響を受けない出さないコンポーネントを作成できる
  • HTML Imports
    • 外部の HTML ファイルを読み込める

まだ仕様策定中であり、利用できるブラウザも多くはないが Polymer というポリフィルがあるので、これを使うことでどのブラウザでも試すことは可能。これからのコンポーネントがやってくる未来に備え、 Web Components に触れておくとよいだろう。

読み終わってみて。

2014 年に初版が出たのもあって、 2017 年のフロントエンド界隈の話と比較するといくつか話が古そうなところもあります。

たとえばコンポーネントについては React を筆頭に Vue や Angular といった仮装 DOM を使ってコンポーネントを実現していくライブラリが活躍しています。 Web Components の実装も進み、 Chrome や Safari ではおよそ利用することが可能に、 Firefox でも実装が進んでいるようです。

React - A JavaScript library for building user interfaces
Vue.js
Angular

Web Components の実装状況
Can I use... Support tables for HTML5, CSS3, etc

CSS についても cssnext と呼ばれる、未来の CSS 仕様に向けた先行実装が今の流行り…?なのかなあ。
Sass で使っていたようなネストや変数、 Mix-in といったものは利用できますし、実行環境が cssnext というツールではなく PostCSS を利用するところに人気があるのかもしれません。

cssnext - Use tomorrow’s CSS syntax, today.
PostCSS - a tool for transforming CSS with JavaScript

PostCSS は Sass などが行っていたようなプリプロセッサというよりは babel のような、 Pluggable な CSS を処理する君で、プラグインを足して独自記法やブラウザが未実装な機能を書けるようにするものです。

このプラグインの一覧サイトがあるのですが、眺めているだけでも非常に様々なものがあります。
きれいなグラデーションを自動生成したり、 @component なんてすると BEM の命名を自動でつけてくれたり、画像や SVG を CSS のインラインに展開してくれたり…。以前までは、それぞれ別のプラグインとして作られ、 Grunt や gulp を使ってバケツリレー変換をしていたものが、 PostCSS というプラットフォームに乗っかることで、 CSS に対する前処理を容易にできるようになったようです。

PostCSS.parts | A searchable catalog of PostCSS plugins

ちなみに Sass っぽく使えるよ!というものもあるので、 Sass がどうしても!の場合にはこういう選択もありだと思います。

jonathantneal/precss: Use Sass-like markup in your CSS

というわけで、現代の先端?流行?と比べると、本で言われている技術ポイントと乖離がありそうですが、ぼくがこの本を読んでみたかった理由はそこではなく。CSS 設計のやり方、考え方、大切さ、コンポーネント分け方のイメージをつけることが目的でした。あとはそもそも OOCSS って? SMACSS って?みたいな状態だったので、これを解消したかったというところですね。

ここについては十分に解消され、実践できる武器になっているかわかりませんが、イメージはなんとなくついたので、あとは実践するのみになりましたとさ。おわり。

スモールリーダーシップという本を読んでいる

別にチームリーダーとかそういう立場ではないのだけれども、チームがうまく回っていない気がしていてなんだかなーと思ってたけれども、どうしたらいいのかわからん。というときに Amazon を眺めていたら見つけたこれ。

Amazon | スモール・リーダーシップ チームを育てながらゴールに導く「協調型」リーダー | 和智 右桂 通販

帯に書かれていたことに一目惚れして、購入キメた。

× カリスマ
× イノベーション
× 精神論

技術でチームを回そう

こんなリーダーたちにオススメ
・初めてリーダーになった人
・チームの売上や進捗をうまくコントロールできない人
・部下を育てたいと思っている人
・チーム内で意見が対立して悩んでいる人
・ PDCA 、進捗管理、問題解決などの具体的手法を知りたい人
・身の丈にあったリーダーシップを身につけたい人

まだ一章を読んだ程度でしかないが、うんうん分かる分かるぞ~~~、といったような、自分の手で言葉や体系立てが出来ていないが経験上そうなのだろう、と思うところが出てくる。過去にえらい人に言われてきたことや、えらい人がやっている部分と一致するところもあって。自分の中で色々繋がり、ちょっと楽しくなっている。

うまく引用できそうなところがわからないので、読んでのざっくりまとめにはなるが、こういうところ。

業務はおよそ知識の差がある。すると出来る人がやるに陥りやすく、知識・経験を積んだ人が突如としてヒーローになる。ヒーローが生まれてもチーム全体としての学び、経験にはならない

リーダーは手を動かさない、1人でうごかない。メンバーの新たな学びにつながり、チームを考える時間が増える

まずは 決められたこと=規律 を守り、自ら考え変えていく=自律 へ

チームとしての学びのために、暗黙知を形式知へしていく。そのためにリーダーが形にする手伝いをする。形式知が増えるとチームの見方も変わり、また暗黙知が増えていく。そうしてまた形式知へ。

ところでこういう記事って書いたことがなくて、どういうポイントを抑えればよいのかいまいちわからない。メモというか、気になったところまとめを書きながら読んではいるが、こうやって記事にするとき書きすぎると本を買わなくても良くね?となってしまうだろうし。とりあえずはこんな形で、読んで特に!!!!となった部分を引用 or まとめる程度でいこう。

それにしても、ちびっこのころはやたら本を読んでいたが、いつしか苦手になってしまったようで、読むスピードと理解がなかなか進まない身体になってしまった。読めば適応してくると思うので頑張ろう。
ちなみに、会社で本買ってええぞって予算があって、それを使わせてもらっている。ありがたし。

CSS設計の教科書を読んだ途中まで

こんにちは、ごみばこです。

最近になってようやく、ちゃんとしっかり CSS の教科書を読みました(設計の大事さと紹介まで)。そのメモというか、まとめです。CSS 設計マジ大事やなー。

Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 | 谷 拓樹 |本 | 通販 | Amazon

余談ですけど、ここのところブログをちょこちょこ書いているのですが、トップページが遊び要素メインで中身が無いと見なされてか Adwords も Amazon アソシエイトも審査落ちしたので、ごみばこいんからのリンクはノーアフィリエイトです。かなしみ、ビールの一杯くらい稼いだっていいじゃない

CSS設計がなぜ重要か

フロントエンドも作って終わりではない。
web サイトのコンテンツが増えたり、キャンペーンをしたりなど、 web サイトの内容が変わっていくので、それに合わせて各コードのメンテナンスをしていかないといけない。それはもしかしたら誰かに引き継ぐかもしれないし、自分でやるかもしれない。リッチな表現が求められる今の web サイトでは HTML も Javascript も CSS も複雑なものになっていく。

中でも CSS はシンプルに書ける一方でたくさんの記述が必要がゆえ、複雑なことをしようとすると、スパゲッティコードになりやすい。だから設計というルールを設けていく。
プログラミングと同様に CSS も設計をすることで、予測しやすい、再利用しやすい、保守しやすい、拡張しやすい、ものを記述できるようになる。

設計をどうやっていくか

見た目の変更や入れ替えがあるなかで、使いまわすようなものも多くある。その使いまわしのために、要素を部品=モジュール、コンポーネントと考えていく設計が有効になる。
そのコンポーネントとして考えるために、いくつかの実際に活用されている設計方針を紹介していく。

OOCSS

Object-oriented CSS

構造と見た目の分離、コンテナとコンテンツの分離を挙げている。
コンポーネントとしての構造、ブラウザ上での見た目を分離して考えること。ある要素がどこにいるかのコンテナ、ある要素のコンテンツを分離して考えること。

後者は難しいが「場所に依存しないセレクタを書くこと。どこそこの中にある○○、とし定義されるようなものを避けること」と考えるとわかりやすい。

SMACSS

Home - Scalable and Modular Architecture for CSS

OOCSS で言われている分離を実践するためのカテゴリが決められている。

Base :見た目のリセット、標準化
Layout:全体的なレイアウト設定(2カラムなの、3カラムなの、ヘッダー?)
Module:コンポーネント自体
State :コンポーネントの状態
Theme :コンポーネントの見た目違い

もう一つのSMACSSのポイントとして「HTMLとCSSの分離」が挙げられている。

要するに。
SMACSS = OOCSS + OOCSSを使うためのカテゴリ + HTMLとCSSの分離

BEM

BEM — Block Element Modifier

CSSにおける命名規則の提案。OOCSS、SMACSSを考えてのコンポーネントを記述できるよう規則が決められている。

Block
Elementの集合体、ひとつのコンポーネント
命名は自由

Element
コンポーネントに含まれる要素の1つ1つ
命名は Block_Element という形式

Modifier
BlockとElementについて、場合分けが起こるときに使う
命名は Block__Modifier または Block_Element__Modifier という形式

たしかにBEMでは、アンダースコアを付けるように、と言っているがそれはさほど重要ではない。キャメルでもハイフンでもいい。コンポーネントの体に合わせた命名規則を設けることで、シンプルにたくさん書けるCSSへ規律をもたらし、事故を未然に防いだり可読性を上げることが大事。

MCSS

MCSS

SMACSS にレイヤーというルールを足すようなもの。複数のレイヤーを構成することによってCSSを設計する。レイヤーとして縛りを設けることで、CSSプロパティの汚染を防いでいく。

Foundation
プロジェクトの土台、resetcssやnormalize.cssがそれ
最初に読み込まれる

Base
コンポーネント定義
他のレイヤーから拡張変更ができる必要がある
Baseレイヤーコンポーネントは上書きできる

Project
具体的なページを構成する要素、Baseレイヤーコンポーネントの集まり。現実的にはこのレイヤーが厚くなりがちだけど、上書きによって階層が深くならないようにする
Baseレイヤーコンポーネント、Projectレイヤーコンポーネントを上書きできる

Cosmetic
下層レイヤーコンポーネントに含まれないちょっとしたスタイル。ヘルパー、ユーティリティのようなもの、グローバルなModifierなど。
基本的に上書きは出来ない

Context
例外的なレイヤー。すべてを上書きできる。
特定のブラウザ、デバイス、状況によって切り替えるようなもの。PC / スマホ、ログインしてる / してない。
セクションを持たず、各コンポーネントについて書かれるセクションの中で記述される。

レイヤーの分け方に合わせて、CSSを記述するときの基本原則がいくつかある。

  • コンポーネントを1つのセクションにまとめる
  • Modifierを個別クラスにし、単体で利用しない
  • コンポーネントのカスケーディング(上書き)が出来る
  • あるコンポーネントに含まれる別のコンポーネントに適用するスタイル。ただし上層のコンポーネントを上書きしてはいけない。同じ層か、下層のみ上書き可能
  • クラス名を略語にする

FLOCSS

この本の筆者が考えている、全部まぜのいいとこ取り。

ソースファイルのセクションわけ、レイヤー制約、命名制約が盛り込まれている。詳細は Github で!
hiloki/flocss: CSS organization methodology.

ルールこそ多いように見えるが、ルールに乗れると非常に楽(体験談)

ここまで読んで

個人的なちょっとしたやつで Bootstrap を入れた上で、新たに書き足す部分を FLOCSS を意識して作ったところ、非常にわかりやすく、事故もなく、安心安全にできてちょっと感動してました。
…、とはいえ FLOCSS でみんなやろうぜ!というわけではなく。本にも書かれているのですが、色々な考え方があるけど俺達はどうやってやるよ、というのを改めてちゃんと考えないとね、って思いましたとさ。

いじょ。