プロダクトマネージャーに訊く #7:シャノン堀さん

このエントリーをはてなブックマークに追加
こんにちは、堀です。先日、インタビューをしていいただいたので、そちらの記事を技術ブログにも転載したいと思います(元ブログのオーナーの丹野さんには快く転載許可をいただきました!)。
ブログ当番だけど書く時間がなくて転載したとかそういうわけではありません。。
------
― 堀さんご自身について教えてください。
株式会社シャノンのCTOの堀です。技術部門のマネジメントをしています。
開発のディレクションと製品企画のディレクションを両方担当していますが、製品企画のほうがウェイトが大きく、7割ぐらいの時間を製品企画側の仕事に費やしています。どんな製品をつくるべきか、どういうプロジェクトチームでいつまでにリリースするのか、といったプロダクトマネジメント全般を他のプロダクトマネージャーと一緒に行っています。
― プロダクトの開発体制を教えて下さい。
現在シャノンの社員数は150人ほどですが、開発部門はQAチームを含めて約25人、インフラチームが約5人、プロダクトマネジメントを行う製品企画チームが4人、といった構成です。上海にも開発拠点があります
プロダクトマネージャーは各スクラムチームのプロダクトオーナーの位置づけで、要件の優先順位の決定やスプリントのレビューを行っています。私自身は各プロダクトマネージャーをフォローしつつ、個別の開発プロジェクトを俯瞰した製品戦略を考えて、MRD(Marketing Requirement Document)を整理するような役割をしています。
テクニカルな内部仕様は開発マネージャーやエンジニアが作成します。設計の方向性が大きく異ると感じた時は指摘しますが、基本的には開発現場に任せており、私はプロダクトマネジメントに時間を割いて製品の競争力強化のプランニングに注力しています。

MBAセミナーで意気投合、大手外資から15人のベンチャーに

― シャノンに入社する前はどのような仕事をされていたんでしょうか?
シャノンには約10年前の2005年の末に入社したのでが、その前は新卒で入社した日本オラクルでエンジニアをしていました。最初の数年は国際化のQAエンジニアを担当して、その後、アプリケーションサーバソフトの不具合に関するエスカレーションをハンドリングして修正パッチを書く、といった仕事をしました。外資系のソフトウェア企業の場合、製品に不具合があって顧客が困っていても本社以外では不具合を修正できないことが多いんですが、日本オラクルの場合は国内のエスカレーション対応部隊がコードを書いて問題を解決することができました。
その時の得たオラクル本社のソフトウェア開発手法とWebアプリケーションのバックエンドの技術的な知識はシャノンに転職してからもすごく役に立ちました。
― ミドルウェアの外資ベンダーから、マーケティングソリューションの会社に移ろうと思ったきっかけは何だったのでしょうか?
より製品開発のコアに関わる仕事をしたいと考えるようになったのです。オラクルでは不具合を改修するパッチを書くことは出来ても、製品そのものを開発するためにはアメリカにいかなければなりません。シリコンバレーのオラクル本社に行くか、日本でベンチャー企業に転職するか、など色々と考えながら情報収集をしていました。当時B2Cでは楽天やライブドアなどのWebサービスのサイトが一般的になってきており、「これからはB2Bでもパッケージ・ソフトではなくWebサービスの時代だ」と思っていました。
また、技術だけでなく経営やビジネスにも興味を持ち始めていて、MBAをの取得も検討していました。ただ、数年間大学院に通うための時間的金銭的コストを回収できるだろうかという懸念もありました。そこで、まずさわりだけでも勉強してみようと思い、MBAで得られる知識の一部である企業価値評価に関するセミナーを見つけて、1泊2日で参加することにしました。
そのセミナーでたまたま隣に座っていたシャノンの現CFOの永島と意気投合して、シャノンに入社することになりました。まだシャノンは15人くらいの会社で、まだクラウドやSaaSのような言葉もなくASPと呼んでいた時代です。「自社でイベントやマーケティングのソリューションをASPで提供していてる。エンジニアも7、8人いるから一緒にやらないか」と誘いを受けて入社することにしました。
― 外資系の大企業から15人のベンチャーに飛び込むことに不安はありませんでしたか?
特に不安はありませんでしたね。グローバル企業で働くなかで、日米でエンジニアのスキル差を感じることはありませんでしたし、トップオブトップのエンジニア達の概念設計スキルは別として、個別のコーディングスキルは日本人のほうがクオリティ高いし負けている感じはしない。うまくやれば海外の企業にに負ける要素はない、と当時思っていました。それは今でも変わりません。
シャノン入社直後は、プロジェクトマネージャーとしていくつかの案件を担当して開発プロジェクトのマネジメントを行っていました。当時は代表の中村がまだ自らコーディングしていたんです。中村がコーディングせずに社長業に専念できる体制をつくるのが最初の役割でした。
以来、開発プロジェクトのマネジメント、開発部門の組織づくり、製品の戦略やコンセプトづくり、仕様策定などを継続して行っています。
― 役割がエンジニアリングからプロダクトや組織のマネジメントにシフトしていくあたって、苦労した点はありますか?
オラクル時代に製品をゼロから作ったり大きな機能追加をしたりという経験があったわけではないので、色々と苦労はしました。特に「企画して開発してリリースする」という製品開発のプロセスと、「世の中に製品を知ってもらって販売する」という営業・マーケティングのプロセスのバランスをとりながら仕事を進めていくのが難しかったですね。今でもここは大きな課題だと思っています。
最初からマーケット・トレンドを広くとらえながら戦略的に製品を企画できたわけではなく、とにかく目の前のお客さんの要望に応えながらどうユーザーを増やしていくかを考えていました。現実的な目前の話と、抽象的な概念の話を行き来しながらあるべき方向性を見出していく、という行為をひたすら繰り返してきました。

