【インタビュー】ニフティの課金系システムチームとは？業務内容を聞いてみた！【課金システム前編】

ニフティの回線をお客様に契約を申し込んで頂く所から、ご利用料金の請求まで様々なシステムを取扱っています。
一例ですが、回線サービスの申し込み管理システムであったり、申込サービス内容や取り扱い説明書の書面データを発送するシステム、ご利用料金の決済システムなど様々なシステムを取扱っています。

• PPPoE 固定IPオプション
  • https://csoption.nifty.com/staticip/pppoe/
• @nifty MAX光
  • https://setsuzoku.nifty.com/max/

メンバー全員でチームが抱えているシステムの面倒を見れるようにしてます。
というのも、うちのチームでは古くから扱っているシステムがあってそれぞれ担当者がいたんですけど、その担当者が離れた途端にそのシステムについて理解している人がいなくなってしまうといった過去があったんです。
そういった経験から、属人化を防ぐためにチームの方針として新旧のシステム問わず知見をメンバーに共有することを徹底して、全員の経験値が平等になるようにしています。

自分たちはスクラム開発を取り入れていて、全員に対して課題報告や知見共有のタイミングがあるので、そういった時間で話をしています。
加えて、一つのタスクに対してもチーム全体で関わるようにしたいのでモブプログラミングを取り入れて、複数人で作業することを意識したりしています。

成果物がある程度できたところで共有会を欠かさず実施したり、議論が必要な部分では全員で話し合うことを意識しています。
タスクのチケット管理をしていて、そのチケットの中に残すべき証跡はしっかり残すようにして貰ったりしていますね。形にすべきものはしっかりドキュメント化するように各メンバーが意識するようにしています。
なんにせよ、担当している人しかわからない。属人化を防がないといけないので何かは残してね。という状況にしていますね。

長く使われているシステムをアップデートするためにレポジトリを確認してみたら、コメントが何もなくてコミットメッセージが少しあるだけで意図が分からなかったりして手がかかってしまったことがあったんですよ。
目の前のタスクを早くこなすことも勿論大事ですが、５年後１０年後そのサービスを扱う人を考えてものづくりをする必要があると考えています。

基本的にはバックエンド系の開発ではPython,Docker、クラウドではAWSを主に使っております。
既存システムの調査ではGo, PL/SQL, Java, C, JavaScript, Perlなどを見ますね。ちょっとした確認程度も含めて色々な技術に触れる機会があります。

新しく触ったりする技術や機能は基本的にメンバー間で知識が偏らないように進めています。
最近では監視設定を導入する際に、メンバーが新機能を見つけては共有会などを開いたりしていました。
業務時間内で調査する時間を意識的に取って、メリットデメリットを共有したりなどを話し合って技術選定をしています。

S.O君やM.M君がよく便利な機能を見つけて提案してくれていてとても助かっています。
今まで取り扱っていたシステムは社内向けのAPIだったため、厳密な性能を求められていませんでした。そこからお客様が見るデータを取扱うように切り替わったので、監視の徹底やAPIの安定稼働をシステム的に達成するためにAWSのApplication Signalsを導入しました。

新しい技術の導入は、以前の開発案件で上がった課題を基に考えることが多いですね。

雑談から「ここの部分まだいけてないよね」とか共有したり、話をしていく中で「その手があったか！」みたいな気付きもあって、そこから課題の共有や発見、解決に繋がったりしています。

私がサブチームリーダーになる前のチームは、個人の開発力でタスクをこなしていく風潮が強かったんです。なので「チームで開発を行っていく」という意識を定着させることに取り組みました。
開発に関する課題を開発力のある人が解決してくことで、仕事が回る場面も勿論ありました。そうすることで新しい技術をチームに取り入れる機会もあったんですが、全員がその技術を扱えるわけではなかったり、長い目で見た時のパフォーマンスやチームの再現性に繋がらない状況でした。
このままでは将来を見越した開発という観点で安心できないと考え、チームビルディングを考えるようになりました。
タスクの大小に関わらず『チームとしてどうすべきか』という観点で話し合い、チーム全員で仕事の進め方を決めるようにしています。個人ではなくチームとして活動する意識を日頃から持つことを意識しています。普段の声掛けやコミュニケーションや打ち合わせなどでこういったイメージを持ってもらうようにしています。

私は他チームが持っていた請求系システムを刷新したことが一番記憶に残っています。レガシーなシステムだったので構造を理解するのに苦労はしましたが、請求系のドメイン知識や、PL/SQLに関する知識が付きました。
また、リプレイス先の技術選定については、前プロジェクトで似たような構成でシステム刷新したことから、同様にAWSを採用しました。
以前開発したシステムに関する課題の解決策を考えて適応することで、アーキテクチャや監視、テスト周りをより良いものに作ることができ、結果としてシステム全般に関する面でチームとして成長できたという実感があります。

細かい機能追加ももちろん頑張っていますが、なんだかんだで毎年一件ぐらい新規開発案件があって、そこでは特に気合を入れて頑張っています。先ほどのS.Oさんの話にもあったように前回の開発の経験から反省を生かしてより良いシステムを作る雰囲気がありますね。
同じ様な構成のシステムであったとしても、クラウドが持つ便利な機能を新たに取り入れたり、システムごとのやりたいことを考えて構築しています。より良くできたら達成感がありますね。
最近はこういった経験から、ただ作るだけでなく運用の負担を軽くするために何が出来るかを考えられるようになってきたのでチームとして良い傾向だと感じています。