こんにちは。入社3年目のHです。
私はECパッケージ「ecbeing」の製品開発部門に配属されたのですが、案件対応にも携わる機会がありました。 製品開発は汎用的なパッケージを作る仕事、案件対応はそれをベースにお客様ごとにカスタマイズする仕事です。 同じECシステムでも求められる視点は大きく異なり、その両方を経験する中で、開発において大切なことが少しずつ見えてきました。
本記事では、それぞれの経験で印象に残っているエピソードをもとに、「標準パッケージの機能を理解すること」と「お客様の運用を理解すること」の大切さをお伝えできればと思います。
製品開発で学んだこと：標準パッケージ全体を見る
製品開発のプロジェクトで特に印象的だったのが、価格未設定商品見積対応です。 このプロジェクトでは、「特定の条件下で、価格を設定していない商品の見積を可能とする」という対応を行いました。
価格が存在することを前提に設計された仕組みに対して、「価格が存在しない商品」という新たな例外ケースを追加することで影響が広範囲にわたります。そのため、いくつかつまずいたポイントがありました。
共通処理の考慮
最初は、設計書を画面単位で順に実装する方針で考えていました。しかし、パッケージの中でどこに同じような処理が使われているか把握できておらず、そのまま着手したことで共通化すべき部分を考慮できないまま進めてしまいました。
その結果うまく進められず、先輩に相談しつつ、共通仕様やそれに伴う懸念点を整理して仕様を固め直すことになりました。手戻りは発生しましたが、全体の仕組みを理解してからはスムーズに進められました。だからこそ製品開発では特に、着手前にパッケージ全体を把握することが重要だと感じています。
複数プロジェクトへの影響
当時は目の前のプロジェクトをこなすことに精一杯で、同じパッケージ上で他にどんなプロジェクトが走っているか、自分の改修がそこにどう影響するかはあまり考えられていませんでした。
その結果、別プロジェクトの機能を自分のプロジェクトに取り込むタイミングになって初めて、その機能の仕組みや運用前提を一から理解する必要が出てきました。予定していた工数よりもかなり時間がかかってしまい、事前に把握できていれば防げた遅れだったと反省しています。
これらの経験から、製品開発では目の前の機能だけでなく、パッケージ全体を把握したうえで開発を進める必要があると学びました。
案件対応で学んだこと：実際の運用を見る
製品開発部門にいながら、案件側の対応にも関わる機会がありました。
案件対応で特に印象に残っているのが、注文書を出力する機能の対応です。
想定とのギャップ
最初は、製品パッケージの仕様やレイアウトに近い形で注文書を出力すればよいと考えていました。注文内容が正しく出力される、それで十分だと思い込んでいました。
ところが、お客様の運用を確認してみると、想定していた使い方と全く異なりました。お客様の運用は、ECシステムから出力される注文書と、別経路から出力される注文内容を紙ベースで並べて比較し、「内容が合っているか」を目視でチェックするという形だったのです。
運用に合わせるレイアウトの必要性
お客様の運用を踏まえると、単に注文書として情報を出力するだけでは不十分でした。比較しやすいように、既存の帳票のレイアウトに合わせる必要がありました。
製品パッケージの仕様だけを見ていたら、この視点には自力では気づけなかったと思います。実際にお客様がどう使うかを聞いて初めて、必要なレイアウトや配慮すべき点が見えてきました。「機能として正しく動く」ことと「実際の運用に合っている」ことは、別の話であると実感した経験でした。
両方を経験したことによる学び
製品開発と案件対応、どちらも経験したからこそ、共通して大事だと感じることが2つあります。
1. 標準パッケージの機能を理解する
製品開発での経験を通じて痛感したのが、パッケージ全体の理解の重要さです。別プロジェクトの機能を把握できていなかったことで想定外の工数がかかったように、パッケージを理解していないと、的確な判断や見通しが立てられません。
これは案件対応でも大切な観点です。標準機能で対応できるものを知らなければ、本来は不要な追加開発をしてしまうかもしれません。逆に理解していれば「それは標準機能で対応できます」と提案できます。製品開発でも案件対応でも、これは土台になる知識です。
2. お客様の運用を理解する
案件対応では、運用を理解していないと「動くけど使われない機能」になってしまいます。注文書出力の経験はまさにそれでした。
そして製品開発でも同じです。標準パッケージとして提供する以上、特定のお客様だけの使い方を想定するわけにはいきません。さまざまな運用パターンを想定する力が求められます。実際の運用パターンを想像できていないと、導入時に大量のカスタマイズが必要になり、結果的に使いにくい機能になってしまうかもしれません。
この2つはつながっている
製品開発と案件対応、どちらか一方の経験だけでは気づけなかったことがあります。パッケージを理解しているからこそ案件で適切な提案ができ、運用を理解しているからこそ製品開発でも実際に使われる機能を考えられます。この2つは切り離せない両輪だと思っています。
おわりに
配属されてからこれまでを振り返ると、最初は「機能として正しく動く」ことを意識していた自分が、経験を重ねる中でパッケージ全体への影響やお客様の運用といった、より広い視点で考える意識を持てるようになりました。
AIができる領域がどんどん広がる中で、「どう作るか」の実装作業はますます効率化されていくと思います。だからこそ、パッケージを理解したうえでお客様に適切な提案ができる判断力や、実際の運用を想像してより使いやすい機能を考える視点は、これからも大切にしていきたいと感じています。
そういったスキルを磨きながら、お客様の信頼を得られるエンジニアに成長していきたいと思います。
お知らせ
ecbeingではAIに関する記事も公開しております！
ecbeingでは新進気鋭なエンジニアを募集しております！
