【上流_2日目_3回目】システム設計1冊目
背景
今まで開発側にいることが多く、設計をバリバリやっていた訳ではないですが、初の要件定義をやることになったためと、今後社員ができた際にきちんと教育指導が行えるように成長することが求められています。
学習アウトプット
ソフトウェア設計モデル
- マイクロサービスアーキテクチャ・・・サービスを構成する各要素を「マイクロサービス」と呼ばれる独立した小さなコンポーネントとして実装するという手法
→近年主流とされているサービスアーキテクチャとのこと
会社による要因
外的要因にて設計した通りにシステムを構築できるとは限らないとのことでした。当然システム開発をする際に予算は決まっており、理想とする機能をそのまま入れれるということはないとのことでした。
開発できるエンジニアのレベルやスキルセットによって構築できるシステムの構成図も変わりますし、AWS, GCP, Azureなどによっても提供しているサービスも異なります。また運用できる資金によっても、もっと安価なサーバーを検討しないといけなかったりなどもあるとのことです。
プロジェクトマネージャーはまだやったことがないのですが、当然お客さんの要望や期日、そして費用で参画できるエンジニアだったりを検討していかなければならないと言った制約もありそうですね。
また今まで現場でも、どれくらいの開発工数で収まりそうな設計が求められていたりもし、あまりリッチに設計しすぎないというのも求められていたりもしました。つまり設計というのは、システム要件に満たした設計をすれば良いだけではなく、プロジェクトに参画しているメンバーのスキルセット、開発で確保できる期間などによっても、設計するシステムが変わってくると言えるのかもしれません。
ただ昔から言われていますが、案件があれば回るというわけではなく、エンジニアとして働く人の人手不足が言われていることから、プロジェクトを受注できたとしても、社内に開発ができるメンバー体制がいなければ、メンバーが揃えられずに案件がぽしゃってしまうこともあるのかもしれません。
そういったことからも、案件が受注できそうな状態からアサインできそうなメンバーを探していたりもされている方もいらっしゃったので、そういった裏事情があるのかもしれませんね。
システムアーキテクチャ設計
なぜその設計をしたのかが説明できないと、アーキテクチャ設計ができていないということでした。
信頼性と安全性
信頼性・・・通常の状態も含めて、システムが止まることなく適切に動くような状態を考慮する
安全性・・・ハッカーによるハッキングや誤操作などから、システムが不具合が起きずに安全に動くように考慮する
環境設計
こちらができると、自社でオンプレミスのようにクラウドなどを使わない場合は、ハードウェアやソフトウェアの発注ができる状態になるとのこと。
移行方式設計
移行するシステムがデカければデカいほどそれに対するコストもでかいとのこと。
過去にリプレイス等の案件に参画したことがありますが、既存で動いているものが問題なく動くことの担保であったり、影響調査、どのような言語からどのような言語にするのか等々考えることが多かった記憶です。
またかなり古い言語であったりした場合にシステムを置き換えませんか？などの提案をしている企業も多いと聞きます。また銀行系はかなり負債のある言語であるCOBOLを使っているところが多く、その後継者が中々見つかりづらいため、システムの負債がかなり大きいようにも見えます。
生成AIの普及によって、プログラムを記載するという障壁はかなり減り、「Azure OpenAI Service」などを使えば、企業の秘匿情報を守りながらコードを書いてもらうことも可能です。
ただコードも100%正しいコードであるという保証がないので、COBOLから何か言語に置き換えたとしても、かなり膨大なテストをしていく必要があるかもしれませんね。また金融機関が止まってしまうと、経済全体に与える影響も多いので、システム担保はかなり大変だと思われますね。
移行を行う際は、一回で切り替えたり、段階てきに切り替えたりなど、そういったことも検討していかないといけないとのこともありました。
Discussion