タグ : %e3%82%b3%e3%83%9f%e3%83%a5%e3%83%8b%e3%82%b1%e3%83%bc%e3%82%b7%e3%83%a7%e3%83%b3

post image

もし生意気な新卒が内気なプロジェクトリーダーを論破したら??

過去に大失敗した経験って今後の人生に大きな影響を与えますよね。
当時は高い授業料だったけど、その経験のおかげで学べたことってみなさんもありませんか?

私は昔から合唱のパートリーダーや生徒会役員など代表としてなにかをする立場によく立っていました(ほとんど嫌々でしたが)。そう言ったこともあり比較的責任感は強く、より良い方法があると積極的に意見や提案、指示をするタイプです。

その性格が裏目に出てしまい、新卒時代に最初にアサインされたプロジェクトで非常にイタい経験をしました。その時のことについてお話しします。

期待のプロジェクト。のはずだったが…

アサインされたプロジェクトの内容は、今は規模が小さい将来性があると期待されていたプロダクトのデザイン刷新及び不具合改修でした。チームも非常に小さく、私とヒデキさん、それからチューター2人の計4人でした。

マネージャーの指示によりヒデキさん(仮名)をリーダーとしてプロジェクトを進め、11月リリースを目指すことになりました。

当時私はプログラミング未経験(3か月間の研修のみ)だったので、キャリアをしっかり積んで行きたかった私は期待を胸に熱心にプロジェクトに取り組みました。

進めるうちにプロジェクトチームの問題が見えるようになりました。

当初はチューターによるOJTを前提としてプロジェクトを進めるはずだったが掛け持ちしていたプロジェクトが忙しく、実質二人でプロジェクトを進めていかなければならなくなりました。

(この会社大丈夫か…?)

こんな状態になってしまった以上私とヒデキさんで協力してなんとか乗り越えていかなければなりませんでした。そこで私は積極的にコミュニケーションを取っていくことが重要だ、そのためにもヒデキさんのことを知らなければと思い、今後の仕事の進め方についてヒデキさんと話し合いをすることにしました。

その結果いくつか方針を設けることにしました。

・効率を上げるためそれぞれの得意なことを担当する
・毎朝のルーティーンとして朝一にお互いの進捗状況と課題について報告する(今で言うスクラム)

どうやらヒデキさんはプログラミングが得意ではなく、管理業務やデザイン提案のほうができるということでしたのでその手の仕事はヒデキさん、実装業務は私がメインで担当することに決めました。

また、ヒデキさんは私とは真逆の性格で、内気で指示されたことはやるが自ら考えて行動するのは苦手みたい。リーダー経験に乏しいのか、正直あまりリーダーの能力を兼ね備えている感じがしませんでした。

(うまくやっていけるだろうか…??)

そんな不安がよぎりながらもうまくいけばいいなと願っていた矢先に事件のきっかけとなる出来事が起こりました。

マネージャーからの急な追加要望

プロジェクトを始めて1か月経過したある日、マネージャーから追加要望が出されました。

「ついでだから今要望として挙がっている機能も全部対応しといて。どれも簡単なものばかりだから」

しかしプログラミング未経験の私にとってはどれも重いタスクで、しかもこの時点ですでにプロジェクトが遅延していました。それなのに引き受けるのは危険だと感じました。また、どれもプロジェクトの目的と直結する機能ではなさそうだったのでおそらく別の機会でも問題はないかもしれません。
対応するにしても数を絞る、少なくともスケジュールを調整するので少し時間をもらうべきだと主張しようとしました。

ところが私が発言する前にヒデキさんは

「承知いたしました。すべて対応いたします。」

とその場で約束してしまいました。

…えっ?

完全に言葉を失ってしまいましたが、何か考えがあるのかと思い、マネージャーとの話し合いが終わった後になぜあの要求を受け入れたのか聞きました。するとヒデキさんから返ってきた答えは予想を裏切るものでした。

「マネージャーがそう言ったから…」