再現性の高いBtoBマーケティング活動を実現する

― シャノンさんの製品について教えて下さい。
マーケティングオートメーションを軸とした、マーケティング統合環境を提供しています。マーケティングオートメーション製品はたくさんあるのですが、弊社の場合は展示会などのイベント管理ソリューションから発展した製品のため、オンライン・マーケティングとオフラインのイベントやセミナーを統合的に管理できるのが特徴です。
日本ではイベントやセミナーを重要視する顧客がとても多く、マーケティング活動をオンラインだけで完結できません。むしろオフラインのほうがビジネス上重要だというケースも多くあります。そうした企業様の課題を解決するソリューションを展開しています。プライベートショーや大規模展示会のバックエンドとしても利用できるのが特徴です。
また、BtoBマーケティングで効果をあげるには、ITシステムに加えて営業とマーケティングの組織改革をセットで考える必要があり、ITソリューションとコンサルティングの提供を同時に行っています。
我々は「マーケティング・イズ・サイエンス」というミッションを掲げており、再現性の高いマーケティング活動の実現を目指しています。BtoCを中心としたオンライン・マーケティングは定量的に効果測定をしやすくなり再現性が高くなってきていると思いますが、オンラインとオフラインを統合する必要があるBtoBマーケティングについては、まだまだケースの数も不十分で再現性が高い手法が確立しているとは言えない状況です。
どうすればデータ・ドリブンで再現性のあるモデルを構築して顧客にマーケティング・ソリューションとして提供できるのか、これが私たちのプロダクト開発の中心テーマです。
― 競合サービスとの違いを教えて下さい。
例えば、北米のマーケティング・オートメーション製品の場合、企業と顧客が地理的に離れていることが前提となっています。メールやサイトで資料請求を受け付けて、Webinarでサービス説明をして、ビデオチャットや電話で商談を進める、といったようにオンラインでマーケティング活動や営業活動が完結することを想定した設計になっていることが多いのです。
一方で人口密度が高い日本の場合、セミナーを開催して参加者の名刺を収集し、すぐに営業担当が見込み顧客を個別に訪問して詳細な説明を行う、といったように商習慣やプロセスが全く異なります。マーケティングの効果測定をするためには、そうしたオフラインの活動を含めた活動をトラッキングする必要があります。
私たちの製品は、セミナーの申し込みフォームを作成する、顧客リードに対してメールを配信する、営業担当者の営業活動によってセミナー参加者を獲得する、といったプロセスをトラッキングし、最終的にどれくらい商談に結びついたか分析できる仕組みになっています。
Webサイトやメールなどオンラインのアクティビティと、セミナーや名刺交換などのオフラインのアクティビティを統合してトラッキングできるのが我々シャノンのサービスの特徴です。オンライン広告のアトリビューション測定と同様に、オフライン活動の売上貢献度の測定も誰もができるようにしたいと考えています。
また、海外ベンダーのサービスは「マーケティング・オートメーションはこうあるべき」というベンダー個別の思想にユーザーが合わせるものが多いのですが、弊社の場合はあるべき姿を示しつつ、現状の業務プロセスに適応できる柔軟性をシステムに持たせています。
マーケティング・サイエンスの最初のステップは、結果を数値で見るようにすることです。実はBtoBマーケティング活動の成果について、KPIをしっかり定義できている企業はまだ少ないんです。KPIを定義して測定し、マーケティング活動の内容と結果の因果関係が明確になり、そして最終的にマーケティング活動を自動化する、という3つのステップを順番にクリアしていく必要があります。
― お客さんはマーケティング部門の方が多いんでしょうか?
マーケティング部門以外の方も多いですね。例えば営業部門や経営企画、新規事業部門などの方も多いです。私たちの顧客企業に関わらず、一般的に「10年以上マーケティング担当をやっています」というような方は少数です。「去年までは営業部門にいて、今年から異動でマーケティングを担当することになった」といった方がマーケティング部門には多いのです。BtoBマーケティングのソリューションは、そういった方でも使いこなせるプロダクトであることが求められます。
BtoBマーケティングは、リストにメール配信して終わりではありません。営業と連携してターゲット顧客の定義の認識を合わせながら、成果に結びつくようパイプライン管理する必要があります。そうしたあたりまえのプロセスをきちんと回して結果を出せるようにするのが我々のソリューションです。
ものが売れない時代だと言われて久しいですが、製品を作って営業をすれば売れた高度経済成長期とは違って、プロダクトの価値を正しく伝えて、ソリューションとそれを求めている人を正しくマッチングすることがとても大事です。それができれば企業は新規市場を開拓できて利益を生むことできます。
― BtoBマーケティングにはIT化されていないプロセスが多そうですね。
はい、BtoBのマーケティング活動には、まだまだ人的労力を必要とする部分が多いのです。例えばセミナーを開催するためには、会場の確保、顧客リストを抽出、案内メールの配信、申し込み管理、など様々なタスクの実行が必要です。担当者がそうしたオペレーションで精一杯になり、イベントを開催することが目的化してしまいがちです。その結果、頑張ってセミナーを開催して100人集客したにも関わらず、営業担当からみると全く価値の無いリードになっている、といったことも往々にしてあります。セミナー開催後に営業担当が個別にアプローチしても全く響かない。求めていないソリューションを営業されるお客さんも迷惑ですよね。労力をかけてすごく頑張っているのに誰もハッピーにならない。
オペレーショナルな部分の労力を最小限にすることで、「誰に何を伝えるべきなのか」という本来やるべきマーケティングのコアな部分に注力できるようにすることで顧客が利益を生み出せるようにすることが、一番大事な我々のミッションだと思っています。

