私の仕事紹介: 自社サービス開発における「開発」以外の仕事
2024年05月13日 月曜日
CONTENTS
はじめに
IIJ に新卒で入社して気づけば１０年目、つまりITエンジニア１０年目ということになります。藤本です。
最近は研修系の記事ばかり書いてる（それも年に１回）気がするので、今回は本分であるエンジニア業について紹介したいと思います。
私の所属する部署では主に「SMF」と呼ばれる技術を使ったルータ管理サービスをBtoB向けに提供しています。
いわゆるWebサービス開発業務となりますが、一口に「Webサービス」といってもそれは様々な技術の集合であり、技術スタックだけでも以下のように挙げられます。
- セキュリティ（TLSや脆弱性対応など）
- フロントエンドアプリケーション
- サーバアプリケーション
- データベース（MySQLやらMongoDBやら）
- インフラ（Linux, ネットワーク, etc…）
- 監視・モニタリング
- テスト
- リリースエンジニアリング
しかし実際にお客様にサービスを届けるにはもっとたくさんやることがあります。
- 新サービスや新しい機能の企画
- 課金体系を含むサービス全体の設計
- 請求系や出荷システムなど既存システムとの連携
- 約款や契約書の準備
- マニュアルなどドキュメント整備
- マーケティング、営業部門との連携
- サポート体制の整備
- ルータの出荷体制など業務フローの設計・運用
- リリースレビュー体制など、社内フローの立て付け
- etc…
イメージを図にしてみると以下のようになります。
もちろん開発チームだけでできるわけもなく、社内の様々な部署の人たちと協力しながら実現しています。
私の技術者としての仕事は設計（アーキテクト）業務の比率が大きく、インフラやアプリケーションの実装方針などを固めています。
その設計業務においては技術的な面以外にも、顧客にサービスを提供するための要素が無視できません。例えば課金の仕方や契約の立て付けなどによってアプリケーションの実装が影響されたり、あるいは社内フローの作り方次第で開発のしやすさ、障害時の影響度合いが変わるためです。
今回は「自社サービス開発」で普段あまりスポットされない、開発と「開発以外」の関わりに焦点をあて、私の仕事を紹介したいと思います。
モデルケース: サービスに大きめの機能追加を行う
自分たちが開発・運用しているサービスにそこそこ大きな機能追加を行うまでの流れを例に、業務内容を紹介したいと思います。
なお自分のチームではいわゆるアジャイルな開発スタイル（なんちゃってスクラム）を採用しており、リリースは週に１回、テストも含めて開発業務は全てチーム内で回しています。
今回の例は大きめの機能改修ということで数週間かけての開発になりますが、普段の不具合修正や軽い機能改修などは開発チーム内で独立してイテレーションを回しています。
普段の情報収集
普段は開発業務の傍ら、サービスに関わる様々な部署の方と情報共有を行います。
- 案件情報
- お客様と会話した際の感触
- サポートに問い合わせのあった内容
- 業務上発生した課題
- 社内の他サービスやプロダクトの開発状況
- 他社の動向や関連する話題など
- etc…
こうした情報共有の中でお客様が困っていることなどを分析し、作るべき機能を考え企画に進みます。
企画
企画フェーズでは新しく作るべき機能のイメージや方向性を固めます。
この段階で満たすべき機能仕様、ターゲット顧客と価格イメージ、ステークホルダーの洗い出しなどを行います。
どこまで「ちゃんと」企画を作るかは機能の大きさや影響次第で、社内wikiにメモ程度にまとめる程度から、説明用の資料としてまとめるものまで様々です。
また作ろうとしてるものに技術的な不確定要素がある場合、この段階で事前検証を行なって潰しておきます。
技術設計
企画が固まると、実装に向けて技術的な設計を行います。いわゆる「アーキテクチャ」を固める段階です。
ざっと挙げると以下のような作業になります。
- データモデルの設計を行う
- データフローを設計し、マイクロサービス構成のどこに実装するか決める
- 場合によっては新しいデータベースの検討、新しいマイクロサービスコンポーネントの言語やフレームワークを決める
- ざっくりとした画面イメージを固める
- どの順番で開発しリリースしていくかなど、開発の進め方を決める
- 「やらないこと」を決める（プロジェクトのスコープ固め）
最後のスコープ固めは企画段階でやってもいいのですが、具体的に技術設計をしてみて分かる困難さなどもあるので、この段階で最終確定させます。
またこの段階で必ず開発チームと背景を含めて情報共有を行い、開発の進め方などの合意を取ります。
と書くといかにも重厚なプロセスに感じますが、５分ほどの立ち話で済ませたり、その程度なこともあります。
開発
いよいよ開発フェーズです。各プロセスを自分でやることもありますし、丸っとチームメンバーに任せることもあります。
ちなみに今回のように企画作成や事後プロセスを検討している間にも、開発チームはアジャイルでイテレーションを回し続けています。
企画するまでもない不具合修正や機能改修を常に回しつつ、大きめの機能追加がたまに飛び込んでくるイメージですね。
実装
言わずもなが、コードを書くプログラミング作業です。
この中にはCI/CDと呼ばれる単体テストやリリースエンジニアリングも含まれます。
テスト
ここでいう「テスト」は最終的な結合試験です。通常はQAチームなどが別にいてそちらに渡すやり方が多いと思いますが、私の部署ではテストも開発の一部と捉えてアジャイルなフローの中に組み込むことで、品質とリリース速度を確保しています。
マニュアル整備
顧客向けに提供するマニュアルなどのドキュメント整備までが開発プロセスの仕事です。なぜならマニュアルも顧客に提供する価値の一部だからです。
週に一度リリースしていると、マニュアルの更新を追いつかせるのも簡単ではありません。
社内調整
開発プロセスと並行して、機能リリース後に回す業務フローや約款といった契約文書の改訂作業などの調整を進めます。
法務部に相談したり、機材の出荷を専門とする部署と協力し、新しい機能リリースによって追加・変更されるフローがきちんと回るようにしておきます。
承認・リリース作業
開発が完了するといよいよリリースです。
責任ある組織として、責任者が内容を確認しGOサインを出す承認プロセスは必ず必要になります。
GOサインが出ると作った機能を週１回の定常リリースタイミングに混ぜ込み、無事リリースとなります。
場合によっては定常リリース以外の特別なメンテナンスを実施することもあります。
ランスルーテスト
リリースしたからといって仕事は終わらず、リリースした機能が本番環境で動作するか必ず確認します。
これは例えばサービスを契約したら実際に宅配業者から機器が発送されてくるか、という確認も含みます。
特にいくつもの部署やサービス、外部の業者などが関わる場合テスト環境での確認には限界があり、気は抜けません。
受注開始！
新しいサービスやオプション追加の場合、ここまで来てようやくお客様に受注していただくことが可能になります。
作った機能をお客様に契約してもらえるというのはとても嬉しいものです。
運用
作った機能は運用しなければいけません。私の部署ではDevOpsの考え方に基づきサービスの運用まで同じチームで行なっているので、運用を疎かにした実装をすると苦労するのは自分たちです。
企画や技術設計の段階で業務フローと合わせて設計を行うと書きましたが、その辺りの設計がまずいと大抵運用に苦労することになります。
運用で苦労しないためにも全体を見つつ技術設計を行う必要があります。
最後に
今回は私が行なっている、いわゆる「ソフトウェア開発」と呼ばれる以外の業務に主に焦点を当てて紹介してみました。
何度も書いている通り私一人で行なっているのではなく、開発チームはもちろん、他の部署やチームのたくさんの方々と協力しながらやっています（まだまだ未熟者で、どうしても開発や技術を優先した決断をしてしまい、迷惑をかけることも多々あります）。
全体を見ながら技術設計をするのは大変ですが、どこか一方だけを見ていてもいいサービスは作れませんし、ソフトウェアだけでなく周りの業務フローやお客様の業務、サポート体制まで含めてきちんと回っている一つの「システム」を眺めるのはとても楽しいものです。
（毎回きちんと回るものが作れるとは言ってない）
IIJ社員がお送りする、私の仕事紹介。
ほかの業種紹介もありますので、気になる方はこちらもチェックください。
