クライアント・エンジニアリング対談 #11（池澤あやか×平山毅）｜ バックエンド開発でのアジャイル推進

記事をシェアする:

幅広い技術・経験・バックグラウンドを持つスペシャリストたちが集結し、お客様と共に新しいサービスやビジネスを共創していく事業部門——それがIBM Client Engineering（CE: クライアント・エンジニアリング）です。本シリーズでは、CEメンバーが対談形式で、各自の専門分野に関するトピックを中心に語っていきます。

第11回目となる今回は、主に金融保険領域や新規事業企画のお客様との共創を進めているチームのリーダー平山毅と、アジャイル開発、大企業とスタートアップの連携など、複眼的デベロッパー視点でサービス開発に取り組むエンジニアの池澤あやかが、バックエンド開発でのアジャイル推進が導く新規サービス開発組織の在り方に与える影響などについて語ります。

 

1. プログラミングに目覚めたきっかけ

平山: CEでエンジニアリングマネージャーをしている平山です。チームメンバーとの対談を続けており、今回はデベロッパー経験も豊富で、CEにジョイン直後から金融やスタートアップなどの多彩な案件に参画いただいており、業界での知名度も高い池澤さんと、アジャイルにおけるバックエンド開発の在り方や、会社の枠を超えたコラボレーションなどを中心に対話していきたいと思っています。それでは池澤さん、簡単に自己紹介をお願いします。

 

池澤: 2022年6月に入社した池澤です。大学卒業後ずっとフリーランスのソフトウェア・エンジニアをやっていました。

ただ、フリーランスとはいっても、メインでお仕事をする企業は限定していて、ここ数年はコワーキングオフィスの無人運営を支援するスタートアップ企業で、業務委託という形で空間の予約システムづくりに携わっていました。「チャットボットを通じて空いているデスクを予約できる」、そんなシステムですね。

それから、中学2年生のときからタレント活動をしていて、IBM入社後もそちらは副業として続けています。

 

——「副業」と「復業」とがありますが、池澤さんの意識は?

池澤: CEでのデベロッパーが本業なので、タレントは副業ですね。

ただ、IBM社内でもその2つが交わるようなお仕事もさせていただいているんです。「TaMaRiBa（タマリバ）」というテレビ東京さまと日本IBMが手を組んで進めているビジネス・コミュニティがありまして、そちらではコメンテーターや出演者としてのお仕事もしています。そして同時に、TaMaRiBaのウェブサイトやオンライン・コミュニティのシステム制作にも携わっています。

…まさか、IBM社員としてこうしたお仕事をするとは予想していなかったので、ちょっとビックリです。

参考: お困りごと解決コミュニティ「TaMaRiBa」に参画します【池澤あやか】

 

平山: IBM Future Design Labとのステキなコラボレーションで、本業と副業がシナジーを発揮している良い例でもありますね。ところでプログラミングに精通されている池澤さんですが、元々はどういうきっかけだったんでしょう?

 

池澤: 中学生のとき、見よう見まねでウェブ制作を始めたのがきっかけです。深く考えることもなく、おもしろそうだなと始めました。

その後もずっとウェブ制作にハマって、WordPress（ワードプレス）を使う中でPHPを学んだりJavaScriptを学んだりと、楽しみながらどんどんのめり込んでいきました。

タレント活動をしていたのも関係しています。というのは、タレントって結構不安定な職なんです、時間も不規則なことが多くて。それで、一般的なアルバイトや仕事よりも時間の制約の少ない仕事ってなんだろう…と考えて、自分が好きなソフトウェア開発を選びました。

 

平山: 最近は社会人でも、爆発的に増え続けていく情報量との付き合い方や、副業やリモートワ―クが一般化していく社会変化への対応に苦労している人も少なくない中、池澤さんは学生時代から自分の時間を確保することや、タイムマネージメントの意識をしっかり持たれていたんですね。

 

2. リモートでの働きかたとスクラム開発

