メモ書き: アジャイル開発手法の実践における注意点

アジャイル開発手法の導入を検討するにあたり、いろんな勉強会に参加してたりするんですが同じような注意点を耳にしたので、一回まとめておこうと記事にしました。

  • アジャイル開発手法は問題解決の手段ではなく、あくまで問題発見のためのフレームワークである
    • 「スクラムをやっているのにうまくいかない」などというのは当然であり、そこから始まる議論や改善のためのアクションが大事　議論を重ねて自分達の開発スタイルにたどり着くのがゴール

      • 「WIPの制限はルールではなく、ガイドラインであり、議論の引き金だ」（カンバン仕事術）

      • 「XPを使えば、問題の解決に取り組むための新しい文脈が手に入る」「XPは問題を解決するものではない」（エクストリームプログラミング）

  • 「アジャイル開発ではこうあるべき」といった教条主義に陥らないこと

    • 「個人やチームがエクストリームかどうかをバイナリで判定するテストは存在しない」（エクストリームプログラミング）

    • あるべき論ではなく、自分たちがより良くやるためにどうすれば良いかを考える
  • （一方で）最初から原則を無視したり、プラクティスを省略したりしないこと

    • 「スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。」（スクラムガイド）

  • アジャイル開発プロセスは相互におけるプラクティスを禁止するものではない
    • 例えば「スクラムでやってるからXPのペアプログラミングはできない」というわけではない チームの課題に応じて別のフレームワークのプラクティスを取り入れることは可能

    • 「 カンバンはメタプロセスである」（カンバン仕事術）

    • 「スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。あるいは、その存在を不要にする。スクラムによって現在のマネジメント、環境、作業技術の相対的な有効性が可視化され、改善が可能になるのである。」（スクラムガイド）

新たに知見を得たり、自分も実践する中で追記や編集するかもしれませんが、一旦現状のまとめとして。

スクラム・カンバン・XPを比較してみた

チームへのアジャイル開発手法の導入を検討するにあたり、主要なアジャイル開発手法であるスクラム・カンバン・XPの比較を行って見ました

※ 正確ではない表現や事実誤認が含まれている可能性があります。ご容赦ください🙏

それぞれの比較

前提

比較方法

  • 表を用いて各種手法に共通すると思われる項目において比較した

※ それぞれのアジャイル開発手法で語られているアングルは異なるものの、表による比較のために強引に同じ水準にまとめた部分があります。 あくまで参考程度としていただけますようお願いいたします🙏

考察

スクラム

  • コミットメントを価値におき、それがプラクティスにおいても要求されるところが最大の違い
  • コミットメントを実現するためチームに課される実施項目（役割・イベントなど）が多いと思われる
    • 逆にいうと、コミットメントへの要求度合いが高い請負契約などでは向いているのかもしれない
  • また、「価値の創出」に重きをおくのでスプリントレビューで達成されたことや、状況の変化をレビューし、価値を出せるかをチェックすると思われる

カンバン

  • 要求されるプラクティスは他と比較して少ないのではじめやすさはあるが、逆にいうと補うべき項目も多いので難易度が低いというわけではないと思われる
  • 他の手法のように生産した成果物の「価値」や「品質」を目的とするものではなく、あくまで「プロセスの改善」を目的とするものなので、カンバンでそれらを作り出そうと思った場合は別のプラクティスなり考え方が必要と思われる

XP

  • 「価値」や「原則・理論」で挙げられている項目が最も多く、具体的なプラクティスというよりは行動規範や指針としての要素が強く感じられる
  • いわゆるアジャイルのレフトウィングの「開発の進め方」や「開発環境」まで言及している
  • 他の2つと比較して「いきいきとした仕事」「ゆとり」といったようなチームで働く人・プログラマーを考えた原則が見受けられる

全体を通して

  • 同じアジャイル開発手法という枠組みで捉えられているが、それぞれ目的やカバーしている領域が異なる部分がある
  • 特に、それぞれの目的や価値については、書いてある内容や量からその重視する点において以下のような差異があるように感じられた

それぞれの目的における差異

  • こういった差異があるので以下のことを気をつけたい
    • 同じ水準で語られることが多いがそれぞれ特色があるので、導入の際にはその目的や要求されるプラクティスをきちんと理解しておくこと
      • そうでないと、プロセスに対して期待値のすれ違いが起こる可能性がありそう
    • やはりどれかのアジャイル開発手法を軸としつつ、言及されていない部分を他の手法から補完することで、全体としてアジャイルに近づくのではと思う

追記:

「手法ごとにカバーしている領域が異なる」という点についてはMartinFowlerのブログにも似たような趣旨のポストがありました。

