感嘆符（!?）を全角に、誤字修正

src/chap-forte.re

@@ -39,35 +39,35 @@ FORTE(フォルテ)@FORTEgp05
 
 === メンバーを否定しないで肯定する
 
-例え内心(それはないな…)と感じても表に出さず一度肯定してから伝えることが重要です。当たり前に思えて意外とできてない人も多いと思います。特に意識していないと自分の率直な感想が出がちですが、そうするとメンバーが否定された!と感じてしまうかもしれません。
+例え内心(それはないな…)と感じても表に出さず一度肯定してから伝えることが重要です。当たり前に思えて意外とできてない人も多いと思います。特に意識していないと自分の率直な感想が出がちですが、そうするとメンバーが否定された！と感じてしまうかもしれません。
 
-例えば年次目標に3冊技術書を読むと言ったメンバーがいるとします。この1年で3冊は普段から本を読む人からすると正直少ないと私は思います。ですが、ここで素直に「少ないですね」と言ってしまうとメンバーが否定された!と感じてしまうかもしれません。「まずは今年3冊確実に、来年から量を増やしていきましょう」などのように表現すると良いでしょう。
+例えば年次目標に3冊技術書を読むと言ったメンバーがいるとします。この1年で3冊は普段から本を読む人からすると正直少ないと私は思います。ですが、ここで素直に「少ないですね」と言ってしまうとメンバーが否定された！と感じてしまうかもしれません。「まずは今年3冊確実に、来年から量を増やしていきましょう」などのように表現すると良いでしょう。
 
 他にも否定から入るのが口癖のようになってしまっている人もいると思います。メンバーから何か言われた時に「いや、それは…」とか、「そうじゃなくて、これは…」とかのように言ってしまうケースです。このような言動を繰り返しているとメンバーは何を言っても否定されると思い、そのうち何も言わなくなってしまいます。もし心当たりがある人は「確かにそうですね。でも他の可能性として…」の様に言い換えることを意識してみると良いでしょう。
 
 === 聞かれない限りアドバイスしない
 
-否定しないに関連して、メンバーが否定された!と思う行動のひとつにリーダーからの押し付けがましい身勝手なアドバイスがあります。オススメの本を紹介する、こういう行動を取ると良い、こういう考え方をすると良いとアドバイスするのも、メンバーにとっては自分の選んだ本を否定された!自分の考えを否定された!となる可能性があるので、関連した話題が出てもメンバーから明確に聞かれない限り、または質問されない限りアドバイスしない方が賢明です。
+否定しないに関連して、メンバーが否定された！と思う行動のひとつにリーダーからの押し付けがましい身勝手なアドバイスがあります。オススメの本を紹介する、こういう行動を取ると良い、こういう考え方をすると良いとアドバイスするのも、メンバーにとっては自分の選んだ本を否定された！自分の考えを否定された！となる可能性があるので、関連した話題が出てもメンバーから明確に聞かれない限り、または質問されない限りアドバイスしない方が賢明です。
 
-ちなみに私の経験としてアドバイスしたら自分の考えを否定された!と感じたメンバーはチームリーダーになりたいというキャリア志向の持ち主であり、上長からリーダーについてアドバイスをして欲しい、次のキャリアとして後進育成もやって欲しいと言われた中でアドバイスをした結果、メンバーには否定された!と感じられました。このように上昇志向がありキャリアアップを望んでいる人に対するアドバイスでもメンバーからすると否定された!となってしまう可能性があるのです。そのため、上長からの依頼であっても、良かれと思っても、本人が望んでいても、明確に求められない限りアドバイスはするべきではないでしょう。
+ちなみに私の経験としてアドバイスしたら自分の考えを否定された！と感じたメンバーはチームリーダーになりたいというキャリア志向の持ち主であり、上長からリーダーについてアドバイスをして欲しい、次のキャリアとして後進育成もやって欲しいと言われた中でアドバイスをした結果、メンバーには否定された！と感じられました。このように上昇志向がありキャリアアップを望んでいる人に対するアドバイスでもメンバーからすると否定された！となってしまう可能性があるのです。そのため、上長からの依頼であっても、良かれと思っても、本人が望んでいても、明確に求められない限りアドバイスはするべきではないでしょう。
 
-これは後にも書きますが、チーム結成時、そして定期的に希望を確認すると回避できるでしょう。本人がアドバイスを望むのか?望むのならどんなアドバイスを望むのか?頻度やきっかけは?こういった項目を事前にメンバーと擦り合わせておくとメンバーの否定された!という思いを防ぐことができます。
+これは後にも書きますが、チーム結成時、そして定期的に希望を確認すると回避できるでしょう。本人がアドバイスを望むのか？望むのならどんなアドバイスを望むのか？頻度やきっかけは？こういった項目を事前にメンバーと擦り合わせておくとメンバーの否定された！という思いを防ぐことができます。
 
 === こちらに非があれば謝罪する
 
 これも当たり前に思えて、会話の流れで謝罪せずに終わらせてしまうと後々問題になることがあります。また、リーダーが「そんな細かいこと…」と思っていてもメンバーは気にしているかもしれないので、きちんと謝罪する癖をつけておきましょう。
 
 とはいえ、何でもかんでも謝罪しても仕方ないので、ポイントとしては指摘をした際が重要です。リーダーとはいえ人間ですので勘違いもあれば、ミスもあります。その際、間違った指摘をしてしまったときはきちんと謝罪をするようにしましょう。
 