平山: フリーランサーからIBM入社に関しては、どういう意識の変容があったのですか?

 

池澤: 大学卒業してすぐは出勤や通勤が求められる「会社勤め」は難しいだろうなと思っていたんです。

でも、社会が変わりましたよね。コロナ禍で「柔軟な働きかた」を認めている会社が増えて、そんな中でIBMに出会いました。中でもCEという組織は柔軟性が特に高くて、さまざまな条件も私に合っていました。

 

平山: たしかに「リモートでの働きかた」にもいろんなケースやバリエーションがあり、一概に「リモート」とまとめられるものでもなくなりましたよね。

今、池澤さんには中国チームが参画する金融向けのメタバース関連の案件にも携わってもらったり、先述したTaMaRiBa ではスクラムをリードしてもらったりしていますが、何か気にかけていることなどはありますか？

 

池澤: どちらの業務もほとんどをリモートで行なっています。中国チームとの協業については、「そうか。言われてみればみんな中国にいるんだった。1時間だけど時差もあるんだった。」というくらいのシームレスさで進んでいるので、特に中国だからと気にかけている点はないですね。日本語が喋れるメンバーも多いですし。

TaMaRiBaではスクラム開発を採用して動いています。スクラムの基本原則は極力崩さないようにしてはいるものの、チームの居心地の良さを重視しており、典型的なやり方に固執しているわけではないです。心がけているのは「なるべくリモートでもコラボレーションしやすいように」という点ですね。

 

平山: スクラムマスターとして文化の異なるチームをつなげる役割も、チームとお客様をつなげる窓口役などもやっていただいていますが、少し具体的なところをお話いただけますか。

 

池澤: そうですね。今のプロジェクトの場合は、リリースサイクルを崩さないことを特に気にかけています。サイクルに合わせてしっかり目標を立ててリリースを行うことで、レトロスペクティブ（チームによる振り返り）でメンバーから出てきた意見を大切にし、実行しやすいので。

最近だと、みんなで同じ時間に集まり黙々と作業をする「もくもく会」を始めたり、ペアプロミンクを取り入れたり。これもチームからリクエストがあったからです。それからメンバーが気持ちよく働けるような声掛けや場づくりも意識しています。

 

平山:まさにアジャイル推進は、カルチャー変革からですかね。そういった意識は大事だと思います。

 

3. 女性技術者コミュニティとモノづくりへのこだわり

平山: Red Hat買収もあり、IBM自身もソフトウェアはオープンソースに注力しています。そして近年は特にデベロッパー・コミュニティを重視しています。スタートアップ経験も豊富な池澤さんですが、デベロッパー・コミュニティにも積極的に参画されていますか?

 

池澤: そうでもないです。でも、女性エンジニアのコミュニティということなら、IBM社内の女性技術者支援コミュニティCOSMOS（コスモス）のイベントには顔を出すように心がけています。やっぱりIBMってすごいですよね。社内にこんなに大規模で、これほど多くのイベントを定期的に開催する女性技術者コミュニティがあるのって。

キャリアプランを考えても、周囲に参考にできたり相談できたりする女性がたくさんいるIBMはありがたいですね。とはいえ、社会的にはまだまだ女性ソフトウェア・エンジニアが少ないので、この状況は変えていきたいです。

 

平山: 池澤さんには社内外で積極的にコミュニティ活動について発信していただきたいです。そして、ダイバーシティが求められる中、多くの女性エンジニアを元気づけモチベートしていただきたいと思います。

ところで、エンジニアってビジネスに興味のない人が多いという印象がありますが、池澤さんは違いますよね?

 

池澤: 違いますね。私はエンジニアには2種類いるのかなと思っています。技術を探求したいエンジニアと、サービス開発が好きなエンジニア。私は後者の「サービス開発が好き」なソフトウェア・エンジニアです。

 

平山: なるほど。以前のIBMは、前者の「技術を探求したい」エンジニアが多い会社でした。そこにある種の美徳を見出していたエンジニアも少なからずいたかと思います。