この時私は、ヒデキさんは承認欲求で動いており、マネージャーからの期待にすべて応えようとしているのだと悟りました。今までの経験から、これでは目的がずれて要求に翻弄されてしまい、最終的にプロジェクトが失敗する未来が容易に想像できました。

さすがにこれはまずいと判断したため、ヒデキさんには答えるときはしっかり考えてからしようと提言しました。しかし、ヒデキさんの意見は

「いや、マネージャーの言うことは聞かないとだめだよ」

(うーん…)

まぁリーダーはヒデキさんだからあまり干渉しすぎるのはよくないな、可能な限りリーダーを支援することに集中する方向でいこうと考え直しました。

しかしついに事件は起こってしまいます。

Yesマンのリーダーと口論、そして…

あれから3週間たち、9月中旬。進捗状況は悪化をたどる一方でした。

リソースが増えずにタスクだけ増える。しかも二人の技術力不足なこともあり、残業の機会は増えていく。少しずつチームの空気が悪くなっているのを感じていました。

私は過度な残業はかえって作業効率を下げるのを知っていたので、残業は2時間ほどで済ませる代わりに仕事終わりに自己研鑽をするようにしました。おかげで少しずつ作業効率は上がってきました。

一方ヒデキさんはほぼ毎日のように夜10時ごろまで残業を続け、1日13時間近く働いていました。疲れ切っているのは私の目から見ても明らかでした。早く帰って休むように何度か進めましたが、それでも9時近くまで残って仕事を続けていました。

9月が終わろうとするころ、それでも予定していたスケジュール通りには進まず、少しずつ遅れが目立ってきました。私たちはこのままではいけないということで朝の時間を使って話し合いをする機会を設けました。

本気でスケジュールについてしっかり見直すのかと思い、いろいろ頭を巡らせていましたが、リーダーのヒデキさんから出た言葉は全くもって違いました。

「悪いけどもっと残業してもらえないかな?」

……はい⁉

できないことがわかっているのにYesとこたえ、自ら首をしめていく行為を続ける姿に私はついに痺れを切らしました。

「今回のプロジェクトで期待されていたことは、少しでも早く時代遅れになっていたUIをモダンなデザインにすることで印象を改善して新規ユーザー登録を増やすことですよね?スケジュールもカツカツなのもわかってたはずです。にもかかわらず追加タスクを引き受けて、スケジュール調整もせずに残業でカバーって…それはおかしいですよね!?
それに遅れているのは私よりヒデキさんのタスクですよね?それなのに私に残業を求めるってどうなんですか?少なくとも今話すべきことはスケジュールをどう調整するかだと思います。」

内気なヒデキさんは完全に圧倒されてしまいました。私自身もやや脅迫気味だったことは自覚していましたが、間違ったことは言っているとは1ミリも思ってませんでした。

(あんなんリーダーとして不適任やろ…‼)

結局その後はチューターの方々にもお忙しい中協力いただきスケジュールの見直しを行いました。そしてスケジュールは変えないものの、リリース対象の機能を減らす方向で進めることにマネージャーに持ち掛け、なんとかタスクの調整ができました。チューターにお世話になった数少ない支援の一つです。

その日から私は打ち合わせをするたびにヒデキさんの決定に対して意見を言うようになりました。

「この機能はそこまで優先度は高くないと思います。それよりも先にUIを決定したほうがいいですね。」

「この進捗報告じゃマネージャーは何も理解できないと思います。このように書いたほうがいいです。」

「自分たちの意見の整理もしてないのにマネージャーに何を聞きにいくんですか?案をいくつか用意して聞きにいかないと意味ないですよ。」

このようにしてヒデキさんに伝えることで論理的思考やリーダーシップの方法を学んでもらいプロジェクトを正そうとしました。

その結果…

プロジェクトリーダーがしゃべらなくなりました。

どうやら何を言っても完全に反論されてしまうので完全に自信喪失してしまったようです。

毎朝のルーティーンも完全に裏目に出てしまい、さらにギクシャクすることに。私もそれがストレスとなり仕事のパフォーマンスが低下していきました。11月リリースの予定でしたが、予定日になっても全体の半分近くしか進んでおらずますます空気が悪くなっていく…

