衝動買いなんてしません

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​プロジェクトマネジメントの学習​は

問題解決や要求の達成を掲げる

ソリューション業務の遂行を

チームで行うに際し、身につけるべき

ことのほぼ全てが凝集されています。


ところがこの”プロジェクトマネジメント”

20年ほど前に流行り始めましたが、

最近では定着したのか、言葉に新鮮味が

無くなったからなのか、新たに本を

出しても売れないためか、

めっきり入門書の類が減りました。


自分はこれまでの経験から、どの年代に

対してもプロジェクトマネジメントは

有効だと考えています。


マネジメントは個人のために作用する方法論

ではなく、チームの総力を発揮し、将来に

繋がる方法論だと考えています。


その為、良い入門書をたたき台にして、

チームメンバー全員で現在までの業務を

振り返り、ありたい姿を描き、明日の糧に

したいと思い、入門書を探しました。



自分の体験談ベースの教育本を社内向けに

作る方法もあったのですが、どうしても

主観が入り偏向的になる可能性があることと、

近しい距離感にいる説明者の実体験談だと、

受講者が自分自身に置き換えて考える際、

妨げになると考えた為、敢えてニュートラル

な外部の本（入門書）を探すことにしました。



現在の自分のチーム

---

自分が纏めるチームは男女混合で22歳～48歳

までおり、中には外国人（日本語が喋れます）

もいます。


非常に個性あふれ、かつ優秀ですが、場当たり的

で苦労貧乏な側面も多く見られ、このままでは

ちょっとずるい人からいいように利用され、

正しく評価されず、苦労の連続になってしまい、

いざイノベーションに取り組む際、自由闊達に

羽ばたく能力を身につけられないと思います。


「場当たり的」という表現を使いましたが、

これには”どのような課題であっても、知らんぷりや

他人事にせず、真正面から取り組んで何とかする”

という意味です。


手前味噌ですが、素晴らしく責任感のあるメンバが

揃っています。


ただ、近年は労働問題（時間の問題）が厳しいため、

いつでも、なにがなんでも全てをやりきるという

ことを個人のゴールにはできません。


よって、より一層、上手なチームワークを

行わないと、引継ぎだらけで自分の責任の所在や

達成感、得られた知識などが偏ってしまい、

労働時間は少なくて済んだものの、個人が能力を

身につけられなくなってしまい、それでは

元も子も無いです。



教材（本）の選定

---

本の選定に際し、デマルコやワインバーグ、

ゼックミスタなどの著名人が書いた本でも

良かったのですが、新卒者と中堅を同じ場で

教育し、議論したかったので、もっともっと

取っつきやすい本を探しました。




・・・探し回った挙句、やっと良さそうな本を

見つけました。


『童話でわかるプロジェクトマネジメント』

一冊買って読んでみたところ、

まずまず良かったので、若手の分だけを自腹で

6冊ほど買って配布し、読んでもらいました。






しかし、この本、なかなかのネーミングです。


色づかいといい、表紙の絵といい、

取っつきやすそうです。

これなら新入社員でもokayです。

中堅どころも笑って取り組んでくれる

でしょう。



取り纏めるチームの担当業務

---

申し遅れましたが、自分は国内外の

ソフトウェア開発を20年以上やってきました。


ここ15年くらいはソリューションという

枠組みで全国各地やアジア圏に様々な

ターゲットがありますが、常に現場の

開発技術チームを受け持っているので、

浮世離れした開発企画などでは無く、

作成したソフトウェアは必ず1～2年以内に

現地投入し、国内外で稼動させています。


投入対象はインフラなので365日無停止稼動を

し続け、トランザクションについても日単位で

億以上のオーダに上ります。


インフラは高い公共性がある為、利便性の向上を

日々要求され、これに伴いシステムサイズは

肥大化の一方であり、結果としてSIerや

ソリューションから下流工程のソフトウェア

設計開発、実装、検証、までを一貫して行う

チームになっています。


・・・悩みの尽きない職務です。


​​​​​​​
常に人がある程度入れ替わる中、組織（チームワーク）

をどうすると最適な開発が行えるのか、

考えています。



教育プランの立案​

---

今回の教育は、前述しましたが、若手から

中堅社員までを一堂に集め、改めて仕事を

やり抜く力であるソリューション力に焦点を当て、

