NTTドコモビジネスの技術ブログ

全613件

2024/03/28

この記事では、内製でソフトウェアを開発するチームにジョインして間もないエンジニアが受託開発と内製開発の違いについて感じたことを紹介したいと思います。目次目次はじめにこれまでの経験 NeWork 開発チームにジョインきっかけいいなと感じたこと報告のための資料作成や調整作業がない価値ある変更は積極的に受け入れていること毎日リリースができること当初の想定と違ったことドキュメント類の決定事項が分かりづらい不具合やバグの優先順位が相対的に高くないときがあること意外と打ち合わせが多いことおわりにはじめにこんにちは、NeWork 開発チームの栄です。普段はオンラインワークスペースサービス NeWork の開発エンジニアをしています。NeWork の開発エンジニアを担当することになってから 1 ヶ月が経過しようとしています。そこでこの記事では、私がこれまで経験してきた受託開発と現在 NeWork で経験している内製開発の違いについて感じたことを振り返りたいと思います。これまでの経験これまではウォーターフォールで受託開発をする部署でシステムエンジニアとして中小企業の DX 化を推進するためのプラットフォーム開発をメインの案件として携わっており、担当業務としては提案や要件定義などの上流工程やシステムテスト、リリースなどを担当しておりました。幸い？なことに忙しく働かさせてもらい、担当業務だけでなく、新たな業務アプリケーションを導入するために全国のユーザーを訪問して勉強会を実施したり、アプリケーション導入後のさらなる改善を図るために実際の利用者のところまで訪問してインタビューをしたりと非常に多くの経験ができたと思います。最終的にはメイン機能の開発やその他別案件でも小さな案件であれば 1 人でも業務を任せてもらえるようになり、やりがいを感じながら充実感を持って業務に取り組めておりました。 NeWork 開発チームにジョインきっかけ業務に不満があったわけでは無いのですが、次第に次のようなことを思うようになりました。自分自身が実際に手を動かして開発できるようになりたいユーザーから得た反応をスピーディーに反映できるようになりたい 1 つめは担当案件では設計・コーディング・単体テストなどの工程は外部に委託をしており、実際に手を動かして開発をする工程になると進捗管理などのマネジメントがメインとなっておりました。しかし、自分が考えた要件や機能を実装できない、実装する方法がわからないことに危機感を感じるようになり、もっとエンジニアとして技術的に成長できる環境に身を置きたいと思うようになりました。 2 つめは受託開発の一次受けだったため基本的にはユーザー主導のスケジュールで進んでいくのですが、すべての工程で報告や確認や承認などが必要になります。(ユーザーからお仕事を頂いているので当然ですが。) そのため、どうしても開発スケジュールが長くなる傾向にありました。さらに、複数ベンダーが開発するプロジェクトだったため、1 つの機能を開発するにしても各社間で設計を合わせて、テストの実施も日程やテスト環境を調整するなども必要でしたので、よりスケジュール長くなってしまっていたと思います。実際に利用者にインタビューをしてフィードバックを貰っても、それを解決するためには次のリリースまでの数ヶ月の期間が必要であり、すぐにユーザーに価値を提供できないもどかしさを感じておりました。そんなとき、NTT グループには社員自らが自律的にキャリアを築き新たな挑戦ができるように各組織が必要とするポストに対して社員が手を上げて応募できる制度があることを知り、そこで NeWork 開発チームが新たな開発エンジニアの募集をしていたため、自ら応募することで現在は NeWork の開発チームにジョインしております。いいなと感じたことここからは、NeWork の開発にジョインしていいなと感じたことを受託開発と内製開発の観点から述べていきたいと思います。報告のための資料作成や調整作業がない私が経験した受託開発ではユーザーと何かしらの契約を交わしており、ほとんどの場合で成果物を納品する義務があります。そのためか細かく進捗を管理しながら多くの成果物を作成するのですが、1 つ 1 つの報告ごとにパワーポイントで資料を作成しておりました。また、テスト結果報告のときはすべてのテストを 1 つずつスクリーンショットで撮ってエクセルに貼り付ける作業をしており、かなりの時間を要します。さらに、大規模開発にもなるとステークホルダーがどんどん増えていき、報告をするためにも社内・社外問わず多くの関係者との各種調整をする必要があり、報告するまでにも多くの時間を要しました。それが NeWork の開発だとほとんどありません。実際に動くソフトウェアを見て進捗を判断してもらえるので新たに報告資料を作成する必要がなかったり、内製かつスクラムで開発をすることにより定期的にプランニングとレビューですべての関係者が揃うため、各種調整をすることなくすぐに関係者とコミュニケーションをとれます。資料を作成することは少しでも相手に対してわかりやすく伝えるために重要ですが、その報告のために不必要な時間をかける必要がないため、より開発作業に対して集中できるようになっていると思います。価値ある変更は積極的に受け入れていること IPA が公開しているアジャイルソフトウェア開発宣言の読み解き方にもあるように、開発者にとって一番大事なことは、「価値あるソフトウェアを素早く継続的に提供し、ユーザーにビジネスゴール達成の観点で満足してもらうこと」だと思います。しかし、受託開発をしているときはどうしてもビジネスゴールの達成よりも QCD(品質・費用・納期)の達成を優先してしまうこともありました。納期を守るために開発後期の段階で仕様変更すること対しては消極的であることがあったのですが、それがユーザーのビジネスゴール達成に大きく貢献できているか？と問われるともっと他にやり方があったのではないかと今にしては思います。一方で NeWork の開発ではユーザーのビジネスゴールの達成を最優先するために、改善に繋がる仕様変更は新たな価値を見つけられたとして、積極的に受けいれております。また、短い時間間隔で定期的にリリースをすることで、ユーザーからのフィードバックもすぐに適用でき、結果としてユーザーが本当に必要なものを作れているのではないかと思います。毎日リリースができること受託開発時は、本当にリリースをしていいのかをチェックするために品質報告会議やリリース判定会議があったり、リリースがあるたびにリハーサルを何度も行ったりなど、多くのプロセスをすべてクリアしてリリースの承認を得る必要がありました。品質を保つためには必要な工程だとは思いますが、やはりすべてのプロセスをクリアするには時間がかかるため、どうしてもリリースまで時間がかかってしまいます。以下の記事にもあるように、NeWork では毎日リリースをできる体制が整っており、とても驚きました。リリース頻度を毎週から毎日にしてみた毎日リリースする機会があれば、ユーザーからのフィードバックもすぐに反映できます。また、毎日効率よくリリースするためにリリース作業が完全自動化されております。以前は深夜に起きて何時間もリリース作業をする必要があったため、この差は個人的にはかなり大きいです。当初の想定と違ったことこれだけでは NeWork の業務はいいところだけ述べており、以前の業務は悪いところしかないようにみえるので、ここからは NeWork にジョインして当初の想定と違って驚いたことを述べたいと思います。ドキュメント類の決定事項が分かりづらいドキュメントが内部の開発者だけでしか見られないこともあり、ドキュメントそのものに対してレビューをすることはほぼありません。そのためか、議論の途中までしか文章化していないこともあって、あとで振り返ったときに決定事項がわかりづらいこともあります。また、開発者全員に開発スキルがあるためか、文字だけで仕様を決めていき絵や図を書かずに設計を進めていたため、後から関係者間で実装内容の認識が異なっており認識合わせに時間がかかったこともあります。一方で受託開発では基本的に行うべきタスクを明確にしないと次の工程に進まないため、要件定義や設計で詳細に作りたいものを決めていきます。また、すべての関係者が技術に明るいわけではないため、理解しやすく認識齟齬が起きないように絵や図を書きながら議論をしていきます。そのため、タスクの割り振りや知識の共有などはしやすかったです。そのため、受託開発での経験を活かし、記載内容をテンプレート化する、文字だけでなくホワイトボードツールなどで絵や図を書くなどして少しでもドキュメントがわかりやすくなるような工夫を導入していきたいと思います。不具合やバグの優先順位が相対的に高くないときがあること不具合やバグがあっても発生するケースが稀であったり、影響の小さいものであれば他のタスクより優先度が下がることもあることに驚きました。以前は金融業界だったこともあり、高い信頼性が求められたため、不具合やバグはすべて対応しておりました。ソフトウェアごとに求められる品質は異なるため、どちらがいい悪いと決めるのは難しいかとは思いますが、そもそも不具合はあってはいけない、不具合を発見したら早急に修正するという環境にいた身としてはこの差にはかなりギャップを感じました。意外と打ち合わせが多いことこれも悪いというわけではないのですが、NeWork の開発では日々のスケジュールとしては午前中の大半は定例会議などで過ごしており、週に 1 回はイベントデーとして 1 日打ち合わせだけの日もあります。自分が想定していた内製開発ではもっと打ち合わせ回数は少なく、開発に充てる時間が大半だと思っておりました。1 週間でのトータル打ち合わせの時間だけでいえば、受託開発のときと大きな差はないと思います。しかし、打ち合わせの内容は結構異なるなと感じました。受託開発時は基本的には社外の方と打ち合わせをすることが多く、打ち合わせのために何回もレビューをして準備を整えてから臨んでいました。内容としても進捗管理や課題管理がメインとなり、長い計画のなかでいかに QCD を満たすかを目指すことが多かったです。一方で NeWork では社内の方との打ち合わせがほとんとです。1 回の計画期間が 2 週間と短いため、計画と振り返りを短いスパンで繰り返すイメージが強いです。おわりにこの記事では、私自身が NeWork の開発にジョインして感じた受託開発と内製開発の違いについて紹介させていただきました。受託開発・内製開発と一口に言ってもさまざまな企業があり、開発現場が異なれば上で挙げた内容が当てはまるとは限りませんが、この記事が読者の皆さまのお役に立てば幸いです。最後に、2024 年 3 月現在、NeWork では一緒に開発を進めてくれる仲間を募集しています。詳細は以下のリンクをご覧ください。皆さまのご応募を心からお待ちしています！ hrmos.co

NTTドコモビジネス の技術ブログ

コンテンツ

NTTドコモビジネスの技術ブログ