$shibayu36->blog;

株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。

TypeScriptでCLIツール作りをするためのプロジェクトサンプルを作ってみた

最近TypeScriptの学習をしようと思い、何でもTypeScriptで作ってみている。今回はCLIツールを作ろうと思ったのだが、ビルド環境やeslint環境など考えることが結構あった。そこでTypeScriptでのCLIツールのプロジェクトサンプルを作りながら勉強してみた。

作成したのは https://github.com/shibayu36/typescript-cli-projectnpm install -g shibayu36/typescript-cli-project でtypescript-cli-projectというコマンドがインストールされ実行できるようになった。

このプロジェクトサンプル作成を通して学んだことをメモしておく。

参考文献

以下2つの文献が入門として非常に参考になった。この2つの文献を参考にしつつ、公式ドキュメントを追いかけながら作成していった。

ビルドの環境を整える

TypeScriptを使うのでビルドの環境を整える必要がある。tscだけでも出来ると思うが、今回はwebpackも使ってビルド環境を作ってみた。

インストールした時にコマンドを使えるようにする

package.jsonのbinで指定されたkeyがコマンド名、valueが実行ファイルとなる。指定するファイルはshebangを設定してないといけなそう。そのためbinディレクトリ以下には、shebangとビルドしたファイルをrequireするだけのファイルを作る。

eslintとprettierとvscode

コードを書く時に何も考えたくないので、lintもかけてフォーマットも自動で行われるようにする。

  • .eslintrc.js
    • overridesを使ってTypeScriptのファイルだけ @typescript-eslint/parser を使うようにしている
    • このようにすることで、jsのファイルなどがあってもうまくeslintが動く
  • .eslintignore
  • .prettierrc.js
  • .vscode/settings.json
    • VSCodeでのフォーマットではデフォルトのフォーマットではなく、eslintのfixが働くようにしている

まとめ

今回はTypeScriptでCLIツール作りをするためのプロジェクトサンプルを作ってみた。今度作るCLIツールはこのプロジェクト構成を使って作ってみたい。

SCRUM BOOT CAMP THE BOOK【増補改訂版】を読んだ

スクラムを基本から学びなおしたいので、スクラムガイド(2017)読んだ - $shibayu36->blog;に続いて、SCRUM BOOT CAMP THE BOOK【増補改訂版】を読んだ。

個人的に印象に残ったのは

  • インセプションデッキは単なる話し合いの機会を提供しているにすぎない。みんなで一緒にスライドを作り、認識合わせをすることが一番
  • プロダクトバックログの順序をつけるときは、直近の数スプリント分くらいに注力する。早く実現したいものが漏れていなければ問題ない
    • 今の自分のチームの優先度付をどうするかについて悩んでいたので参考になった

読書ログ

* スプリントプラニングを開始する前にプロダクトバックログリファインメントと呼ぶ事前準備が必要。プロダクトバックログの上位項目について準備する 338
    * 項目の中身を具体的にする、項目の疑問点を解決する、受け入れ基準を明らかにする、項目を自分たちが扱えるサイズに分割する、項目を見積もる、など
* デイリースクラムは問題解決の場ではない。問題が報告されたらデイリースクラム終了後に改めて必要な人を集めた別の会議を設定する。デイリースクラムはタイムボックスを守る 386
* スプリントレトロスペクティブで出たアクションアイテムのうち最低1つは次のスプリントのスプリントバックログに含める 426
* スクラムの流れの図 474 ※
* プロダクトオーナーとスクラムマスターを兼任するのは絶対にだめ 615
    * POは作るものをより良くすることに注力する必要があるので、開発チームにもっとたくさん作って欲しいなどのプレッシャーを無意識のうちにかけてしまうかもしれない
* インセプションデッキは単なる話し合いの機会を提供しているにすぎない 711
    * 自分たちの向かう先についてみんなで知るためのツール
    * 1時間半くらいでみんなでスライド一枚を作り上げるくらいの気持ちで
    * 出来る限り一緒にスライドを作る時間を確保する
* 優先順位は分類ごとに一列に並べる 808
    * 超重要、重要、ふつう、あればうれしいとか
    * 感想) 分類ごとで良い、というのは面白い
* エレベーターピッチを作る時は、メンバーごとに書く時間を取り、全員がかけたら共有しあう 1028
    * 認識のずれなどが見える化される
