"開発体制"投稿一覧

バグ対処や人員確保、スケジューリング、顧客要望などでスケジュールが押してアジャイル開発になってしまっている気がします。

まずアジャイル開発...というところの定義の認識を揃えるところから始めると良さそうです。Wikipediaの引用ですが、アジャイル開発の定義は以下のようになっています。

典型...

続きを見る

メリット・デメリットをテーブルの上に出し尽くして議論できた前提なのであれば、メインで物事をリードする関係者の覚悟次第だと思いますね。
もちろん課題に対して最適で、お客さんへの価値提供を念頭に置いた技術選定をすべきという話はありますが、結局は開発に関わる誰がどれくらいのコミットなのかで最終判断は変わってくるのではないかと。
仮に課題に対して最適で、お客さんへの価値提供を念頭に置い... 続きを見る

テストを書いたりレビューのやり方を明確にしたりなど、デプロイしてOKになるための基準を明確に定めておくことが必要かと思います。
決めるだけだとなあなあになる可能性もありますので、CIでリントエラーやテストエラーになった場合はマージできないようにするなど、やらないとデプロイできない仕組みにもしておく必要があります。管理する側も「あー仕組み的にリリースできないから、ごめん、修正して」と言える... 続きを見る

スクラムというのは型なので、ただ型を入れているだけだとそれに従って動いているロボットみたいになってしまいます。
基本的に型を入れたときに、ちゃんとそのチームに合ってるいかどうか、差分を見つけ出すのが大事です。

例えば、前のチームだと「スプリントレビューっていらないよね」という話だったり、そもそも常にコミュニケーションを取ったり、POがちゃんとスプリントのレビューに入... 続きを見る

工数で話すというのはあると思いますが、注意は必要です。

最近あったのが「友達紹介キャンペーンをやりたいです」と言われたのですが、その要求が3行しか書いておらず、それでこっちが超概算見積もりで10人月で出した後に、予実を確認をしてみたら20人月かかったという例です。それに対して、何かすごい文句を言われるとかもあるのですが、基本的に「もうちょっと要求をちゃんとしてくれ」という話を... 続きを見る

どうして「ずれ」が発生するのかをまず考えることが重要です。
ブリリアントジャーク的な人がいるのか、そういう心情的な問題なのか、それともスキルがあまりにも違いすぎるとかですと、それをアサインする責任のところの問題にもなってくると思うので、こういった箇所はもうちょっと深掘りしないと原因がわからないと思いつつ、とはいえスクラムは仲良くなるイベントがたくさんあると思います。
続きを見る

ストーリーポイントも概念的な話なので、これはチームによるかもしれないですが、まず時間見積もりから逆に始めてみるというのも一回手かなと思っています。

ストーリーポインターだとフィボナッチ数列になり、やっぱり掴みづらくなるとは思うので、一回フィボナッチ数列「1、2、3、5、8」とかを時間として置き換えてしまって、「だいたいこの「5」というのは3日ぐらいだよね」とか「「8」というの... 続きを見る

やっぱり失うものに関しては時間とその時間にかけた労力・メンタルです。
これは、もういろんな現場で見ていてやっぱり長いというのが一番のストレスだったりとかしていますし、結局予実を管理していなかったりすると思うので、失うものは時間というところが大きいかなと思っています。

メリットのところは、意思決定の材料として使えるものが獲得できるというのがあります。
続きを見る

基本的に経営陣に対しては金額で出しています。

「この機能をつくるためには、5500万ぐらいかかります」みたいな形で、一応工数みたいなのを書きはしますが、だいたい人月と工数で変換して出すようにしています。

例を挙げると、「友達紹介キャンペーンをやりたいです」みたいなのがビジネスサイドに来たときに、まず企画を通すためにやっぱり工数点が必要だと思っていまして、... 続きを見る

