キックオフ～

フレームワークスに対する期待値を背負って臨む

-O.Y（以下「O」）： ～

この案件は難しい案件だなとキックオフの時点で思った。BtoBとBtoCで別々のWMSを使っているがそれを統合したい、加えて、出荷量の増加にも耐え得るものにしたい、様々な既存システムとの関係も維持しつつ可能な限り整理したい。要件そのものは理解できるけど、キックオフの時点ではどういう着地になるか全く見通せなかったよね。

H.J（以下「H」）：

ユーザーさんからするとシステム導入して終わりではなく、その後のビジネス展開にスピード感を持って一緒に取り組める会社を選びたいという希望があったしね。フレームワークスの特徴として、大型案件の導入事例の多さと、パッケージベンダーではあっても導入後の追加改修にも対応が可能。そこがフレームワークスを選定頂いた１つの理由になったような気がしますよね。

O：

最初に、現状分析を2ヶ月実施したんだよね。現行業務フローを基に、どんなデータや機能が存在するか、という情報を聞いてまとめたんだけど、凄く丁寧に細かい所まで説明して頂いて。大規模なシステム刷新をしたいユーザーさんからすれば「フレームワークスが本当に信頼できるかどうか」をこの期間にシビアに判断していたと思う。だから、アウトプットそのものの見た目に拘るよりも、我々の１つ１つの発言がきちんと全体の流れを踏まえたものになっているか、聞いた事をただ纏めているのではなく、＋αで理解を深めるための質問をするとか。今後、未来に向けた議論ができる相手として認めて貰うことを意識してた。やっぱり最初が一番緊張するよね。

パッケージを当てはめるのではなく
パッケージを起点に柔軟な思考で答えを作りだす楽しさ

O：

現状分析の結果を基に、自分たちのパッケージにただ当てはめることは簡単なんだよ。でも「ユーザーさんが本当に実現したいことは何か」という本質に読み替えないといけない。それがパッケージの機能に近ければ一番良いんだけど、近くなかったら「近くない」とはっきり伝えることと、代わりにユーザーさんの実現したいことを踏まえた上で「こういう形ではどうですか」ということを提案しないといけない。

N.R（以下「N」）：

フレームワークス以外の物流システム会社へも声が掛かっていたと思うんですけど、競合他社と比べて現状分析とか代替案の提案ができるっていう強みがあったから受注に繋がったんですかね？

O：

当時の資料には「EC企業導入実績やシステムの変化対応に強い有力２社に絞り込み後、将来の変化対応力の差でフレームワークスを選定」という記載があるね。我々はパッケージだけで他社と勝負しているわけじゃない。パッケージをベースとして利用する意識が染みついている。あくまでベースだから、要件に合わせて形を柔軟に変えていく、という意味では「新たにシステムを作っている」に近い。パッケージに囚われ過ぎず、上流フェーズで「どう作ろうかな」とか「どうすれば期待する形にできるかな」を考えるのは楽しいよ。

W.O（以下「W」）：

一般的なパッケージ商品って、ユーザーさんが叶えたい要望が、パッケージの範囲で「できる」「できない」で白黒はっきり判断しているものが多いと思うんですよね。「うちはパッケージ商品なので、それは無理です」みたいな。Oさんは、「Aは難しいけど、Bはできる」みたいに、ユーザーさんに別案を提示していて、それにとても憧れて、私もそういう提案ができるようになりたいと思っています。

O：

いずれWさんも実感する事になると思うけど、要件が全く同じプロジェクトは存在しない。その代わりに、過去のプロジェクトでの経験を活かせないプロジェクトも存在しない。過去のプロジェクトの知見を自分なりに咀嚼して次に活かせているという感覚は、やりがいを感じる瞬間でもあるね。

基本設計～

ユーザーの熱量に比例してアップした難易度と作業量

O：

当時入社したてのNさんには基本設計から入ってもらったよね。元々我々の協力会社さんに勤務していて、フレームワークスのパッケージを理解していたから、当初はサブPLという立場で協力会社メンバーの進捗を管理してもらうような立ち位置を考えていたんだけど、結果、どちらかというと頭と手を目一杯動かして貰う形になったね。

H：

このプロジェクトは基本設計フェーズに入っても大人数での打合せが多かったよね。ユーザーさんサイドで10人以上が打合せに参加してくれる事が多くて。しかも全員が真剣に今回のプロジェクトを自分ごととして捉えているから議論のレベルも高く、熱量があった。議論が盛り上がると、前回着地済のはずの内容がひっくり返ることも多かったけど。結果、難易度も作業量も増して、Nさんにもかなり頑張って貰う事になったんだよね。Oさんと私でシステム全体としての整合性が取れているかを慎重にチェックしながら設計をして、それを漏れなく個別の機能に反映するために、各開発担当に渡す設計資料の準備と口頭での詳細な補足に相当な時間と気を遣ったね。

N：

