なぜWBSを作成しなければならないか

プロジェクトに携わると必ずと言って良いほど「WBSを出して下さい」と言ったり言われたりします。WBSとはWork Breakdown Structureの頭文字をとった頭字語で、プロジェクトを計画する際によく使われるツールですが、多くの人はWBSを作る立場になる前に少なくとも1つ以上のWBSを見たことがあるのではないでしょうか。

ところが、自分がWBSを作る立場になると、WBSの作成は簡単そうに見えて意外と難しいということに気づくケースが多いように思います。少なくとも私はそうでした。

以前にも書いたように、たまたま参画したプロジェクトのPM(プロジェクトマネージャ、プロマネ)が「見える化」をしないタイプだとしたら、おそらくWBSは存在していない(作られていない)でしょう。そういうプロジェクトは概して無計画で、出たとこ勝負であり、ノリ重視であったりします。人生は出たとこ勝負で良いかもしれませんが、プロジェクトとなれば(当人がプロジェクトのオーナーで無い限りは)そういうわけにもいきません。そういう現場が好きな人以外は、そのようなプロジェクトに間違って参画してしまうとそれなりに苦しい時間を過ごすことになります。

「プロジェクトは計画通りにいかない」という人がいます。もちろんそのとおりだと思います。プロジェクトには大なり小なり想定外のイベントは付物で、事故と言ってもいいでしょう。しかし、だからといって計画を立てなくて良いということにはなりません。それは何故でしょうか。

WBSはプロジェクトの完了に必要な要素を全て洗い出したものです。多くの場合、洗い出した項目とガントチャートを組合せてスケジュール表として作成します。(以降、WBSといえばスケジュール表を兼ねているものを指す)だから、WBSがあれば、

  • そもそも何をしなければならないか(全体の規模感)が分かるため、心構えができる。
  • 何をいつから始めれば良いかが分かるため、気付いたら時間切れという事態を避けられる。
  • 各作業の全体の中の位置付けが分かるため、次の作業を意識して取組むことができる。
  • 先々の予定を把握することで、余裕を持って作業に取組むことができる。
  • 結果的に、生み出す成果物の品質が高くなり、プロジェクトの成功確率が高まる。

…と、このようなメリットが期待できるのです。逆にWBSが無ければどうなるでしょうか。

  • 何をしなければならないか「分かったつもり」になっているため、必要な項目が漏れる。
  • 何をいつから始めれば良いか分からないため、項目を思いついた時点で既に時間切れの場合がある。
  • 全体の中の位置付けが分からないため、1つの作業に没頭してしまい、目的と期限を見失う。
  • 先々の予定が分からないので、差し迫ってない項目は放置し、差し迫ってから着手する。
  • そのため、突貫工事で低品質の成果物を生み出し、高稼働でコスト増またはスケジュール遅延となる。

…と、このようなデメリットが想定されるのではないでしょうか。ここでは私の思いつく限りを列挙しましたが、きっと皆さんはそれぞれの状況下でそれぞれのメリット・デメリットを挙げることができるでしょう。突き詰めていくとWBSの有無がプロジェクトの成否だけでなくプロジェクトに関わる人たちに影響をもたらすと言えます。


ビジネスモデルキャンバスの威力を体験してきました

今日はITコーディネータの実務研修に参加してきました。テーマは「提案営業のための『戦略的IT経営』実践術」ということで、ビジネスモデルキャンバスが中心の演習でした。講師は熊本を中心に活躍しておられるITコーディネータの先輩・アイティ経営研究所代表の中尾克代さん。普段からビジネスモデルキャンバスを活用したコンサルティングを行っているそうです。

ビジネスモデルキャンバスというのは名前の通りビジネスモデルを書き出すフレームワークで、ビジネスモデルの現状を把握したり変革を起こすためのツールの一つです。「ビジネスモデルキャンバス」という言葉は数年前に耳にしたことがあったのですが、ブームに乗れなかったというか正直なところ「本当に効果があるのかな?」とずっと懐疑的な態度でいました。ツールについての詳細はネットの記事や書籍等に譲りますが、今回の演習を通して感じたことをお伝えしたいと思います。