でも、それがここ数年で大きくシフトしてきました。「技術は、世の中の役に立ってこそ。それこそが重要」という意識が高まっています。

 

池澤: 同感です。私の場合「触れるものをつくりたい」という意識が強いです。「触れるもの」とは「物理的に触れるもの」と、心や感情を動かす「琴線に触れるもの」の両方の意味ですね。

モノづくり全般が好きなんです。たとえば、趣味でDIYをしていますし、ハードウェア開発に携わるのも好きですし、ウェブ開発やアプリケーション開発も「モノづくり」だと私は思っています。体験を提供して、そこで価値を感じてもらえますから。

 

平山: 「つくる」はCEが大事にしているポイントですね。他にも「モノづくり」でこだわっていることはありますか?

 

池澤: 「クイックにつくる!!」です。これに尽きます。これは私たちCEの精神であり、魂です!

 

平山: そして「ダメならすぐつくり直す!!」も、ですね。すごく重要なポイントです。まさにアジャイル開発の醍醐味ですね。

 

4. バックエンド開発でもアジャイル推進するテストコード

平山: 一方で、「クイックにつくる!!」そして「ダメならすぐつくり直す!!」が浸透しているフロントエンド開発に対し、バックエンド開発はまたちょっと違いますよね。第６回の

「フロント開発とアジャイル組織」では、池澤さんも多くのプロジェクトで一緒に共同開発をしている渡邊さんと、フロント開発とアジャイルの親和性について会話をしました。バックエンド開発の経験も長い池澤さんですが、その辺りはどう捉えていますか?

 

池澤: 私は元々がウェブ制作のフロントエンドからスタートして、バックエンドはなんとなく「ノリ」でそちらにも進んでしまったというのが実態なんですけど、でも、やってみるとすごくおもしろかったんです。

最近はまたフロント寄りに戻っているので、今は両方のおもしろさが分かります。

 

平山: 私も両方をやってきたエンジニアなので、その感覚はすごく分かります。そしてやはり、バックエンドは「じっくり設計して作る」要素が強いですよね。

 

池澤: そうですね。私はバックエンド系の技術者が持つ「テストコードをしっかり書く」「テストコードを大切にする」という文化がすごく好きなんです。そして大切なモノだと思っています。

フロントエンドは、バックエンドよりはそうしたテストコードの文化が少し希薄なのかなと感じています。レンダリング部分が重視され過ぎと言うか、「最終的な見た目さえ問題なければOK!」みたいな…。とはいえ、しっかりフロントエンドのテストに力を入れている方々もいるので、私もこれからキャッチアップしないとなあと思っています。

 

——「テストをしっかりデザインする」のと、「クイックにつくる!!」は相反するもののようにも聞こえますが。

池澤: そんなことないです。テストがあった方が結果的に早いですよ。

もちろんケースバイケースなところはあるし、スタート当初は「早く作ることこそ正義」だったりもしますが、開発も規模が大きくなると依存関係が複雑になってきます。そうすると毎回全部、自分で挙動を確かめるのではなく、出力結果が正しいかをテストコードで自動でチェックしてもらったほうが圧倒的に早いです。

それに、心理的な違いも大きいですね。テストコードがあれば、気軽にアプリケーションを改修できますが、テストコードがない場合は「これ試したら壊れちゃうかも…」ってビクビクしながらやるようなところがあります。

テスト自動化のためのテスト戦略は、今後もっと学んで広げていきたいエリアです。

 

平山: バックエンドはシステム的に大きくなりがちだし、そこが動かなければすべてが止まってしまいますもんね。その重要性をしっかり理解してフロントにも応用できる池澤さんのようなエンジニアは貴重な存在です。テスト文化とアジャイル開発の関わりについてはどうお考えですか?

 

池澤: アジャイル開発においてもテストの重要性は変わらないと思います。特に、ピボットが多いのがアジャイルなので、テストコードがあると改修しやすいぶん、より早く開発ができます。

 