前職ではこれだけの規模・人数で仕事をしたことがなかったので、最初のうちは慣れなかったです。「ここは任せた」と言われ、細かい部分を自分で考えて進める必要があったので、とにかく時間に追われていた記憶があります。

H：

フレームワークスの会社規模でこの規模のプロジェクトをこなすというのは結構凄いことなんじゃないかな。フレームワークスが物流に特化していて業務知識や知見がすごくあるからだと思うよ。

泥臭く時間をかけること、未来を見据えた実装に拘ること

O：

色々と無茶振りをしたけど、僕とHさんが楽してるなーって思わなかった？

N：

思うわけないじゃないですか(笑)。ただお二人との知識や経験の差は感じましたね。案件に途中参画したこともあって、私が仕様を理解する為の時間を割いて貰いましたが、かなり苦労しました。

O：

自分もプレイングマネージャーとして相当手を動かしたなぁ。全体整理と設計だけじゃなくて開発もテストもNさん達のコードレビューもたくさんしたし。この規模のシステムで、品質を担保するにはとにかく泥臭くやるしかなかった。

N：

開発者の気持ちをよく分かってくれるから、開発者としてはストレスフリーで働けています。

H：

このプロジェクトの中で、当時としてはなかなか先進的な取り組みもしているんだよね、マテハンとのAPI[*2]連携。既に倉庫で稼働済みのロボットストレージ（自動倉庫）と連携するから、昼間はテストができず夜中にテストするとか、推進上のリスクもあった。

O：

あまり期間的な余裕はない中で、かつ、ユーザーさんから要望されたわけではないAPI連携方式に拘ったのは、RFP[*3]に記載のあった「今後の機械化を見据えた柔軟性の担保」という観点で間違いなくプラスになると思ったから。とは言え当時、我々内部でも現行連携方式を踏襲した方がリスクは低いかも、という話も挙がってましたね。相手システム側もAPI連携は初だという反応でしたし。でも妥協しなくて良かったと思っている。

H：

API連携基盤を帳票発行基盤と統合する事で、内部で帳票発行の詳細ログが追跡できるようになって、稼働後の調査でも活躍したしね。

• *2 API……Application Programming Interfaceの略。ここではWeb-APIを指す。インターネット上で情報のやり取りに広く使われているHTTP/HTTPSを利用したアプリケーション同士が接続する仕組み。
• *3 RFP……Request for Proposalの略。提案依頼書という意味で、システム開発や業務委託などを行う際に、発注側が開発側に対して具体的な要件や条件を伝えるための文書。

稼働後立会

反省点だらけの初動対応

O：

稼働後の立ち会いはまさにカオスだった。2拠点同時展開したんだよね。BtoB拠点の方は割とすんなり稼働して上出来だったんだけど、BtoC拠点は大変な状況だと連絡が入って、即合流(苦笑)。

W：

2つの拠点でそんなに違ったんですか？

O：

BtoBは人間系の作業が中心、BtoCは複数のマテハンが登場する上、従来のオペレーションから大きく変わったからね。現場の作業員の方も戸惑ってた部分もあったみたい。

H：

エラー報告を受けたら、１件ずつエラー原因を特定して、解消するための操作方法を教えたり、若しくは我々で強制的にリカバリしたり、の繰り返し。ただ、その何倍ものペースで、エラー報告が積みあがっていく状況。

O：

システム不具合が原因のものもあるし、実装自体は仕様通りなんだけど複数の操作ミスが複合的に絡み合っているものもある。後者は言ってしまえば「仕様通りです」なんだけど、それだと何も解決できないわけじゃん。もう瞬発力の勝負だと思ったから、今できる最善手が何かを即判断して、皆にも動いて貰った。

N：

新規画面を、その場で口頭で伝えられた要件で作り、2時間後にはリリースして現場でそれを使い始める。そういう世界でしたね。

O：

あの状況ではそれしか打ち手が無かっただけで、全く褒められた対応じゃないから本当は言いたくないんだけど。でも現地立会メンバーが皆同じ意識でいてくれたからこそ乗り越えられた。

H：

ユーザーさん側でも調査部隊を増員してくれて、エラーが出ているものをパターン毎に仕分けて、それを我々が複数人で並行して調査する、本当に関係者総動員で対応だったね。

N：

立ち会い期間って、トラブル対応がなければ1～2週間のイメージなんですけど、結局1ヶ月位は現地にいましたね。

O：

とにかく、我々の反省点は「現場での受入テストの支援内容が不十分だったこと」だね。もちろん頭では受入テストの重要性を理解していたんだけど、正常系の流れが何となくチェックできた段階で、問題なく動きそう、という思い込みがあったんだと思う。我々は本来、誰より心配性でなければならないのに。結果、1ヶ月弱もの間、現場に迷惑を掛けた。二度と繰り返しちゃいけないね。

保守+追加開発

実務未経験でも参画しやすい環境

W：

私がプロジェクトに入ったのは稼働から1年半くらいのタイミングですね。今の担当は追加の開発です。

H：