私の例でいきますと、基本的にスクラムチームだけで完結する場合、それに関してWBSは特に引かないです。
見積もりに関しては、複数のプロダクトトチームが関わっているようなプロジェクトですと、工数見積もりが必要なので、スクラムチームではない、外でPMチームみたいなところで並列的にやっている状態です。
途中の修正は、スクラムチームの場合はリファインメントとか色々してはいますが基本的にそ... 続きを見る

Prosに関しては「基本的には時間が短くなります」というのがまず大事なメリットとしてはあるので、見積もっている、さっきのトレードオフみたいなところでいくと「費用対効果はいいよね」という風にはなっています。

Consについては、新しい人が来たときにその人のオンボーディングをする中で、やっぱりチームの文化の言語化、解釈は、結構な時間がかかるものだとは思っていまして、オンボーディン... 続きを見る

一人でやるなら技術合理性だけで良いと思いますが、組織で仕事するなら組織戦略を考えないといけないわけで、技術合理性と組織維持と両方考えないといけないのが普通だと思います。

この２つで悩む典型的な状況は以下のようなものではないでしょうか？

1. 学習コストを考えると短期的に古い技術が効率が良いが、長期的には新しい技術を使ったほうが良い
2. 現在の... 続きを見る

※本投稿は、2023年6月29日に開催されたイベント「KotlinとScala 活用者が語る技術選定のヒント（https://offers.connpass.com/event/287192/<... 続きを見る

※本投稿は、2023年6月29日に開催されたイベント「KotlinとScala 活用者が語る技術選定のヒント（https://offers.connpass.com/event/287192/<... 続きを見る

まず前提に、「課題に対して適切な技術である」事が必要だと思います。

その中でいくつかの選択肢がある場合に、判断が必要になるかと思います。

・強いエンジニアを採用してスゴイプロダクトをスピーディに展開したいのであれば、そのようなエンジニアが興味を持ちそうな技術を採用
・普通のエンジニアでを採用して枯れたプロダクトを長く運用していくような場合であれ... 続きを見る

個人的には、おっしゃるとおり「技術選定は開発者のモチベーションを高めるためではなく、顧客や自社のビジネス課題を解決するために最適なものを選ぶべき」で間違いないですし、頭の中では多くのエンジニアが理解できているかと思います。

一方で、「早く」「安全に」「高度に」を実現するために技術が日進月歩で進んでいることもまた事実ですので、結果的にビジネスで成功することを広く長い視野でみてい... 続きを見る

アジャイルコーチとしてさまざまな現場に入って活動しているものです。

- プロダクトディスカバリーに課題を感じているか

はい。ほとんどの現場がこの課題を感じているように思います。

- 感じている場合、どんな流れで開発プロセスを回しているか

プロダクト側の組織や人を育てるしかありませんが、これには時間がかかります。... 続きを見る

個人的に思うことです。

PRというのは外部に内部をアピールする場ですので、ちょっとしたことを発信していく文化はとてもいいと思います。

ただ、「GitHub Copilot導入しました！」とかは、僕にとっては「冷やし中華はじめました」ぐらいどうでもいいことなので、アピールと言うより、「時代に乗ってるアピールするチャラい企業文化なのかなぁ」と斜めに見てしまい... 続きを見る

正解はないとは思いますが、自分が大事にしているのは、広く、ある程度深く見ていくのが大事かなと思っています。技術だけに閉じずに、日本の個人情報の法律がこういう形になっているからコーポレートや法務と連携して決めていったりだとか、会社の予算を考えて技術を選定していくだとか、技術と関係ないところも含めて見れるのがアーキテクトの面白い部分だと感じています。
他方、最近は様々な技術でどんどん新しいも... 続きを見る

デイリーのmtgと定期的な振り返りの効果(というよりは行わない時の損失)はとても大きいなと感じています。コミュニケーションの機会がフレームとしてセットされてることで複数人での情報が埋まったり、課題や機会の定期的な言語化と棚卸し、上位目的の共有機会などは定期的なイベントとしてセットされないとなかなかワークしないなと。

前後では、明確にコミュニケーション量が増加したことで、チーム... 続きを見る