顧客のペインポイント、課題を抽出する

f:id:tannomizuki:20160830082316p:plain
― 顧客の課題が解決できるよいプロダクトを作っていく上でどのような工夫をしていますか?
まずは顧客のペインポイントは何か、本当にしたいことは何なのかを理解することです。お客さんと話す時でも、社内で議論するときでもありがちなのが「こういう機能を追加して欲しい」という機能の話が中心になってしまうことです。何を作るかではなく、その機能が必要な理由、顧客が抱える課題の話にフォーカスするように注意しています。
プロダクトマネージャーに相当する人が不在で、事業側の声が大きい人の意見に引きずられていたり、逆に開発チームだけで閉じてしまっているプロジェクトはうまくいかないですね。そうしたプロジェクトでは、どんな機能が必要かという話ばかりが先行していて、なぜユーザーはその機能が必要なのか、ビジネス上のどんな必要性があるのかが曖昧なまま開発が進行してしまう。
また、「本当にお金を払ってまで解決したい課題なのか」を問うようにしています。お金払ってまで解決したいのかどうかで、痛みの深さを大別できます。解決しないとビジネスが回らないほどの課題なのか、今よりちょっとベターになるという程度の話なのかに分類することで優先順位を検討しやすくなります。
― 機能要望から課題を特定するためにはどうすればいいんでしょうか?
単純に「なぜ」を繰り返すことです。その機能がなぜ必要なのか、社内で要望を出した営業担当もわからない、実は要望元のユーザーも言語化できていない。ユーザーの上長に確認して初めてわかる、ということもあります。
顧客へのインタビューを行って、営業スキームや営業部門とマーケティング部門との関係性、部門ごとの課題、サービスの利用状況、などビジネス・プロセスや組織構造の全体像を紐解いていく必要があります。組織的な課題に目を向けることで、要望の背景を理解することができます。
例えば「このデータをCSVで出力できるようにして欲しい」といった要望があった時には、「出力して何をするんですか?」と聞くと、「CSV出力してExcelで集計した結果を営業に渡したい」といったデータ出力の目的がわかります。であれば、営業担当に直接データを共有できるようにしたほうがいいですよね。最終的に実施したいアクションに直結する機能を提供したほうが業務効率がアップします。
全ての要望に対してそこまで深くヒアリングできないので、推測で進めることも多いのですが、課題に関する仮説をたてて仕様やコンセプトを決めることが重要です。
― 堀さんが直接お客さんにヒアリングされることも多いのでしょうか?
はい、定期的に既存顧客へのヒアリングをするようにしています。組織が小さかった頃は商談やアフターフォローに同行することが多かったんですが、最近はそういう機会が減ってきたので、意識して顧客訪問の機会を作っています。
― ヒアリングはどのように進めているのでしょうか。
顧客インタビューについてはAtrasianで利用されているフォーマットが参考になります。
このフォーマットでは、観察結果の伝達、問題の解釈、機会への接続、という3つの項目にわけてインタビュー結果を整理します。
私がインタビュアーになってお客さんに質問して、同行した製品企画部のメンバーがフォーマットに基いてヒアリング結果を整理します。毎回とても気づきが多いですね。自分たちの製品が実際にどう使われているのか、実際の利用シーンでどのような課題があるのか、具体的に見えてきます。
― BtoB製品の場合、営業担当から「大手のA社がこの機能があれば買うと言っている」といった機能追加のリクエストが出ることも多いと思いますが、そうした案件固有の要望に対してはどのように対応していますか?
以前はそうした機能要望にも対応するようにしていたのですが、最近は機能追加をすれば売れるというような案件はすごく減ってきていますし、営業提案でカバーできるものについてはそうしてもらうようにしています。もちろん、大手顧客からのリクエストが他の顧客にも大きく役立つ場合などは前向きに検討しますが、それよりもBtoBマーケティングのあるべき姿を強く打ち出せるような、メッセージ性のある戦略的な機能開発にウェイトが移ってきています。