-ここで最初に書いた@<b>{会話の流れで謝罪せずに終わらせてしまう}ケースが発生し得ます。例えばメンバーが書いたコードを見ながら会話していて「ここ間違ってるよ」と指摘したのに設計書通りで正しかったという場合に「あ、私のミスだった。で、次は～」「ごめんね、で次は～」「すまん、違ってた。で、次は～」のように明確に謝罪しなかったり、しても流れで謝罪しているとリーダーが非を認めなかった!謝罪がなかった!とメンバーが感じてしまう可能性があります。ここはきちんと「すいません、私が間違ってました。」と謝罪するようにしましょう。
+ここで最初に書いた@<b>{会話の流れで謝罪せずに終わらせてしまう}ケースが発生し得ます。例えばメンバーが書いたコードを見ながら会話していて「ここ間違ってるよ」と指摘したのに設計書通りで正しかったという場合に「あ、私のミスだった。で、次は～」「ごめんね、で次は～」「すまん、違ってた。で、次は～」のように明確に謝罪しなかったり、しても流れで謝罪しているとリーダーが非を認めなかった！謝罪がなかった！とメンバーが感じてしまう可能性があります。ここはきちんと「すいません、私が間違ってました。」と謝罪するようにしましょう。
 
 === 指摘をする際にはエビデンスを用意してから指摘する
 
 一つ前の話の防止策にもなるのですが、メンバーに対して何かしらの指摘をする際にはコード、設計書、テスト結果などのエビデンスを用意しましょう。なぜならば、その指摘内容に誤りがあると謝罪が必要になり、うまく謝罪できないとメンバーの不信感につながります。そのため、指摘する前にエビデンスを用意してから指摘しましょう。もし会話の最中などで気づいた場合は「確認したい点がある」と言って一緒にエビデンスを確認してから指摘するようにしましょう。
 
 === 無理難題を言われても断らず、かと言って確約もしない
 
-チームメンバーからこうして欲しいという要望があっても、様々な事情でそれを叶えられない場合があります。そういった場合に詳細に理由を説明し、難しい、できないと回答しても、メンバーからするとリーダーがこちらの要望を聞いてくれない!という感情につながりかねません。
+チームメンバーからこうして欲しいという要望があっても、様々な事情でそれを叶えられない場合があります。そういった場合に詳細に理由を説明し、難しい、できないと回答しても、メンバーからするとリーダーがこちらの要望を聞いてくれない！という感情につながりかねません。
 
 かといって、できもしないことを約束するのは悪手です。その場は収まっても後で約束が守れないとなった場合に問題が悪化するからです。また、過去にこの件についてTwitterで聞いてみたところ、リプくださった2名の方はできもしないことを約束されるより、詳細に理由を説明してほしいとのことでした。このことからも空約束するよりも詳細に理由を説明した方が無難ではあります。
 
@@ -89,17 +89,17 @@ FORTE(フォルテ)@FORTEgp05
 
 ==== モブプロで汗をかくから同じキーボードを使いたくない、実装中のコードを見られたくない
 
-これはメンバーが手汗をかくため、同じキーボードを使い回したくないということがありました。それぞれがキーボードを用意してドライバー交代時にキーボードも交換することで解決しますが、本人は手汗を書くことを気にしているので根本的な解決にはなっていません。
+これはメンバーが手汗をかくため、同じキーボードを使い回したくないということがありました。それぞれがキーボードを用意してドライバー交代時にキーボードも交換することで解決しますが、本人は手汗をかくことを気にしているので根本的な解決にはなっていません。
 
