SEの『技術力の種類』と上げる方法
「何ができれば技術力あるって言えるのかな？」
「どうしたらできる人になれるんだろう？」
「技術力」っていろいろな意味を持つ言葉ですよね。
「彼は技術力があるんですよ！」と言った時に連想することは人それぞれです。
- プログラミング技術に長けている
- アーキテクチャ設計に長けている
- 性能のチューニングに長けている
- 要件から設計に落とし込む能力がある
- 仕事が速くて正確
ぱっと思い付くだけでも、これだけあります。
私自身はどうかというと、自分の技術力にはそれなりに自信を持っていますし、会社の人から「技術力あるね」と言われることもあります。
といっても初めから自信があったわけではないし、今だって特別優秀なわけでもありません。
自分の経験を振り返りながら「SEの技術力の種類と上げ方」を紹介します。
Contents
技術力の種類
SEの技術力は大きく分けて3つあります。
- 要求分析のスキル
- 設計のスキル
- 実装のスキル
1. 要求分析のスキル
顧客の要望を聞いて、解決策を提案するスキルです。
狭い意味での技術力は実装能力を連想しがちですが、要求分析も技術力の一つです。
要求のヒアリングと提案力
顧客がどんな課題を抱えていて、それをITによってどう解決するかを考えます。
そのためには顧客の話を理解し、適切な質問をすることで課題を正しく把握することが重要です。
話を聞いている内に、当初言っていたのと実際の課題が違っていたなんてことがよくあります。顧客自身が気づいていない課題もあるので、話を聞きながら、様々な角度の質問をして、課題を探っていきます。
「お客さんの言ってる通りに進めればいいだろう」とイエスマンなSEが多いですが、それだと開発が進んだ後で「やっぱり違ってた、仕様変更させてほしい」と言われることになりがちです。
イエスマンは楽なようで、最終的に苦労するので、必要なことはしっかりと意見したほうがよいでしょう。
モデリング、ドキュメンテーションして説明する力
ヒアリングして解決策を考えたら、それを図や文章にして説明します。
「この課題はこう解決します。よろしいですね？」
と確認します。これをきちんとやっておかないと、後で「あれも足りない、これも足りない。これもやってくれと言ったはずだ。」のようなもめ事が生まれます。
- UML
- OOAD（オブジェクト指向分析設計）
を学ぶと、要求を図にして表現する方法が学べます。
OOADって、すごく高度で難しいものであるかのような喧伝がされていましたが、実際やってみるとUMLは図の表記法であり、OOADはその図を作る手順なだけです。特別構えることなく気軽に学べばいいと思います。
「こういう手順で図を書いていけばいいのね！」ってくらい分かれば十分です。重要なのはそれらの手法を、実際の仕事で活用することです。
それと必ずしもUMLを使わなければいけないわけでもありません。説明したい内容が表現できていればいいんです。ExcelやPower Pointの図形で十分事足りることも多々あります。
2. 設計のスキル
大きく分けて3つあります。
1) 仕様の設計
「商品検索画面で、このボタンを押したら、DBから商品名で検索して、特売フラグが1だったら価格を10%引きで表示する。」
のように、
- 画面
- DB
- 処理ロジック
を決めます。
要件定義した内容をインプットにして、要件が満たされるように機能を設計します。一般的なSEの設計力ってこの「仕様の設計」を指している場合が多いかと思います。
設計をするには、それを実現する技術の裏付けが必要です。それらがない人が設計をするとトンチンカンな設計になってしまいます。
WebなのにPCソフトみたいなUI設計をしているとんでもない設計書を見たことがあります。2000年代前半、業務システムをWeb化する仕事ではそういった事例がよくありました。
ですから、「仕様の設計」も技術力なんです。
2) システムアーキテクチャ設計
いわゆるインフラの設計です。
「サーバは2台構成で、DBはOracleを使ってWebサーバはApache、APサーバはTomcatを使う」みたいな構成を決めます。
専任のインフラエンジニアがいる場合は、その人に必要な機能要件や性能要件を伝えれば適切なハードウェア・OS・ミドルウェアを選定してくれます。
3) アプリケーションアーキテクチャ設計
「フレームワークに何を使って、MVCアーキテクチャで、Model部分はActive Recordパターンでモジュール分割する」みたいな開発のルールを規定します。
サンプルコードやコーディング規約なども必要に応じて作ります。
私が以前会社で技術力があると評判になったのは、このようなアプリケーションアーキテクチャ設計をしていた時でした。
技術力と言われて一番イメージしやすい分野かもしれません。
フレームワークを覚えるコツは、実際に使ってみることです。ちょっとしたものでいいので、そのフレームワークを使って何か作ってみると自然に理解できます。それができたら、プロジェクトに合わせて、どう使えばいいかを考えて方針を決めてチームに展開すればOKです。
3. 実装のスキル
設計したものをソースコードに落とし込むスキルです。
メインフレーム・汎用機と呼ばれる大型コンピュータが主流であった時代には、プログラムのソースコードと一対一で対応するくらい細かい設計書が書かれていました。そのため、コーディングは日本語をプログラミング言語に翻訳するだけの単純作業なのでかんたんと考えられていました。
そのせいか業務システム開発の分野では未だにプログラミングスキルを軽視する風潮がありますが、現代は「コーディングも設計の一部だ」と考えられています。
ソフトウェア開発は、よく建築と比較されています。
- お客さんに「どんな家に住みたいか」ヒアリングするのが要件分析
- 建築士が建物の図面を書いたり、模型を作って検証するのが設計
- 大工さんがトントンカンカンと家を建てる作業が実装
と考えた場合、ソフトウェア開発の実装はビルドです。大工さんがトントンカンカンと家を建てる作業に当たるのはビルドボタンを押すことなんです。コーディングは実装作業ではなく設計作業なのです。
Javaで言ったらコンパイルして、サーバにデプロイする行為が実装であり、コーディングはビルド（実装）するための設計図であるソースコードを書いている設計行為なのです。
コーディングを設計行為として取り組むと、「きれいに整理されたコード(設計書)を書こう」という気持ちになれるので、コードがきれいになります。
会社の規模と社員の技術力は比例しない
私はこれまでに三度転職し
→ 零細ベンダー(社員80人）
→ 東証一部上場独立系SIer（社員5000人）
→ 大手流通業グループIT子会社（グループ社員50000人)
→ 以降フリーランス
→ ECサイト開発運営ベンチャー（社員10人）
→ 大手ブログサービス運営企業(3500人)
→ 大手コンシューマゲームソフト開発企業スマホ部門子会社（社員600名）
と、業種も規模も様々な会社で仕事をしてきました。
新卒で入った会社が零細ベンダーだったので、一度目の転職で大手SIerに入った時には、「大手だから、さぞやすごい技術者がいっぱいいるんだろうな！」と期待したのですが、零細ベンダーと変わりませんでした。
できる人もいれば、ダメな人もいる、それは大きな会社でも小さな会社でも一緒だったんです。
技術力と転職の関係
「やまろうさんは技術力あるから、いくらでも転職できそうですよね」とよく言われますが、たしかにいくらでも転職できます。
ですが、これって因果関係が逆なんです。
「技術力があるから転職できるんじゃなくて、転職したから、技術力がついたんです！」
もちろん転職しなくたって技術力はつきますが、転職すると、以前の会社では問われていなかったスキルを求められたり、人に頼っていた部分を自分がやることになったりと変化が生まれます。変化に対応すると、能力はぐんと高まります。
ですから、SEの仕事においても、因果関係を逆にして、
「転職して技術力を上げる！」
をぜひやってみてください。
転職する前の一年より、転職後の一年の方が技術力がぐんと上がることが実感できるはずです！