【イベントレポート】内製開発エンジニア勉強会 ~社内システムを内製化して学び・悩み・悟ったアレコレ~

f:id:pcads_media:20210122192953j:plain
こんにちは!TECH Street編集部です◎

今回は2020年12月23日(水)に開催した、【内製開発エンジニア勉強会~社内システムを内製化して学び・悩み・悟ったアレコレ~】のイベントレポートお届けいたします!

お話しいただいたのはこのお二方。

f:id:pcads_media:20210122193150p:plain

石井 孝典さん/パーソルキャリア株式会社 (左)
なーねこ(長谷川 真)さん/株式会社サイカ(右)

今回は、社員が使用する社内システム(基幹業務システム)における内製開発に実績と知見があるお二方から、各社での取り組みや気付きをシェアしていただきました!

 

基幹システム刷新における品質担保のためのデータベースを用いた自動テストの構築とデータリフレッシュについて

 

パーソルキャリアの石井さんからは、転職サービス「 doda 」の転職希望者情報や企業からの求人情報を管理する社内基幹システムデータベース(ARCS)に関して、自動テストのノウハウや基幹システム刷新苦労話、データリフレッシュ技術についてお話し頂きました:)!

ARCSでの自動テスト導入について

開発段階における自動テスト導入に際し、意識したのは「継続的インテグレーション」。
これを行うことでバグを早期に発見したり、ソフトウェアの品質を高めたり、リリースまでの時間を短縮することに繋がったのだとか。

従来のプロジェクトでは、このような提案はコストカット等の理由で最初に削られてしまうような内容なのだそう…しかし、今回の基幹システム刷新プロジェクトにおいては、内製開発エンジニアが必要性を強くプッシュし導入に至ったことが、大きなポイントとなったそう。

では、具体的に「継続的インテグレーション」とはどのようなものなのでしょうか。

f:id:pcads_media:20210122193434p:plain
「継続的インテグレーション」においては、
・自動テスト
・自動デプロイ
・頻繁なコミット

この3つを実現させることがポイントになっているとのこと。この構造を実現するために石井さんは下記のソリューションを採用しました。

静的解析:ソースコードのお作法のようなものを自動的に/機械的にチェックをする
自動テスト:MsTest(v2)を使用しテストコードを実装
コードカバレッジ:自動テストがちゃんと実装されているのかを確認する

しかし、業務開発に自動テストを導入することの難しさも....

①初期開発コストの増大と未来のコスト・工期削減どちらをとるか問題が大変。

・手動で行う単体テストコードに比べて開発するコード量が増えるため規模によっては初期コストが増大(汗)
・dodaの基幹システム刷新プロジェクトでは、手動テストの6倍のコスト増…!

実際は1年以上運用していればペイできる、とのことですが、とはいえいきなり6倍コストがかかる見積を突き付けられた時のインパクトはかなり大きいですよね。社内で話を通すのも中々大変だと予想されます…。しかし、石井さんは、「絶対に効果は出ると思うのでそこは頑張って!」と力説!ここは内製開発エンジニアの腕の見せ所ポイントのようです。

②テストコードを書く前に下準備。開発が出来る状態に持っていくのが大変。

・開発ルールの策定
・静的解析/カバレッジ開発ルールの整備
・開発環境の構築と開発時のテスト実行ガイドライン整備

テストコードを初めて書くときは、ただコードを書くだけでなく、設計すべきポイントやルールを考える仕事も結構な工数として発生します。

③テストコードを書くだけでゴールはない。運用ができる状態に持っていくのが大変。

・運用ルールの作成(静的解析/カバレッジ計測含む)
・運用対戦/トレーサビリティの構築
・Error=0を目指す
・適切なCI/CD環境の構築(テストカテゴリの設定・スケジューリング)

テストコードは継続的に回していかないとなりません。その中で見つかったバグをどうやって対処していくか、などの運用体制の設計は非常に重要とのこと。

では石井さんはこのような大変さを乗り越えて、どのように改善に取り組んでいるのでしょうか?:)

データベースを使った自動テスト実装

