小さく始めても何らかの要因で継続するのが難しくなることってあるよね！
話したいこと
日頃の開発では、おそらく手戻りを少なくしたりトライを簡単にするのに、小さく始めてみることが多いのではないかなーと思います。その一方で、やはり小さく進めてもメンバーが忙しい状況などで途中からグダグダになったりして、継続が難しくなることはあるのではないかなと思います。その時に意識したいことをまとめようと思います。
アプローチ
グダグダになっている時はこんな感じのアプローチが考えられるかなと考えています。
graph LR;
グダグダになった時のアプローチ --> メンバーがそのトライに対して持っている障害を取り除く;
グダグダになった時のアプローチ --> メンバーが持っている別の障害となっているものを取り除く;
グダグダになった時のアプローチ --> そもそもそのトライが仕組みとして適切な形に変更していく;
メンバーがそのトライに対して持っている障害を取り除く
メンバーがトライできない要因として挙げられるのは、まずはこれな気がします。 メンバーがトライしたいがそのトライをやるにあたって障害を持っている場合は、 自分だったら障害について一緒に考えるようにしています。 メンバーが考えられない要因が一つはあるはずだから、その部分について一緒に考えることによって視野が狭まらないようにこのアプローチをとっている気がする。 あとは、この場合は何かしらの不安を抱えてこの状態になっているので、一緒にやることがベターな対応策だと考えています。
メンバーが持っている別の障害となっているものを取り除く
それ以外で考えられる要因としては、組織で働いている以上、開発以外のタスクに見舞われることがあります。 その負荷によって、どうしてもそのトライを実行できない状況の時です。 こういう場合は、 - 優先度に応じて、そのトライをやれる時まで待つ - 別のタスクをサポートすることによって、そのトライを実行しやすい状況に持っていく みたいな対応を行なっている気がします。
そもそもそのトライが仕組みとして適切な形に変更していく
最後に、そもそもそのトライが今の課題感と合っていないことや、ステップとして簡単に取り組めるようなものではないといったことです。 それっぽいなーと思ったら、スクラムで開発を進めている場合、スプリント終わりの振り返りで検査し、適応していくのが良さそうだと感じています。 より簡単にできないかをメンバー間で考えると、より一層良いトライにできるのではないかなと思います。
まとめ
以上、自分が普段意識していることでしたー。当たり前のことではありますが、忙しい中だと忘れてしまうことだと思うので、 日々意識していきたいことかなと思いました。
多分開発を進めるうちにまた項目が増えてくるだろうから、引き続き更新していこうー
とりあえず小さくやることと徐々に変化する大切さ
最近感じていること
小さくでも時間をもらって、トライしていくことが大事である。 一回トライをすると、どこかしらこうしたら良かったという点が出てくる。 その一方で、どこかしらやりたいことに合致している部分も出てくる。 それらをちゃんと分類して、次のアクションをどうしていくのかを考えていくといくと徐々に 自分の描いていたtobeに近づいていったりする。 まさにアジャイルだな。と感じている部分。最初の価値は最小でエッヂの効いた価値貢献をし、 検査、適応を通して徐々に完成形に近づけていくアプローチをしていくのが大切だ。
でも、「最初の価値は最小でエッヂの効いた価値貢献」の部分を適切に設定しないとその後がうまくいかないので、その点をうまく設計しておいたほうが良さそうではある。
今後どういうことを心がけるか
前述のことを踏まえて、自分はこういうことを意識していきたい
- 新しく始める取り組みは、MVPを意識する
- 徐々に変化できるような仕組みを整備しておく（検査・適応）
つくづく感じる内部品質の大切さとログを適切にみる能力
内部品質について
感じていること
内部品質ってやっぱり大事だなーと感じた今日この頃。 次から次へと障害が発生することで、自分たちの業務は滞るし、障害対応時は通常時と比べ、プレッシャーがかかったりする。 このような状況だとエンジニア側の心も段々と折れてくるし、ビジネス側の調整もしないといけない。 そういう点で、事業を継続的に成長させていくためには、内部品質の優先度を落とした開発はやらない方が健全だなと感じている。
こうしたいなと感じていること
内部品質を確保する時間は適切に確保していく。 特に下記活動については死守していかないとなーとおもっている。どのフェーズでも重要だと思っている。
- リファクタリング
- テスト
後回しにしちゃうことがあるけれど、硬い気持ちで意地でもやっておきたいと思った。
ログを適切に見る能力
感じていること
どういうことを観測し、どういう示唆を得たいのかを適切にログに残せる形にし、それを理解する力がないと、適切に障害対応など緊急時の対応が進まないことがある。 webブラウザに表示されている内容の対応とかだと、画面上を触ってみたらバグとかはわかりやすいが、ネットワークの問題とかまで見ないといけない問題については、この力が必須だなーと感じた。
こうしたいなと感じていること
どういう部分が画面上からだと観測しづらいものなのかを日々整理し、それらのデバッグの仕方とかを日々考えるようにしたい。 そうすれば、前述の能力も養われる気がする。
まとめ
短い内容ですが、こういう気持ちでエンジニアとして取り組みたいという決意表明でした。
プルリクエストを制御する danger というものがあるらしい
danger とは
CI の内容に応じて、さまざまな制御をしてくれるパッケージ。
その中で PR の制御とかも入っているので、ちょっと触ってみた。
やったこと
サンプルに載っていたものを拝借して、こんなコードを実装した。
name: test danger JS
on: [pull_request]
jobs:
build:
name: Danger JS
runs-on: ubuntu-latest
permissions: write-all
steps:
- uses: actions/checkout@v3
- name: Use Node.js 10.x
uses: actions/setup-node@v4
with:
node-version: 20.9.0
- name: install yarn
run: npm install -g pnpm
- name: pnpm install
run: |
pnpm install --frozen-lockfile
- name: Danger
run: |
yarn danger ci
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
DANGER_DISABLE_TRANSPILATION: true
push し、PR を作成してみたら、こんな感じのアウトプットになった。
コメントでの出力
CI の出力
まとめ
自分たちが定義した通りに、コメントや CI の結果を出してくれるものなので、github の branch protection rule とかと一緒に運用すると効果が出そう。