これを見たマネージャーはようやくフォローに入り、急遽ほかのメンバーを増員することに。その人が私たちの仲介役を買ってくれたおかげで少しずつ改善されていき、何とかリリースできました。

とはいえ予定よりも3か月の遅延、9人月分のコスト、挙句の果てにはデグレードの発生とプロジェクト評価は散々。非常に納得いかない結果となりました。

正しいことを伝えただけなのに…

プロジェクトが終了した後、なぜこうなってしまったのか考えることにしました。

私の当時の主張はこうでした。

・リーダーは成功に向けてメンバーを導く役割がある
・そのためには正しい判断を下し、自らが率先して行動を起こさなくてはならない
・にもかかわらずリーダーとしての役目を全然果たしていない
・それどころか悪い判断を繰り返してプロジェクトを崩壊させようとしている
・私はこれ以上プロジェクトが悪化しないために正しいことを言ってきたはずだ

しかし私にも大きな問題があることは何となく途中から気づいてはいました。自分の行動を可能な限り客観的に分析したところ、私の言動はヒデキさん(やほかの人)にはこのように見えていたのかもしれません。

・私はヒデキさんに自らのリーダーシップを押し付けようとしている
・私はヒデキさんがリーダーの役割を果たしていないと主張しているが、私もメンバーの役割を果たしていない
・私は文句ばっかり言っていてヒデキさんを困らせている。実際に態度が非協力的だ

つまり、私はあるべき姿についてずっと注意を払ってコミュニケーションをとっていましたが、相手の立場を考えて受け入れられるコミュニケーションをしてきていなかったのです。

結局のところ私の最大の問題は「伝え方」にあったということです。

「何が正しいか」よりも「どう伝えるか」

ソフトウェア開発のみならず、人が関わっている以上コミュニケーションはプロジェクトの成功において非常に重要な要素です。

書籍「デッドライン」や「ピープルウェア」でも成功の秘訣としてソフトの面が重要であると主張してありますが、今回プロジェクトが大失敗に終わったことで、私は「何が正しいか」よりも「どう伝えるか」がコミュニケーションにおいて重要であるということを初めて実感しました。

当時のプロジェクト関係者には多大な迷惑をかけてしまいましたが、終わった後は大きな恨みつらみが残ることなく、通常通りに会話ができたのは非常にありがたい限りでした。

このプロジェクトでの過ちは二度と繰り返さないと心に決め、今でもコミュニケーションをとる際は細心の注意を払うようにしています。

あなたのプロジェクトではどうでしょう?チーム内でぎくしゃくした関係はありませんか?
もし心当たりがあるようでしたら、一度自分の主張を相手にどう伝えているのか見直してみてはいかがでしょうか?

post image

図を使ったコミュニケーションのすすめ

前回の記事「なぜあなたの説明は上司や部下に伝わらないのか?」では図を使って説明することのメリットについてお話ししました。

とはいえ実践するには

  • どのように書けばいいのかわからない
  • メールやコミュニケーションツールを使っていると図を使うのは難しい

など困ったことが出てくると思います。
そこで今回は私が実際にどのようにして図を作っているのかをお話しします。

ドローイングツール「draw.io」について

私は使用しているすべてのパソコンに draw.io を導入しています。
これは無料のドローイングツールで、フローチャートやUMLをはじめ、AWSの構成図などシステム図を描くのに便利なダイアグラムが入っています。

手書きだと書くのに時間がかかったりネットでの共有が不便だったりしますが、draw.ioのようなツールを使えばこういった悩みは解消できます。

お絵かきツールではないのでフリーハンドで何かを書くことはできませんが、エンジニアと話をするときはたいていシステムの構成やデータの流れについてのはずです。だとしたら事前に用意されている図形だけで手早く表現できるので十分です。

クイックスタート