開発している基幹システムは様々なシステムが刺さっている状態で運用されているため、モック化せずにデータベースを利用しているとのこと。これにより、複数の他システムとの兼ね合いで完全再現できないことや、他システムの変更による影響が探知できなくなることを防いでいるそうです。(実は、参考書にはバッドパターンとして紹介されている方法だそうですが、あえてやってみたとのこと…!) 

f:id:pcads_media:20210122193616p:plain

この方法を導入したことによって発生した問題のうち、一番大きかったのは自動テストを実行するとデータベースにはいっている情報が変わってしまう、という問題だったそうです。

Oracle Exadata Cloud at Customerを使用したデータリフレッシュ

これを解決するために目を付けたのが、社内で使っていたデータベースのなかにあった「Snap Clone」の機能だとか。上記の課題はこの機能を使うことで殆ど解決することが出来たそうです。

f:id:pcads_media:20210122193812p:plain

しかし、非常に効果的であるとわかった「Snap Clone」を使用する際にも、一筋縄ではいかずいろいろなトラブルが発生したとのこと…。

・Snap Cloneというか検証用の環境準備でDump作成したらOracleTextなどが飛んでしまい再構築作業が辛かった
・Oracle Database(Snap Clone)の仕組みや手順に関する説明が少なく習熟が困難だった
・MSのようにユースケースやリファレンスがドキュメントとして固まってないので正しい使い方なのか分からないのも微妙に困った

また、最大のトラブルとしては、Oracle DatabaseのEOSL対応のためOracle Exadata Cloud at Customerが利用不可になったことだそうです…!2〜3か月かけて準備してきたものが使えなくなる可能性があり、またゼロから考え直す必要があったとのこと。

ただ、移行先はOracle の正式なクラウドサービス。石井さんは「Oracle の正式なクラウドであれば容量無制限じゃないか?」と、気づき、クローンを自動的に作れる構造を構築し、対処することができましたとのことです!

Oracle Cloud Serviceを利用したデータリフレッシュ

f:id:pcads_media:20210122193911j:plain

実際のデータリフレッシュフローはこちら。

f:id:pcads_media:20210125152245j:plain
基幹システムの構築にあたり、1つのプロジェクト当たり500GBくらいの容量が必要であったため、コストコントロールが必要となりました。石井さんは、CDB1つずつをプロジェクトに割り当てるのではなく、大きなCDBに複数のPDBを作成するなどの工夫をしてコストカットを実現しながら実行できたそうです。

f:id:pcads_media:20210125152804j:plain

このように、一つ一つの課題を解決しながらプロジェクトを推進していきましたが、やはり苦労は絶えなかったそうです。(一難去ってまた一難ですね…!)

・CDB、PDBやDBシステムやノードの概念の理解に苦労した
・OracleのVersion依存で出来ることができなかったり、代替案を探すことがつらかった
・コストのかかり方や実際のDBの使われ方を考慮して開発側に考慮しつつコストを抑える運用案を考えるのに苦労した
・Cloneの時間は単純にDBの要領に依存するがDBが大きすぎて1つの検証にも時間がかかり大変だった

これら、多くの課題を乗り越えたうえで気づいた、基幹システムの内製にあたるポイントはこちら。

・業務システムでも規模が大きいまたは高頻度な改修を行うシステムではテストを自動化することで運用開始後からすぐに恩恵を受けることが出来る
・自動テストに初めてトライする際は実装コスト以外に運用設計に多くの準備工数がかかることに注意
・DBをデータソースとして自動テストはバッドパターンといわれているがやれないことはない。特殊な要件や事情がある場合はあえてトライしてみるのも悪くない


石井さんからは、システム構築の歴史からからコストカットまで、ここまで話しちゃって大丈夫!?と思うほど、非常に具体的なご説明をいただきました。石井さん、貴重なお話をありがとうございました! 

続いては、株式会社サイカのなーねこさんからお話を頂きます!

 

「エンジニア・人事・情シス」複数キャリア視点からみる内製開発と今後のキャリアについて

 

なーねこさんは現在サイカ社にて情シスの立ち上げを担当されているそうですが、これまではシステムエンジニアをベースに、人事や業務改善など複数のキャリアを歩まれているとのこと!

また、情シスの方々が情報共有をできる情シスSlackコミュニティも運用しているそうです(気になる…!)

本日は、これまでのご経験をもとに「ノウハウ」「内製開発エンジニアのキャリア」についてお話しいただきます。ポイントは以下の2つ。