演習は参加者同士で相互にヒアリングし、ビジネスモデルキャンバスに落とし込んでいくというもの。私も相手にヒアリングしてビジネスモデルキャンバスを作成しましたが、逆に私もヒアリングされて私のビジネスモデルを整理していただきました。このツールは9つの要素で構成され、それぞれを質問して埋めていきます。質問に対する回答がちょっとポイントがずれてしまったり書き出す時の表現が難しいと感じた個所もあります。どんなツールもそうですが、思い通りに使えるようになるためにはそれなりに練習が必要ですね。

このツールの良いところは何と言ってもシンプルな点。商品やサービスの本質をズバリ表現することができます。トヨタ式のA3用紙1枚に通じるところがありますね。1枚の用紙に整理すると全体を一瞬で見渡すことができ、書き出した内容に違和感があればすぐにわかります。私もヒアリングを受けながら、ああかな?こうかな?と、出来るだけ端的に答えるようにしていましたが、インタビュアからの鋭い質問を受けて思わずウ~ンと唸ってしまう場面もありました。

次に、自分のビジネスモデルキャンバスをベースに課題を抽出するという演習を行ったのですが、演習用のシナリオが用意されていなかったため参加者のリアルな課題を共有することが出来ました。私の場合も課題だと思っていたことが真の課題ではなく、実は別に課題があったという発見もあり、まさにツールの効果を実感したところです。ビジネスモデルキャンバスは、顧客(相手)の現状を把握して課題を抽出し、新しい戦略を描いていくという目的だけではなく、自分自身のビジネスを振り返る目的にも使えるということが分かりました。そういう意味では今回の研修が、これまで受講したITコーディネータのどの研修よりも有意義でした。


アイティ経営研究所
http://www.itbizlab.jp/

「見える化」というプロマネの仕事

「プロジェクトマネージャ(PM)の目的は何か」という問いには人によって表現は微妙に異なると思いますが、およそ「成功裏にプロジェクトを完了させること」ということになるでしょう。では「その目的の為にPMが行う作業(=手段)は何か」という問いにはどのように答えるでしょうか。もちろん、これも人によって、特に業種・業態やプロジェクトの特性によって表現は異なると思いますが、私が一言で答えを問われた場合には「見える化(=可視化)」と答えます。

もちろん、PMの仕事というのは究極的には「成功裏にプロジェクトを完了させるために、あらゆる手を尽くす」ということになるのですが、「あらゆる手」に共通するポイントというのが「見える化」なのではないかと考えています。とはいえ「見える化」して終わりという意味ではなく、「見える化」するところから始まるという意味です。念のため。

プロジェクト管理手法というのは数多あるのですが、どれもが管理すべき対象を見えるようにして状況を把握し、様々な手を打つための判断の手助けをしてくれるものだと私は理解しています。例えば、計画の見える化、タスクの見える化、スコープの見える化、スケジュールの見える化、コストの見える化、品質の見える化、リソースの見える化、リスクの見える化、コミュニケーションの見える化…などです。

なので、プロジェクトをマネジメントする立場に就いた場合には、いかなる形式であろうと、これらを「見える化」する、つまり具体的なドキュメントに落とし込むかツールに入力・表示するというところから始める必要があるということです。こういった作業は面倒くさいものですが、「見える化」する作業を省略していったい何をマネジメントするというのでしょうか。

よく、頭の中にはあるから(アウトプットしなくても)大丈夫だということを主張する人も見かけますが、実際にアウトプットしてみると意外と出来ないということが分かると思います。脳内に記憶できる情報量も限られているそうですので、全てを同時に、かつ瞬時に把握し合理的な判断を下すというのはどう考えても無理があります。まして、プロジェクトでは日々想定外の問題が発生し、常に合理的な判断を求められるのです。そのためにいちいち思い出しながら進めるというのは効率が悪すぎます。それにもしそのうちのいくつかを思い出さなかったとしたら、それはどういう結果を招くでしょうか。

ここまでプロジェクトマネジメントのイメージで書いてきたつもりですが、改めて考えてみると一般的な組織のマネジメントにも当てはまるのではないかと思っています。もちろん経営者は判断するのが仕事ですが、瞬時に的確な判断を行うために「見える化」が必要なんだと理解しています。


「図解 使える失敗学」畑村洋太郎 著

IT業界で仕事をしていると、様々なことが技術的な問題として片づけられやすいのですが、実際には人の問題であり、突き詰めると組織の問題だったということが往々にしてあるものです。担当者によってスキルはばらつきがあると思いますが、個々の担当者はレベルが高いのに失敗が起こるとしたらそれは組織の問題と捉えて良いだろうと考えています。