draw.ioを使うのに難しいことはほとんどありません。
デスクトップ版、ブラウザ版ともにあるので好きなほうを使いましょう。
アプリを起動、ブラウザ版の場合はdraw.ioにアクセスします。起動すると以下のような画面が表示されるので「新規ファイルを作成する」もしくは「既存のファイルを開く」を選択します。

これで後はパワーポイントと同じようにパレットから図形を選択して編集するだけです。

パレットに図形を追加する

画面左にある項目を展開するといろんな図形ツールが表示されますが、「その他の図形」をクリックするといろんな図形ツールが表示されるのでなければパレットに追加してください。
私がよく使うのは「フローチャート」「UML」「AWS」です。エンジニアならこれらはいれておきたい。

実際に使ってみよう

私が普段のコミュニケーションで使う図形は基本的にこれだけ。

アクター

オブジェクト(長方形)

例えば以下はユーザーがWebアプリから連携先のデータを取得するのだが、その前に認証確認を行うといったサービスを表現しています。

図形の数はたったの5つ。あとは矢印で組み合わせるだけでできます。
この程度であれば数分程度で作ることができます。

打ち合わせの時はdraw.ioを開いてみんなに見せながらこの図をつくればいいですし、Slackなどのコミュニケーションツールで共有したければ
「ファイル」→「形式を指定してエクスポート」
で出力して添付すればOKです。

この書き方のメリット

今回紹介した書き方ではUMLの図形を使用しております。
ただ注意していただきたいのは、この方法はUMLの使い方としては間違っています。それでもこの書き方には、誰でも手早く相手と意思疎通を図ることができるメリットがあります。

UMLは統一モデリング言語(Unified Modeling Language)の略語で、OMG *1 (Object Management Group)によって仕様が策定されております。
それぞれの図に明確な定義があるためあいまいさを回避することができ、世界中で使われています。私も最近勉強しましたが、使いこなせるようになると非常に便利です。

そのためUMLはアジャイル開発でのドキュメントとしては非常に価値があります。しかし簡単で即座に回答が必要な普段のコミュニケーションではオーバースペックなのです。

ブラッシュアップしていこう

最初は慣れるのに時間がかかるかもしれませんが、結果的に多くの時間を節約することができます。
draw.ioなどのアプリケーションを使えばコミュニケーションツールとの親和性も高く、編集や管理も簡単です。

普段から図を使ってコミュニケーションをしていくように心がけましょう。そしてどんどんブラッシュアップしていきましょう。

P.S

私がUMLに興味を持ち本格的に学ぶようになったのはこの書き方をするようになったのがきっかけです。もしあなたもUMLに興味をもつようになったらぜひとも本格的に学んでみてください。覚えておいて損はありません。

P.P.S

もしUMLに慣れてきて本格的に使おうと考えている方は「astah*」などのモデリングソフトを使うことをおすすめします。ドローイングソフトは図を描くという点では便利ですが、モデリングソフトならデータとしてしっかり管理できるのでそのあたりがすごく使いやすいです。

post image

なぜあなたの説明は上司や部下に伝わらないのか?

なんだか年を取るにつれて他人の話をあまり聞かなくなってきた気がします。
皆さんはどうでしょうか?

そんなことを考えているからかどうかわかりませんが、近ごろミスコミュニケーションによるトラブルについてよく耳にするようになりました。あなたも

  • 何回説明しても理解してもらえない
  • 相手と話がかみ合わない
  • こちらの話を間違って解釈されてしまう

など感じたことはないでしょうか?

「人の話をしっかり聞いていないのが悪い」
とつい片づけてしまいたくなりますが、もちろん職場の治安が悪ければそれが原因であるのは十分にあり得ますが…

そうではなく、もう少し健全な組織でのミスコミュニケーションについて考えてみましょう。

人は聞いた話をどこまで理解しているのか?

自慢ではないですが、私は部下の指示だけでなく上司への説明、打ち合わせでのファシリテーションでこちらの意図が伝わらずに困ったことはほとんどありません。

また、今まで多くの人と仕事をして様子を見てきましたが、自分と他者を比較してみると、どうやら「聞く力」ではなく「伝える力」が不十分なのが原因であると考えるようになりました。

