アパレルとテクノロジーのものづくり

随分とご無沙汰しております。約1年ぶりにnoteを書きます。早速ですが今回はアパレルとテクノロジーの架け橋シリーズ第一弾。

✓テクノロジーの知識を得たいアパレル業界のみなさま
✓アパレル業界の知識を得たいファッションテック界隈のみなさま

上記の非常にニッチなところへ向け、何かの参考になれば嬉しいなという想いでこのシリーズを書き記します。尚、この内容はすべてに当てはまる訳ではないこと、はじめにご承知いただけますと幸いです。

ソフトウェアのものづくりの流れを理解する

突然ですが、アパレル業界のみなさま、昨今、ECだAIだDXだなんだかんだとコロナによりデジタル化への勢いが増していますが、ソフトウェアやWEBサービスなどがどのような流れで作られているかご存じでしょうか。なんとなく知っているという方、いや難しそうだし全然知らないという方も多いかもしれません。

私はこれまで、アパレル業界で生産管理を長く経験したのち、アパレル関連システムの企画（要件定義）や進行管理など、いろいろと行ってまいりました。その中で結構目にするのが、流れを知らないばかりに起こるもったいないケースです。例えば「使ってみないと分からない」からはじまり、こんなつもりじゃなかったと後で要件を変更・修正するケース。本当によくあります。洋服を生産する際、服作りの流れを知っていた方が良いように、ソフトウェアを開発する際も同様なのですが、なかなかその流れが理解されておらず、もったいない事になっている印象があります。ITに対し難しい印象があるかもしれませんが、私はどちらも知る身として、両者のものづくりは物理的か否かの違いで、実は共通する部分が多いと感じています。ということで、今回はソフトウェアのものづくりをアパレルのものづくりになぞらえてご紹介してみたいと思います。

ソフトウェアのものづくりの流れをアパレルのものづくりで置き換えてみた

早速ですが、まずシステム開発の一般的な流れをご説明します。
尚、開発にはウォーターフォール開発とアジャイル開発という2つの手法がありますが、（詳細は追ってご説明するとして）まずは基本的な流れのウォーターフォール開発を基に進めさせてください。

1. 要件定義
システムの運用方法を含めた「このシステムで出来ること」(機能など)の要件を決定→要件定義書を作成する

2. 基本設計 (外部設計)
利用者視点でシステムに必要な機能を洗い出し、画面や各機能の仕様（UI/UXやデータベースなど）を決定→基本設計書を作成する

3. 詳細設計 (内部設計)
2. の基本設計を基に、開発者視点でコードやプログラムが実装できるように詳細化→詳細設計書を作成する

4. コーディング・単体テスト
コーディング(プログラミング言語を使ってソースコードを作成すること)を行い、単体(ひとつのプログラム)での動作確認を行う

5. 結合テスト
複数のプログラムを結合して実行させ、うまく動作するかの確認を行う

6. 総合テスト
構築したシステム全体を通し、利用者側が要求する機能や性能を満たしているか（処理速度や大量アクセスへの耐久など）のテストを行う

7. 運用テスト
実際にシステムを運用する環境下(利用者の環境)で、要件を満たしているか、開発したシステムに不具合がないかを確認

8. 本番移行・フォロー
構築したシステムを本番環境に移行し(リリース)、不具合があった場合などは即座に修正を行う

参考: システム開発の工程と流れを簡単に説明する
【図解】システム開発の工程と流れを開発モデル毎に解説

なんだかまだよく分からないと思いますが…
続いて、アパレルものづくりでざっくり置き換えて、要するにこんなこと、と抽象化してみたのがこちらです。

若干強引な部分はありますが、基本的に大枠の流れが同じなので、イメージしていただきやすいのではないでしょうか。まず、"どんな人へどんなものを作るか"を企画し、情報収集をして(=要件定義)、それを縫製仕様書に記し設計します(=基本設計)。そこからパターンを起こして職人が裁断～縫製できるように調整(=詳細設計)し、製品へと形になっていく(=コーディング)流れです。最後に検品や確認(=各種テスト)を厚めに行います。おそらく開発前にこの各工程のスケジュールの共有がありますので、この工程はこういう作業をしているんだなと置き換えていただけると分かりやすいかと思います。

開発のリードタイムは人数や要件にもよりますが、WEBなど小～中規模のものでは大体数週間～3ヶ月程度、基幹システムなど規模が大きくなると1年以上かかるものも多くあります。物理的なものづくりでないにせよ、品質とコストと納期に追われがちで結構泥臭い作業が多いです。まして魔法のように簡単にできるわけではなく、アパレル同様にいろんな人を介し、様々なプロセスを経て完成します。コーディング時にはライブラリ(プログラムの部品の寄せ集めファイル; 縫製で言う機能性の高いミシンかアタッチメント？)も使用しますが、人の手が掛かっていることも同じですね。

