北のエンジニアの学び備忘録〜時々、野球〜

自分らしくイキイキ働ける環境を追い求めるエンジニアの学びの記録

明日から試したい会話のTips

はじめに

今回の投稿は「キミが信頼されないのは話が「ズレてる」だけなんだ」の読書メモです。

話のピントが合う「2つの質問」

「具体的には?」「たとえば?」の2つを使うことが、話のピントを合わせる定番らしい。
相手が曖昧な表現や、抽象度の高い言葉を使って話している時に、同じイメージを持って会話ができるようにするための質問と理解した。
自分から話す時にも、「具体的な例をあげると・・・」と言った形で補足することを意識して、話し相手に同じイメージを持ってもらえるように意識することも必要と学んだ。

相づちで使える「3S+あいうえお」

「3S=さすがですね、すごいですね、すばらしいですね」を使うことで、話し相手がノッてくるらしい。
(確かに、自分が話している時にこの言葉が聞こえると、調子に乗って話し続けてしまうかも。。。)
「あいうえお=あー、いいですねー、うーん、え!?、おー」を心の中で唱えると表情やリアクションが変化して、話がはずむらしい。
(確かに、Zoomなどのオンライン会議だと相手のリアクションが大きいか小さいかで雰囲気が変わってくるなぁ)

自分が参加したZoom会議を録画して聞き直したことがあったが、その中で自分の相づちが残念な印象があった(不機嫌なように聞こえる相づちを連発していた)ので、改めて、自分の相づちを見直したいと思った。

話をするときの基本は「丁寧に」話すこと

「漏れなく」「細かく」を意識することで、丁寧な表現になるらしい。
この点は日頃から意識できていると思うが、先日、同僚から「自分の意見を言うことで満足している。会話になっていない」と指摘されたことを思い出した。
丁寧に話すことだけでなく、相手の反応(話についてきているか、興味を持って聞いているか、etc)を感じながら短く&シンプルに話すことを心掛けたい。

まとめ

知っているけど、実践できていないTipsに出会えました。明日から実践します。

アラフォーから鍛える具体と抽象

はじめに

今回の投稿は「13歳から鍛える具体と抽象」の読書メモです。

抽象化が苦手だから、会話の中で簡潔に答えられないのか

[「13歳から鍛える具体と抽象」本文(50pp.)から引用]
抽象化してまとめた言葉や概念を扱うことができないと、周りの人から「話の長い要領を得ない人」と思われることになります。逆にいえば、抽象化がうまくできるようになると、「要点を簡素に説明できる人」になれるということです。

仕事でもプライベートでも、自分の話しているターンで相手の表情が徐々に曇っていくことがある。
自分の言っていることが伝わっていないんだなぁ、、話が長くなって相手を困らせているなぁ、、と自覚しつつも、自分の何の能力が劣っているからそうなるのか、何を鍛えると改善できるのかが、言語化できていなかった。
この本を読んで、それを言語化できた気がする。具体的なエピソードから抽象化して表現することが苦手なのだ。

賢くなるための基本をアラフォーになって知った

[「13歳から鍛える具体と抽象」本文(70pp.)から引用]
私たちが経験から学んで賢くなっていくプロセスは、同じように最初に具体から抽象への「抽象化」が起こり、その後に抽象から具体へという「具体化」が起きるという順番になります。
(中略)
私たちが賢くなっていくためには「具体と抽象」を行ったり来たりすることが基本であることがわかるでしょう。

学生時代の試験、社会人になってからの資格試験、仕事での担当業務でも同じようにその瞬間、その瞬間を対処するのに必要な知識を丸暗記したり、先人の真似をすることで、乗り越えてきた。
その時に具体と抽象を行ったり来たりするような思考プロセスを意識することはなかったので、無意識のうちにできていたのか、たまたま上手くいっていたのか。。。
恐らく後者だと思う。何となくこなすのではなく、意識して「抽象化↔︎具体化」のサイクルを回すことで、経験を知識に変換し、再利用可能なものにしていきたい。 (スクラムのベースの1つである「経験主義」に通じるものだと認識しました)

「考える」ための疑問詞:WhyとHow

[「13歳から鍛える具体と抽象」本文(81pp.)から引用]
たとえばWhyとは手段と目的(何のために必要なのか?)を結びつけるものであり、Howは逆に目的と手段(どうやって実現するのか?)を結びつけるものといえます。
ここでの手段と目的の関係は、「見えやすいものと見えにくいもの」「一つの目的に対して手段は複数あるという関係性」から、具体と抽象の関係の一種と見ることができるので、具体を抽象にするための疑問詞がWhy、抽象を具体にするための疑問詞がHowということもできるでしょう