切磋琢磨しよう！と集合教育形式(スクール）で

やることにしました。



事前に本を配布し、読了状態で集合教育を

行いますが、教育者は中堅社員とし、受講者は若手

としました。


普段のOJTでは見られない、集大成的な話を

中堅社員に説明するようにお願いしました。


ファシリテータは自分が行いますが、必ず参加者が

一回以上発言するタイミングとネタを与え、

議論した結果を思い思いにメモって持ち帰って

貰う形式にしました。


そういった点では、宿題や課題が残った

ままになるケースも多かったです。

これは、後々にグループ内で継続検討課題

として取り組めたので、良い傾向にあった

と言えます。


ここで、本当は悲しいのですが、いつも自分が

その仲間の輪に入ってばかりいないように

しました。


せっかく、中堅と若手の間に共通認識が芽生え

つつあり、会話が盛り上がるタイミングです。


ここは敢えて、思い切り身を引くことに

しました(T_T)



近年の若手エンジニア像

---

これまで自分が手掛けてきたプロジェクトは、

下地がある程度出来上がっている社員を

引き抜き、期間限定で難易度の高いソリューション

をやることが多かったのですが、

近年の若手エンジニアは価値観や目標が

以前よりバラバラで、だんだん纏めるのに

苦労を伴うようになってきました。


その為、こういったプロマネ教育を通じて

本質的なソリューション力を養いつつ、

そもそも現在の中堅と若手はどういった価値観

で会話し、どういった心構えでソフトウェア

エンジニアとしてやっていくのが良いか、

探ろうというテーマも同時進行しています。

（参加者の硬直化を避けたい為、現時点では

非公開テーマです）


また、年々若手は受け身になっていく傾向が

あります。



中堅エンジニアと若手エンジニアのギャップ

---

ここ10年余り、ソフトウェア開発は

コモディティ化が進み、急速に単価が下がる

縮小均衡傾向となり、ひと昔前まで引く手

数多であった旧来のエンジニアには大変難しい

冬の時代でした。


にもかかわらず、ソフトウェア品質問題は

後を絶たず、新聞にも何度となく掲載され、

日経コンピュータ（昔、取材を受けたことがあります）

などでも年中取り沙汰され、社会に与える

影響は絶大です。



レガシーで複雑化した既存インフラと

大規模災害を呼べる大きな影響力を持ち、

これに付き合わなくてはなりません。

大変なプレッシャーです。



こういった逆境を生き抜いたエンジニアには、

変な自負が生まれ、あたかも自分が生き

残ったのは、「全方位の能力を持った」から

だと気負ってしまいがちです。


事実、こういうエンジニアは気概以外に

資質も含め、十分な能力者が多いのですが、

チームワークが不得意でなりません。


その彼らの気概のベースには

”徹夜してでもスキルを身につけるタイミング

は逃すな”

とか

”苦労は金を出してでも買え”

といったものがあります。


これらはひとつの事実であるため、間違い

では無いように見えますが、時代背景が

異なる若手に対し、独善的にぶつけても

理解や成果は上がらないので、

結果的に間違いとなってしまいます。



これが、若手との距離を一層、広げている

ように見えます。


その結果、若手から中堅に対し、

”～さんには追い付けませんよ”

”～さんと会話して決めたんでOKです”

のような発言が年中聞こえてくるように

なりました。


強い他人依存と、既知解探しの思考プロセス

が生み出す典型的な発言に聞こえます。


謙虚なのか、上昇志向が無いのか、

それとも他の何かなのか、正直分からない

ことも多く、その発言をストレートに咎めて

みると、ほとんどの場合、肩透かしのような

回答が返ってくるだけです。

（「普通、みんなこんなもんですよ？」とか・・）



しかし、ここで停滞しては互いに時間の無駄です。

少なくとも、その状態ではスキルアップ

できるとは思えません。


伝え方を選び、通るべき道を順序立てて

セッティングすれば、過去の自分よりもっと効率的に

同じ以上のスキルを取得する可能性を持って

いるのが若手のはずです。



よって、中堅にはPJの進め方をおさらいの

意味で本ベースに説明をしてもらい、若手は

それを傾聴し、考え、自分らが拙くもやって

きた業務との照合を行い、その真価を問います。



こうして外部の本をベースに互いの距離感を

埋め、中堅と若手が本質的に会話できるように

なることが、いま最も必要なことだと考えます。



※もちろん、この議論には「中堅世代が苦労して

遠回りしたことに真の価値があるんだ」という

節から目を背けていることは認め、中堅にも

その旨を伝えてから勉強会を開催しています。


本来、苦労は乗り越えた個人にとって、何より

尊ぶべき貴重な体験であることは、実体験を通じ

嫌というほど知っていますが、今はそれを

前面に推し出して若手と対峙する方法以外で

伝えないとならない、と捉えています。


何故なら、10人中8人はその苦労を乗り越え

られなくなっている事実がある為です。


言い方を変えますと、そういった苦労を

越えなくても良いのではないかという考え方

も認められているということで、時代の変遷

による価値の変化だと思います。


その代償として、もしかすると、個々人の

パフォーマンスは昔より下がっているのかも

しれません。

しかし、この議論のベースにある「昔」は、

超超過労働をしていたため、それを普通と

みなすのは前提が間違っていると考える

べきであると自分は思います。



社会での（ソフトウェア）ソリューション

---

前述しましたが、レガシーによりユーザ要求咀嚼が

複雑になったことで、単一機能の提供ではなく、

ソリューション指向が高まり、

ソフトウェアテクノロジーは単なる解決の

一手段に成り下がりました。


元々、一手段なのは不変の事実ですが、

そのテクノロジー保有者にはスキルと共に

創造力もありました。

→　もっと砕けた表現にしますと、

奢侈財のような面白味や興味を掻き立てる

商売が主体となったことで”企画”と

ソリューションが混濁し、文系の仕事に

スライドしていったと捉えています。


これは主に北米から始まったシンドロームです。

いつの間にか難解なテクノロジーが汎用化

（難しさはあまり変わらない）し、

エンジニアが増えると、ソフトウェア品質は

90点取れれば、あとは企画のインパクトで

商売は成立する、という方向性です。


いつしか、

　ソリューション　＞　テクノロジー　

という構図が出来上がり、

給与体系、出世の階段も差が付けられること

になりました。


なにやら悔しいです。



ソリューションの三大要求について

---

自分の受け持つチームの本業はソフトウェア

開発ですが、ここで取り上げるのは開発理論や

マネジメント観点（規模見積もりや工程/課題管理

うんぬん）ではありません。


エンジニアがソフトウェア開発スキルを行使

しながら、業務としてアウトプットを出すため

に必要な本質に重きを置いた教育です。



そもそも商用利用のソフトウェア開発

（に依らずですが）に於いて、設定すべき

ゴールは

a)ユーザ要求

