1.はじめに
この記事はラクスパートナーズ Advent Calendar 2024の11日目の記事です。
2.経験した業務内容について
社内、社内外関係者が扱うBIツールの開発を行なってます。DWHの設計開発も行なってます。
マート数、ダッシュボードが100を超える業務に携わっており、ベースとなるダッシュボードは同じではあるものの、マートによってはBIツールの仕様によって、若干特殊な処理をしなくてはいけないものあったりするため
アジャイル開発で一つずつ回しております
一つのマートごとに、
マートの設計書作成
フロー構築
ダッシュボード開発
この3工程で行っております
マートを作成する上での使用する各テーブルのデータ連携（この元となるテーブルもかなりおおい）もあるので
実際の工程でいうともっとかなり工数があります。
3.移行プロジェクトで気をつけること
本題に入ります。
移行プロジェクトは文字通り、いま動いているシステムを移行して別のシステムに移行することを指します。
そのため、現在動いているシステムの設計書が必要です
3.1 元の設計書も人間が作成したもの
間違いは当然あります。資料のバージョンアップが間に合わず、現在動いているシステムと異なっていたりします。まずは前提として認識しておくことの重要な一つです。
3.2 信じるな疑え
そのため、むやみやたらに資料を鵜呑みにせず
疑う姿勢をもって業務を取り組むことが大切です。
そのまま設計書を信じて作成すると、帰って修正が増え、運用の段階で負荷になったり、開発の手戻りが増えてしまいます。
3.3 既存の製品と移行先の製品の差分をしっかりと理解する
現行のシステム設計書はあくまでも、今の仕様の製品で動作するものであって
必ずしも新たしい製品で動作するとは限りません。
。。とは言いつつも、数百のマートがあるのでどうしても見落としは出てきます。
PoCの段階で、テストであるマートで再現できると言っても、
数百のマートが全て同じ仕様でできないからです。（今思えばできるわけないが、こんなにも違うかと思いました。）
3.4 「これでいいのか？」は８割打者
3.2で伝えたことの延長線上ではあるのですが、「これってこれでいいのかな」
と思ったらすぐに伝えるべきです。
なかなか、仕様通りに作って欲しいと言われてしまうとどうしても思考が止まってしまって
発言しにくいことが起きるかもしれません。
ですが、それがかえって運用負荷・開発の手戻りとなるので、自信を持って伝えましょう
3.5 オンスケ意識を絶対持つこと
アジャイル開発の中で、どうしてもイレギュラーな仕様に目の当たりにすることがあるかもしれません。
この開発は本来一週間を予定していたけれども、実際は二週間かかりそうとなってしまって、
後続の作業者が作業できなくなってしまう事象が発生してしまうので、
別ユニットの作業が早く終わりそうなら、その作業も並行して終わらせて、後続の人のアイドル時間を減らす意識が大事です。
4.PL・現場リーダーが困らないために
大規模プロジェクトで、どうしても発生するかもしれないのがコミュニケーションの伝達不足かなと思います。
そのために、朝会などで進捗を報告する場面があるかと思いますが
場合によっては、PLや現場リーダーが別プロジェクトにも参画していて、発言が伝わりきれなかったりすることもあります。
また、SlackやTeamsなどでメンションしたけど忙しすぎて見落としているかもしれないこともあるかと思います。
そのために、ことの重要性をしっかりと強調しながら伝える力が大事かなと思います。
＝＝＝＝
A氏「この間連絡したけど、返信が来てないな。。 でも見ているだろうし、忙しいから後で見るだろう」
→夕会
A氏「これメンションしたと思いますが、どうですか？」
リーダー「あ、連絡してくれてたのか。。ごめん見落としてた」
＝＝＝＝
結果的に進捗が遅れるなんて嫌ですよね。
伝える力って本当に難しいですが、これが結構大事だったりするので、意識しましょう（自戒）
5.まとめ
私が行っていることが、エンジニアの中ではかなりニッチな部分な関係で
今回は、できるだけ汎用性が高くお伝えしていきました。
日頃意識していることは、PM／PLが何を自分たちに求めているかを汲み取りながら仕事をしています。
これが結果としてスムーズに業務が進めることができる近道かなとも感じています。
これからも、求められるような人材になっていきたいなと思ってます。