検索
  • 川西真紀

『技術転換』チャレンジした本人に聞きました!

こんにちは。Agile Studio マーケティング担当の川西です。


10/21(水)にAgile Studio主催のウェビナー『モダンでアジャイルなエンジニアに技術転換する ~ テクニックとマインドの伝え方』が開催されました。


今回のウェビナーでは、技術転換にチャレンジした本人(雄一さん)と、それを支援したマネージャとの対話を通じて、実事例をベースに、有効なテクニックと必要なマインドセットについて明らかにしていきました。ウェビナーの内容を時系列でレポートしていきます。


最初の話は、業務SEであった雄一さんをどうやってモダンエンジニアにシフトさせたかでした。約半年で体験フェーズ、実習フェーズ、実践フェーズに分けて進めたようですが、段階的な成長と本人の努力による成果を実感させるため、フェーズ分けは重要とのことでした。


実践フェーズに入り、一番最初に問題になったのは、マインドが変わっていなかったところだそうです。実習まででアジャイルやスクラムの開発手法は身についていても、お客様と話をするとお客様の要望にすべて答えないといけないというマインドになってしまったようです。お客様の要望を重視するあまり、チームに負荷をかけてしまった結果、チーム内の会話がほとんどなくなり、コミュニケーション不足によるコンフリクトが起き、無駄な作業が増えて進まないという状態になったようです。

それでは、こういう状況をどうやって打開したか。変わるきっかけになったのは何か。

サポーターの方は危ないなと思ってもすぐに自分で動かずに、お客様の要望になんでもかんでもすべて答えなくてよいことを根気強くアドバイスし続けてくれたそうです。それでお客様対応を少しずつ改善することができ、結果的にチームの大切さにようやく気づくことができたそうです。


次の話は、一人が技術転換をしてもあまり意味がなく、どんどん技術転換を広げていかないといけないということでした。

雄一さんの後に、2人の方が技術転換にチャレンジし、今は3人で「モダンチーム」と呼ばれるチームを結成して、みんなで学び、みんなで支える活動を推進しているそうです。

社内発信、勉強会、イベントを通じていろんな輪をつくり、立場で自然と決まってしまう役割分担をなくしたフラットな組織を目指しているそうです。


最後に質疑応答の時間がありました。参加者のみなさまからたくさんご質問をいただきましたので、その内容についてレポートします。


Q.

実際にお客様との折衝は(優先順位付けなど)どのように実施しましたか?

A.

バックログ、ユーザストーリーみたいなものはあって、最初にお客様と優先順位は決めて進めていたが、後でこうした方がいいというのがどんどん出てきて、気が付くとバックログがそればっかりになっていてうまくいきませんでした。

プロジェクトとしては成功しましたが、進め方としてはよくなくて、アジャイルなつもりで終わってしまいました。今は必要な時に必要なことを入れ替えたりしながら進められています。


Q.

2年くらいの基幹系システムの開発にアジャイルは取り入れられますか?(やめたほうがよい?)

A.

規模にもよりますが、やり方によっては100名でもできると思います。

何を作るかユーザに聞いてみないと価値がわからないものはアジャイルでやるべきですが、

かっちりとした勘定系のシステムのリプレイスをアジャイルでやるのは混乱を招くかもしれません。チームの自己組織化を促進するために内部だけアジャイルをやってみるのはよくやるので、そういう形からチャレンジするのが現実的かもしれません。


Q.

スクラム開発は、プロジェクトの兼任は可能でしょうか?それとも、フルアサイン前提でしょうか?

A.

フルアサインでないと難しいです。まれにSMとか兼任の場合がありますが、少なくともエンジニアはフルでないと難しいと思います。


Q.

師匠や伝説のアーキテクトの方がレビューやアドバイスをして成長していくとした場合、1人に対して複数名のサポートが必要かと思います。

そうすると、少数ずつ転換していく戦略が無難でしょうか。(中途半端なスキルのサポートでは成長しずらいので)

A.

雄一さんの場合は最初の一人だったというのもあって手厚くサポートし、二人目、三人目はチーム自らで育ててもらう形に切り替えました。少数から徐々に広げていく方がスピード感が出ると思います。

最初の一人二人くらいは外部のコーチをいれてでも手厚く育てて早くマインドチェンジし、チームで自ら育てていく方針に変更していく方がよいと思います。


Q.

失敗から立て直すときにお客様とはどのようにコミュニケーションを取りましたか?

A.

正直にここまでしかできないと明確に線を引きました。一人ではうまくいかなかったかもしれませんが、周りのサポートもあったので、周りとのコミュニケーションも大事だと思います。


Q.

逆にウォーターフォールの方が良いと感じるところはありますか?

A.

ウォーターフォールのいいところは最初に要件が決まるところです。最初に要件が決まっているのであればウォーターフォールでやった方がよいと思います。どちらもいいところがあって、へんに使うとどちらもうまくいかなくなってしまうので、適材適所というところがあると思います。


レポートは以上となります。

今回私が一番印象に残ったのは、「技術転換は組織変革そのものになりうる」です。

ただ単に個人の技術転換だけでなく、アジャイルなところを身に付けて、よりよい仕事、会社にしていきたいというのが組織変革につながるということです。技術転換がよいきっかけになるというのはなるほどと思いました。


Agile Studioには技術転換支援のサービスがございます。

お困り事がございましたら、ぜひお問合せください。

62回の閲覧
  • Facebook
  • Twitter
  • アジャイル動画

 お電話でのお問い合わせはこちら

0776-25-8488

平日10:00~17:00まで。セールス目的のお電話はご遠慮ください。 

メールでのお問い合わせはこちら

agile-studio@esm.co.jp 

永和システムマネジメント

​株式会社永和システムマネジメント​

 〒918-8231 福井県福井市問屋町3丁目111番地
 

© 2020 ESM, Inc.