b)社会要求

c)自社要求

をバランスよく満たすことが最初の定義です。


まずプロジェクトリーダは、ユーザ要求を

”絶対”にしないことが肝要です。


その理由は、ユーザも知らない要求が

潜在しているからです。


それを見抜き、仮説にもとづいた提案を

しながら、完璧を目指すのがプロフェッショナル

だと考えます。


---[例]-----------------------------------------------------

「走行安定性を考え、4WDの自動車が欲しい」

という新卒社会人の購買意欲があったとします。


これを聞いたカーディーラー販売員は別ビュー

からの提案（要求に対する追補）をします。

　→　燃費が悪いですよ

　→　維持費が高いですよ。

などです。

これらは4WDの自動車から言える端的な特徴です。


維持費と言う成分も細かく分解すれば、

税金やオイル代、はたまた任意保険など

数限りないですが、可能な限りリアリティ

のある根拠情報を定量的に提示します。

（オイルの交換スパンや価格など）

この際、絶対に揺るがない軸は「時間軸」

なので定量化と合わせて時間の経過にもとづく

仮説を提示します。


任意保険は加齢とともに経年で安くなる可能性が

高いですが、オイル代は物価変動と共に高く

なる可能性があります。


こういった”自動車を購入した人間が向き合う

一般的な課題”を多面的に考え、ユーザ要求に

追補をし、ユーザの主張がそれでも揺るがないのか

総合的な判断を仰ぎます。


優先順位は「安全性、利便性、初期費、維持費」

でしょうか。

ユーザの要求だけでは無く、社会通念と照合して

合理性があるかチェックしてあげる必要もあります。