プロダクト発表イベントから逆算して発想する

― ユーザーヒアリングによって様々な課題が抽出されると思いますが、そこからどのように製品コンセプトに落とし込んでいくのでしょうか。どうやって着想を得ていますか?
最近弊社のプロダクトマーケティング担当が取り入れているのがキーノート・ドリブンの発想法です。例えば1000人の前でプレゼンをするとしたら、どういうビジョンや機能だったら聞き手に響くだろう、と想像して実際に発表資料を作ってみます。冒頭で社長がプロダクトの思想やビジョンを発表して、その後に自分が機能の詳細を説明してデモをする、という具体的なシーンを想像してみます。どんなプロダクトだったら聴衆にインパクトを与えられるだろう、というところから逆算して発想するのです。
Amazonでは製品開発の前にプレスリリースを最初に書く、という話を聞いたことがあるかもしれませんが、それと同様の手法ですね。
プレスリリースでも一度試したことはあるんですが、日本の典型的なプレスリリースのフォーマットだとイマジネーションがわきにくい。キーノートの方が「なぜこのプロダクトが顧客にとって重要なのか」というストーリーを整理しやすいですし、作り手であるエンジニアにもビジョンを共有しやすいと感じています。既存機能の改善ではない、大型の新機能の企画の際にこのやり方をしています。
― 着想を得た後は、どのようなプロセスで製品企画を進めていますか?
製品企画は2ページ程度のMRD(Marketing Requirement Document)からスタートします。Inspiredという書籍で「プロダクトに関する10の質問」という、なぜ今このプロダクトを作るのかを問うチェックリストが紹介されています。
  1. 製品化によって具体的にどんな問題を解決するのか? (バリュープロポジション)
  2. だれのためにこの問題を解決しようとしているのか? (ターゲット市場)
  3. 市場の大きさは? (市場規模)
  4. 製品化の成功をどうやって評価するのか? (指標、収益戦略)
  5. 現在、他に競合する製品はあるか? (競合の見通し)
  6. なぜ当社がこの製品化をやるのに最適なプレーヤーと言えるのか? (差別化要因)
  7. なぜ今なのか? (市場投入の時期)
  8. どうやって製品を市場に出すのか? (市場投入戦略)
  9. 成功のために絶対に必要な要素は何か? (ソリューションの要件)
  10. これらを前提とした上で、最終的な提案は何か?(やるかやらないか)
 このチェックリストを基にしたMRDのテンプレートを作りました。なぜやるのか、なぜ今か、どの市場向けか、ターゲットユーザーは誰か、開発コストはどれくらいか、といった項目を整理してMRDとしてまとめます。MRDをベースにビジネス的に価値がある企画なのか、経営陣と営業部門、マーケティング部門の責任者、そしてプロダクトマネージャーで議論します。
