Naoki.V

= ITエンジニア(16年) && チームビルディング(6年)　　{ …

Naoki.V

= ITエンジニア(16年) && チームビルディング(6年)　　{ 開発チームを立ち上げて成長させていく過程で学んだ知見をnoteへ投稿していきます。}

  • チームの成長

    アジャイル開発チームの成長に関する記事です。

  • アジャイル開発で起きた問題

    アジャイル開発で起きた問題に関する記事です。

  • 読書感想文

    書籍から得られたことを書き留めてます。

  • 個人の成長

    エンジニア・社会人としての成長に関する記事です。

  • 固定された記事

自己紹介／noteに投稿すること

自己紹介ITエンジニアとして16年の経験があります。 2016年頃から自身の周りで「アジャイル開発」の機運が高まり、2017年にアジャイル開発チームを立ち上げました。 私がゼロから立ち上げた開発チームは6年間で「3人→12人」の規模に成長しました。 noteに投稿すること私が開発チームを立ち上げて成長させていく過程で学んだ知見をnoteへ投稿していきたいと思います。

Naoki.V

    • 効率を優先して生み出された成果物が必ずしも最適であるとは限らない

      効率を優先して生み出された成果物が必ずしも最適であるとは限りません。むしろ、後々になって再検討や修正などが発生して、長期的な視点では非効率になるケースがあります。 最短経路で進まず、一見、非効率に思える準備・検討を事前に行うことで、最適な成果物を生み出すことができるようになります。 一時停止、遠回り一時停止や遠回りをしたほうが、安全に利用できる成果物を出すことができます。 【実例】ユーザインタフェース設計 ユーザが次のアクションを素早く行うことができるように、UIを簡

      Naoki.V

      • 「スクラムやってます！」←実態はウォーターフォールかも？

        「アジャイルやってます！」「スクラムやってます！」というチームの実態が、スクラムではなくウォーターフォールになってるケースがあります。 実態はウォーターフォールである「偽物のスクラムチーム」の特徴と、「本物のスクラムチーム」になるために必要なことを、本投稿では解説させていただきます。 本物のスクラムチーム VS 偽物のスクラムチーム私自身は「本物のスクラムチーム」と「偽物のスクラムチーム（実態はウォーターフォール）」の両方を経験したことがあります。 本物のスクラムチーム

        Naoki.V

        • 「作業」ではなく「仕事」をしよう

          本投稿では書籍から得られた知見を投稿させていただきます。 【書籍】 付加価値のつくりかた 田尻望 「作業」ではなく「仕事」をする「作業」をするだけのメンバー アジャイル開発ではプロジェクトのゴールを達成するために、1~4週間ほどの期間をスプリントと定めて反復開発を行います。 スプリント毎に成果物を出すために必要なタスクはチケット化して、進捗状況を管理します。 チケットはプロジェクトのゴールを達成するためのタスクでしか無いのに、チケットを消化することが目的となってしま

          Naoki.V
        • 固定された記事

        自己紹介／noteに投稿すること

        Naoki.V

        マガジン

        • チームの成長
          3本
        • アジャイル開発で起きた問題
          5本
        • 読書感想文
          1本
        • 個人の成長
          3本

        記事

          急がばヒアリング

          はじめに本投稿では私が開発チームを立ち上げて成長させていく過程で学んだ知見を投稿させていただきます。 使われないサービスを作ってしまう私は2017年のアジャイル開発チームを立ち上げ、10以上の案件に関わらせていただきました。 アジャイル開発を行えば、素早い開発が出来るようになりますが、その成果物がユーザに使われるかは別の問題です。 アジャイル開発で経験したパターン自分が関わらせていただいた案件には、ユーザにヒアリングを行いながら進める案件と、ヒアリングを全く行わずに進め

          Naoki.V

          急がばヒアリング

          Naoki.V

          いまの仕事を手放さないと成長できない

          はじめに本投稿では私が開発チームを立ち上げて成長させていく過程で学んだ知見を投稿させていただきます。 2パターンの人間がいるアジャイル開発は「プロダクトオーナー」「スクラムマスター」「デザイナー」「エンジニア」などロール（役割）の異なるメンバーで構成されます。 ロールが異なっても、以下の2パターンの人間がいます。 自分の仕事を手放せる人このタイプの人は、自分の仕事を他の人に移譲します。 仕事を押し付けるのではなく「なぜこの業務が必要なのか？」「この業務を円滑に進めるに

          Naoki.V

          いまの仕事を手放さないと成長できない

          Naoki.V

          ロールを与えられた会社員がチームをダメにする

          はじめに本投稿ではアジャイル開発を6年間続けたチームで起きた問題について投稿します。 実際に起きた問題8ヶ月間でリリースの要望を受けていた新規案件で、プロジェクトスタートから半年間、何も進展が状況が続いた 何が原因だったのか？デザイン経験の無いUXデザイナーがアサインされた。 スクラムマスター経験が無いスクラムマスターがアサインされた。 UXデザイナーは半年間の間、毎週ワークショップを開催しただけで、結果を集約して次のステップへ進めることをしなかった。 スクラムマスタ

          Naoki.V

          ロールを与えられた会社員がチームをダメにする

          Naoki.V

          相手に応じてアクションを変えよ

          はじめに本投稿では私が開発チームを立ち上げて成長させていく過程で学んだ知見を投稿させていただきます。 プロダクトオーナーアジャイル開発を行うチームを立ち上げてから6年間で、8人ほどのプロダクトオーナーと一緒にお仕事させていただく機会に恵まれました。 その中で、プロダクトオーナーには、おおまかに分けて2つのタイプがいました。 スクラムタイプのプロダクトオーナー新規案件の立ち上げ時にアサインされることが多いのは、スクラムタイプのプロダクトオーナーです。 このタイプのプロダ

          Naoki.V

          相手に応じてアクションを変えよ

          Naoki.V

          忖度がチームを駄目にする

          はじめに本投稿ではアジャイル開発を6年間続けたチームで起きた問題について投稿します。 実際に起きた問題チームではスクラムイベント（プランニング、レビュー）のタイミングでフィードバックを行い、カイゼンを継続的に実施していました。 しかし、メンバーの入れ替えがあったタイミングから、フィードバック／カイゼンが行われなくなりました。 何が原因だったのか？メンバーの入れ替えがあり、既存のメンバーより随分と年次が高いメンバーがチームに参加しました。 それまでのチームは年次の差が小

          Naoki.V

          忖度がチームを駄目にする

          Naoki.V

          能力の輪を広げる

          はじめに本投稿では私が開発チームを立ち上げて成長させていく過程で学んだ知見を投稿させていただきます。 業務範囲アジャイル開発では「プロダクトオーナー」「スクラムマスター」「デザイナー」「エンジニア」「QAテスター」など、複数のロールを持つメンバーからチームが構成されます。 それぞれのロールには、それぞれに求められている業務・成果物があります。 能力の輪メンバーの能力はぞれぞれ異なり、それぞれに「出来ること／出来ないこと」「得意なこと／不得意なこと」があります。 求めら

          Naoki.V

          能力の輪を広げる

          Naoki.V

          そして近視眼的な開発しかできなくなった

          はじめに本投稿ではアジャイル開発を6年間続けたチームで起きた問題について投稿します。 実際に起きた問題チームでは案件に応じて、1スプリント1~2週間のアジャイル開発を行ってましたが、スケジュールに関係するトラブルが度々発生してました。 実例１ 開発期間が8ヶ月間の案件において、半年間検討を続けても、開発する機能が決まってない状況になっていた。 実例２ 「X月までにリリースしてほしい」という要望を受けていた機能群について、期日までにリリース可能であるかを誰も把握してな

          Naoki.V

          そして近視眼的な開発しかできなくなった

          Naoki.V

          やる気がないとチャンスを掴めない

          前回の記事やる気がないとチャンスは掴めない自分は社会人になってからずっと良い環境にいられました。 新しいことにチャレンジできて、良い上司・良い仲間に囲まれてる環境にいられました。 技術力が十分に無いエンジニアだった頃からチャンスを掴めていたのは、「やる気」のおかげだと思ってます。 技術力がないのに「やる気」まで無かったら、絶対に今の環境にはいなかったでしょう。また、技術力があっても「やる気」が無かったら、チャンスを掴むことはできなかったでしょう。 飛んできたチャンスを掴

          Naoki.V

          やる気がないとチャンスを掴めない

          Naoki.V

          やる気は技術力に勝る

          はじめにITエンジニアとして10年以上開発を行っている自身の経験や、開発チームを立ち上げて成長させた経験から、「やる気」の重要性について投稿したいと思います。 一番言いたいこと「やる気」があれば、「技術力」が劣っていたとしても、適切な役割やタスクを与えることで、成果物を出せる人材・チームを牽引できる人材に成長させることができます。 やる気が技術力を伸ばすやる気のあるエンジニアは日々の業務に必要な技術だけでなく、新しい技術の習得にも熱心です。 やる気のエンジニアは自発的に

          Naoki.V

          やる気は技術力に勝る

          Naoki.V