-また、メンバーによっては実装中のコードを見られたくないという人もいました。レビューはどうするのか?と聞くと我慢していると言っていたので、コードを見られるのが嫌という人もいるようです(正直チーム開発に向いてないんじゃないかと思いましたが、まぁそういう人もいるということでしょう)
+また、メンバーによっては実装中のコードを見られたくないという人もいました。レビューはどうするのか？と聞くと我慢していると言っていたので、コードを見られるのが嫌という人もいるようです(正直チーム開発に向いてないんじゃないかと思いましたが、まぁそういう人もいるということでしょう)
 
 ==== 早く作業したいのにアイスブレイクが長い
 
 私のチームでは毎日の朝会で最初にアイスブレイクとしてハピネスレーダーをやっています。この時間が長いため、朝会が長くなり、作業時間が削られて嫌だ感じたメンバーがいました。こちらはリモート開発で雑談が少ないことへの対策、ルーティンとしして毎朝行うことでモードを仕事モードに切り替えるなどの意味を持ってやっているわけですが、無駄だと思われているようです。
 
 アイスブレイクにかかる時間としては5分以内、長くても10分以内に終わっています。朝会自体も長くて30分です。メンバーが不満を感じた際のチーム人数は二人でした。これはメンバー側にアイスブレイクの意図が伝わっていない可能性がありますが、意図はちゃんと最初に説明しています。それでも不満に思うメンバーはいるので不満を感じていそうだなと思ったり、フィードバックを受けた際は押し付けないでやめたほうが良いでしょう。
 
-ちなみにそのメンバーに朝会のふりかえりとして無駄な項目はないか?と聞いたら特に無いと言っていたので、アイスプレイクが無駄という不満を感じておきながら無駄な項目はないという矛盾した言動を取っています。このようにメンバーは本音と建前を使い分けるのでリーダーからすると本音を見抜くのは大変ですが、チーム開発を円滑に進める上で重要なポイントなので気を配りましょう。正直こういった気を使わなくても一緒に開発できるメンバーが欲しいのがリーダーとしての本音ですが、残念ながら多くの場合においてメンバーは選ぶことはできません。与えられたカードで勝負するしかないのです。
+ちなみにそのメンバーに朝会のふりかえりとして無駄な項目はないか？と聞いたら特に無いと言っていたので、アイスプレイクが無駄という不満を感じておきながら無駄な項目はないという矛盾した言動を取っています。このようにメンバーは本音と建前を使い分けるのでリーダーからすると本音を見抜くのは大変ですが、チーム開発を円滑に進める上で重要なポイントなので気を配りましょう。正直こういった気を使わなくても一緒に開発できるメンバーが欲しいのがリーダーとしての本音ですが、残念ながら多くの場合においてメンバーは選ぶことはできません。与えられたカードで勝負するしかないのです。
 
 === みんながみんなアジャイルなどが好きな訳では無い
 
@@ -161,7 +161,7 @@ FORTE(フォルテ)@FORTEgp05
 
 一つ目は自分が嫌いなプログラミング言語、技術や、過去に苦労した技術をけなさないというものです。過去に自分が経験したこととしては、とあるプログラミング言語に対してツライ点があるとSlackに投稿したところ、そのSlackにはそのプログラミング言語が好きな人が多く、そういった不満は見てる人に嫌な思いさせないようにすべきという投稿がされたことがあります。自分が嫌いでもツライ経験があってもチームメンバーもそうとは限らないので、愚痴や不満は安易に投稿すべきではないでしょう。
 
-昨今はリモートから出社に回帰し始めていますが、それでもテキストコミュニケーションが主流になっていると思います。そこで投稿するテキストがビジネスライクすぎる、つまりいつも文末が句読点で終わっていたり、感情が感じられないとリモートに慣れてない相手だと怒ってる、機嫌が悪いと勘違いされることがあります。仕事なのであまりフランクな表現は使うべきではないですが、!や〜などは使っても問題になりづらいでしょう。また、絵文字が使いづらいという方はリアクションで使うのがおすすめです。逆にテキストがフランクすぎると馴れ馴れしいと感じられることがあるので、硬すぎるのが良くないからといってフランクになりすぎるのもよくないです。バランスが重要なのでよく他のメンバーを観察して柔軟に変える必要があるでしょう。
+昨今はリモートから出社に回帰し始めていますが、それでもテキストコミュニケーションが主流になっていると思います。そこで投稿するテキストがビジネスライクすぎる、つまりいつも文末が句読点で終わっていたり、感情が感じられないとリモートに慣れてない相手だと怒ってる、機嫌が悪いと勘違いされることがあります。仕事なのであまりフランクな表現は使うべきではないですが、！や〜などは使っても問題になりづらいでしょう。また、絵文字が使いづらいという方はリアクションで使うのがおすすめです。逆にテキストがフランクすぎると馴れ馴れしいと感じられることがあるので、硬すぎるのが良くないからといってフランクになりすぎるのもよくないです。バランスが重要なのでよく他のメンバーを観察して柔軟に変える必要があるでしょう。
 
 最後は発生したバグやイマイチなコードを槍玉に上げてしまうとそれを実装した人がチームメンバーだったりすると一気に空気が悪くなります。自分が改修する際にバグを踏んで手間取ったり、緊急対応で時間を取られたりすると槍玉に上げたくなりますが、実装した当人に悪気なんてないですし、槍玉に挙げたところで問題が解決するわけではないのでデメリットしかありません。愚痴を言うなら機密情報は伏せた上でSNSや匿名ブログ、仕事に関係ない閉じた空間の無関係ない相手にすべきでしょう。