システム構築を請け負う時に必要なスキルを考えてみました。
頭の中の整理するつもりで作ってみたけど、漏れはあるかもしれないし、書き方(カテゴライズ？)の工夫ももっと必要と思う。
何故こういうものを作ろうと思ったかというと、後進を育成する際、教えることがありすぎて何から教えていいものか困っている。
加えて、この業界は技術の進展が速すぎるため、育成要綱の固定化がしづらいということもある。
後輩にはこれを見てもらって、自分に何が足りていないか、どこまで理解できているかなど自分を評価するのに役立ててもらえればと思う。
スキルロードマップ
以下、要約を記載。
なお、題材はソリューション(問題解決)開発ではあるが、自社開発であっても別の何かであってもステークホルダを挿げ替えるだけで大きく変わりはありません。
要件定義
要件定義とは一言で言うと、お客様とシステム開発のゴールを定めることと言ってもよいと思う。ただ、鵜呑みにならず、ネットや書籍、経験を通じて自分なりにも考えてみてほしいと思う。
システムを開発するには、まずお客様の業務を正確に理解することが必要。水産加工会社の物流システムを作成するのに、水産加工会社の物流について理解できなければ話が何も進まない。ただ、初めての分野で要件定義開始時点では全くの無知ということもありうる。そういう時は、事前の情報収集やお客様との会話の中で瞬時に、論理的に理解を深めていく必要がある。十分に難しいことだとは思うが、それを淡々とこなすのがプロフェッショナルとしての矜持だ。
お客様の事業等が大きく変革する場合、組織や仕組みも合わせて変革する必要がある。この変わるときに顕在化する問題や課題は言わずもがな正確に把握、対処する必要もあるが、漏らしてはならない。
組織・仕組みの差異に顕在化するであろう問題・課題の他、お客様でさえ気づかない潜在した問題・課題も十分に存在しうる。対象が大きければ大きいほど、潜在する可能性もあがる。やってみたものの、見落としがあったでは済まされない問題もある。システム構想を明確にし、お客様とコミュニケーションをとり、変革イメージをしっかりシミュレーションし、問題・課題を潜在化させないことが大切。
アーキテクチャ関連
弊社の中でアーキテクチャという言葉を使うのは多分自分しかいません(笑)
アーキテクチャとは一言でいうと「構造・構成」です。
システムをどのようにデザインするか（見た目や機能も含め）というのは設計の話。
システムをどのような技術で構成するかということですね。また、このような構成を考える人をアーキテクトと言ったりします。
お客様の環境の制約もありますが、サーバ要件を考えたり、開発メンバーを踏まえた開発言語の選定、効率化・保守効率の高いアプリケーション構成(フレームワーク・サードパーティライブラリ）、プログラムの作成方針や管理方針などを検討します。
インフラ関連や運用設計にも近い部分もあり、サーバの負荷分散・冗長化、耐障害性や障害時の迅速なシステム復旧などもこの分野に含まれるでしょう。
知識と経験がものをいう分野なので若いうちに果敢にチャレンジすることをお勧めする。
勉強の仕方はこれと言ってなく、仕事に必要な技術・知識をとことん掘り下げていく他ないかな。
一通りできれば飯には困らない分野です。もちろん、技術は常に進展を繰り返していくのでアップデートは必要ですが。
運用設計
これはちょっと定義が曖昧なのですが、システムを正常稼動させるための設計です。
例えば、人を介さずに行うジョブプログラムの実行スケジュール設計だとか、
システムオートメーションをガチガチに固められない場合の人による運用設計だとか、
サーバの定期再起動、サーバ証明書更新(方法、時期)、問題・障害が発生した場合の初動、想定対策等を検討、決定します。
システムは作って終わりではないので、稼動しているイメージを考えて構築することも大事ですが、いくつもの「もしも」を考えて構築しなければなりません。
インフラ関連
(内容的にはアーキテクチャより)
お客様の環境、ホスティングするサーバに左右されるため具体的には書けないのですが、
ネットワークだとお客様環境のサーバは大体サーバ専用のIPセグメントにいてアプリケーション通信に必要なパケットしか通さないFW(FireWall)が設定されているのが常識です。
ここにDMZが介在する場合もあれば、お客様が用意したBIG-IPがあるかもしれない。
ハードウェアの分野は最近は仮想化がもの凄い勢いで進んでおり、運用面でも作業することがほぼなくなった。
が、仮想化技術やその運用(例えばESX-iの)については、概要だけでも知っておくべきだと思う。
(お客様に相談された場合に話が通じないのは論外)
セキュリティ・認証要件は、ほとんどのお客様はActiveDirectoryかOpenLDAPによる認証を導入されており、当然のようにLDAP認証、もしくはシングルサインオンを求められる。
他システムとの連携もあり、お客様により本当に多種多用。経験があるのは、Hulft、DBリンク接続、MQ、SOAP、他API etc
システム設計
要件定義で決まったことを実現するための設計を行うターンです。自分的重要なポイントは以下の２つだと思っている。
- UI/UX設計
UI/UXはお客様の業務効率に大きな影響を与えます。例えば、１操作あたりの手間を１秒改善できたとしたら
一日100操作で100秒、年間200日と過程したら2万秒(約5時間半)、ユーザが100人いたら550時間、人換算で3人月超のコストダウンが見込めます。
具体的にはレイアウト・操作性、入力チェック、制限なんかもUI/UX設計に含まれると思います。 - モデリング
システムエンジニアはここが腕の見せどころではないでしょうか。
ユーザと業務の相関関係ならユースケース図、流れならシーケンス図やワークフロー、状態ならステートマシン図など、
あらゆる視点から業務分析を行い、可視化するスキルが必要。
また、データベース設計についてもデータ項目の正規化だけでなく、パフォーマンスを考慮した設計が必要(オプティマイザや実行コストの知識が必要)
開発工程
実際にプログラミングからその検証までを行うフェーズ。
設計書に従ってプログラミングするのですが、実際はそうでもない。
プログラムには、そのプログラム独自のシンタックスがあります。
そして、我々日本人が設計書に記載するのは「日本語」です。
実際の経験談ですが、「そのままプログラムになるような詳細設計書を書く」という規定のプロジェクトがありました。
はい。頑張って繰返しや条件分岐を日本語で書きましたよ。結果、どうなったか。「日本語でプログラムを書くもんじゃない」とパソコンをハンマーで破壊したくなりました。
日本語は表現の幅が広いのでいかにようにも取れる場合がたくさんあり、前後を読んだり、行間を読んだり、書いた人に確認したりですね(笑)
結局のところ、煩わしさ以外何もありませんでしたと。
また、プログラミングには色々なアプローチがあり、例を出すのが億劫なほど、日本語の表現に困るものが多いです。
クラス設計を書いたこともありました。人間が作るものは完璧ではないので、リファクタリングや変更やらで色んなところが変わっていきます。
(最終的にはメンテナンスされなくなりました。クラス設計はプログラムから自動生成するのが正解)
設計でガチガチに固めても良いことはないし、どうしたらいいかわからないジレンマ。
理想は「プログラマはシステム設計をもとに忖度できる」です。
忖度するために、どういったことが必要かというと(やっと本題)
- 規則、原則に学ぶ
図中にもありますが、〇〇の規則、〇〇の原則など、プログラミングするにあたり、禁止している、もしくは推奨している事項があります。
これらは過去、棘の道を歩んできた先人たちが残した格言のようなものです。 - プログラミング言語について造詣を深める
GC(ガベージコレクタ)について調べてみる
Listの種類によって挿入や参照速度違うとか
バージョン間の差異(新しい文法、非推奨になった文法などをチェックしているか)
その言語のパラダイム(生まれた経緯、これまでの歴史)
記法や関数の把握 - フレームワーク、ライブラリを使う、読む
フレームワークはいろんなものを触ってみるとよい。また、コアコードを読んで仕組みを知るとスキルが上がる。ライブラリも同様 - オブジェクト指向やデザインパターンを学ぶ
そうするのが普通だと世間では言われているが、自分の脳味噌を整理しながらプログラミングするために必要なこと。 - 相互レビューして知見を共有する
いくら知識や技術に秀でたプログラマでも、人との差異は生まれるもの。レビューし、決定をフィードバックする。
プログラマの知識ベースとして正しいものがあれば、おおよそおかしな方向には進まないだろう理論。
逆にここに書いたものを意識していないプログラマは、どういった知識ベースを元にプログラミングしているのだろうか。
テストに関しては、基本情報技術者試験に記載の知識レベルで出来てる必要がある。
わからないやつは出直してこい。
将来的にはTDD(テスト駆動開発)やCI(継続的インテグレーション)も取り入れるべきと考えている。
基本・応用情報技術者試験(おまけ)
もの知らないなら勉強・取得した方がいい。
システム開発上、発生しうる課題に取り組む際に、言葉・概要を知る知らないでは大きく対応が変わってくる。
(経験談では新卒の時、概要だけなんとなくわかってただけでなんとか一生懸命話についていけた。微塵も知らなければ完全に地蔵状態だったと思う)
10年ぐらい前、とある会社のマネージャが「基本情報技術者試験は自動車でいうところの運転免許のようなものだ。持ってないなら運転してはいけない」
と言っていて、内心そんなことねぇよと思いながらも、普通に仕事してたら取れる資格だから「そっすねー」とか合わせてたのを思いだした。
どこの企業も資格取得を推奨しているし、企業にも個人にも十分なメリットがある。
ただ、ビジネスは結果が重要なので、誰に文句言われることもなく業績を上げている人間なら別に不要かな とも、、、
