jtk

🍺 nodebrew 🍺

インストールされている Node.js のバージョン確認

$ nodebrew list
v10.15.0
v11.6.0
v12.11.0

current: v12.11.0

安定版のインストール

nodebrew install-binary stable

バージョン指定でインストール

nodebrew install-binary v10.16.3

使用するバージョンの切り替え

$ nodebrew use v10.15.0
use v10.15.0

現在のバージョン確認

$ node -v
v10.15.0

2019年9月 振り返り

結果

ブログ

目標:月 12 回(週 3 回)更新
結果:月 4 回 更新

読書

目標:月 1 冊
結果:月 2 冊

反省点など

スクラム開発を知りたい欲が高まって関連本読んだが、技術的に進歩はほぼなし

来月に向けて

Nuxt 触ってサイト完成までもっていく。実績として1つ公開したサイトを作っておきたい
ブログの更新は目標回数見直そうかなと思います

【読書メモ】カイゼン・ジャーニー

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー を読みました。
先日の 正しいものを正しくつくる で開発手法(アジャイルスクラム)に興味を持ったので同じ著者の方の本ということで選びました。

概要・ポイント

書かれている内容は「正しいものを正しくつくる」の内容と似ていると思います。
物語形式で書かれており、そのなかで解説が都度入ってくるというスタイルで、主人公がタスク管理について〜開発チームのリーダーとしてチームをまとめたり、同じ方向を向かせるために様々な方法を通して解決していく流れです。

最後にユーザーインタビューを突貫でしたり詰め込んでいる感がありますが、前提として物語を読みたい < カイゼンや開発について勉強したい、だったのでそこは気になりませんでした。

良かった点

  • 物語形式で話が進む点
  • 開発手法のこともあったが業務改善の方法についても多く触れられていた点
  • デザインプロセスから

惜しかった点

  • 大きいポイントではないが人物相関図があればもっと話が入ったかもしれない

まとめ

タイトルに「カイゼン〜」があるので当たり前なのですが、思っていたよりも開発寄りの話ではなく業務のカイゼンの手法の話も多かった。
あまりその手の本を読んでこなかったので勉強になった。
経験踏まえて我流でやっていることにもモデルや概念は元々あるというのも知ることができた。

ただ知らなかった考えの中で役立ちそうそうなことも多かった。

  • 氷山モデル
  • Working Agreement
  • 狩野モデル
  • ECRS
  • リーダーズインテグレーション
  • CCPM

Nuxt.js をさわってみる

Vue.js と WordPressと使って、SSRできる仕組みということで Nuxt.js を触ってみました。
yuheijotaki/nuxt-study_20190919: Nuxt.js for study 20190919

f:id:jotaki:20190924093802p:plain

導入は基本これ通りです。
Vue CLI使うとすんなり環境構築できますね
Nuxt.js使ってみた - Qiita

sass を使う

index.vueやcomponents配下の.vueファイルでsassを使うには、ふつうのVueと同じで $ npm i -D sass-loader node-sass
をインストールする

_mixin.scss など .scssのグローバルファイルを使う

$ npm run dev をすると触れるようになるのですが、Sassのグローバルファイルを使いたい場合、Nuxt Style Resources というモジュールをインストールして nuxt.config.js に設定情報を記述する。
$ npm i -D @nuxtjs/style-resources
nuxt.config.js

module.exports = {
  // ...
  modules: ['@nuxtjs/style-resources'],
  styleResources: {
    scss: [
      '~/assets/sass/foundation/_variable.scss',
      '~/assets/sass/foundation/_mixin.scss',
      '~/assets/sass/foundation/_common.scss'
    ]
  }
}

これでindex.vueやcomponents配下の.vueファイルで_variable.scssで設定した変数が使えるようになる。
参考: 《Nuxt.js》Sassの共通の変数やmixinを一括で各コンポーネントに読み込む方法。 - Qiita

参考

【読書メモ】正しいものを正しくつくる

正しいものを正しくつくる を読みました。
数ヶ月前にスクラム開発を取り入れたある程度大きな案件に携わったのですが、そもそもアジャイルスクラム開発についての理解が薄かったので最近出た本で評判が良さそうだったのでこの本を選びました。

概要・ポイント

この本のなかの「正しい」という言葉の定義については、

「わかるものをわかるようにする、わかったことを形にする」 「正しいものを正しくつくる」を、「わかったことを正しくつくる」と読み替えて、

あたりが定義されている箇所かなと思います。

  • 第1章 なぜプロダクトづくりがうまくいかないのか → プロダクトづくりの現状
  • 第2章 プロダクトをアジャイルにつくる → アジャイル開発/スクラムとは、イベントについて
  • 第3章 不確実性への適応 → アジャイル開発で出てくる問題点にどう対応すべきか
  • 第4章 アジャイル開発は2度失敗する → プロダクトオーナーが自身やチームとどう関わるか
  • 第5章 仮説検証型アジャイル開発 → 検証活動について
  • 第6章 ともにつくる → まとめ

