アソビュー！Advent Calendar 2023 - 5日目
こんにちは、エンジニアの森です。
本日は実装技術以外の面でもエンジニアとしてプロジェクトに貢献出来るということをお伝え致したく、技術的な話を少し脇に置き、広義のエンジニアをやっているとハード/ソフト関係なく直面する不具合と現実的にどう対処しているかを共有します。
0か1かでは表現できない現実
「不具合とは何か」について考えた際に思い浮かぶのは
「仕様を満たしていない、ロジックが誤っている」など、誰が見ても誤りであると判断できるようなケースです。
言うなれば、0か1かで表現できるような内容と言えます。
しかし現実には、
「仕様を満たしているしロジックも合っているが、よくわからないし思っていたのと違う」
という理由で不具合として報告が上がることがあります。
認識の相違から起きる不具合をどう考えていくか
よくわからないし思っていたのと違う
上記に関しては 事前のコミュニケーション不足 の一言で片付けられてしまうことが多いですが、
じゃあコミュニケーションを十分に取っていれば問題なくいくかというと、
どれだけ注意をしていても不具合の発生を完全に防ぐことはできません。
- 仕様を考えた人自体が正解を持っていない
- そもそも仕様の根拠となる要求が実際には存在していない
等そもそもシステム化するべきでは無い段階なのに開発を進めてしまっていることがあるからです。
エンジニアがコントロールできないところでプロジェクトの方針が決まってしまうこともあるため、
そういった時にエンジニアとしてどういった行動が取れるかがプロジェクトの成否に関わってくると考えます。
- 〜のような機能が欲しい
エンジニアとしてはふわっとした要件が来た際に以下の様な観点で確認を取ると完成形が見えやすくなり、認識の齟齬を事前に防げると考えます。
言語化し定義する
〜のようなとはAができてBの処理を行なってCのデータを記録として残すということですか？
A,B,Cといった機能を実現する具体的な要件を出し、実際にどのように機能が実現されるかを確認する。
今回この機能が必要になったのはAという理由からですか？
必要になった背景を知り、既にある機能で実現できないか、機能を実装した場合に要件は満たされるのかを確認する。
じゃあアソビューではどうなの？
アソビューが大切にしていること（Value）の中に「For you（すべては顧客のために）」というキーワードがあります。
開発組織のメンバーも普段の業務の中でこの考えを大切にしており、チーム全体でのタスク内容確認や機能がどういった価値を提供できるかの認識合わせ等を行っているため、考慮漏れや認識の齟齬が起きにくくなっています。
私が所属するチームでの具体的な例を一つ挙げると新規機能を実装する際には設計をConfluence(企業内wiki)で資料にまとめ、チーム内レビューを実装着手前に実施し認識齟齬や考慮漏れが無いか等を全員で確認する場を設けるなどを行なっています。
終わりに
現在アソビューでは一緒に働いてくれる仲間を募集しております!
今回のブログを見て頂き興味を持ってくださった方はカジュアル面談も実施していますので
お気軽にエントリーしていただければと思います!
また私は現在フルリモートで働いておりますがそういった働き方も出来る会社なので
フルリモート勤務での働き方を考えている方もぜひどうぞ。