・「課題発見能力」めちゃくちゃ大事!
・「視点を増やして」ポータブルスキルアップ

そもそも内製開発をするうえで、内製開発エンジニアは、システムを開発するだけではなく、システム利用に関する業務フローなども設計されていると思います。なーねこさんは「業務フローの開発までしていることをもっと誇りに思っていいと思う!」と語ります。

f:id:pcads_media:20210125152932j:plain

なーねこさんが内製開発を担当した際、「顧客が説明した要件」と「顧客が本当に必要だったもの」が異なるものだった経験があるそうです。

例えば、顧客からは「経理のシステムをなんとかしたいのでマクロで自動収集したい」という要件の依頼受けた際。実際に経理の方と一緒に働いてみることで、顧客が本当に必要だったのは営業から出てきたものを承認・差し戻しをすることであり、マクロではなく、Webシステムの方が適していることに気づきました。

一方、提出する側の営業サイドはExcelでの提出が良かったため、マクロでWebサービスをたたく、というような設計にしたことで顧客が本当に必要だったものに対するソリューションを提供することが出来ました。

f:id:pcads_media:20210125153024j:plainこのような内製開発が成功した要因として、以下が重要なポイントでした。

・業務フローごと変更した
 →課題を整理し業務フローごと「設計」した
・課題の本質を考えた
 →顧客(経理)の要望通りではなく、実際に業務にかかわり「課題発見」をした

開発だけでなく、業務フローの構築までを担当している内製エンジニアだからこその気づきや発見から、顧客が本当に必要なソリューションを生み出すことが出来るのですね。

また、なーねこさんは人事や情シスなど、複数のキャリアを経験していますがその点も大きなメリットがあるようです。

f:id:pcads_media:20210125153107j:plain複数のキャリアがあるからこそ「視点」が増え「課題発見」の能力が向上したとのこと。

また、複数キャリアを経験していくメリットについて、「100人に1人」の能力を3つ積み重ねることで「100万人に1人」の人材になっていくことが出来るという点をあげています。 

f:id:pcads_media:20210125153204j:plain

キャリアは職種だけではなく、役割や業務内容によっても構築されるので、自分が好きなことや趣味などにおいても、積み上げていくことができるとのこと。

今後の内製開発については、

・すべて内製という開発は確実に減る(減っていると思う)
・各種業務に特化したSaaSが様々登場している
・コアな部分(人事マスタ等)の一部の開発と、各種SaaSを連結する開発にシフト
・オンプレを減らし、ノーコード開発の利用なども増える

という見方をしているそうです。

これらの経験や、現在の状況を踏まえ、なーねこさんからは下記のアドバイスをいただきました。

・内製開発のありかたも変化していきます!
・ポータブルスキルを磨こう!
・複数キャリアで新たな視点を手に入れよう!
・キャリアを通じて「課題発見能力」を身につけよう!

キャリアは職種だけでなく趣味やプライベートでの活動も影響するということ、複数のキャリアを持つことで「課題発見能力」が向上し、内製エンジニアとして提案できるソリューションがより本質的な課題に沿ったものになる、ということは多くの内製エンジニアの皆様にも非常に参考になるお話だったのではないでしょうか◎

開発だけでなく、業務フローの構築までも担当する内製エンジニアだからこそ、日々の生活の中で多用なキャリアを構築していくことが業務に直結するのでしょうね…!なーねこさん、貴重なお話をありがとうございました。

登壇スライド

speakerdeck.com

 

まとめ

今回は、非常に具体的な事例のご紹介から、内製エンジニアとしてのキャリアの歩み方、またキャリアを構築していくうえで得られる内製エンジニアとしての強みまで幅広くお話しいただきました。

実際に社内のシステム開発においてのTIPSとなるだけでなく、今後の業務やキャリア構築をしていくうえでの良い気づきやきっかけとなりましたら幸いです!

参加者満足度

f:id:pcads_media:20210125153404p:plain

参加者コメント

・現実的な開発の話に加え、キャリアについてなど視野を広げる大切さを学んだ。
・リアルな生の声がたくさん聞けた
・自身の業務に近く参考になる。
・具体的な内容を教えて頂けたこと。
・今まで知らなかったことを学べました。