もし、ここで互いが納得いかなければ、今一度、

背景や要求の真意を探りに行き、納得が取り付ける

まで続けます（価値の共有）


また、現在の自動車に関しては、初期費と維持費は

比例関係（共変）にあると考えます。


このように、ユーザは一番気になることにしか

目が行かないことが多いため、販売員は長期に

わたる満足を供与するために、それ以外の

要素である「利便性、初期費、維持費」に

ついても知見をもとに説明をすることで、

よりユーザに役立つ要求の明確化が行えます。

-------------------------------------------------------------------


社会要求についても同様です。（低炭素化の要求などなど）


しかし、自社要求は毛色が違います。

多くのサラリーマン・エンジニアを悩ませるのが、

この社内からの（時に理不尽な）要求です。


論拠は技術要件でもユーザ要件でもなんでもなく、

単なる在庫整理かも知れませんし、利己的でかつ

断る余地のない不自由な選択肢の提示かも知れません。


もちろん、法的に排除されるようなことは普通、

無いでしょうが、自分の正義やプライドを持って

して勘案した挙句の提案が通用しないケースです。


多くの場合はコスト要求だと思われます。

しかしながら、自社要求もソフトウェア開発の

大きな要素です。


よって、戦略的な妥協（compromise)をしながら、

前進するしかないです。


今回、ここでご紹介するのは、こういった

ソリューションをソフトウェア設計開発に

携わりながら行う人物向けのスタディです。


「こうすればベストソリューションが・・」とか

「あなたの会社の労働効率を30%アップ」的な

ことをのたまう訳ではなく、実体験の生情報を

記載します。



エンジニアがソリューションを行う

---

時にソフトウェアエンジニアは、とんでもなく

くだらないミスをします。


コンピュータ側の考え方や都合に慣れ過ぎて

オーバービューが見えなくなってしまった

結果だと思います。


人間ならやらないミスを、人間が作った

コンピュータは平然としてしまいます。



こういった事故はソフトウェアエンジニア

に対し、意義を理解させることの重要性を

示唆していると思います。


計算機は複雑な算数の問題でを瞬時に解くことが

できますが、計算問題そのものを作りだすことは

できません。


算数の問題を解くという方法論は、例えば24個の

リンゴを10人のクラスメイトに配るには？

などに使われます。


余った4個のリンゴを隣のクラスにあげるか、

じゃんけんの勝者に配るか、そもそもリンゴの

調達を20個にするか、答えは捉え方一つで

計算機向けの問題になったり、

そうじゃなくなったりします。


テストの問題として提起されている訳では

無いので、前提条件は合理的であれば変える

ことは全然問題ないのが社会で発生する問題です。

（ここでの合理性は、論理的な意味に加え

関係者のコンセンサスも含めます）


こうした問題を「ソフトウェアエンジニア」だけの

キャリアで、ソリューションするには不足があります。



本題のプロジェクトマネジメント

---

ここで登場するのが、

所謂、プロジェクトマネジメントです。


マネジメントというと、リーダとメンバーに

分けがちですが、実際は違います。

もちろん、適切に振る舞う為に役割や権限の

明確化は必要なので、役割としてのリーダは

必要です。


リーダにはリーダの目的があり、メンバには

メンバの目的があります。

リーダの目的は案件の最終成果を（いくつか）

出すことです。


その目的のために全メンバの目的

（リーダから見ると目標）を束ねるという

方法論でチームとしての成果を導きます。


とうぜんメンバにも目的があり、方法論が

あります。


決してリーダが具体の指示をすることで

引き出されるものが成果では無いです。

という事は、リーダ、メンバ問わずに自律的

且つ主体的な人格を持つ集団であることが

肝要です。

ここでの議論の焦点です。


しかし、非常にあいまいでグレートな響きを持つ

「自律性」「主体性」は、当てはめるケースによって、

たいへん都合よく使われることも多いです。


特にコンサルタントを生業にする人間には

こういった事をそれっぽく、すぐ口にします。

（それっぽい現状分析の後に）


その場合、自分はいつもそういうコンサルに

依頼するのですが、『それならば、私に代わって

本案件のプロジェクトリーダをやってください。

仰るセオリーに従うと私以上にできそうですか？

スキームを見せてください』

です。

とっても嫌味に聞こえますが、決して嫌味では