WさんはそもそもSE未経験の状態でフレームワークスに入社して、このプロジェクトに入ったよね。途中から入るのは大変なプロジェクトじゃないかと思ったんだけど、どうでした？

W：

実務経験がない状態で入ったので、先入観や変な癖がない状態でプロジェクトに参画できたので、逆に良かったと感じています。

O：

「諸先輩方が優しくて最高です！」みたいなコメントがほしいな(笑)。

W：

それは、大前提にありますよ（笑）「ここが分からないです」って手を上げると、先輩方がバッと集結して手助けしてくれる優しい環境だと感じています。実務経験がないので入社当初は「コードを書ける気がしない。一応勉強はしてきたけど使い物にならないかも」と不安でした。当初の業務は、追加改修・保守が主で、「一から独りぼっちで開発」ではなく、既にあるソースに手を加えていくことがほとんどだったので、その不安は早々に消えました。既存の案件で皆さんが培ってきたものの上を歩む様な形でプロジェクトに参画できました。

H：

段階を追って学べている、という感じ？

W：

そうですね。簡単な開発から初めて、進捗に合わせて「ここまではできたから、次はこういう画面を作ってみよう！」みたいな穏やかな感じで進めて頂きました。

O：

うちは本当に優しい社員が多いよね。フレームワークスの半分は優しさでできてるよ。

W：

本当にそう思います。丸投げとか人のせいにするとかはないですね。

次の世代に引き継ぐことの重要性

O：

稼働をしてから3年半。システム導入後に安定稼働したら、ある程度システム改修も落ち着くことが多い中、有難いことに今でも追加開発の相談を頂いている。「現状よりも良くできる」という高い現場力が、常に新たな改善アイデアを産む文化なんだと思う。我々としてもある程度スピード感のある支援ができてるんじゃないかな。そして、僕が永らく窓口を対応していたけど、そろそろNさんに主担当を担って貰おうと思って現在引継ぎ中なわけだけど。急な話で驚いた？

N：

いつか引き継ぐ時が来るかな、と思っていました。

O：

ほぼ隙間なく追加開発の話がある状況で引継ぎのタイミングを逸してたんだけど、Nさんの成長を考えるともっと早く窓口の役割を譲ったほうが良かったな、と思っている。PM/PL業務じゃなく保守業務でも、ユーザーさんとの会話や調整をする経験値を積む事はできるし、自分が主担当なんだ、という意識はとても重要だから。少し甘やかし過ぎたかな。

N：

引き継いでもうすぐ3ヶ月になりますが、感じるのは、ユーザーさんとの友好関係を築いた上でずっとやってきたんだなと。既に優しいレールが敷かれた状態で保守の窓口になったので、やりやすさは感じます。大量の依頼が来たりもして刺激的ですが(笑)、ユーザーさんも優しめに対応してくださるんです。そこはやっぱり窮地を乗り越えたメンバーかつ保守期間があったからこその関係性なのかなと思いましたね。

プロジェクト全体を振り返って

O：

「人に恵まれたプロジェクトだった」という一言に尽きるかな。我々に力量があればもっとスマートにできたなという反省点は多々あるけど、ユーザーさんとワンチームで、厳しい局面も泥臭い人の力でカバーしつつやり切った、この仕事の面白さ・奥深さを再認識できたプロジェクトだったなと。そして約4年前に開始したこのプロジェクトをアクティブな状態でNさんやWさんと言った若い世代に引き継げたというのも、すごく感慨深い。これからは自分たちで、ユーザーさんの為に何ができるかを考え、時にチャレンジをして、自身の成長にも繋げていって欲しいと思う。

H：

プロジェクトの中で「機械と人が整合性の取れた状態で連動する」という仕組みを設計できたことですね。前からもチャレンジしていた部分はあるんだけれど、ここで本格的にシステム全体の設計方法から「通信のタイミング」「エラーがあった時の制御方法」みたいな細かいところまで踏まえて色々設計とかさせてもらった。それが他の仕事に繋がっているということもあって、非常に重要なチャレンジだったんじゃないかと思う。

N：

これだけの人数がいるプロジェクトに関わるのは初めてで、その中での適切な立ち回りの仕方とかを当時はできてなかったな、と思います。協力会社さんとかユーザーさんと関わる機会もたくさんあったので、そういう状況を経験できたっていうのが一番大きいですかね。特に協力会社さんとの関係づくり・わかりやすい設計方法・自分がやりたいことを相手に伝える方法とか、そういったことがこのプロジェクトで身についたのかなと思います。

W：

今回お話を聞いて、プロジェクト初期から関わっていた皆さんの苦労と、熱い思いが伝わってきました。皆さんが培ってきたユーザーさんとの信頼を崩さないように、今後保守や追加開発を行っていきたいです。少し個人的な話になりますが、転職前も今も、ユーザーさんと寄り添いながら、一緒に喜んでいただけるシステムを構築していくお仕事がしたかったんですよね。それを叶えることができるフレームワークスに入社して良かったと改めて思いました！