tobb422のブログスマートフォン用の表示で見るtobb422のブログスタートアップエンジニアの奔走この広告は、90日以上更新していないブログに表示しています。チームビルディングはじめに完全に迷走して、自分でも調子乗ったタイトルつけたなって思うので、許してください。スタートアップで開発をしているエンジニアです。実務を通して得た学びや、書籍を通じて得た視点を言語化する練習も兼ねて、つらつらと書いていきます。人数がふえてい増えていく中でチームに対して考え方が変わってきました。「理想のチーム」について考え、取り組むというサイクルを回していました。これ自体見当違いだ!と思っているわけではないのですが、私自身の考えとして「良いチームを作ることが目的」ということに非常に違和感を持つようになりました。いまでも「カッコいい開発チームを作りたい」という漠然とした理想は持っている一方で、こうした良いチームというものは、あくまで自分達が取り組んだ結果かもしれないと考えています。私の中でこの変化は非常に大きいものでした。開発速度を上げるために必要なことメンバーが自律的に動けるきっかけといった具合に、いわゆる「仕組みづくり」です。実際これは程度の問題で「良いチームとは?」を考えて、仕組みづくりにたどり着ける方も多くいると思います。「チーム・事業にとって、良い仕組みを作ること」を目的にするほうがしっくり来たという話です。実際にチームビルディングをしていく中で、後者のほうがしっくりきています。ここからは、「良い文化が良いチームを作る」という前提で話を進めます。良いチームは、成長で作られる私の好きな言葉に「偉大な(高機能な)チームは成長によって作られる。雇うことで作られるものではない」という言葉があるのですが、最近この言葉がより一層好きになってきました。事業が上手くいっていない、またはチームとして上手く成果を出せていないときにチームとしての真価が問われているなと思います。今いる人材では決して上手く回らないと決めつけ「スーパースターの獲得にかける」チームは、個人的にあまり好きではありません。スーパースター級な人材が多いことは、良いチームの必要条件ではないはずです。再現性も高く、非常に価値のあることだと考えています。どんなにスーパースター級な人材が集まったとしても、チームとして課題は生まれます。「良い文化が良いチームを作る」という前提に立ち返るとチームで課題が出た際に必要なのは、文化(仕組み)を見直すです。課題」の関係を作りやすいです。個人」の構図に持っていくと(例で出したのは少し極端すぎましたが...)一向に話が進みません、、そして心理的安全性も担保されないです。課題」の構図をいつも保てるような仕組みを考える必要があると思っています。良い文化が生まれやすく、結果良いチームにつながると思うので、非常にいいなと考えています。良い文化は、実験から生まれる(そろそろ、着地見失ってきました。私は、チーム・事業の状況や最終的なゴール・ビジョンによって変わるものだと思ってます。したいという想いが持つことができるみたいなものはあるかなと考えています。結局、みんなで考えて、本当にこの仕組みはやりやすいのか(事業が回るのか)を試していくことでしか良い文化(仕組み)は作れないのだと思っています。ここを一種の実験だと楽しめる人は、素敵だな〜と感じる今日このごろです。課題に対して、仕組みや環境を整えることで解決しようと取り組みカイゼンを回すことで、良い文化は生まれ、結果、良いチームが作られる(はず)まとめ(完全に着地点見失って辛くなってきたので、ここで無理やり終わらせます。)最近チームビルディングで考えていることは良い文化が、良いチームを作る良いチームは、成長から生まれる良い文化は、実験から生まれるでした。使った新規プロジェクトを担当することになりました。本投稿は、その読書メモです。読書メモなので、私が読むことを想定して書き殴ります。ターゲットとしている層は、「既にReactでアプリケーションを書いている人がステップアップするという位置づけ」らしいです。あとで気がついたが、なぜかこの書籍だけはてなブログの「Amazon商品紹介」で選択しても表示できない...https://www.amazon.co.jp/gp/product/1789530172雑感としては、知らなかった概念や機能を知るきっかけになったが、プロダクトに導入するには、この書籍だけでは理解を深めるのが難しかったです。Hooks今回の新規プロジェクトで既に使ってみています。関数で定義していくことに優しい世の中になっているように感じます。以下の記事とドキュメントを利用して、キャッチアップしました。比較して語られているケースを良く見ます。コンポーネントを渡すのではなくて、関数を渡すということです。実際に使用されているソースコードを見つけたので、そちらを見るとなんとなく理解が深まるかもしれません。関数で定義したコンポーネントをラップして、返してくれるようです。使えば正解というわけではなさそうです。用法用量お守りください。ドキュメントに書いてあると通りなのですが、無駄なノードを追加しなくて済む書き方と認識しておくので問題なさそうです。まとめ非常に雑ですが、読書メモなのでこれで良しとします。序盤でも触れましたが、普段開発してて知らない概念や機能に触れることができたのはよかったかな〜と思っています。図で表すとこんな感じです。上記を実現するためのサンプルです。Webページのレンダリングは省略しています。コンテナに必要なツールをインストールして稼働させました!もちろん、必要なツールが揃っていれば、ローカルで直接稼働させることもできるはずです。動かすということ自体はよく記事になっているので、省略します。組み込めるのでこちらも省略します。操作を簡単に行うことができれば言語は問わないと思います。いったツールを使えば、その辺りもうまくできそうです。いうスタートアップ企業にてエンジニアをしています。ところから現在は、5人のエンジニアで開発を進めるまでにチームが大きくなってきました。β版プロダクトから正式版リリースに向け、チーム一丸となって開発を進めており、より一層スピード感を持って開発できるよう日々試行錯誤しています。今回は、「スピードをあげるために何が必要かと」いままで考えたことをまとめておこうと思います。チームの開発速度を上げるチームの開発速度を上げるためには、以下2点を実現する必要があると考えました。リリース)を短くする以降、上記2つを実現する方法を考えます。同時に実装できる機能を増やす現在、開発チームでは、ストーリー毎に開発を進めており(たとえば、ユーザーがサインアップできるといったイメージ)要は、同時にこなすこのストーリーの数を増やせば良いと考えています。新たに開発者を増やす既存の開発者が分身するこれまでの経験から、同一人物が同時に複数のストーリーをこなすのはあまり現実的ではないと考えており並行するストーリーを増やすためには、新たに開発者を増やすことが必要だと考えています。リリースと一貫して担当していただける方を採用しなければなりません。人物像(スキルセット)は明確になり、ターゲットは絞りやすいです。採用して、同時進行できるストーリー数が増やせなければ意味がないので、採用をゴールにしないよう心がけています。自走できるようになるまでのコストを低くしていくことも必要だと考えています。チーム思想が明確にあり、意思決定の指針となっているドキュメントが充実しているといったことが満たされていれば、自走までのキャッチアップもしやすいと思います。リリース)を短くする1ストーリー辺りにかかる時間が短くなれば、プロジェクトは全体的に前倒しになるためリードタイムを短くできるよう心がけています。仕組み化を進めて、あらゆる面でチューニング可能だと考えています。以下はチューニング可能な項目です。実際のデプロイ時間などあらゆる工程を少しずつ短くでき、トータルでかかる時間は大幅に短縮されると考えています。各工程を割り出して、それぞれのリードタイムを短くするためには?と考えることで、より具体的な施策へ繋げらることができたと思います。(今後、具体的にどういったことに取り組んでいるかもブログで紹介できるといいなぁとおもっています。リリース)を短くすることが必要ではないかと考えています。そこから下位分析をしていくと、ドキュメントをしっかり書くチームのバリューを明確にするといった割とよく言われているプラクティスにつながりました。開発チームとしては、クライアントに継続的に価値を提供し続けられる開発体制を作るべきであり、その際に、開発速度は非常に重要な指標ではないかと考えています。ハックしていかなければいけないのではないかなぁ〜と日々思っている今日このごろでした。(最近ブログ更新をサボっていて、久々に書くとうまく文章かけない。未来の自分のためにも一度整理しておきます。開発することを想定しています。ついて以下のような要素を挙げていました。APIの品質検査方法として、以下を挙げています。(SSKDs)を想定しているわけではないのですが、いずれにせよ、参考にできることは非常に多いと、私は考えています。詳しくは、書籍をご覧ください。ホットワードになっています。使いやすさは向上するのではないかと考えおり、チーム開発において、ハッピーになれる人が増えると思っています。一貫性があるAPIを開発するために...一貫性を確保することは、非常に難易度が高いです、、そして、チームの人数(関係者)が増えれば増えるほど、運用が難しいように思えます。開発するために心がけていることをメモしておきます。開発者向け)詳しく追っていきます。従うことを意識するのが良いかなと思っています。返す上記に従う形で、設計をするのが良いのではないかと考えています。エンティティ)」と同じではないと考えています。して語られているようにも思います。扱いやすい単位に、各エンティティを集約することが重要な気がします。1つのモデル」ではないということです。層と呼ぶことが多いです。利用しやすい単位にまとめて返すことが良いと考えています。各ページに依存してしまうのは良くないので、難しいところです。リソースを定義するために、フロントエンドチームと議論しながら、そのアプリケーションで扱うドメインの定義を行っていく必要があると思います。公開しているエンドポイント、そして定義されているリソースを書いていくようにしています。ライブラリを導入することで自動でドキュメントを出力してくれます。同じような仕組みを取り入れていると思うので、そちらを利用するのが便利だと思います。命名規則や、アンチパターンなどをまとめておくようにしています。リソースの定義も書いておくと良いかもしれません。一貫性を確保には、メンバー間での調整がかなり必要で調整をなくすためにも、明文化できるものは全て記載しておくくらいでも良いかなと思っています。開発者は、全てを知らなくても良いコーディング方法を見つけられる(選択的無知)を意識して置くことも必須です。運用する要素として、以下の要素挙げました。開発者向け)もちろん、これが正解というわけではなく、1つの考え方として思ってもらえると幸いです。「1人目のエンジニアとして、スタートアップに入社して1年経過した」というエントリーを書きました。開発チームのチームビルディングについて書いてみたいと思います。タイムラインまず、前提知識の共有のためどんな形でチームが変化したかを簡単に説明します。雑用(私)1名の体制へと、こんな具合にチームは拡大しています。開発チームのさらなる拡大を図っています!ご興味お持ちいただける方はぜひw以下は、全てチームビルディングとして、取り組んでいる具体的な施策の紹介です。恒常的に行っているもの以下の取り組みは、恒常的に行っているものです。チームとして活動する上で、必要不可欠な取り組みだと考えています。スプリント計画チーム開発がスタートして一番最初に行った施策が、スプリントの実施でした。2週間を1スプリントとして実施しており、チーム一丸となってプロジェクトを前に進めることを前提に見積もり(プランニングポーカー)の実施で短中期的な計画の精度をあげることや振り返りの実施でチームとしての成熟度を高めることを目的としていました。振り返りの際にでてくる視点も様々なものがあり、大変興味深いものでした。現在のチームでもスプリントを実施しており見積もりと振り返りを定期的に行い、チームとして成熟度を高めていけるよう心がけています。チームらしさを作る意味で大きな役割を果たしていると思います。プロダクトバックログこちらもチームメンバーが増えても実施し続けている施策の1つです。スプリント計画を行うことで、2週間ないしは、1ヶ月先のプランニングはできるようになってきました。長期的な計画に対しては、不確かなものが多く、3ヶ月先の着地に相当なブレがある状況が続いていました。(いまでも、完全に解決できているわけではないのですが...)そこで、スプリントでは見えてこなかった、もう少し長期的な計画としてプロダクトバックログを取り入れることにしました。6ヶ月先に自分たちがどれくらいできそうかを見積もることができるようになってきました。ボードメンバー等、他のチームに説明ができるように心がけています。デイリースクラム毎日、夕方にチームメンバーで進捗共有を行っています。目的としては、チームの進捗確認でチームがスプリントで立てた計画を無事実施できているかの確認タスクの優先順位の確認を行っています。これらの確認のために、カンバンを導入しておりチームとして抱えているタスクの可視化ができるようにしています。個人で実装や設計で悩んでいることがあればチームで解決していけるように心がけています。弊社ではリモートワークも取り入れており、普段は何をやっているのか全く見えない状況だったりもするのですが、このデイリースクラムのおかげで常にチームの状況を把握できるようになっています。4人と増えてきたタイミングで復活しました。必要に応じて行っているもの以下の取り組みは、状況に応じて実施しているものです。ほとんどが、恒常的に行う施策を機能しつづけさせるための点検・すり合わせの責務を担っています。オンボーディング新しくメンバーが増えたタイミングで行っています。共通して行っているオンボーディング施策として、キックオフMTGがあります。いまのところ、開発チームメンバー全員参加で行っている施策で以下のようなアジェンダで実施しています。どんなことでチームに貢献したいと考えているのかをチーム間で共有することで、タスクの振り方などにちょっとした差が出てくると思っています。教えてもらう場を作ることを意識しています。最後の期待していることをしっかりとメンバー間で伝え合うことで、期待値のすり合わせも行っています。した価値観の共有を行うことが非常に重要だと考えています。人数が増えてくると、カンバンが上手く機能しなくなってきます。これは、カンバンにかかわらず、スプリントの方法やプロダクトバックログの方法にもいえることなのですが絶えず変化するチームの中で、常に完璧な方法は存在しないです。そのため、定期的に時間を取り、それぞれの取り組みが現在のやり方で果たそうとしている目的を達成できるかを点検するようにしています。Waiting(待ち)にタスクが溜まってしまう事象が多くなりました。あるタスクについて全員でネクストアクションを確認するようにしています。当時は、上手く機能していたとしても、メンバーが増える・プロジェクトが変わるなどして常に機能し続けるものは存在しないと考えています。日頃の取り組むを点検する場を設けることは非常に大切だと考えています。ドキュメント作成ドキュメントに関わらず、議事録なども重要なのですが、チームで決めたルールや原則は、基本的には全てドキュメントに残すことを心がけています。スタートアップであるため、スピード感を持って開発することがが非常に重要だと考えています。それと同時に、持続可能な開発を行っていくこともまた、非常に重要だと考えています。決めたこと等は、必ずドキュメントに残し、明文化するように心がけています。そのドキュメントは全メンバーがいつでもアクセスできるようにしており、メンバー間で暗黙知が増えないようにしています。誰が入って、誰が抜けたとしても、「開発チームとして機能し続ける」仕組みづくりは、非常に重要です。過去に決めたルールなどは、定期的に点検するコストもあるのですが、これが一番スピード感を持って、開発し続けられる方法だと考えています。単発で実施した大きな取り組み日頃行っている取り組みの指針となる指針となるより抽象的な概念についてチームですり合わせを行うことを目的に実施しているものです。回数をこなせていないので、ブラッシュアップの余地がある施策ではありますが、これからも継続していきたいと考えています。開発思想すり合わせ会チームが4人になったタイミングで、開発思想すり合わせ会というものを行いました。目的は、普段の開発で何を大切にすべきかについて目線を合わせることで会社のバリューのような位置付けだと考えています。(実際に、開発思想の中から会社のバリューとしてランクアップしたものもあります。)詳しくは、弊社Wantedlyページにて記事が上がっているので、そちらをご覧ください。www.wantedly.com向き直り会こちらは、大きなプロジェクトのリリースを終えたタイミングで実施しました。目的としては、非連続的な成長に繋がるきっかけづくりでチームの最終目標から逆算して、現在との差分を把握する場になっています。こちらも詳しい記事が上がっているので、そちらをご覧ください。最近に行った施策です。事業戦略に沿った形で、1年先に開発チームとしてはどんな体制になっていなければならないかそのために、いまやっておかなければならない取り組みは何かを把握する会として実施しました。こちらは、私のブログにて、別途詳細に書いていきたいと思っています。【レポート】開発戦略目線合わせ会を実施したまとめ振り返ってみると、1年間でチーム開発といえども非常に変化があったなぁと感じます。施策に取り組むにあたっては、以下をしっかりと抑えておく必要があるなと学ぶことができました。個人的には取り組むべき面白い分野だと考えています。これからも引き続き、チームとして正しく前に進み続けられるように創意工夫を凝らして、より良い仕組み作りに努めていきたいと思っています。開発はもちろん、こうしたチームビルディング開発チームがパフォーマンスを発揮し続けられる仕組みづくりについて一緒に考えることに興味をお持ちいただける方がいらっしゃれば、ぜひお会いしましょう〜!ご応募いただけると嬉しみです。いうスタートアップでエンジニアをしています。開発戦略目線合わせ会というものを実施したので、その備忘録を書いておきます。わせ会ってなんやねんって感じかと思うのでざっくり説明します。以下のようなアジェンダで取り組みました。自分たちが開発しているプロダクトの特徴を整理ex:SaaSで、市場規模××、....etc会社の事業戦略を理解する(1年後まで)そのために、どんな開発体制が必要かを考える必要な開発体制を実現するために必要な項目を洗い出す現在との差分から直近で取り組むべき内容を決める以下、具体的にどんな話をしたかを書き留めておきます。事業や今後の方針まで書いていると令和になりそうなので(いま平成31年4月30日)省略します。事業拡大に合わせてチーム(数)が拡大したとしても、スピード感を持って開発し続けていくことが最も重要な要素だということがわかりました。自分たちが目指している戦略から落とし込んで導き出したものなので、メンバー全員が納得感をもっていて、なぜこれが必要なのかを説明できる状態になっていると思います。開発体制を決めたことも重要なのですが、それ以上に、メンバー全員が納得感を持って、なぜこの開発体制が必要なのかを理解している状態になっていることが非常に価値が有ることだと思っています。必要な開発を実現するためには?スピード感を持って開発し続けられる状態とはどんな状態でしょうか?もう一つの目的である「日々の取り組みの指針」を定義していくことで深ぼることにしました。テクノロジーの戦略的活用が組織変革を加速するという書籍を参考に考えることにしました。この書籍は、ハイパフォーマンス組織を実現するためには?という軸で様々な企業を分析した本で、いろんな指標から、ローパフォーマンス組織とハイパフォーマンス組織の差分を考えることができます。深ぼっていくことにしました。書籍では、以下4つを組織のパフォーマンスを測る指標として考えています。オンデマンドにデプロイが可能な仕組みづくりを行っていくことが重要と定義しました。オンデマンドにデプロイが可能な仕組みづくりが必要であると判断しました。オンデマンドにデプロイが可能な仕組みづくりを直近の目標としたわけですが、もう少し深掘りしたいと思います。上記を達成するための指標は、以下の2点です。疎結合かつ凝集度の高いアーキテクチャ設計CIの整備デプロイの自動化・簡略化インフラ環境のスケーラビリティモニタリング(プロアクティブな通知)初めに比べて、だいぶ何をすべきかが見えてきたように思います。事業戦略を意識したアーキテクチャ設計(ワークレビューやペアプロによる個人のレベルアップ)(マイクロサービス化に伴うCI/CDの整備)まとめ結果やることは、テスト書く設計を大切にといった具合に、結構当たり前なことになりました。現在の開発チームでも、これらは日頃から意識して行っていることです。事業戦略から落とし込んで、日々やることにWhyをもたせることができたことが一番の収穫だと考えています。今回の会では、それらの価値観や普段の業務(特にリファクタ系やテスト系)が事業に直結していると再認識できる会になったのではないかと考えています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。