bliki-ja.github.io

やはりそれぞれの手法が目的としている領域をきちんと理解するというのは変わらず、足りない部分を自律的に補う、というのは必要ですね。

2022/08/04 『ソフトウェアアーキテクチャの基礎』 - Techmee vol.2 感想

timeedev.connpass.com

参加してきました。 タイトルの「ソフトウェアアーキテクチャの基礎」自体は未読で参加したのですが、学びが多かったので感想をメモしておきたいと思います。

アーキテクチャ決定は「最善」ではなく「最悪ではない」アーキテクチャを目指す

  • 自分としては最善を目指しがちで作業が止まる、というのが癖としてあるので、もしアーキテクチャ選定に関わるのであれば気をつけないとなと思いました
  • 同時に、「最悪ではない」を実現するには（発表にもあった）判断を遅らせることや、また判断を遅らせてもよいポイントを見抜くための「後で変えられるもの/変えられないもの」を見極めるスキルや経験、意識が必要だよなとも思いました

アーキテクチャ特性は全ての特性を高い水準で満たすことはできないので、トレードオフを意識して取捨選択をしたり、程度を決める必要がある

  • こういったトレードオフの判断をするために、アーキテクチャ特性にどんなものがあるか理解が必要になるんだな、ということを思いました
  • また「どういう状況で、どういう選択を、なぜとったのか」というのをしっかり把握しておく、ないしは記録しておくことが、アーキテクチャの継続的な成長にも必要そうだと思いました
    • この話に関連してADRも話題に上がっていたかなと思いますが、お話を聞く限りまだここら辺のベストプラクティスはないような気もしています

機能が増えるに従って設計の重要性が増し始める

  • 具体的にはPMFあたりから設計の重要性を意識し始めるよね、という話もあった気がします（間違ってたらすみません）
  • 個人的な所感ですが、だいたい最初のローンチから2-3年くらいという感覚もしており、ここら辺は皆何となくの感覚があるのかもしれません
  • いずれにせよ、「アーキテクチャが今の環境に対応できているか？今後対応していけるか？」というのは、何かしら時期（四半期とか）や企業活動（調達とか）の折に触れて検討すべきことなのかもしれません（何かしら内外の変化が生じているはずなので）

DevOps・組織構造・ビジネスおけるコアな価値など、さまざまな要因が アーキテクチャ決定に影響する

  • この要因を把握するだけでもしんどそう...と思いました
    • だからこそ発表の中でも「アーキテクチャの決定は難しい」とされていた気がします
  • どこまで検討に時間をかけるか、というのも現実の問題として現れてきそうとも思いました

参考になった書籍

感想として大きなものはこんなところだったかなと思います また、「dependency-cruiser で依存関係を把握して境界作りに役立てる」というのは良いアイデアだと思ったのと、以前別の勉強会でもありましたがやはり実戦で学ぶところが多いので、身近なところから考えてみるというのは大事だなと感じました。

駄文ですが、感想でした。 参加させていただき、ありがとうございました！

2022/07/22 NestJS meetup Online #3 感想

nest-jp.connpass.com

こちらのイベントに参加したので、まなびになった部分をメモとして残しておきたいと思います。

参加したモチベ

  • 参加しているプロジェクトでNestJSを採用している
  • 技術選定をどう考えるか、ということ自体に興味があった

まなび

技術選定

  • 技術選定においては技術的なチャレンジ・ワクワク感というのも軸としてありうる
    • 枯れている技術は安定しているが、チャレンジ要素は少ない　
    • 一方で新しい技術はチャレンジングで面白いが、技術的な解決が難しくなるシーンもあり
    • 両者のトレードオフを意識する必要がある
  • 検索ボリュームで情報の流通量を調べて技術選定に活かす
  • 継続的な発展が期待できそうかを判断するにあたり、スポンサーの多さ・内容をチェックするのも良さそう

NestJSのよさ

  • 技術的なキャッチアップがしやすく、始めやすい
    • JSを触っていれば、基本文法でつまづくというのはないハードルの低さ
    • 思想の癖が薄めで軌道修正がしやすいフレームワーク なので正解を知っており、周囲をリードするような人さえいれば導入がしやすい
  • スイッチングコストの低さ
    • フロント・サーバサイドをTypeScriptで一本化できる
    • ここは発表いただいた3社全てに共通する採用理由だったかと思います Nest JSのもつ良さの中でも主要なポイントだと思いました
    • （エンジニア採用という面でもメリットが大きそう）
  • DIが標準でサポートされている
    • （自分は正直ありがたみがよくわかっていないが）前回のNest JS Meetupでもこの部分に良さを感じている方が多かった印象です

