思いやり。

0
294

最近の案件のお話。

今進めている案件で、『Vue.js(JavaScript)』と『Laravel(PHP)』の両方に関わるという、
ちょっと変則的な関わり方をしています。

私の他にも、デザイナー・フロントエンドエンジニア・プログラマー(各1名)が参加しており、
フロントエンドエンジニア(Vue.js)
プログラマー(Laravel(PHP))
という立ち位置です。

で、問題になるのが
プログラマからフロントエンドエンジニアに渡すデータの構造

これが結構ややこしいというか、ネックになっている印象が強いです。

Laravel側であれば、
1.データの取得方法(SQL)を工夫する。
2.取得したデータ(Collection)の構造を変更する。
ようなイメージですし、フロントエンド側は、
1.computedプロパティで調整する。
2.filterメソッドでデータに制約をかける。
かと思います。

今回の案件の場合、私の担当範囲に限っては、データの受け渡しは自分自身なので大したことはないのですが、基本的なチーム構成を考えると、この部分は別々の担当者が存在することになります。基本的にはフロント側に合わせて調整する形を今回は採用していますが、データベースの構造上そもそも調整が難しかったりすると…大惨事です(最悪、データベースの構造を変更する可能性すらありうるかも)。

ここでのやりとりが工数に響いてくるのがよくわかったので、互いにコミュニケーションをとることはもちろんですが、プログラマーもデザインデータを確認し、『ここのDOM要素はどういった形で構築されるかなぁ』と考えたり、フロントエンド側もテーブル定義書などを見て、『ここのデータ構造だと、出てくるデータはこういう形かなぁ』と考えたり、ある程度相手の土俵を考慮した上で作業を進めつつ、コミュニケーションをとる必要がありそうです。

チーム全体のボトルネックがどこにあるのかを見極めつつ、少しでもボトルネックが解消されるようにしていきたいなぁと思う、今日この頃です。