多くの場合に失敗は現場で顕在化するため、組織は現場の問題として片付けたがる傾向がありますが、もし問題の根っこがプロセスや組織にあるとしたら、現場の問題、個人の問題として扱っている限りは失敗は無くならないでしょう。それ以上現場の担当者を責めても励ましても効果は上がらないと考えるべきです。

「失敗学」といえば元々は製造業界や建築業界で発生した事故の分析というイメージがありますが、今ではそこに留まらず幅広く組織で発生するトラブルを分析されているようです。本書は、失敗学を紹介する本ではなく、そんな失敗学の研究の成果を個人レベルで実践できるようにアレンジされたものです。見開きで右ページの本文と左ページの図解がセットで1つのトピックとなっており、読み進めやすく構成されています。

大まかな章立ては次の通りです。

  1. 失敗との向き合い方(個人レベルでの)
  2. 失敗の発生原理と知識化
  3. 失敗からの学び方(失敗を成功に変えるには?)
  4. 失敗学を組織に応用する方法

こうして見ると、最初は確かに個人レベルの話なのですが、最後は組織レベルの話になっています。担当者一人一人が担当者としてスキルアップすることが、必ずしも組織としてレベルアップすることと等価ではなく、行きつくところは組織レベルでの取組みが必要だと理解しました。本書にもあるように「組織としての失敗対策はトップダウンしか為し得ない」ということです。

失敗についての情報はどうしてもネガティブなものとして捉えられ、蓄積や活用が進みにくいものです。特にトラブルの直接的な引き金になった担当者であれば尚更だと思います。そういうこともあり、組織のトップが率先して現場の失敗情報を吸い上げ、それをまた各現場に下ろして組織全体に行き渡らせるといった取組みが必要なのだと考えています。


書名:図解 使える失敗学
著者:畑村 洋太郎
発行:中経出版/2014年7月31日
ISBN:978-4-04-600238-9

限られたリソースで最大の効果をもたらすトリアージ

もう随分前になりますが、このブログの中で「デスマーチ」そして「パーフェクトソフトウェア」という2つの著作をご紹介したことがあります。両者に共通するポイントはリソースは有限であるため全てのバグを取り除くことができないという点と、その有限のリソースの中でバグをどのように分類し優先順位を付けて対応するかという点であろうと思います。いずれもソフトウェア開発に関する著作ですので「バグ」が対象にはなっているのですが、もっと広くプロジェクトマネジメントという観点に引き上げてみると、バグだけではなくバグ対応を含めたToDoの捌き方のアドバイスということになります。

前者の「デスマーチ」ではトリアージという戦争時における負傷者救護の優先順位づけのアイデア(これは今の災害時の救急医療現場でも活用されているようです!)を紹介していますが、後者の「パーフェクトソフトウェア」ではトリアージを実践するための具体的なバグの分類方法を提案しています。当時のブログ記事の中でも私なりにアレンジした分類方法をご紹介しましたが、今回はより進んだ分類方法をご紹介します。

システム開発では、開発中のシステムに対する仕様の変更や追加の要求が出されることが良くあります。要求を出す方としては当然のことながらすべてに対応してもらいたいと思うものですが、要求を受ける方としても当然のことながらプロジェクトとして実施している場合は納期も予算もありますので(これがリソースが有限であるということの意味ですが)出された要求の全てに応えることができないという状況に陥ることがあります。

そんな時、要求を一覧化して対応するかしないかを選別しても良いのですが、もっと明確な基準があると判断にも迷わないですし、なされた判断も客観的で納得感が出てくると思いませんか。例えば、次のような分類を考えてみましょう。

レベル0:そもそも技術的に不可能であり、対応できない要求
レベル1:対応できなければリリース延期またはプロジェクトを中止する要求
レベル2:リリース時に無くても良いが、対応しないと業務に支障のある要求
レベル3:可能なら対応したいが、対応しなくても止むを得ない要求

これらの分類をするだけでも客観的な評価となり得ますが、次のような設問フローを作るとより客観的で論理的な判断を下すことが可能になり説得力が増します。

トリアージの判定フロー

