スクラム開発について思ってること

はじめに

今年からスクラム開発をとりあえずやってみよう的な感じで実践してきましたが、
最近改めてスクラム開発の本を読んでみたこともあり、一度今までを振り返ろうと思いました。

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

よかったこと

コミュニケーションが増えた

デイリースクラムやペアプロを取り入れることで、メンバー同士のコミュニケーションが増えました。

問題が起きたときも早めに検知できるようになりました。

定期的に変化を取り入れられた

最初はプランニングとふりかえり、デイリーを毎日でした。

そこからデイリーを朝晩の2回やるようにしたり、ペアプロを取り入れたりと、
変化を取り入れながら進めていけました。

とりあえずやってみて、合わなかったらやめようというスタンスで、
メンバーもそこに前向きでいてくれたのが嬉しかったです。

うまくできなかったこと

中長期的な目標との兼ね合い

これは個人的な苦手意識もあるんですが、1週間イテレーションでスプリントを回すときに、
○ヶ月後にこうなってなきゃいけないから、この1週間はここまで進める必要がある、っていうマイルストーンをうまく置けませんでした。

スクラム開発って経験主義的で、やってみた結果が自分たちの実力でありそれ以上でも以下でもないという話だと思っていて、それにはとても同意です。

ただ、とはいえここまではやっとかないといけないよねっていうラインもあって、目標と現実の兼ね合いというのが難しいと感じてます。

役割が曖昧

自分の立ち位置が不明確でした。

個人的にはスクラムマスター的立ち位置を望んでいるのですが、それを合意したわけでもなく、
プロダクトオーナーにあたる人はおらず、自分とメンバーで話して方向性を定めていってました。

それによりなにか問題が起きたわけではないのですが、良いプロダクトを妥協なく追求できたのかという点には疑問が残ります。

今後取り組みたいこと

認識を合わせて、役割を明確にする

スクラムについて認識を合わせること。その上で役割を明確にすることを実践したいです。

プロダクトオーナーを担ってほしい人はいるので、その人も含めてスクラムについて考える機会を作ります。

中長期的な目標

正直ここはまだ具体的なアクションが見出だせてません。課題です。

おわりに

まだうまく出来なかったり迷っていることはあるものの、前進も作れているのでそこは自分を承認してあげようと思います。

あとスクラム開発を通じてメンバーが成長するのを実感するのはとても楽しいです。これが一番の原動力です。

1on1についての学びと今後の方針

はじめに

今年から部下との1on1をする機会を設けるようになりました。

今までは雑談と仕事の話を半々くらいで、とりあえず少しずつ信頼関係ができればいいかなくらいに考えていましたが、
今回1on1についての本を読んでみて今後に生かしていきたい点がいくつかあったので書き記しておきます。

シリコンバレー式 最強の育て方 ― 人材マネジメントの新しい常識 1 on1ミーティング―

取り組んでいきたいこと

毎回必ずひとつ良い点を見つけて伝える

シンプルに自分がされたら嬉しいなと思いました。

相手が自分のことを見てくれているという間隔にもつながると思うし、
こちらも部下の良いところを見つけようという姿勢に自然となるので必ずやりたいです。

相手を「承認」する

承認するというのは、事実を認めそれをそのまま素直に伝えることで褒めるとは違います。

参考書籍に出てくる例として、
「髪切ったね」が承認で、「髪切ったね、似合ってるよ」が褒めるです。

承認はただ事実を述べているだけなので、そこに嘘や忖度はありません。

これも相手の「存在を認められているんだ」という感覚につながる重要な考え方だと思いました。

他のチームメンバーの良いところを聞いてみる

他者の良いところを話すということは、感謝や尊敬の念に繋がりチームにいい影響をもたらすと思うし、
話している本人の幸福感にも良い影響があるという研究結果もあるそうです。

そこから良いところを言われた方に「〇〇さんがこういうところを褒めてたよ」って伝えてあげると、褒められた本人もとても嬉しいと思います。

直接褒められるよりもリアル感があっていいですよね笑

答えを伝えるのではなく引き出す

部下が困ったり悩んだりしているとき、自分がその答えがわかっているとつい「こうすればいいよ」と言ってしまいがちですが、
それではただ与えられたことをこなすだけになってしまい部下の成長に繋がりません。

部下が主体的に答えを導き出してくれると信じて、我慢強く対話や質問を繰り返していくようにしたいです。

逆ホウレンソウ

ホウレンソウというと部下から上司に対してのアクションを思い浮かべますが、
一方で成果を上げているマネージャーには、上司から部下に対して上層部からの情報を伝える「逆ホウレンソウ」をしっかりできている人が多いとのことです。

どこまでの情報を伝えるべきかというのはしっかり考えるべき点かとは思いますが、
基本的に情報はオープンになっている方が部下が主体的に取り組んだり考えたりするための材料になると思うので、積極的に「逆ホウレンソウ」していきたいです。

場所を変えてみる

自分はいつも会社のカフェスペース的なところで1on1を実施しているのですが、場所を変えてみるのは面白そうだなと思いました。

相手の好みにもよりますが、散歩しながらとか近くに公園があればそこで話すとか、外の開放的なスペースでやってみたいですね。

名前を考える

今はただ「1on1」という名前でスケジュールを登録していますが、名は体を表すというようにこちらの意図が伝わるような名前にしたほうが良いのかなって思いました。

できればちょっとユーモアがあってワクワクするようなのがいいですね笑

カッコつけない