ビデオオンにしていただいた皆様との集合写真

f:id:pcads_media:20210125153608j:plain
次のページでは、参加者の皆様から頂いた質問についてもご紹介いたします♪

>>当日のQ&Aをご紹介♪


 

参加者から石井さんへの質問

 

Q.影響調査は特にツールは使っていないのですか?

A.影響調査ツールをプロジェクト中に導入しました。ちょっと修正するのに数週間の調査が必要、みたいな状況だったので影響調査ツールを導入に至りました。ただ問題は、影響調査ツールは1つのシステムに対する影響調査ツールであるので、複合のシステムを網羅的にチェックできるシステムは存在しませんでした。ですので最終的には基幹システムの調査をするツールを導入しましたが、結局影響調査ツールの出す結果が100%じゃないかぎりエンジニアは納得しないので、ソースコードを読む力が必要になってきますね

Q.CI環境構築って専任部隊を作ったのですか?

A.専任部隊はなかったです。「こういうのやってみたかったけどできなかったんです」という意見をもったエンジニアが内製だからこそできる、という環境があったので協力してもらいました。

Q.プロジェクトにCIの意識を持たせることを、どうやってプッシュ・認めさせたのでしょうか?

A.実はこのプロジェクトは予算に組み込まれていなかったので、どうにか隙間を埋めて実行してしまった!のですが、経験のない人に理解してもらうのは難しいので、内省エンジニアで草の根的に開発し、実際に見せることで認めさせるように努力しました。

Q.そもそも内製開発できず外に頼るしかない、そんな企業にアドバイスを!

A.SIerで10年とかやってきた人材は意外と市場にいるので、そういう人材を迎え入れるのがいいかと思います。ベンダー側でプロジェクトを進めてきた経験がある人たちなので、外注する際にもそういう人たちにエッセンスを入れてもらうのがいいのではないでしょうか。

Q.内製開発の自動テスト以外で苦労したポイントはありますか?

A.全てではないかといっても過言ではないのですが、ちょうど基幹システム刷新のときは社内で内製開発チームを作ろうとした時期と同じだったのですが、自分たちで導入したルールが正しいか・良いのかを確認する必要がありました。プロジェクトの途中で人が増える、という状況もあったので、一番苦労したことはやはりチーミングだったかと思います。

Q.「エンジニア」ではなく「内製エンジニア」だからこその苦悩で「これが一番」を聞いてみたいです。

A.「内製開発エンジニア」だけで大規模な開発ができるわけではないので、外部のベンダーとのコミュニケーションは難しいと感じます。内製開発エンジニアとして、プロジェクトの進め方を提案するがそれ通りにすすめてうまくいかなかったときの責任の所在や複数のベンダー間で板挟みになってしまうことも多くあります。

 

参加者から長谷川さんへの質問

 

Q.情シスSlackをつくったきっかけは?

A.自分がたまたま情シスに未経験のまま転職することになってしまったのがきっかけです。情シスって社内に数名しかいないことが多いので外に聞くしかないと思いました。外にも同じような悩みを抱えている人も多いので、Slackをつくってみたらのびた、という感じです。

Q.2つ目、3つ目のキャリアはどうやって選ばれたのでしょうか。

A.人のために動くことが好きだったということを見てくれていた上司がいた、というのも大きかったです。

Q.「エンジニア」ではなく「内製エンジニア」だからこその苦悩で「これが一番」を聞いてみたい

A.経営者の理解がないと、内製エンジニアは事業側のエンジニアによく引き抜かれてしまう、ということが発生します。なので、事前に立て付けをしっかりしておく必要がありますね。

Q.内製開発で苦労したポイントはありますか?

A.技術選定が大事かと思います。昔、FlashがはやったときにFluxを使いたいというエンジニアがおり、マネージャーとして許可してしまったゆえ、だれもメンテナンスが出来ない状況になってしまったことがありました。最新の技術は使いたくなりがちだが、作って終わりではないので、技術選定は非常に重要かと思います。

Q&Aは以上となります◎

最後に、今回ご登壇いただいた石井さん、長谷川さん、参加いただきました皆様、ありがとうございました!今回のイベントレポートは以上となります♪また、次回のイベントもお楽しみに:)