(1) 要求が技術的に不可能であるか。
[Yes⇒レベル0/No⇒(2)へ]
(2) 対応されなければリリース延期するか。
[Yes⇒レベル1/No⇒(3)へ]
(3) 対応されなければ業務に支障があるか。
[Yes⇒レベル2/No⇒レベル3]

判断をするときには設問に答えていくだけで客観的な優先付けを行うことができ、レベル0は除外して優先度の高いものから残されたリソースの範囲で対応できるものを決定していくことになります。これも救急医療現場で使われるABCDEアプローチのようなもので、判断を急ぐときにはシンプルで強力なツールとなります。分類の数が多くなっても設問を増やすだけで良く、状況に応じてアレンジもしやすいです。


東京都福祉保健局によるトリアージの説明

かんばんボード(タスクかんばん)のレーン設計

以前、かんばんボードを導入する肝はレーンの設計にあるということを述べたのですが、では具体的にどのようにレーンを設計すべきかというテーマについて考えてみたいと思います。

レーンとレイヤーのイメージ

レーンとレイヤーのイメージ

その前に、レーンをさらに横のレイヤーに区切って使うかどうか迷うと思いますが、個人で導入する場合はともかく、チームで導入する場合にはレイヤーに区切った方が良いです。また、区切るとしてもメンバー毎のレイヤーとするか案件毎のレイヤーとするか迷うのですが、案件毎にした場合、時間の経過による案件の増減に合わせてレイヤーを増減させなければならず、それはそれで運用に手間がかかります。メンバー毎のレイヤーにしておけば案件の増減に比べればメンバーの増減は少ないと思いますので、比較的手間はかかりません。それとメンバー毎としておけば、メンバーの生産性と抱えている作業量についてもある程度可視化できるので、チーム運営はしやすくなります。

そうはいってもメンバー毎のレイヤーにすると、案件ごとの状況が見えなくなってくることがあります。(だから案件毎のレイヤーにしたいという衝動に駆られるのですが。)私はタスクかんばんは目の前の仕事を片付けるためにチーム運営を円滑化するツールだと理解しているので、案件毎の進捗管理などはWBS(ガントチャート)のような全体を俯瞰できるツールを使って補う方が良いと考えています。

オーソドックスなレーン設計はToDo、Doing、Doneです。ToDoはやるべきことで未着手のタスク、Doingは現在仕掛中のタスク、Doneは仕上がったタスクです。タスクを付箋に書き出し、ステータスが変化するごとに貼るレーンを変えていきます。あるいはチーム内で完結する現場であればこれだけで事足りてしまうかもしれません。週次でマイルストーンを決めてToDoに落とし込み、週末にToDoが全て捌けてDoneに移動していればよいのです。週末(または週の頭)にはチームでミーティングを行い、翌週(または今週)やるべきタスクを棚卸してToDoに貼り付けていきます。

しかし、業種業態や活動の目的によってチーム外の関係者の多少が違うので一括りには出来ません。チーム内だけで完結しない場合、先ほどの3つのレーンだけでは管理できない局面があります。それは、チーム外の関係先に依頼するような場合、こちらの都合ですぐに返事があるわけではありません。つまり相手のタスクが終わるのを待っている状態、自分ではなく相手がボールを持っているということを表現する必要があります。そのタスクを例えばWaitingのように表します。

また、逆にチーム外の関係者から依頼を受けるパターンや、自分が完遂した作業を確認してもらったり承認してもらったりするパターンがあると思います。既に自分の手を離れていて、最後の確認や承認を待っているという状態です。そのタスクを例えばFinishingのように表します。ここまではメンバー毎のタスクです。


かんばんボード(タスクかんばん)導入の肝

タスク管理の手法というのはいくつかあると思うのですが、その中の一つに「かんばんボード」(あるいはタスクかんばん、タスクボードとも言うらしいですが)という見える化によるタスク管理手法があります。基本はアナログですが、タスクかんばんを実現するアプリも存在するようです。

かんばんボードの原理は簡単で、チームが持っているタスクを全て付箋に書き出してホワイトボードに貼り付けるのですが、ステータスによって貼り付ける位置を変えていくというものです。でも、これを本格的に取り組もうと思っても教科書的なものが見当たらない。ネットで調べると多少それらしきものは見つかるのですが、いざ取り組んでみようと思うとなかなか難しいのではないかと思います。

