ぷろぐら×でざいん

エンジニアは非エンジニアの気持ちがわからない(2)

エンジニアは非エンジニアの気持ちがわからない(2)

エンジニアは非エンジニアの気持ちがわからない(2)

これ作れますか?これ可能ですか?

たぬき: 作れますよー、可能ですよー。(技術的にはね)

エンジニアのポジティブな返答、特に「作れる」、「できる」、「可能」という言葉をそのまま受け入れてはダメなことが多々あります。それらは全て技術的には実現性があるという意味だとからです。技術的実現性とは現状のデータベース構造やフレームワーク、そして個人技術力・知識を持ってすれば問題なくできるということです。寧ろ、今の世の中、とんでも要求(ドラえもんの道具)以外は作ることができるはずです。

しかし、エンジニアが「作れる」、「できる」、「可能」という言葉を発する際に蔑ろにされている要素があります。それは時間です。エンジニアは自分自身の持っている工数を計算した上で「できる」とは発言していないことが大半です。なので、「こういうことしたいんですよねー」に対する返答が「できる」でも、「じゃあ、いつまでかかりそうですかー」の返答に対しては大抵「プロダクトマネージャーにあげておいて」または「リクエストを上げておいて」とコミットメントまで繋がらないです。

よって、エンジニアに何か新しい機能を作って欲しい時は具体的なイメージ(納期やワイヤーフレーム)などを持っていくと比較的スムーズに明確なマイルストーンまで落とし込むことができと思います。


メモ機能が欲しいんですけど

たぬき: 何で必要なのでしょうか?(またかよ…)

メモ機能をお願いされることが結構多いのですが、この要求ほど嫌なものは中々ないです。理由は幾つかありますが、まず要件に落とし込むと明らかに考えがまとまっていないことがわかります。例えば、「どこのページのどこで追加し、どこに表示しますか。ラベルの名前、テキストエリアの大きさ、文字数はどうしますか。編集は行い、削除機能は必要ですか?」もちろん、作る前など可能な限り要件を聞き、作るのですが、どうしてもズレが生じてしますことや、そのメモを様々なページに表示してくれというような追加要求が出ることも多い気がします。

また、メモという抽象的なフィールドがあることで汎用的過ぎるために運営側、ユーザー側が明確なルールを持って利用しない限り、情報が混沌としてしまいます。そして、メモに入力される情報の統一性が見えてきた段階で、新たなメモの依頼が来きます。

この問題は無駄な工数を割くという点よりも、寧ろ開発負債が増えることが問題だと私は思います。乱雑するメモフィールドは開発側の負担も大きくなりますし、何のフィールドが何に使われているかわからないと更に無駄なフィールドが追加されるというスパイラルに陥り易いからです。

このような現象はメモだけに言えたことではないとは思いますが、やはり運営側・ユーザー側が何をその機能にて解決したいのかのヒアリングを事前にしっかりと行うことは重要だと思います。
その問題を解決する際に「メモ」が必要という場合もありますが、大抵の場合は特定の情報を入れるフィールドや追加機能になります。または、システムの機能追加・機能改善よりも運営の方法やユーザードキュメントが少なく、本来の機能だけでカバーできることもあります。


合わせて読みたい
エンジニアは非エンジニアの気持ちがわからない(1)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください