チームの成長を考える
システム開発の現場だとチームで何かを作るというのが当たり前のように行われていて、チームの力を高めるとかチームを成長させるとかを考えなきゃいけないわけだけど、実際のところ何をすればよくて、どうやって成長を測ればいいのか、というのがよくわからなくなってきたのでちょっと整理する。
チームとは
いろんな人が言ってることの影響を受けているので誰が何を言っていたか覚えてないけど、自分の中ではチームは以下の定義があると理解している。
- チームの目的・目標が明確であり、メンバー全員がコミットしている
- チームの目的・目標のためにメンバーはお互いに助け合う
チームというのは1つの生きもので、構成メンバーはそれぞれ自分が得意とする分野で貢献する。
メンバーは個であると同時に全の一部なわけで、運命共同体とも言える。
チームの成長とメンバーの成長は密接に関係している(当たり前だけど)
成長とは
成長って言葉もフワッとしてるので、ちゃんと定義すると、
- できることをさらにできるようにする(質・量・速さなど)
- できないことをできるようにする
という感じかな。
チームの成長
まずはチームになることから始めるといいのかな。
何のために集まってるんだっけ?ということを明確にして、何を成し遂げたいのか、目標を明確化して全員がそれにコミットする必要がある。
その際に、心理的安全性を意識しないと、声の大きい人の意見だけでなんとなく方向性が決められてしまう。全員が考えを表に出せるようにする必要があって、そのために心理的安全性を確保する必要があるのだと思っている。
チームの目標が定まって全員がコミットできたら、メンバーそれぞれがどのように貢献するのかをはっきりさせた方が良さそう。そうすることでチームの強み・弱みが明確になって、できること・できないことを区別できるようになる。
個人の得意・不得意と同様に、チームの得意・不得意を把握して、伸ばすべきポイント、補う必要があるポイントを明確にしたい。
チームの目標という軸があって、全員それを基準にやるべきことを考えれば、助けを求めるポイント、助けるべきポイントもわかるんじゃないかなぁ。
それに上記を整理することでチームのパラメータが可視化されて、その後の成長度合いも測りやすくなりそう。
あとはお互いリスペクトを忘れないこと。
チームメンバーを貶めてチームに得になることなんてないし。
同じ時間で、より多くのことを、より高品質でできるようになれば成果にもつながると思ってる。
1人1人が成長して、チームのためにその力を発揮すれば、チーム全体の力も上がっていくと思う。
自分は何者なのか
このブログの目的は、自分の内に留めていた色々なことを表に出して自分というものを再認識すること、なので、まずは現時点での自己紹介を書いてみる。
パーソナルな部分
属性
- 1982年生まれ
- 男
- A型
- やぎ座
家族
- 既婚、子供2人(5歳息子、2歳娘 ※2019年5月時点)
- 共働き
- 妻はバリバリ仕事したい人
- 自分にないものをたくさん持ってる妻を尊敬している
- だから家計が問題なければ主夫になってもいいと思ってたこともある(最近は仕事も楽しいから仕事もしたいけど)
- 家事は洗濯担当
- 洗濯は好き、掃除は嫌い
- 料理は嫌いじゃないが苦手なのであんまりしない
- 子供は2人とも可愛い
- でも最近あまり一緒の時間を過ごせてない
- 電車好きの息子に振り回され気味
- 車好きの娘を昼寝させるためにドライブするの好き
趣味
- 車好き、MT厨
- 某イタ車が愛車だが故障が多くて次は日本車にしようと思っている
- 冷房が効かないのがつらい
- タイベル交換5年ごともつらい
- 某イタ車が愛車だが故障が多くて次は日本車にしようと思っている
- テニス好き
- 好きなプレースタイルはサーブ&ボレー
- 好きな選手はピート・サンプラス、パトリック・ラフター
- 2000年頃に一度テニスから離れたが、2017年から試合を観たり、自分がプレイしたり(オートテニスで練習)を再開
- 2019年はまだ一度も練習出来てない
仕事など
経歴
1社目
- 新卒1社目は自動車のエンジン部品メーカー
- 6ヶ月の工場実習でライン工を体験
- その後生産管理部に配属され、船舶エンジンの部品などを担当(1年半)
- 経験したこと、学びなど
- 業務効率化
- 生産計画立案とマネジメント
- 他部署(製造現場、品質管理、営業、製品出荷、研究開発など)との調整
- 外注パートナー企業との折衝
- 新製品の立ち上げ管理
- 生産管理システムのリニューアル(自身が携わったわけではない)
2社目
- 現職。システム開発会社
- 13番目の社員
- プログラマーになりたくてITへ転職したが、生産管理の経験を買われてマネジメントへ進むことに
- 実装経験がほとんどないのは弱み
- その分マネジメントの経験が豊富なのは強み
- 自分が出来ないからこそ、メンバーの意見を尊重して信頼して任せることが容易
- とはいえ、設計はしてるし、LinuxコマンドやSQLも覚えたり、全く出来ないままというわけでもない
プロジェクトマネージャー
- 一応会社での肩書きはこれ
- 会社は社員数40名程度のシステム開発会社
- やってることは
技術的なこと
- プログラミングは素人同然
- PHPなら多少読める&簡単な修正くらいなら出来る
- SQLはある程度読み書き出来る
- Linuxもある程度操作は出来る
- AWSはEC2、S3くらいは自分で構築して使ったことがある
- Gitはそれなりに使っている
- 全体的に開発のサポートがある程度出来るレベル
価値観・考え方
- 最高のプロダクトは最高のチームから生まれる
- チームの質はリーダーの質で決まる
- メンバー全員が最高に輝ける環境を作るのがリーダーの仕事
理想のチーム・組織とは
- メンバー全員が同じ目的に向かって高いモチベーションと専門性を発揮し、助け合いながら楽しく成果を出すことの出来るチーム・組織
- ゴールの明確化
- モチベーションを高く維持する
- スキルの継続的な向上を促す
- コミュニケーションの質を高く維持する
- 楽しく!
- 全ては仕組み作りが重要だと思ってる
興味
今までやってきたこと
- テスト
- テスト設計
- テスト実施
- 要件定義・基本設計
- 主に業務用システム
- システム担当者ではなくユーザの声を聞く
- 読み手を意識したドキュメンテーション
- コスト・スケジュールを意識してスコープを調整
- 1on1の導入
- メンバーの話したいことを話してもらう場
- コミュニケーション頻度を高める
- 週1回30分
- メンバーの意思を尊重
- ふりかえりの導入
- 1on1やふりかえりを実施したことによる副産物
- コーポレートサイトの完全リニューアルをチームメンバーが主導して実施
- 社外イベントへの登壇
- テックブログ運営方法の改善
まとめ
ざっと書き出してみたが、10連休で家族との時間を優先していたとはいえ、書き始めてから1週間以上かかってしまった。
書きながら気付くことも多く、これは都度加筆・修正をしていった方が良さそう。
ふりかえってみると、キャリアの初期からマネジメントが業務の中心だったんだなぁと改めて感じる。
そして最初の職場から、受注生産製品(船舶用部品は完全に受注生産で、常に受注数>生産数だった)を担当して、計画に従うことの困難さに直面していた。
今思えば、あの頃からアジャイルな対応を必要とする現場にいたんだなぁと。あの頃はアジャイルなんて言葉も知らなかったし、上司に相談するくらいしか自分には出来なかったけど、今ならもっと効果的な対応が出来そうだなと思ったりもするけど、そのあたりは別の機会に考えを深めてみようと思う。
自分探しの旅に出ました
会社のブログはちょろちょろ書いてきたけど、個人では何も書いてなかったなーと思ったのでブログを開設してみた。
タイトルに特に意味はないのだけれど、ネーミングセンスがないので適当に。
まあでもこの名前にしたのは、考えてることを垂れ流していれば、なんとなく自分の輪郭が浮かび上がってくるかなと思ったりしたので、自分という1人の人間がそのうち表現されてくるんじゃないかという意味を込めてたりはする。
飽きたらそのうち名前変えるかもしれないけど。
今はなんとなくそんな気分なだけ。
次回からはもうちょい真面目に書きます。たぶん。