やってみると分かるのですが、実はかんばんボードを使いこなす肝はレーン(ステータス)の設計ではないかと思うのです。レーンというのはボードを縦に区切った言わば列のことで、通常はステータスを割り当てています。(但し、必ずしも列という形にこだわる必要はなく、自由にレイアウトを決めて良いと思います。)Redmineなどのタスク管理ツールでタスクを管理する時もステータスの設計が使い勝手に影響してきますよね。

例えば参考になるのが以下のサイト。
Web開発チームをタスクボードだけで見える化する 5つのコツ
http://engineer.blog.lancers.jp/2012/07/task_board_tips/

文献を見る限り一番オーソドックスなレイアウトはToDo、Doing、Doneという3つのレーンで区切る方法。ですが、杓子定規にこれを運用する必要はなく、現場の判断で変えて良いと思いますし、変えていくべきです。タスクのステータス設計にはどんな業務を対象とするかによっていくつものバリエーションがあり得ます。例えば開発現場でも設計工程と開発・テスト工程とでは管理すべきタスクが異なりますよね。

まずは導入しようと思う時に、この現場ではどのようにステータスを管理・運用しているかということを分析することになります。業務によっては併せてワークフローの設計もした方が良いケースもあります。具体的なステータス設計の例は追々ご紹介できたらと思います。


マネジメントは家康の精神で?

まだ私が独立したての頃、私の師匠に呼ばれてある会社の技術支援をしたときの話です。会社員時代には自分の作業をいかにスケジュール通りに行うかということが主な関心事でしたが、その時初めて他人に作業をお願いするという経験をしました。

会社員時代には部下を持ったことがありませんので、正直なところそれがどれほどの苦労を伴うかというのは知りえないのですが、独立してからのそれというのは、相手は自分にとって顧客という立場だということで一層難しく感じられました。

仮に相手が自分の部下だったとしたら、その立場を利用して尻を引っぱたき、半強制的に作業をさせるということが出来るかもしれないのですが(実際にそうするかどうかは別として)、少なくとも相手が顧客だとそうはいかないですよね。

そんな時、師匠が面白い話をしてくださいました。それは「家康の精神で取り組む」ということ。初めはさっぱり意味がわからなかったのですが、後になってどうやらこういうことらしいということが分かってきました。

  • 信長:殺してしまう → 作業を取り上げる
  • 秀吉:鳴くまで待つ → 作業が終わるまで待つ
  • 家康:鳴かせてみる → 何とかして終わらせる

つまり人に割り振った作業というのはあらゆる手段を使って作業を進捗させるべきで、その為に色々と工夫をすべきだということです。

これはまた別の現場での話ですが、マネジメントする立場の方が会議の場で作業者の進捗状況を尋ね、たとえそれが間に合いそうにないという時でも、作業者の言い分を鵜呑みにしてそれをそのまま上司に報告するだけというパターンを目撃したことがあります。しかしそれでは目的は達成されないわけで、マネジメントする立場であれば期限通りに仕上がるように手を打たなければならない。もう過去のことですがそんなことをつい最近のことのように思い出しました。


そういえば、良いルールって何だろう?

世の中にはルールと呼ばれるものがいっぱいあります。規則や規定なども含めるともっといっぱいありますよね。中には「何でこんなルールがあるんだ!」と叫びたくなるようのものもあると思います。では、良いルールってどんなルールなんでしょう?診断サービスの企画を練っていく過程でそんなことがふと頭をよぎりました。

ルールと言っても、社会一般におけるグローバルなルールから、学校や家庭内のローカルなルールまで様々ですが、ここでは主に会社など組織のルールについて考えてみたいと思います。組織のルールと言ってまず思いつくのが「就業規則」ですが、もっともっと身近な業務ルールや作業手順まで範囲を広げてみましょう。

私が様々な現場にお邪魔してよく聞かされる話として「ルールはあるけど守られていない」というものがあります。なぜ、ルールが守られないのでしょうか。あるいはなぜ、守られないルールが存在しているのでしょうか。表面的には様々な理由が考えられますが、一つ思いつく根本的な理由は「ルールが現実的でない」あるいは「合理的でない」というものです。

