はじめに
ソフトウェアエンジニアに必要なスキルについて考えてみた。
ここで扱うのは、広義としての「ソフトウェアエンジニア」で、SE、プログラマを含むものとし、SIerではなく主に自社開発エンジニアを対象とします。また、バックグラウンドがソフトウェアではない人を前提とします。
なぜスキルを意識する必要があるのか
目の前のタスクを何となくこなしているだけだと、数年経って振り返ったとき、自分のスキルの低さに愕然とすることがある。そして、このレーダーチャートのように替えがきく人材となってしまう。
先をイメージして、必要なスキルを意識的に身につけることが重要である。
技術の数値化は永遠のテーマだが、例えば、それぞれの項目について「公の場に登壇したり、ネットに記事が投稿できるかどうか、そこでの質疑応答に対応できるのか」と考えると具体的にイメージしやすいかもしれない。
中堅になったときは、まんべんなくそれぞれのスキルが5～8になることを目指し、その先で、自分の得意分野を見出し、そこを10にするようなイメージが良さそう。
スキル
ここでは各スキルが足りていないとどういったことになるのかに着目して整理する。
論理的思考
- 論理的思考ができないと、まともな設計ができない
- 問題がおきても、ロジカルに攻めることができないので、時間がかかる または 解決できない
- 開発においてかなり致命的
プログラミング
- 一番怖いのは「動く ＝ プログラミングできた」と思い込んでしまうこと
- 読みにくいコード、拡張性の悪いコード、テストがまともにされていないコードは害悪
- 会社の開発サイクル効率を悪くしていることに気づかない
- 「他人が作ったコードを部分的に修正 ＝ 自分はプログラミングができる」と満足してしまう
- 他人のコードを読めるスキルはもちろん必要だが、無理やりコードをつぎ込んでの修正は害悪
- もちろん、俯瞰的に考え、適切な方法で修正を加える行為には意味がある
仕様（要求/外部設計）
- 思いつきでただ箇条書きしたものを仕様書としてしまう
- システムに応じて検討が必要な考慮項目が足りているのか一部フォーマット化を考えないと、失敗したときのフィードバックができない
- この工程で手を抜くため質の悪いものができてしまう
- アジャイルという言葉でとりあえずコーディングに走ってしまう
- それっぽいものができるが、致命的な抜けや無駄な手戻りが発生する
※ 私はウォーターフォール信奉者ではない
仕様（内部設計）
- プログラミングの項目と似ているが、機能追加、修正改善が難しい構造を作ってしまう
- 誰もよりつかないコードになる
- 会社の開発サイクル効率を悪くする
- 機能追加や仕様変更に対して工数がかかる と言うだけで、自分のデザインが悪かったという考えに及ばない
- 省略され、ないがしろにされる傾向にある
ドキュメント
- 読み手をイメージする想像力に欠け、自分本位な資料
- 議事録をとらない（とれない）
- どのような経緯でものごとが決定されたのか、またどのようなアクションが必要か がまとめられない人との会議は無駄
- 途中まで書きかけた資料でドヤ顔。文字数としては最後の10%が足りないだけかもしれないが、その10%を埋めるために必要な考慮にこそ意味があり、逆にその10%をやり切らなかった資料にスキルとしての価値はない
プレゼン/レビュー
- ドキュメントと同様に、聞き手の立場をイメージした構成/内容にできない
- 「プレゼンができない」≒「理解していない」
ドメイン
- ここでいうドメインとは、開発対象やそれに関連する専門分野の知識（対象物、IT系の開発環境、言語、ハードウェア、業界動向）に関すること
- 部分的には、日々仕事をこなす中で自然に身につくところがあり、それだけで満足してしまい深堀りできない
- 仕事の中では得られない、新しい技術などを自ら発掘できない
コミュニケーション
- 「コミュニケーション」 ≠ 「社交性」
- お客様からの要望聞き取りが正しくできない
- 単純にお客様の言葉だけを鵜呑みにするのではなく、その背景や理由を聞き取れないため、期待と異なるものを作ってしまう
- 関係者に的確な意図を伝えられないため非効率
テスト
- 根拠のないランダムテストしかできない
- 毎回おなじようなバグを作る
タスク管理（自己管理）
- なんとなく遅延しても気にしない
- 相談なしに遅れると「責任感がない」と判断されること に気づかない
新規開発
- そもそも、０から作るときに何に気をつけるべきかもわからない
- ０からはじめるやり方がわからない
- 普段アンテナ張っていないため技術のアイデアが出てこない