「エンジニアはこうなるな！」〜私、やぎしんが思う、エンジニアアンチパターン〜

※前置き：プログラマなので、開発フェーズで仕事するのが主です。運用はあんまり経験値ないです・・・※

社会人として現場で仕事をするようになってから2年とちょっと経ちました。

いろいろなことを学び、その中でも大事だと感じたことを、新人SE・プログラマにぜひ伝えておきたいなと思ったのでしたためてみます。

それは、

”＜システムが実際の業務でどのように使用されるのか＞を常に考えること”

です。

ここで言いたいのは、実装している画面や機能が

・具体的にどのように利用されるのか

・どのようにデータを作成・更新・削除していくのか

・関連するデータはどのデータに影響を及ぼすのか

を理解することが重要であり、それをチームメンバーやユーザーから聞き出すことはもっと重要ですよ！ってこと。

「そんなこと当たり前だろ・・・・」

でも実際に仕事をしているとそう簡単にはいかなかったり、実践できている現場って少ないのかなって感じています。だからこそ、これが実践できるエンジニアってこれからも重宝されていくのでは？って思うのです。

業務知識を考察・調査できない要因として例えば、

• プロジェクト特有の言葉が使われていると、理解しようとしない人は”どこ修正したらいいか”を聞いて、そのまま実装に入ってしまう。
• そもそも業務システムが複雑で、データがどのように扱われるのか理解するのが難しいときがある・・・（スケジュールがカツカツだと尚更）。
• 開発者個人の考えで開発が進み、実際にそのシステムを使用するエンドユーザーが使いづらい仕様になってしまっている。

一番最後の、

”開発者個人の考えで・・・”

は結構現場で見てきましたね・・・・。

「これ、実装できないっすよー」

「どうやって実装するのかわからない」

「そんなの聞いてないよ！初耳！」

って具合です。

でも実際自分が作成したものをテストしているときに、

「この画面の操作の仕方って本当に操作しやすい？」

「このデータ動かせちゃうけど、結局反映されないんだ・・・じゃ画面上さわれなくすればよくない？」

「画面の更新のタイミング、これで使いづらくないか？」

とかの疑問（※１）を、チームで共有したり、ユーザーに質問できるかどうかは非常に大事だと思ってます。

そこで、私が思う、

エンジニアアンチパターン

ってのを表現してみました！笑

① 設計のディレクション時に言われなかったので実装しませんでした奴〜（指示待ち奴）

② 「なるはやで」「いい具合に」「なんとかして」って言われた時にちゃんとその内容を聞き出せない奴〜（）

③ 「〇〇だと思った・・・」奴〜（結局設計や実装方針を理解できてなくて出戻り奴）

④ 説明できない奴〜（内容を理解できてないけど、実装したら動いた！でドヤ奴）

⑤ あいさつできない奴〜（チームと馴染もうとしない奴の典型的な例）

※完全に独断と偏見ですし、ちょっと言葉が悪かったら申し訳ありません・・・その時はコメントでご指摘ください※

総じて、マジで、

コミュニケーションをとることって大事なんだぜ！！！！

ってことなんですよ。

自分もそれができているのかは他の人にしか見えてなかったりするので、できているかどうかを評価してもらう！ってことを個人的に実践していきたいなーと思っています。

最後に・・・

大変失礼いたしました。

やぎしん

※１：私が疑問に思ったことを「そもそも疑問に思わなかった」って僕の後輩が言ってました。疑問に思わないとそもそも仕事ができないって感じるところに疑問を感じれなかったことが悪い、ってなると指導の方法がわからないんですよねー。

ここが今困っていることの一つです。