リーダーである以上かっこ悪いところは見せられないとか思っちゃうこともあるのですが、
無理せずにメンバーと同じ目線で問題に取り組んでいけるようなリーダーでありたいと思いました。

おわりに

いろいろ改善点が見つかって、次の1on1がなかなか楽しみになりました。

実は今まではちょっぴり義務感とかもあったりしたんですが笑

焦らずにひとつひとつ改善をしていければと思います！

魚を与えるのではなく魚の釣り方を教えるということ

はじめに

私はエンジニアとして働いているのですが、
今年に入ってからチームリーダーとしてメンバーのマネジメントを担当することが増えてきました。

その中で、メンバーの指導というところで大きく考え方が変わったところを書きます。

これまで

リーダーの経験が浅く、どのように振る舞えばいいのかまだわからないことも多かったのですが、
とりあえず、チームメンバーが困っているときとか立ち止まっているときは積極的に声を掛けるように心がけていました。

この姿勢自体はこれからも心がけていきたいし、やってしかるべきだと思っているのですが、
ここで問題だったなーと思うことに、解決策をすぐ伝えてしまうコミュニケーションを取っていたことがあります。

当時は問題を早く解決して仕事を進めることがリーダーの責務であり、
それがメンバーの助けにもなると考えていました。

今思うと、メンバーの成長という観点が抜けていました。

学んだこと

メンバーが成長するには

人が成長するためには、

• 自らで問題を認識して、
• 主体的にその問題に対して取り組むこと。

が重要ということです。

自分がこれまでやっていた解決策をすぐに伝えてしまうコミュニケーションだと、メンバーはこのプロセスをスキップしてしまうことになります。

この点に気づき、自らのマネジメントのやり方を変えなくてはいけないと思うようになりました。

勘違い

一方で、自分もさすがに解決策を伝えるだけでは良くないとは思っていたので、
その解決策に至ったプロセスはできる限り詳細にロジカルに伝えるようにはしていました。

そのプロセスを理解してもらうことがメンバーの学びになると考えていたからです。

これも大きな勘違いをしていたなと感じていて、
メンバーは「頭では理解できたけど、実感は無い」みたいな状態になっていたと思います。

これではメンバー自身の気付きにはならないので、
その場では理解できていたとしても、成長にはつながっていなかったかと思います。

また、知識や物事に対するの認識は人によって様々なので、
その差から自分にとってはロジカルでも他の人にとってはロジカルにならないといったことも起きていたのかなと思います。

モチベーション

別の観点から、メンバーのモチベーションにも影響があるかと感じています。

問題にぶつかったとき、その解決策を他人から示されてしまうと、
他の人から言われたことをするという、いわゆる外発的モチベーションに繋がってしまうのかと考えています。

一方で、問題に対するアプローチを自分で考えて、決めるということをすると、
自らが意味があると判断したものに取り組むという、内発的モチベーションに繋がるのかと思います。

これから

メンバーが頭を悩ませているとき、その解決策をそのまま伝えるのではなく、
メンバーが自らその解決策にたどり着けるように促す質問をベースにしたコミュニケーションを取れるよう意識していきたいです。

参考書籍

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

モチベーション3.0 持続する「やる気!」をいかに引き出すか (講談社+α文庫)

「SOFT SKILLS」バカにされるのを恐れるな

SOFT SKILLS

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

最近「SOFT SKILLS」という本を読みました。

買ったのは結構前なんですが、そのときはちょっと読んでみたもののあまりピンとこず、そのままkindleでひっそりと眠っていました。

最近もう一度読んでみようかと手にとったところ、前読んだときよりも内容がずっと魅力的に思えて、一気に読んでしまいました。

なぜ今読んだらとても面白かったのか

おそらく、自分の持つ理想の将来像が変わったからだと思っています。

本を買った当時は、「社内でいかに価値のある人間になるか」が自分の成長の軸だったと思っています。

転職等は全く考えておらず、会社の外に目を向けるという発想があまり無かったように思います。

今は、「一人のエンジニアとして価値のある人間になりたい」という想いが強いです。

転職も考えるようになり、今の所属に縛られずバリューを提供できるようなエンジニアになりたいと思っています。

この心境の変化こそが、本を読んだときの印象がガラッと変わった一番の要因ではないかと考えています。

この本はまさに、エンジニアとして自分の人生をどう歩んでいくかの指針を示してくれます。

バカにされるのを恐れるな

一番印象に残った言葉です。この記事を書こうと思ったきっかけでもあります。

本書では、自分自身のマーケティングのためには、ブログや講演、勉強会等で定期的に発信を続けるべきだという旨が書かれています。

そのためには、自分がバカみたいに見えるのを克服しなければならないというのがこの言葉の意味です。

自分は発信することの大切さは理解していたものの、まさにこの「バカにされる恐怖」を過剰に感じていました。

このブログだったり、Qiitaやtwitterなどでアウトプットを続けようと意気込んでみるものの、どれも中途半端な状態です。

その要因のうちの一つがこの恐怖であると認識しています。

その恐怖を克服する第一歩としてこの記事を書いてみようと思いました。

他人に価値をもたらせ

また本書では、自分自身のマーケティングについて、他人に価値をもたらすアウトプットをすることが肝要だと述べられています。

アウトプットを増やしてもそれが誰の役にも立たなければただの独り言なので、いかに価値をもたらすかを忘れないようにしたいです。

この記事で言えば、SOFT SKILLSに興味を持って読んでくれる人がいればとても嬉しいです。