現在の私たちが作ろうとしているプロダクトとは、「どうあるべきか本当のところが誰にもわからないが、なんとかして形に仕立てていく」

と書かれている通り、その前提がどのように生まれてどのようにそれぞれの立場や役割で関わったり向き合うべきか、もしくは周囲の状況(ユーザーやニーズ)の多様化など、不確実性の高いプロダクトづくりにどう向き合うべきかのような内容が主かなと思います。

良かった点

  • アジャイル開発、スクラム開発について一連のフローやイベントの目的が分かった
  • スクラムマスター、プロダクトオーナーがどのような視点(視座/視野)で仕事をするのか(するべきなのか)がなんとなく分かった
  • 現在の開発スタイルへの考え方のトレンドというか流れと、今後どのように開発者がプロジェクトに携わるようになるかが分かった

惜しかった点

  • 仮説検証段階の話は、自分の今の立ち位置だとピンとくる話が少なかった。けど、それも含めて越境していくことなんだと思う。

まとめ

開発手法についてのこういう類の本ははじめて読んだのですが、会話などの直接コミュニケーションも大事にすることは意外でした。 アジャイルソフトウェア開発宣言 というのがあるのですが、そこにも

プロセスやツールよりも個人と対話を、 とあるので開発手法っていうのが上辺だけの開発にまつわる決まりと勘違いしていました。

プロジェクトに関わる人が多い案件はやってこなかったので、今の会社はそれができる体制が整っているので今だから勉强できること、という感じで新しい学びが得られるように今後もしたいなと思います。

2019年8月 振り返り

結果

ブログ

目標:月 12 回(週 3 回)更新
結果:月 7 回 更新

読書

目標:月 1 冊
結果:月 2 冊

反省点など

読書やVueのクイズを一旦完成までもっていけたが、ブログの更新数がまた達成できず

来月に向けて

来月も忙しそうだが細かめの内容でもメモしてアップする習慣をつける  
Vueで新しくなにかを作る

Backlogでの課題管理など

最近案件でBacklogを使っていて、課題管理など自分なりにやりやすい方法をみつけたのでまとめてみます。

f:id:jotaki:20190827101916p:plain

ルール決め(ざっくりとでも)

最初に構想をもつ。
下記に挙げるようなフローにおいて、

  • どのタイミングで起票するか
  • どのくらいの粒度で課題を立てるか
  • だれに担当者の割り振りを行うか
  • いつどのようなときにステータスを変更するか
  • だれにとっての完了か
  • なにWikiに記載するか

上記はプロジェクトごとに、どのようなプロジェクトか、誰と共有するプロジェクトか、いつまでのプロジェクトかでも変わるので毎回変わる。
また運用していく中でもこっちの方が分かりやすいねといった感じで変わっていくが、あらかじめ枠組みないと各自のルールで進めてしまい課題に対しての捉え方(特にステータス変更)がバラバラになってしまう気がする。

起票タイミング

何か課題となること(タスクとなること)を見込みを含めて起こりそうになったタイミングですぐに起票する。
起票しないと忘れてしまうし、仮にタスクがなしになったときも完了理由を「対応しない」で課題完了すればOK。

課題の粒度

基本的には細かければ細かいほうがやりやすい。
大きな粒度だと、例えばその中でタスクが10個ある状態だと9個完了してても残りの1個がまだで課題完了ができない。→ 一覧で見たときに進捗含め可視化しづらい。

課題詳細

コメントには重要な情報を置きっぱなしにせずに、こちらに不変の情報(仕様や修正内容)を記載する。
各課題はコメントの着信ベースで閲覧されるが、課題の本来の目的に立ち返るときに参照できるものに随時アップデートしておく。
何個かタスクが入った場合はチェックボックスを使う必要があるが、本来確認事項のメモなどに使う用途のような気がするのでやはり課題自体の粒度を細かめにするのがよさそう。

ステータス

どのタイミングで各ステータスに変更するか、共通認識をもっておくことが大事。
特に「完了」課題は一覧でフィルターかからないのがデフォルトのため、基本的には誰にも見られない課題になってしまい注意が必要そう。

担当者

基本的には未設定にしない。だれがボール持っているかをはっきりさせる。

コメント、コメントのお知らせ

誰に言っているのかをはっきりさせる。(@でメンションつけれればいいなと、自動的にお知らせも届く)
お知らせはcc的な意味合い込めて関わる人にはつける。

種別とマイルストーン

あんまりきちんと使えてないんですけど、課題フィルターするときとかつけておくと便利だなーと思います。

ガントチャート

こちらは全然使えてないです。

Wiki

こういうBacklogルール含めルールなどをHomeはインデックスつけておいておく。


こんな感じでしょうか。
とにかく忘れるのが怖い(自分の記憶に自信がない)ので、管理のための管理にはならないようにツールに頼りたいと思います。

↑とは関係ないですが、最近読んだBacklogのアクセシビリティ改善の話
https://speakerdeck.com/nulabinc/actions-for-improving-accessibility-in-backlog-ja11yc