リモートワークのフリーランスエンジニア開発外注方法を学べるWEBメディア

リモートワークのフリーランス活用WEBメディア

【E-bookをプレゼント】

人材採用の起爆剤!
今までのノウハウを全部つぎ込んで無料配布中。

これを読めば、確実な人材採用方法を学べます。
是非、ビジネスにお役立てください。

ダウンロードはこちら
※無料メールマガジン登録でダウンロードできます。

[インタビュー]トラブル事例!某有名メーカーのエンジニアの言いなりで設計をミスした私の失敗談

 
この記事を書いている人 - WRITER -
アプトリーのWEBライター。 リモートワークを身近な存在にするために、自社内での実例など交えながらせきららに記事を書いていきます。 実業務では主にPHPを。HTML,CSS.JSなどは使いますが…というレベルです。 リモートワークを導入してみたい。どういったものなのかを知りたいという方向けに掘り下げた記事を主に作成します。

インターネットのショッピングサイトの構築を担当した時のことです。

それまで企業内や取引様向けの受発注システムの主に要件定義、設計、テストをするエンジニアであった私は、はじめて消費者向けのプロジェクトを担当することになりました。

消費者向けということで、これまでと全く異なる知識が必要だったのがショッピング機能です。

これまでの作業よりも複雑な案件だった

それまでは注文や受注が確定したら、データとして書き出ずだけでよかったのですが、インターネットのショッピングサイトの場合は、注文する商品のデータを買い物籠に複数保持し、そして受取の方法や、決済手段の選択などの処理を複雑に組み込む必要があり、面食らっておりました。

このプロジェクトには某外資系の大手メーカよりプロジェクトマネージャーと、プログラム開発を担当するエンジニアが参加しておりました。そして開発期間を短縮できることを売り文句に某大手メーカーが製品としてもっていたショッピングツールを使うことを推奨してきました。

インターネットショッピング機能の構築に少々自信がなかった私は、このツールの有用性を検証せずに安易に受け入れてしまいました。これが大きな失敗となることがこのときは分かっておりませんでした。

このショッピングサイトの商品は、外部にリアルタイム管理された在庫データをもっていました。

買い物にかごに商品が入れられると在庫数を減らして、予約状態になります。そして注文が確定すると、予約から確定注文データに変更するというからくりになっていました。

スケジュールがとても厳しかったため、テストをかなりバタバタな状態で行い、本稼動を迎えました。

そして本稼動後の注文データを検証した結果、あってはならないことが起きておりました。すなわちショッピングサイトでは注文が確定していないのに、確定注文データができてしまっていたのです。

このあってはならないことの原因は…?

今回採用したショッピングツールは内部的に独自のデータの置き換えして処理が進められていました。

ツールがゆえにこの動きの詳細が全く分からなかったですが、ショッピングの過程で操作を一旦やめて、あとでもう一度やり直した場合などに不具合が発生していたのです。

すなわちショッピングは中断しているので、ショッピングサイト自体には注文は成立しておらず、受注は確定しておりませんが、外部管理された在庫データの方は予約から確定注文に遷移してしまっていて、注文データができあがってしまっていたのです。

あわててショッピングサイトの稼動を停止し、注文の後続処理をとめて復旧作業をはじめました。

某外資系の大手メーカの開発者にショッピングツールがどんな操作を行ったかの履歴情報を出すよう求めると、内部的にデータ変換されてしまっているので、履歴を出してもどのデータがどの注文ことかは分からないと言うのです。困り果てて、仕方なくインターネットショッピングサイトが受注を受け付けたメール情報をデータ化し、確定した注文データと突合せ、正しい注文データを抽出しました。

これで誤って消費者に注文していない商品を届けるという最悪の事態は回避できましたが、ショッピングサイトのプログラムを修正しないと、稼動を再開することができません。

ショッピングツ-ルがおかしな挙動をしていることは明白であったため、バグとして早期に修正することを要望したのですが、某有名メーカーのかなり上役の方までいらっしゃいましたが、どうにも修正することができないという回答でした。

いつになったら終わるのか…

仕方なく徹夜で、外部のリアルタイム管理の在庫サーバー側で改修作業を行いました。

予約から確定注文に変わったデータのうち、どれが正しい注文なのか判別することが、ショッピングサイト側のショッピング工程ではできなかったため、スマートな方法ではありませんでしたが、リアルタイム在庫管理のサーバー側で確定した注文を後続処理に流す前に、ショッピングサイトの受注データとのマッチング処理を急遽組み込むことにしました。

マッチしなかった分は、リアルタイム在庫数に加算で戻してやることによって整合性をとりました。

作業は3日連続、昼夜をぶっ通しで続け、ようやく終わり、稼動を再開することができました。

この失敗談はテスト不足であったため、稼動前に発見できず起きてしまったことは間違いありません。

しかしながら設計の段階で、本当に採用に値するショッピングツールであるかよくよく検討するべきでした。某有名メーカーであるから大丈夫であろうと判断してしまったことが悔やまれます。どんなに有名メーカーのものであろうが、本当に有効となるツールであるかきちんと調べるべきでした。

また開発者も某有名メーカーの人だから、任せられると勝手に思い込んでおりました。

結果的に全く役に立たないエンジニアでした。所属がどこであろうがエンジニアはその人個人のスキルで判断するのが大切であることが身にしみて分かりました。

このショッピングツールはこのあとも時折暴走し、その都度手直しがとても大変でした。

典型的な失敗プロジェクトとなってしまいました。


アプトリーはリモートワーカーと企業様を繋ぐサポート事業を行っています。

  • 新規事業の設計開発が一気通貫が得意です
  • 納品よりもビジネスの成功にコミットします
  • スクラムのチーム開発も得意です
 

少しでも興味を持っていただけた方は画面右下にありますチャットからお気軽にお問合せしていただければと思います。

いいね !をしていただくと
最新記事をお届けします♪

Twitter で

- Comments -

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Copyright© リモートワークのフリーランス活用WEBメディア , 2019 All Rights Reserved.