エンジニアとはプログラミングする事が仕事ではありません。
プログラミングは作業の一つであり、実際に必要なのは、顧客の要求に対して、どう考え、どう設計し、どのように検証したかを、説明、保証することです。
プロジェクトのメンバーにはプログラミングだけできればオッケーというスキルの人が稀におられます。
自分が作ったところが、正しく作れていることをうまく説明できない人がいます。
具体的には、
デザインレビューやコードレビューで指摘された箇所に対して、指摘者が納得できる回答ができないような人です。
「仕様書Aの関数Bの処理内容が間違ってます」
と指摘しているのに
「関数Bとついでに関数C,Dも直しました」
などと勝手に指摘外の部分を手直ししたり、
「仕様書の関数Eとコードが一致してません」
と指摘しているのに
「関数ＥはFとGに分解したので合わせるとあっています」
とかなんだか強引な辻褄合わせをしたり、と。
他にも同じ指摘を何度もくらったり。。
まずはきちんと指摘箇所に対して回答せい！そして水平展開せい！(｀´）
これじゃまだ不具合が残存しているのではないかと疑いたくなります。
他には進捗報告なんかで説明の悪さが顕著に出ます。
リーダー「〇〇さん、今日の進捗はいかがですか？」
〇〇さん「うーん、仕様書を3ページぐらい書いて、あとどう書くか悩んでいるところがあります。知ってそうな人に相談したのだそのうち進むと思うのですが微妙です」
・・・┐(´д`)┌?
結局どうなんだ？よくわからん。。
進捗報告は計画に対してどうだったか、が欲しいのです。
大体は週単位でその週の目標が計画されているはずだから、この日どこまでできてないとまずい、とかわかるはず。
で、今日はどうだったか、今後の見通しはどうか、をリーダーは問うているのです。
そういう聞き方してくれればいいのに、、と言うかもしれませんが、進捗管理しているリーダーが曖昧な回答など欲しているはずもなく、なんとかそこは定量的に説明してもらいたいところです。
進捗報告に関してはまだツールで抑えれる部分もあるのでまだいいですけど。
先の記事で書いたredmineなんかで進捗した数値を担当者に入力してもらえれば把握できますね。
冒頭のように開発者は自身の担当部分について、きちんとインプット(顧客や上位仕様書の要求）通りに作ったことをアウトプット(仕様書やコード、試験成績書)を使って説明する責任があります。
最初から全部一貫して説明するのが難しくても、まずは指摘や質問には真摯に丁寧に答えるようにしていきましょう。それが信頼を得る第一歩であり、エンジニアの必要条件だと思います。
では。ご覧頂き有難うございました。
↓にほんブログ村ランキングに参加しています
コメント