以前とある上司が部下に対してこんな風に指示していたのを聞きました(内容は一部修正しております)。


上司

ユーザーがアプリからAPIを通じて外部サービスのデータを取得する機能を実装してほしい。構成としてまずユーザーがアプリからAWSにアクセスしてRequest Paramをマッピングし直したのちにLambdaが外部APIを呼び出してその結果を返すようにしてくれ。ただしアカウント情報が間違っている場合はユーザーをログイン画面に戻すように。

部下

承知しました。外部サービスにログイン情報を送って、違ったらエラーが返ってくるからその場合はログイン画面に遷移させればいいんですね?

上司

違う、そうじゃなくてその前にCognitoで認証処理を行うからそこで失敗したらログイン画面に遷移させてってことだ。

部下

なるほど、アプリ側でCognitoを読み込んで成功してからLambdaで処理を行うということですね。

上司

いやいや、CognitoのところもAWS側でやるんだよ。

部下

…???


結局部下はこの話を理解するのにかなり時間がかかっていました。
用語がいろいろ出てくる、前提条件が事前に説明されていない、誤解の招きやすい表現など要因が多いほど話は複雑になり、先に話していた内容も記憶から抜けていきます。

会話と記憶力だけでは限界があります。

図を使って視覚的に説明する

私は普段から図を使って説明するように心がけております。

先ほどの例を使うのであればこんな感じです。


ユーザーがアプリからAPIを通じて外部サービスのデータを取得する機能を実装してほしんだが構成はこんな感じになるように。認証がOKだったら2のリクエストをマッピングして(5と6あたりを指さしながら)ここを実行するように。


これだけでは大事なことについて十分に説明できていませんが、何となく何が伝えたいのかが理解できるかと思います。そこから次のコミュニケーションが生まれますのでさらに深く掘り下げていけばいいのです。

他にも図を使って説明することでこのようなメリットがあることに気づきました。

1. 全体を俯瞰しやすくなる

詳細や根拠は一切説明できておらず不正確な点も多々ありますが、少なくとも相手は全体像をざっくり理解できるようになります。
もし、全体像の認識にずれがあった場合は相手は素早くそれに気づき、的確に指摘することもできます。

2. どこについて話しているかがわかりやすくなる

これから自分がどこについて説明しようとしているのか相手はすぐわかるようになります。

3. 共通の認識(ユビキタス言語)を使ってやりとりすることができる

バックエンドで動いているコンピューティングシステムのことを「AWS」と呼ぶのか「Lambda」と呼ぶのかでいちいち議論することがなくなります。使う言葉を統一することで誤解が発生しにくくなります。お互いの認識にずれがなくなり、しまいには「これ」とか「それ」で会話がすすむようにもなります。

4. 簡単に記録に残すことができる

説明したことをわざわざ文字に起こすのは大変ですが、図を使えば比較的容易に記録として残すことができます。

5. 文章だけよりも理解しやすい

文章は冗長的になりやすく、理解にも時間がかかりますが、図を使えば簡潔にまとめられ、右脳も刺激するため直感的に理解できます。また図を書く行為そのものに自身の理解を整理する役割もあります。

図を使って説明していますか?

私もクラス図やER図を見ながら話をしているエンジニアはちらほら見てきましたが、普段のコミュニケーションや打ち合わせで積極的に図を使っているひとはほとんど見たことがありません。

これは何となくですが、偉い人達の打ち合わせほど口頭でのやりとりが多く図を使うのが少ないように感じます。

エンジニアリングの話もマーケティングや商品企画の話も複雑で、会話や記憶だけで理解できるほど簡単なものではないはずです。

紙とペンがあるなら、ホワイトボードがあるなら、もっと積極的に使いましょう。

では紙やペン、ホワイトボードがない場合は?
メールやコミュニケーションツールを使っている場合はどうすればいいのか?

そもそもどのようにして図を活用すればいいのか?

次回の記事では具体的に私がどのようにやってきたのかついて説明します。