無いです。


これは主に中東や南アジア系の駐在員から

言われるセリフに似ています。

”そんなに言うならお前がこっちに来てやれ”

・・・とても良く聞くセリフです。


これを言われると仕方がないので、現地へ赴いて

一緒に泥水を飲みながら応対するのですが、

絶対、現地に赴かないと理解できない発見

だらけです。


本気でやろうとするから出てくる発言ですし、

本気で対峙するなら応答すべきです。


もちろん職務分掌から見ても権限を持てない

コンサルに本当にやらせる訳では無いのですが、

それくらいの心意気でスキームを持って

来れますか、と言う点を初めに伺っておき、

今後への期待度に結び付けています。


今のところ、けっこうな大手コンサルが

数千万円の契約金で取り組もうとしましたが、

全社挫折していきました。


こういったこともあって国内のコンサルは

あまり能力的に信用できません。


また、同じようにベンチャーキャピタル(VC)

についても、近年は積極的に運営にかかわる

ところが増えつつあると言いますが、

実際は”チャンスを与えるところまで”の支援

にとどまり、結果的にお金だけ投資するって

ところが多いように見えます。


こうなってくると先駆者である欧米式の外部

トリガーで自律性・主体性を養うのは難しいです。



誰がプロジェクトを運営するのか

---

やはり、自分たちでやるのがベストでは

ないでしょうか。



結局、複数の人間が集まって上手いこと

仕事の成果を出すためには個々人が

『目的の理解をすること』に尽きます。


これが出来ていれば、主体的に判断して

いきますし、客観的な事実から良否の判定も

できます。


課題があれば立ち止まるでしょうし、

必要な知識が自分に持ち合わせなければ、

有識者の参集もするはずです。


しかし、目的を理解している事＝目的の意味を

理解している事、では思った以上に

自律的な行動をする人は現れません。



意味と意義、その理解と行動

---

その原因は「意味の理解」と「意義の理解」の

差によるものだと考えています。



喫煙は将来、病気のリスクを上げることは

統計的にも医学的にも証明されていますが、

それでは2,000本で癌になるのか、250本で

癌になるのかは解明できていません。


もちろん非喫煙者でも癌になります。

（第三変数問題）


この場合、「喫煙の害について意味を理解している」

が「喫煙は継続する」という一見矛盾ともいえる

ことが起きます。


ここでの喫煙者心理は”分かっちゃいるけど

止められない”です。


でも、本当はおかしくて、本当に分かって

いたら絶対に止めるはずです。


例えば、250本吸った瞬間に肺が爆発する

ことが100%決まっていることなら、

誰も250本喫煙しないはずです。

それどころか、そんな危険なものには

手も出さないはずです。


この”危険なので手を出さない”というのは

「意義が理解できた状態」です。

目的を理解するときは、意義を理解する

ことが最重要です。


意義を理解したうえであれば、行動は目的に

向かって合理的に進み、誤りがあっても気付けます。


これらを複数のメンバで行う事で多眼的な

行動の立案（複数の行動選択）が発生し、

それら議論はいわゆるコラボレーションとして

融合し、創造的な立案が行えることもあります。


その際、簡素化や効率化を狙って単なるルールを

決めることは大変危険で、進化を止める方法です。


一緒に働くメンバが、レビューなどの時に

「～のルールに従って・・」と言い始めたら、

一度はその目的を聞き出すことが必要です。

根拠の正当性証明を避ける呪文化している

可能性があります。

　
また、もちろんメンバの達成感や実際に

達成した成功体験は他に変えられない

資産となります。



スクールの開始

---

以下は実際に当該の本をベースに自分がリーダを

して、スクールをおこなったときの資料です。

メンバ分の本を購入し、事前に配布し読んでもらい、

一週間ほど時間を空けて、開校しました。


スクール形式のため先生役は必ず必要です。

フリーディスカッションも重要ですが、

基礎教育であるため、いったん『既知解はある』

として進めます。


先生役は自分をはじめとして

中堅クラスで分担し、童話ごとに先生を決めて

隔週でスクールを開催しました。



販売されている本の内容に一部、触れるので

多くは書けませんが、参考に以下を少しご紹介します。

※あくまで自分の判断、やり方です。