NestJSのつらさ

  • これというベストプラクティスがまだない部分がある
  • ドキュメントの充実度が低い
    • （ここは人による部分もありそうで、「充実している」という意見もありました）
  • NestJSというよりORMにツラみがありそう
  • 「この機能はNestJSでもあるだろ」というような機能でも意外となく、解決するのにExpressの知識が必要な場合もある
    • （ここは逆にいうとExpressの知識がきちんとあれば解決に至ることができる、とも言えるのかなとも思った）

Nest JSの運用テクニック

  • 肥大化にはまずモジュールの分割で対応するのが良さそう
  • 依存関係が複雑になり始めたらdependency-cruiserを使うのも一つの手

編集後記

  • トータルでNestJSは「いま始めるのにちょうどいい技術」という印象を受けました
    • 始めやすさ・変更のしやすさ、技術の成熟度（枯すぎず・新しすぎず）というのがいいバランスの状態なのかなと思いました
    • 逆にいうとこれは今現在の状態なので、今後どうなっていくかという意味でもウォッチしていきたいフレームワーク だなと思いました
  • 技術選定については、技術的なチャレンジの要素も選定の軸になりうるというのが気づきでした
    • ワクワク感や楽しさというのも加味して考えるのも一つポイントだなと思いました
  • NestJS MeetUp #3 - YouTubeので興味のある方はぜひご覧いただければと思います
  • 登壇者・運営の方々、貴重な機会をいただきありがとうございました！🙏

2022/07/20 ビットキー × Voicy × バニッシュ・スタンダード 3社合同開催「DDD勉強会」感想

bitkey.connpass.com

こちらの勉強会に参加させていただきました。自分のTwitterのメモを頼りに感想を書いておこうと思います。

※ 投稿者は「DDDってよくわからないけど、なんかいいらしいぞ！」くらいの知識しかないので、 不正確な理解・適切でない表現についてはご容赦いただけると幸いです 🙏

メモ

他のアジャイル・スクラムの勉強会でも似たような話（「スクラムは方法論じゃないので”スクラムではこうすべきですか？”はやめましょう！」）を聞いたので、心に残ったフレーズでした。

教条主義というか、考え方やツールに固執して振り回されるのではなく、直面する現実にきちんと向き合ってその考え方やツールが適応できるか・課題を解決できるか考えないといけないよなあと思いました。

ここら辺は勉強不足で「そういう言葉どこかで聞いたことあるなあ」くらいでしたが、今回のお話がまさに現場においてこれらを実践したらどうなったか、という話だったと理解しています。

他の発表もそうでしたが、今回はリファクタリング・リプレースの文脈でDDDの採用となったケースが多いのかな？と思いました。

一方で別の勉強会ではクライアントワークにおいて、初期段階で速くドメイン知識を吸収するために採用しているケースもあるという話を聞いているので、DDDの利用シーンは特に限定されておらず、直面する課題と、DDDが解決してくれるものが適合しているかで考えないといけないなという先の話にもつながる結論に落ち着きました。

そして、そのDDDが解決してくれるものとして仕組み化による堅牢性や知識の集約、ということが話されていました

また、DDDの実践においてはチーム・システム両面において段階的に適応するのがやはり王道なんだなと感じました。

特にDDDは人によって理解がまちまちだと思うので、チームに関しては共通認識をしっかり作っていかないと難しそうに感じ、 その段階的な適応を推進するために、知識や立場の面で周囲をリードする存在はやはり必要そうに思いました。

同時に、課題に直面しているとどうしても一足飛びに解決策に飛びつき、全て適応したくなるところを抑える問いとして、 「〇〇を始められる開発組織なんだっけ？」という発表スライドのタイトルにもなっていたフレーズは冷静さを取り戻させてくれる良いフレーズだなと思いました。

感想

まだまだDDDの理解のスタートラインに立ったばかりの自分でも色々な発見があり、楽しい勉強会でした。 主催してくださった3社の方ありがとうございました🙏

また、第二回目も予定されているようなので、関心のある方はぜひ参加されると良いと思います。

bitkey.connpass.com

エンジニアとしてブログを始めてみる

重すぎる腰を上げて、エンジニアとしてのブログをやっと作成した。

前々からアウトプット大事だなーとは思っていたものの、ブログやるならドメインとかとったほうがいいのかな、どこでどうやるのがいいのかな、なーんてことを考えていて全く進捗していなかったので、結局一番手間が掛からず始められそうな、はてなブログで始めることにした。

そもそも続くかどうかも、読む価値のあるコンテンツを投稿できるかもわからんのに色々と考えすぎたと反省しつつ、読んだ本とか参加した勉強会の感想なんかをゆるく書いていければいいなーと思っている。