* プロダクトバックログの順序をつけるときは、直近の数スプリント分くらいに注力する。早く実現したいものが漏れていなければ問題ない 1614 ※
* 9人以上の人数で開発する場合、複数の開発チームで協力しながら開発を進めるアプローチを取る 2665
    * プロダクトオーナーは一人、プロダクトバックログも1つ
    * それぞれの開発チームにスクラムマスターがいる
    * プロダクトバックログが大きくなるとプロダクトオーナーの負担が大きくなる。プロダクトオーナーを支えたり横断的に問題解決したりするために、スクラムオブスクラムを行う
        * デイリースクラムの後にリーダーだけが集まって検査を行う

開発チーム運営では問題発見・改善だけでなく、良かったことの共有も大事にする

 開発チームをスクラムなどを使って運営している時、改善がどんどん行われることは良いことである。しかし、その時によく起こりがちなのが、問題発見と改善にフォーカスしすぎた結果、チームの悪いところばかり見すぎてしまうことだ。過剰に悪いところばかり見てしまうと、徐々にチームが疲弊してしまうといったことが起こる。改善が捗ることは良いことだが、それでチームが疲弊してしまわないように注意しなければならない。

 ちなみにスクラムガイドを参照してみると、スプリントレトロスペクティブの目的には「うまくいった項目や今後の改善が必要な項目を特定・整理する」と書かれている。つまり、デイリースクラムやふりかえり会などでは、問題発見と解決だけでなく、良かったことを言語化し再生産可能にすることも重視されているのである。

 以上から、開発チーム運営では問題発見・改善だけでなく、良かったことの言語化・共有を大事にし、その2つをうまくバランスさせる必要があると考えている。

 しかしながら、これまでの経験では、かなり意識的に良かったことを取り上げるようにしないと、結局問題発見・改善ばかりに目がいってしまうことが多かった。そのため、良かったことの共有を行いやすいように具体的に工夫したことを紹介してみる。

デイリースクラムに、良かったこと・自画自賛コーナーを設ける

 良かったことを日常的に取り上げる場がないと、中々良かったことは共有されない。そこでデイリースクラムに「良かったこと・自画自賛」というコーナーを用意し、小さい良かったことや自慢を取り上げやすいように工夫したことがある。

 ちなみに、次のようにいくつか失敗パターンもあった。

  • 口頭でいうコーナーを作るだけだとなかなか出てこない
  • 良かったことを自分の日記に書くみたいな形式だとなかなか出てこない

 今まで試した中で良かったことが一番出てくるのは、デイリースクラムの会場をみんなで同時に書き込みできるツール(例: scrapboxgoogle docs)を使って用意し、ワイワイ書けるようにしておくことである。このようにすると、書きやすいだけでなく、誰かが書いた良かったことに対しさらにコメントが付くなどの連鎖反応が生まれることもあった。

 他にも提案した自分が真っ先に書きまくるというのも普通に大事なので、そこは頑張りましょう。

KPTにGoodを追加してGKPTにする

 KPTを使ってふりかえり会を行うのは定番である。しかし、Keepと言われると結構ハードルが高いようで、あまり良かったことが共有されないことが多かった。

 そこでKPT会にGoodという項目を混ぜてGKPT(参考: http://c16e.com/1510132118/ )にするという工夫をしたことがある。2チームほどでGoodを追加したGKPT会を経験したが、やはりKeepと比べてGoodは書きやすいようで、良かったことが出てくる割合が増えたように感じた。

 また、Goodを増やして良かったことを書きやすくしたとしても、議論しやすいのはProblemなので、結局ふりかえり会の時間の大半はProblemについて話しているとなることも多い。そうならないように、GoodやKeepの時間を明示的に取るというのも有効だと思う。

 あとは出てきたGoodやKeepを再生産可能な形に言語化するのはスクラムマスターやファシリテーターの腕の見せどころなので頑張りましょう。

まとめ

 今回は、開発チーム運営では問題発見・改善だけでなく良かったこと共有を大事にすると良い理由と、そのために自分が具体的にした工夫を書いてみた。ただこのような工夫をしても、気を抜くと問題ばかりにフォーカスしてしまうことが多々あるので、より良い方法を模索していきたいと思う。

参考