--------------------------------------------------------------
【狙い】
・読本で標準的な知識を得る
・これまでの業務を振り返り、この新知識が
　利活用できるか？　脳内シミュレーションを行う

【進め方】
・同じ本を読んだ先輩から要点の指導を受ける
・自分の振り返り内容と比べながら
　ディスカッションを行う
・互いに何が不足しているのか見え、より実践的な
　計画が立てられるようになる
--------------------------------------------------------------


--------------------------------------------------------------
【第一章　三匹の子ブタ　要点】
・お母さんブタは気づいた
　「今のままだと未来がヤバイ、なんとかしよう」
　(ref.p19)
　
　　　↓

【振り返り・気づき】
□自分の業務で何がヤバイか気付けますか？
□何が、どれくらいヤバイか把握できますか？
□どうすればいいのか対処できそうですか？
--------------------------------------------------------------


--------------------------------------------------------------
【第一章　三匹の子ブタ　要点】
・プロジェクトは日常業務とは違う
　今までやったことがない特別な仕事(ref.p20)
・設計に於いてはどんな仕事も“非日常”である
・毎案件がプロジェクト的要素を持っている
・しっかり考察し、計画すれば、学びが大きい！

　　　↓
　　　
【振り返り・気づき】
□現在の業務の目的、特徴は何ですか？
□計画は作りましたか？
--------------------------------------------------------------


--------------------------------------------------------------
【第一章　三匹の子ブタ　要点】
・一致団結してやろうとメンバー全員に
　考えてもらう(ref.p38)
・何のためにやるのかをハッキリさせる
　(ref.p42)

　　　↓

□目的を可視化し、共同作業者(チームメンバー）
　に説明し、納得させていますか？
□納得は、相手からの応答を見て判断していますか？
--------------------------------------------------------------


--------------------------------------------------------------
【第一章　三匹の子ブタ　要点】
・やるべきことを具体的に洗い出す(ref.p46)
・役割分担をし、成果物・責任を決める(ref.p52)
・必要な時間を予測する(ref.p59)

　　　↓

□不明点を相談し、納得しましたか？
□各タスクの成果物は明確ですか？
□工程表として可視化し、共同作業者(チームメンバー）
　に説明し、納得させていますか？
--------------------------------------------------------------


--------------------------------------------------------------
【第一章　三匹の子ブタ　要点】
・絶対に遅れてはいけない作業(critical-path)を
　把握する(ref.p68)
　なるべくクリティカルなタスクを作らないように！

　　　↓

□クリティカル・パスの成果物をベースに
　実担当者とシミュレーションし、
　安全な工程になりましたか？
□前後工程の担当者含めて、クリティカルである
　認識を共有しましたか？
--------------------------------------------------------------


--------------------------------------------------------------
【第一章　三匹の子ブタ　要点】
・助けあることでプロジェクトは失敗を
　減らせる(ref.p94)

　　　↓

□独りぼっちでやろうとしていないか？
□課題が可視化できる仕組みは作ったか？
--------------------------------------------------------------

僅か60分程度のスクールですが、事前の準備と

気持ちの準備をして参加してくれたので、

とても分かりやすく、今後の実践に活かせる

内容となりました。



マネジメントには人間力が問われます。

（いかなる場合でも同じですが）


参加者はこのスクールを通じて、

その人間力を鍛える第一歩を踏み出せました。



エンジニアには必要以上に華美であったり、

粉飾的な鼓舞、独善的で一過的な支援は

意味を為しません。

そのため、今後一年間は折あるごとに

今回の学習を思い出してもらえるように声かけを

行っていこうと思います。


実践では訓練されたパートナー以外も大勢設計に

参加するため、イレギュラーやイリーガルな

事件も起きえます。


そういう計画外に直面したとき、妥当な判断、

チームの意思決定を行う事が大切です。


これらはPMBOKを学んだだけでは、

全く実践行使できません。

リーダとしてメンバから認知され、ステークホルダー

からも一様に認められるようになる必要があります。


自分の経験上、正直者であることが最初にして

最大の資格であると考えています。




今現在、読本とスクールをベースとした勉強会を

半年行って、先日全章分のスクールが完了しました。


4月から新しい期が始まったばかりなので、

ここでの学習効果がどのように表れてくるのか

分かりませんが、これをきっかけにして

一段高い視座で頑張れるチームになると

信じています。

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​