そこから出てくる言い分は、例えば「ルールを守りたいのはやまやまだが、いちいちルールを守っていたら作業効率が低下する」とか、「こんな不条理なルールには従う必要はない」とか、「守ったところでどうにかなるものではないし、今のやり方で問題ない」など、捉え方は人それぞれだろうと思いますが、こういうのを一括りにして従業員のモラルの問題として片付けてしまいがちではないでしょうか。

仮にそうだとしても、それで従業員のお尻を叩いたり、鼻先にニンジンをぶら下げたりしても効果が出るものではないでしょう。今の私の考えでは、良いルールというのは「守られるルール」、逆に悪いルールというのは「守られないルール」だと思っています。

確かに、組織を運営するに当たっては組織ごとに「あるべき姿」あるいは「あるべきルール」というものがあるでしょう。しかし、それを全てそのまま実際のルールとして運用しようとしてしまうと、組織の成熟度によっては理想と現実のギャップが大きすぎるということが起こり得ます。

一般的なマネジメントシステムにおいては、ルールというのは一回作って終わりというのではなく、状況の変化に応じて適宜見直していくものとされています。ですので、組織の成熟度に応じて守れる大きさのルールから始め、それが守れるようになったらルールを改定し、それを繰り返すことで「あるべき姿」に近づけるといった工夫が可能です。

「あるべきルール」という目標を大きく持つことは大切なことですが、そこへ一足飛びに到達することを考えるのではなく、「守れるルール」という中間目標を細かく設定し、達成状況をウォッチしながら徐々に前進していければ良いのではないでしょうか。


「人気店はバーゲンセールに頼らない」齊藤孝浩 著

本書はインディペンデント・コントラクター協会の理事のお一人である齊藤孝浩さんの著作です。齊藤さんはいわゆるアパレル業界のコンサルタントで、商品陳列や適正在庫といったカテゴリでご活躍をされている方です。個人的にはいつもIC協会のイベント等でお世話になっております。

本書は誰もが知っているような国内外のアパレルチェーンにおける成功事例を集めた本です。私はアパレル業界には疎いのですが、そんな人でも本書を読めばアパレル業界のトレンドに詳しくなり、明日からでもアパレルチェーンを展開できてしまうのではないかと錯覚してしまいそうになるほど具体的なノウハウが詰まっています。もしかしたら業界内では普通に知られていることばかりなのかもしれませんが、ブランド名を明示しているので外の人間からするとそんなことまでバラしちゃっていいの?と思ってしまいます。明日は用も無いのにZARAに行ってみたくなりました。(実はまだ行ったことありません。)

さて、私が本書を読んで感じたポイント。それは本文でも触れられていることなのですが、成功する秘訣は業務のサイクルの短さだということ。いわゆるPDCAを週単位で回せるというのは月単位、四半期単位、半期単位で回している企業にとっては脅威でしょう。また、本書では言及されていませんが、ここに挙げられた事例は制約理論(TOC)を実践した実例なのではないかと思われます。特に、エリヤフ・ゴールドラット博士晩年の著作である「ザ・クリスタルボール」。そのテーマはまさに小売業における適正在庫であって、そこに書かれていることを実践したとしか思えません。

本書は、今まさにアパレル業界で働いている人はもちろん、これからアパレル業界で働きたいと思っている人にとっては必読の書ですし、直接関係ないと思われる人でも本書にはビジネスにおけるヒントを多く得られると思います。また、特に女性の方に対しては、本書を読めばまた違ったショッピングの楽しみ方が出来るのではないかと思います。まずは是非手に取ってみてください。

あと、私の関心は本書の内容を逸脱して、成功した企業が行っているオペレーションが素晴らしいだけでなく、このようなオペレーションを可能にした組織がありますが、そのような組織を作り上げたその方法論を私は知りたいと思いました。また、成功に至る判断のためには迅速で的確なフィードバックが不可欠ですが、その背後にはそれを可能にした情報システムがあるはずです。それらがどのようなシステムなのか、どのような処理でどのようなアーキテクチャなのかということにも興味が及びました。そういったチームビルディング、システム設計といった側面を取り扱った姉妹編が出版されたら間違いなく買ってしまいますね。

――――
書名:人気店はバーゲンセールに頼らない
副題:勝ち組ファッション企業の新常識
著者:齊藤孝浩
発行:中央公論新社/2013年4月10日
ISBN:978-4-12-150451-7


ファッション流通ブログde業界関心事 (齊藤さんのブログ)