平山: なるほど。文字通り「アジリティが高い」のがアジャイル開発ですもんね。品質のリスクがあっては、CI/CD（Continuous Integration/Continuous Delivery）は実現できません。その実現のために、自動テストは大事になってきますね。

少し、我われCEチームで採用している技術的な面も紹介したいと思います。

従来のWebアーキテクチャーでは、アプリケーションとデータベースが密結合になっており、かつ開発者が分かれていたので、その間のテストが難しく、バグや障害を生み出す中心的な箇所になっていました。

アジャイル開発でも、フロントエンド開発とバックエンド開発の担当は分かれているケースが多いのですが、実際にはその役割はとても近いんです。フロントとバックの連携部分にOpen APIを構成して、データベースを抽象化し、フロントアプリからはお互いが理解できるようにAPIでアクセスするようにして疎結合にし、変更の影響を小さくしています。

そのため、バックエンド部分のテストも、一貫して同様のテストツールで実現できるようにしています。

5. エンジニアリングとビジネスの溝を埋める

平山: 最後に、DXを進める上では、エンジニアリング側とビジネス側がより上手にコラボレーションし、これまでの溝を埋めていく必要があると私は思っているのですが、その点で今まで対談してきたデザイナーやデータサイエンティストは比較的にビジネスに近い位置で業務ができつつあるものの、エンジニアはビジネスの現場からの距離がまだ遠いのではないかと私は認識しています。

エンジニア観点で池澤さんからご意見いただけますか。

 

池澤: 従来型のウォーターフォール開発だと、エンジニア側の役割は「降りてきたものを実装する」となってしまいます。それだとビジネスとエンジニアが「お願いする側と頼まれる側」の関係となり、それぞれの役割を果たすだけになってしまいます。ただ、これは構造上、仕方ないかなって思うんです。

でも「本当に良いものを提供する」が共通のゴールであるなら、たとえエンジニアであっても「新しく開発しようとしているこの機能にはビジネス的価値があるのか」と思いを巡らせるなど、当事者意識を持つことが大切なのかなと思います。そうした意識を養うには、私たちCEでも採用しているスクラム開発はとてもよいフレームワークだと思います。

 

平山: 実際にそれがエンドユーザーにどんなふうに使われるのか、そして喜んでもらえるのか、そうしたイメージがクリアになっていくは全関係者にとって嬉しいことですもんね。

それに開発者と一緒に進めることで、ビジネス側もシステム的な要件が掴め、次のビジネスに役立てやすくなります。つまり、ビジネスの変化が激しい中で成果が得やすくなるということ——このアジリティを上げる開発手法を採用しない手はないですね。

ただ、理屈は分かっても、実践においては文化変革や品質確保など、自分たちだけでは実行することが難しい「やるべきタスク」もあります。ぜひ、池澤さんをはじめその手法に精通したメンバーの揃う我われCEにお声がけいただきたいですね。

 

池澤: 「まず一回、これでやってみない?」とこまめに確認しながら進められるのは、ビジネス的にも大きな強みですよね。価値を生み出しやすくなるチャンスなので、積極的に試してみて欲しいです。

それに、スクラムは短期間のリリースサイクルを回すという特徴がありますが、確実に2週間ごとに成果がでるのは、やっぱり魅力的ですよね!

 

平山: そうですね、池澤さんのキャリアも、まずやってみるというところから、専門性や知名度を築かれていることが分かりました。日々の積み重ねも、アジャイル推進では大事ですね。一緒に日本のイノベーションを促進していきましょう。本日はありがとうございました。

 

TEXT 八木橋パチ

問い合わせ情報

 

この記事を読んだあなたへのおすすめ

「キャリア一人称」から三人称へ | Client Engineering Welcome Sessionより

クライアント・エンジニアリング対談 #6（渡邊桂太×平山毅） | フロント開発とアジャイル組織

クライアント・エンジニアリング対談 #2（水田秀行×平山毅）｜社会シミュレーションとデジタルツイン