フルスタックエンジニアという言葉があり、クラウド、OS、アプリ、DB、ネットワークなどを含むシステム設計、構築、開発、テストなど全ての工程をほぼ1人でこなせるエンジニアというようなイメージの説明が書いてあります。

器用貧乏、激務になりやすい、とも言われているようですが、もちろん、会社やチーム、業種などで待遇や残業の量なども全く異なるかと思います。

以前はこうした人はスーパーSEとか呼ばれ、ちやほやされていたかというと、やはり火消しや新規案件獲得など激務になることが多かった気がします。

そして、ITアーキテクトというのはビジネス面が強調され、より全体を俯瞰して設計、方針作り、ガイドラインを作成でき、コミュニケーションに長けている、という感じの定義がされていたりするようです。

ここで、ITアーキテクトはフルスタックエンジニアのようなことをしないで成り立つのか？という疑問が出てきます。

昨今のシステム構築は手軽に始められるけど、使いこなしたり、標準的な使い方のまま、要件を満たす、安定稼働させる、仕様変更やバージョンアップをしやすく設計する、などのアンチパターンを使わない標準的な設計が難しくなってきた気がします。

同じシステム提案で、とあるITコンサル会社はゴリゴリのスクラッチ開発を提案し、別の大手Sierは汎用的なクラウド基盤での開発を提案していました。

前者のスクラッチ開発では要求仕様をいいようになるべくそのまま取り込みます、といい、後者のクラウド開発ではガイドラインを作って業務や連携を標準的な方法に整理していきましょう、といいました。

どちらがいいと思いますか？

企業の業務やビジネスの都合上、スクラッチになることがあります。大手企業では自分たちのビジネスフロー見直しをしたくない、連携機能を改変したら多額のコストが発生するため変更したくない、自分たちの思い通りに仕様を定義できるなどの理由で選ぶこともあります。

ただ、のちのちのことを考えると、多少の痛みを伴ってもクラウドの汎用基盤に移行する方がいいものが多くあったようにも思います。

この10年ほどで企業のシステムへの考え方はかなり変わった気がします。早い企業では2000年頃には汎用的な基盤への移行を本格的に検討していました。

話を戻します。

さて、こうした汎用的な基盤上で製品選定、設計を行う際、実際の実現性を無視して設計できるものでしょうか？

「誰かができると書いている」「仕様上できることになっている」ので選定した、というのはあまりに怖いです。個別には実現できていても、実は連携がうまくいかない、パフォーマンスがでない、安定性が悪い、そもそも連携に対応していないから連携機能を作るか、コンバータみたいなものを挟まないとつながらない、などなど確認としては不十分すぎます。

ですので、PoC（Proof of Cncept：概念検証）が必要と考えています。そこでいろいろな動作確認や解決すべき課題などを洗い出し、機能は正常に動作するか、実用に耐えるか、などを確認したりします。資料整理も含め、我社の得意分野でもあります。

我社ではこう考えます。

「ITアーキテクトである以上、確実な設計を行うためにフルスタックエンジニアの知識・スキルは必要」

我社はフルスタックエンジニア、ITアーキテクトの方、またはそれらを目指す方を募集しています。