最近仕事で、「あなたの文章にはWhy(なぜ、それをやらないといけないのか)が表現できていない。そもそも、Whyを理解できてないでしょ?他の人の考えを鵜呑みにして、考えることを諦めていない?」と指摘されたことを思い出した。
冒頭で抽象化することが苦手と表現していたが、苦手というよりも、抽象化のトレーニングを避けてきた結果の現状である。
「抽象化↔︎具体化」のサイクルを回すために、「Why」と「How」を言語化することを意識して取り組みたいと思う。

まとめ

既にアラフォーの身ですが、このタイミングでこの本に出会えたことに感謝して、「抽象化↔︎具体化」のトレーニングに勤しみたいと思います。

自分はミーティング駆動型で、無意識にエンジニアの時間を無駄にしていたことを知った

はじめに

今回の投稿は以下の記事を読んで感じたことの備忘録です。

1日のスケジュールを1時間単位で区切るマネージャー

これまでの私はこの考え方で社会人生活を送ってきました。ずっと馴染めないと思い悩んだ学生時代の時間割のごとく、週単位のカレンダーの隙間を縫うようにミーティングの予定、ミーティングの準備の予定を詰め込んでいたなと、、
↑の記事を読んで思い返しました。今思うと、ミーティングをすればするほど、仕事をした気になっていた気がします。。

1日のスケジュールを半日単位で区切るエンジニア

↑の記事によると、モノを作る人たちに共通する時間の使い方、最低でも半日単位で時間を使うことを好むらしい。
(最低でも半日単位が辛うじて始めるのに十分な時間らしい)
これが現実だとすると、自分が過去に担当したプロジェクトマネジメントはとても不毛で、無駄なことをしていたに違いない。。
「1人日が8時間、⚪︎⚪︎のタスクは3時間もあれば終わるだろう、同じくらいの規模のタスクが◻️個あるから、、、」という感じで Excel上に計算式を組み、スケジュールの見通しを立てていたし、
エンジニアが算出した見積もりの根拠に対しても、タスクごとに⚪︎時間(または0.X人日)と積み上げるように指示していた。

加えて、開発週次定例、システム運用定例、システム課題棚卸会、etc、、といった具合に30分〜1時間単位のMTGを毎日のように設定し、エンジニアの開発時間を断片化させ、マルチタスクを生み、結果、非効率な働き方を強いていたんだなと気付くことができた。。

カレンダーの余白は空き時間ではない

これが今回一番、肝に銘じたいと思ったキーワード。
エンジニアが纏まった開発時間を確保できるように(マルチタスクによるスイッチング等、非効率な時間を生むキッカケを作らないように)
日々のスケジュール登録、調整に気を配りたいと思います。

リソース効率とフロー効率について

はじめに

先週に以下の記事を読み、これまで参画したプロジェクトで上手くいかなかった原因の1つがこれか!と腹落ちしたので、その備忘録です。

リソース効率が高い=生産性が低い?

これまで参画したプロジェクトではリソース効率(Devメンバーの稼働率)を日々チェックし、マネジメントを行っていました。
Devメンバー全員が常に、何かのタスクを持っている状態を維持することが最短でリリースできる手段だと信じて、日々進捗状況を細かく確認してWBSを更新していました。

この考え方に以下のデメリットがあることを十分に認識できていませんでした。。

引用
リソース効率を高めると個人のやっている感は高くなりますが、一方で
・待ちが発生する分マルチタスク化が進み、リードタイムも悪化する
マルチタスクが作業効率をさらに低下させる(スイッチングコストの上乗せ)
・予備戦力がないので完了時期が読めなくなる
などの凶悪な弊害も発生します。

↑の引用記事に記載の通り、これが正しいと教わってきた身でしたが、「スイッチングコストが〜」や「予備戦力がなくて〜」については、Devメンバーから時折投げかけられていたキーワードにあったなぁとも思い出し、、リソース効率を追い求めることに疑問を感じる場面はありながらも、これ以外の手段を検討せずに進めてしまっていたなぁと後悔の念が湧いてきました。。

フロー効率が高い=生産性が高い?

各タスクの開始から終了までのリードタイムや、ある機能を開発するためのバックログが起票されてからリリースするまでの期間が短い、=フロー効率が良いと理解しました。

引用
フロー効率に焦点をあてると、「生産性を高める」という言葉の指す意味が変わります。開発者を「リソース」と見立て、彼らがどれだけ多くの仕事をさばいているかというメトリクスへの関心が薄れます。稼働率(リソース効率)がいくら高くても、フローが停滞し、進みが遅ければ意味がないことに気づくからです。
追求すべきは、フロー効率を高めてリードタイムを短くし、フローのスループットを高め続けることです。そうすれば、稼働率も自然と適切なレベルにまで上がります。それこそが、「生産性が高い」と呼べる状態でしょう。

フロー効率の良さをざっくりと引用してしまったが引用元の記事を読んで、フロー効率を高めることがプロダクトの価値、そのプロダクトを利用する人たちの満足度を高めることに繋がると感じました。

まとめ