MRDが承認されたら、ユーザーストーリーの整理や画面設計を行って要件定義をし、アーキテクチャの概要を検討して開発スケジュールのアウトラインを作成して、PRDとしてまとめます。PRDが承認されると初めて実装に着手できます。
以前はMRDを作る前に数十ページに及ぶPRD(Product Requirement Document)を作成していたのですが、最初の一歩を間違えると、また数十ページのドキュメントを書きなおす必要がありました。まずMRDを作成することで、やるかやらないのかの意思決定を短期間でできるようになり、PRD作成の手戻りも無くなりました。
また、プロダクト開発とビジネスを網羅的に考えるフレームワークとして、プラグマティック・マーケティング・フレームワークを使うこともあります。
f:id:tannomizuki:20151221100826j:plain
横軸にストラテジーとエクセキューションの軸があって、上下にボックスが積み上がっていますが、上側がプロダクトマーケティング寄り、下側がプロダクトマネジメント寄りのタスクやプロセスになっています。これをチェックリストとして使うことで、バイヤーペルソナを考えたか、重要な販売チャネルを忘れていないか、デモサイトは用意したか、といったようにマーケティング活動の抜け漏れを確認できます。
― かなりプロセスが整備されているように見えますが、これからより強化したいポイントはありますか?
いくつかありますが、プロダクトが完成した後のプロモーションを企画の初期段階でどう詰めるか、という点はまだ試行錯誤しているところがあります。外向けのプロモーションもそうですが、弊社の場合は営業担当がサービスを販売するので、インターナルのプロモーションも重要です。リソースが限られているなかで、営業担当に新しいプロダクトや機能の魅力をどう伝えるか、企画の初期段階からどう巻き込むか、という点が手薄になりがちなので注意しています。

ゴールイメージを共有し、要件と技術的制約の妥協点をエンジニアと共に探る

