はじめに

テクノロジー＆イノベーション本部のエンジニア部隊では次に示すような様々な仕事を行なっており、これまでに公開した記事でも仕事内容をご紹介させていただきました。

今回は、事業部門と協業して行う開発（以下、「協業開発」と表現します）についてご紹介します。

協業開発とは

テクノロジー＆イノベーション本部は、その名の通りTISの本部組織として位置づけられています。

またエンジニアリングに特化した集団であるということが組織の特徴としてあげられます。

ここで説明する協業開発とは、事業部門が担うお客様向け開発プロジェクトや自社サービス開発に参画することを指し、協業開発の目的は以下2点にあります。

  • 開発プロジェクトにおける技術面のリード役（☛プロジェクトに対する貢献）
  • 開発プロジェクトで得たノウハウのフィードバック（☛自社の開発競争力の向上）

全社横断的に開発プロジェクトへ参画するため、プロジェクトの内容も多岐にわたります。

わたしの拠点である大阪チームの近年の開発事例を以下に記載します。

顧客業種 プロジェクト概要 プロジェクト規模※ 協業内容
金融 クレジットカード決済基幹システムの更改 大 アプリケーションアーキテクトとして要件定義からリリースまで参画。
電気・ガス 工事管理システムの更改 中 アプリケーションアーキテクトとして設計からシステムテストまで参画。
金融 プリペイドカードプロセッシングサービスのエンハンス開発 小 構成管理プロセス見直しのため、現状整理から構成管理システム導入まで実施。
金融 同上 小 高難易度アプリケーション機能の担当として設計から結合テストまで参画（技術要素：認証基盤、暗号化）

※プロジェクト規模については便宜上、プロジェクト参加人数（大:数百名、中:数十名、小:数名）で表現しています。

いずれも弊社の開発フレームワークであるNablarchを利用した開発プロジェクトでした。

Nablarchは冒頭でも紹介した「自社の開発競争力を向上させるための施策」の1つです。テクノロジー＆イノベーション本部で開発しており、協業開発の仕事としてもNablarchを利用した開発プロジェクトへの参画頻度は多いです。

アーキテクトの仕事とは

協業開発において、我々はアーキテクトという役割を担うことが多いです。

我々が担当しているアーキテクト業務は、IPAがITSS（ITスキル標準）にて定義している「ITアーキテクト（アプリケーションアーキテクチャ）」の領域が主です。

開発フェーズの中では、具体的に以下のような業務を担当します。

  • システムに対するグランドデザインの検討
  • システムアーキテクチャの設計
  • アプリケーション実行基盤の構築
  • 開発プロセスの策定
  • 技術課題の解決

※アーキテクトの仕事については「＠IT|あらためて見直す、ITアーキテクトの役割」をぜひご覧ください。TISのアーキテクトが解説している記事であり、より具体的に仕事の内容をイメージできます。

ただし昨今は案件の中で扱う技術・プロセスは多様化しています。クラウド環境・コンテナ化への対応、またアジャイル／スクラム開発やDevOpsへの取り組みなど、アプリケーションレイヤのアーキテクチャスキルに留まらず幅広い知識が求められる仕事です。

仕事の進め方

プロジェクト参画までの流れ

事業部門から協業支援依頼という形で相談を受けるところから始まります。

企画・提案段階から参画することもあれば、開発プロジェクトの立ち上げから参画することもありますし、開発プロジェクト途上（設計工程、製造工程）から参画することもあります。

事業部門が我々に期待する役割や開発プロジェクトの特性（工期、開発手法、利用技術など様々）をヒアリングし、協業体制を検討していきます。

双方の合意がとれたら開発プロジェクトへの参画が決定します。

プロジェクトメンバーとして

プロジェクトに参画したらプロジェクトの目標を達成すべく、社内外の関係者と日々連携して業務にあたります。

プロジェクトマネージャーやプロジェクトリーダーと作業計画、進捗、課題などを共有し、業務を進めます。関係者とのコミュニケーションは非常に多い仕事です。アーキテクトの立場でお客様と折衝する場面も多々あります。

組織が異なるメンバー同士のプロジェクトとなりますが、プロジェクトの一員として振舞うことに組織の隔たりはなく業務にあたっています。

協業開発という仕事を経験して

わたしは協業開発という仕事に長い間携わってきました。仕事を通じて感じることを少しご紹介します。

やりがい

月並みですが、お客様も含めたプロジェクトメンバーから頼られることにやりがいを感じています。

プログラムのちょっとした実装の相談から難解なトラブルシューティングなど、対応を積み重ねていくことでプロジェクトメンバーとの信頼関係が構築されていきます。

困ったらあの人に相談しよう、という状況を作り上げることが理想と考えています（全て受け取るのは大変ですが……）。

うまくいかないとき

わたしのチームでは解決できない技術課題にぶち当たることもあります。

そのときは自分の力量不足に悲観することもありますし、焦燥感を煽ることもあります。

そういうときは、身近にいる上司や同僚へ相談するようにしています。

チームをバックアップする組織体制が整っていることは利点だと感じていますし、安心感があります。

社内Q&Aサイトに疑問を投稿して解決したこともあります。全社的にもバックアップの仕組みがあるといえます（その社内Q&Aサイトの回答者が自部門の方だったというのはよくある話です）。

おわりに

協業開発という仕事をご紹介させていただきました。

協業開発に携わったメンバーの記事もこの機会に紹介させていただきます。ぜひこちらもご覧ください。

本コンテンツはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。