リソース効率を追い求めていた過去の現場では、その関係者が疲弊する日々でした。
フロー効率を良くすることと、それに関する関係者理解を追い求めることが、無理のないプロジェクト運用を実現できると感じました。
リソース効率に捉われずに、フロー効率を意識したマネジメントを実践していきたいと思います。

認定スクラムマスター(CSM)になれたけど、、、その道険し。。。

はじめに

認定スクラムマスター(CSM)講座を受講後のオンラインテストを受験しました。
(制限時間:60分、問題数:50問、4択の選択式、37問以上の正解で合格)
結果は「47問の正解」で「合格」となりました(正式に認定されました)。

オンラインテスト向けの学習の記録

CSM講座を受講した際に講師から、以下の資料から出題されると説明を受けたので、

CSM講座の復習を1回、上記資料を3周読み込んで試験に臨みました。
既にスクラム開発を行っている現場で従事できていたお陰か、見聞きしたキーワードが多く、時間に余裕を持って回答&合格となり、安心しました。
(講師や会社の同僚から「難しい試験ではない」と聞いていたので、1発で合格できて安心しました。。)

(直近の)現場での経験

研修、テストに向けた学習を通じて各スクラムイベントや作成物、価値基準を理解できたと思っていましたが、現場で実践する難しさを日々感じております。。
今今で特に難しいと感じているのが、PO支援で行っているプロダクトバックログアイテム(PBI)を整理することです。
担当するプロダクトが持つ機能や、その機能を実現しているアーキテクチャへの理解度が浅い中で次のスプリントプランニングまでに、POとPBIの内容をすり合わせてReadyにしないといけない、、
かつDEVメンバーと適宜会話しながら次スプリントで実施予定のPBIがベロシティ内に収まりそうか(届かないことはないか)を見極めないといけない。。

スクラムのスピード感に圧倒されながら、スプリントレトロスペクティブに備えてチームを観察しつつ、次スプリント以降のPBIを整理する。

これらの対応に苦戦する日々が続いており(勝ち筋はまだ見えておらず)、毎日疲労困憊で帰宅している気がします。。

まとめ

認定スクラムマスター(CSM)のテストに向けた勉強の記録と、現場で難しいと感じたことを整理しました。

今は調整が必要な障害事項が発生していない、かつチーム内の手厚いサポートを受けられている期間でもあるので、、
知らない事や出来ない事に臆せず(勇気を持って)、1つ1つの事象を学びに昇華したいと思います。

勇気(Courage)を得るためのTips

背景

Agile Business Institute Inc.主催の認定スクラムマスター(CSM)講座を受講しました。
研修の内容や雰囲気が詳しく記載されている記事を見つけたので、詳細な記載は割愛します。
(私が参加した会も同様のものでしたので、引用させていただきます) zenn.dev

学び

研修終了後に講師へ直接質問できる場があり(ボーナスタイムと呼ばれていた)、実務で感じていた悩みに関する質問ができたので、 その内容と講師から頂いたアドバイスをここに記録したいと思います。

【実務での悩み】

直近でスクラム開発を既に適用しているチームに参画した。
(自分はスクラム開発を初体験、チームメンバーは全員経験者という状況)
その中でスクラムマスターとして立ち上がっていこうというモチベーションで取り組んでいるが、スクラム開発やプロダクトの内容、それを支える技術要素等について無知であることをオープンにしていくことを恐れてしまい、立ち上がりに時間がかかっている。
スクラムの価値基準の1つである「勇気(Courage)」を実践できていないように感じている)

【講師から頂いたアドバイス

「勇気(Courage)」を実践するためのコツ、アドバイスを求めたところ、以下のコメントを頂いた。
(とても曖昧な聞き方をしたのだが、私の現状を踏まえた回答をもらえて、凄く救われた思いでした)

  1. ペアワーク(共同SM)をリクエストする

    1日、1週間でも良いので一緒にSMを伴走してくれるようにチームにお願いする。

  2. 「3−5−3」(3つの責任、5つのイベント、3つの作成物)に集中する

    チームメンバーは様々なアジャイルラクティスや開発知識を知っているかもしれないが、「スクラムマスターとしては『3−5−3』だけを知っている必要がある」「『3−5−3』に集中すれば良い」と言い聞かせて、自分自身をリラックスさせることに集中する。

  3. ゲームを楽しむ

    アジャイルはゲームなので、楽しむことが重要である。楽しむマインドを忘れない。

  4. 成功体験を積み上げていく

    自信を持つために一番の近道は成功体験を積むこと。簡単なもの(例えば、バックログを見やすくする、等)を選んで成功体験を得ること、それの積み重ねが大事。

余談

社会人13年〜14年目を迎える今日この頃、インプット過多でアウトプットができていませんでした。以降、週1回の頻度を目標に学びをこの場等を使ってアウトプットしていきたいと思います。
(1/21までに初投稿することを目標にしてましたが、何やかんやで、日付を跨いでしまいました。。反省。。)