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