できるだけスムーズな開発をするために

続いて、スムーズな開発のためのコツをご紹介したいと思います。

まず、冒頭でお伝えした "こんなつもりじゃなかったと後で要件を変更・修正するケース" がなぜもったいないのかについて。先ほどのフロー図を見るとお分かりいただけるかもしれませんが、例えば、もう何百枚と完成したアパレル製品があり、「納前確認・試着」のタイミングでシルエットを変えたい、裏地やファスナーを変えたいなどの修正指示があった場合を想像してみてください。パターンからやり直したり、縫い目をほどいて縫い直すなどの割と地獄の作業が発生しますよね･･･これが同じように発生します。(=詳細設計変更から再度コーディング+厚めのテスト) 
きっとみなさまこう思うでしょう･･･「もっと早く言ってよ～！」（アパレルの場合はサンプルを作成すると思うので、こういう大掛かりな修正は少ないと思いますが･･･でも経験はあります･･･白目)

当初から計画していない大きめの修正は、バグ（不具合）につながる可能性が高まります。服作りでも急な仕様変更は滑脱やパンクなど思わぬ製品不良につながりやすいですよね。加えて、計画より余計な工数が掛かることになりますので、その分の日数やコストが増えます。なので最初からできるだけパターン作成（=詳細設計）のタイミングまでに（許される範囲で）念入りに打合せを行い、仕様を固めましょう。サンプルやデモを先方に作成していただくか、他の手法でイメージを伝えてもらう、また、雑誌の切り抜きのようにこちらから普段使っているシステムの画面や機能を見せて仕様の希望を伝えることも有効でしょう。
ちなみに、画面のボタンの大きさや色を変更するのは洋服の釦変更と同じで比較的難しくはありませんが、ボタンを押した際の機能を変更するとなると、要件次第ではもう既に開いてしまった釦ホールの位置を変更する(一から裁断・縫い直した方が早いシリーズ)へ発展する場合もありますので、ご承知おきください。

そしてもうひとつ、開発をお願いする企業や人がアパレル業界に詳しくない場合、特に気を付ける点があります。それは要件定義の際の意思疎通がスムーズにいかない可能性がある、ということです。あくまで傾向ではありますが、考えられる要因は3つあります。

1. 基本的な考え方や文化が対極的（感覚的と論理的、クローズドとオープンなど）
2. アパレル業界の用語や手法が定義化・標準化されていない（とても複雑）
3. カタカナ満載のテック用語 VS それに苦手意識が強めのアパレル側

一言で言えば、自然とコミュニケーションの齟齬が生まれやすい要因が揃っていると感じています。特に2. 、業界の曖昧な "なんとなくこんな感じ" を全く知らない人に（プログラミング前提で）正しく理解してもらうことはなかなか大変です。伝えたつもりが間違った解釈をされる場合も多く、我々の常識は他領域で常識でないことを念頭に入れ、いろいろと伝える工夫をしなければなりません。いい感じに～と丸投げなんてもっての外です。3. は先方の伝え方の工夫も必要ですが、「分からない」とシャッターを下ろさずに、積極的に質問や確認を行いましょう。（本当に苦手な場合はアパレル業界に詳しい会社を選んだり、詳しい人に通訳してもらえばOKです）

結局、ビジネスの基本ではありますが、お互い相手にどうすれば伝わるのかと考え、コミュニケーションすることが重要、本当これに尽きますね。

さいごに

さて、今回はソフトウェアのものづくりの流れとコツをご紹介いたしましたが、如何でしたでしょうか。意外と共通する部分多くないですか･･･？

私が以前社内システムの開発に携わっていた時は、私自身も開発に関して分からないことが多かったので、このように自分の知っている事へ置き換えて流れを理解し、それを利用して開発者や社内のメンバーと意思疎通を行いました。置き換えることで相手の気持ちを理解・想像しやすくなり、またこちらの意見も伝わりやすくなると感じています。
ちょっと説明が表面的な事だけになってしまい恐縮ですが、今後社内システムの入れ替えやIT導入補助金を用いて自社ECを作る、既存システムのカスタマイズを行うなどの機会も増えてくるかもしれませんので、その時の参考になれば幸いです。

次回以降、アパレルとテクノロジーの架け橋シリーズではアジャイル開発とオープン化の話を書いてみたいなと思います。(謎)

久々のnoteで長くなってしまいました･･･最後までお読みいただき、ありがとうございました！