― PRDを作成した後のプロセスで気をつけるべき点はありますか?
「プロジェクトだけを見て、プロダクトを見ていない」という事態にならないように注意をするようにしています。プロジェクトの進捗だけ報告を受けて、忙しさにかまけてプロダクトのレビューを怠ってしまい、蓋を開けてみたら想定と全然違うプロダクトになっていた、といった事態は避けたいものです。スクラムを導入していますが、最低でも週次でスプリント・レビューが必要です。
レビューをするのはプロダクトマネージャーだけに限る必要はありません。第三者が定期的にプロダクトを確認することでプロダクトの完成度が大きく変わります。開発に一定のリズムを作って、実際のモノを見るタイミングを作ることが大事です。
― 企画と最終的なアウトプットのずれが生じてしまうのはどうすれば避けられるのでしょうか?
最終イメージを文字面ではなくビジュアルで合意することですね。PMとエンジニアが同じ景色を共有できるようにする努力する必要があります。
エンジニアと企画サイドは言語に違いがあるので共有するのは難しいのですが、ゴールイメージを極力具体的なビジュアルに落として、同じ風景を見るようにすれば、レビューが少なくてもうまくきます。ただ、開発体制が大きくなってくるとそれもだんだん難しくなってきますね。特に弊社の製品はBtoBマーケティングのソリューションですから、エンジニアからすると製品の良し悪しの基準がわかりにくい。自分自身がユーザーになりうるECサイトのようなBtoCサービスであれば、「こういうカートは使いづらいだろう」と自分のユーザー体験をベースにあるべき仕様の議論がしやすいのですが、BtoB製品の場合はそれが難しい。だからこそ具体的にゴールイメージを共有する必要があります。
― エンジニアにゴールイメージを伝える上で、どういう点に注意すればいいでしょうか。
PMが仕様を噛み砕き過ぎてしまうと、エンジニアが「なぜ作るのか」を考えて創意工夫する余地がなくなってしまい、受託開発のようになってしまいます。要件を伝えて仕様はできるエンジニアに限り考えてはもらうようにしています。ただケースバイケースですね。PMが詳細な画面設計までしてしまうこともあります。いずれにしても、なぜやるのか、ビジネス上どんなメリットがあるか、という開発の趣旨をエンジニアが理解できるように気をつけています。
― ゴールイメージを共有した後のPMの仕事は?
要件を満たす上で技術的な課題がある場合は、PMはエンジニアと一緒に妥協点を探る必要があります。ビジネス側の理屈だけで要件を押しつけると、開発する側に負荷がかかって製品開発は滞ってしまいます。
また、将来の拡張性のために抽象度を上げて設計した結果、開発工数が増大してしまう、というのはソフトウェア開発でありがちな失敗です。技術的な観点ではすごく良い仕組みだったとしても、その「将来」というのはたいていの場合予期せぬ違った形で訪れます。会社の戦略を考えると確かにその拡張の可能性はある。でも往々にして次のプロジェクトでは方針が変わって別の要件の優先度が高くなり、拡張するより作りなおしたほうが早い、ということになってしまう。そうした過剰な開発をしないようにPMは開発チームと共に気をつける必要があります。
― どうすれば過剰な作りこみを避けられますか?
開発マネージャーには、今必要な要件にフォーカスをきっちり合わせよう、ただ変更はできるようにしておこうと話しています。抽象度を上げて拡張性を高めるのではなく、CIやテストの自動化によって変更に強い仕組みやアーキテクチャにしておこう、と。
これはシステムの設計上の話だけではなく製品企画も一緒です。「この機能は将来お客さんが必要になるかもしれない」という「いつか使う」系は大抵失敗しますね。

BtoBのインターネット・サービスはこれから益々面白くなる

― PMを目指す人にお勧めの本を教えて下さい。
シャノンに入ってすぐに読んでとても勉強になったのが、「売れるもマーケ当たらぬもマーケの22の法則」という本です。 
マーケティングというのは、製品機能の戦いではなく、商品の認知をめぐる戦いである。ユーザーのマインドシェアを何%獲得できるかが重要だ、という内容の本です。私はエンジニア出身なので、製品企画に関わり始めた時はマーケティングの知識が不足していました。4P(Product/Price/Promotion/Place)のような基本的な用語を聞いたことはある、という状態でした。この本はマーケティングについて学び始めた時に最初に読んだ本で、マーケティングの本質的な部分を理解するのに役立ちました。
定番ですが、プロダクトマネジメントについては「Inspired」は参考になります。その他には、「キャズム」「イノベーションのジレンマ」「エクセレントカンパニー」などはPMとして一度は読んでおいたほうがいいと思います。
本ではありませんが、新しい概念を学ぶ時にはSlideShareが便利です。調べたい単語で検索してスライドを3つぐらい読むと、短時間でおおよそのポイントをつかむことができます。
― 最後に記事の読者に伝えたいことはありますか?
我々と一緒にやりたい方を継続的に募集しています。日本ではまだまだ少ないBtoBのWebサービスを一緒に作ってくれる人、自分の力を試してみたいという人をお待ちしています。
マーケティングオートメーションの領域は変化も激しくて大変ですが、今すごい勢いで成長している面白いフェーズです。BtoCの世界も非常にビジネスとして面白いと思いますが、既にメガプレイヤーが多くてこれから競争に勝つのはすごく大変です。BtoBのWebサービスはこれから発展する市場なので、自分のアイデアを活かす余地が大きく、やり方次第で世の中に大きな影響を与えられます。ですから、自分の力を試してみたい人にとってはすごく向いている市場だと思います。
私は「何かを変えたい」「世の中に自分の足跡を残したい」と思いながらこの仕事しています。同じように感じていて、自分の思いを実現する場を探している方はぜひご連絡ください。
― ありがとうございました。
次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...