組織や管理職が技術革新のボトルネック
とあるBlogを読んでみて、組織や管理職が技術革新のボトルネックではないか、と思った。
ラフな感想。
【元ネタ】
継続インテグレーションは強みではなくなった:柴田 芳樹 (Yoshiki Shibata):So-netブログ
継続インテグレーションは強みではなくなった(2):柴田 芳樹 (Yoshiki Shibata):So-netブログ
カンファレンスは、若い人ばかり?(2):柴田 芳樹 (Yoshiki Shibata):So-netブログ
(引用開始)
私自身が日頃から感じていて、Jenkinsユーザ・カンファレンスの参加者による質問を聞いて再認識したことは、JenkinsなどのCIツールの導入を阻害しているは、現場のエンジニアではなく、ソフトウェア開発組織の管理職でないかということです。つまり、管理職がCIツールの導入の検討を指示して、予算(工数、機材費)を認めてくれればスムーズに導入できるかと思います。しかし、現実は、CIツールに関する知識や使用した開発経験もないため、管理職が指示することはなかったりします。そして、開発現場が上司に提案をして説得しなければならないことが多いということです。
現状は、このような開発組織が多いでしょうが、Jenkinsユーザ・カンファレンスに参加したような若い人達が10年後、20年後には積極的に改善を指示してくれるのではないかと期待しています。
(引用終了)
2012年現時点では、RedmineもJenkinsもGitももはや当たり前の開発環境。
使いこなせて当然だし、それらツールをどのように運用したらいいのか、という方向へ進化している。
でも、自分自身がツールを使ったプロセス改善を組織へ導入しようとしてみて、色んな阻害要因があることに気づいた。
現場でボトムアップに導入するのは結構うまくいく。
現場の問題解決に役立てたいという動機があるから、現場のプログラマやリーダーは積極的に使いこなそうとするし、若い人ほどすぐに慣れてくれる。
しかし、30歳を過ぎたSEはなかなか馴染んでくれない。
自分たちの過去のやり方に固執して、新しい技術を取り込んでくれないのだ。
第三者から見れば、過去の成功体験、過去の習慣が新しい技術の導入を阻んでいるように見える。
そして、組織全体へ拡張していこうとすると、それぞれの現場の問題は異なるので、一つのツールで全てが解決できるわけではないから、適用方法を考えないといけない。
すると、ドキュメントを作ったり、説明会を開いたり、実際に手取り足取り説明したり、色々と手間はかかる。
経営トップはこういうツールの導入はあまり違和感はないみたい。
現場が上手く回って、結果的に売り上げが出るなら問題ないのだ。
でも、管理職層は今までの自分たちのやり方が新しいツール導入で変わってしまうため、変化を恐れる時が多いみたい。
計画→実行監視→測定というサイクルが従来は手作業だったのに、ツール上で行うようになってしまうため、そのやり方に慣れるのが大変だからだ。
「アジャイル開発の本質とスケールアップ」では「スクラムチームは常に改善し続けるために解決されなくてはならない組織的な阻害要因に直面し続ける」という言葉があるけれど、それを連想させる。
開発環境も含めた開発プロセスを改善しようとすると、組織と緊張関係をもたらす場合が出てくる。
そういうこともそろそろ考えないといけないのかなと思っている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- プロジェクトのリスクはコストの増減で管理する(2021.04.08)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Redmine」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Git・構成管理」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- YoutubeのCCNA講座が秀逸だった(2021.01.04)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- RedmineでGitのbareリポジトリにアクセスする方法(2020.10.22)
- 第16回東京Redmine勉強会の感想 #redmineT(2019.05.19)
「チケット駆動開発」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
- カンバンはステータス名が大事(2021.01.02)
- GTDは箱の使い分けが鍵を握る(2020.12.09)
- ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説(2020.12.05)
「Agile」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
「Jenkins」カテゴリの記事
- 第12回東京Redmine勉強会の感想 #redmineT(2017.05.14)
- 技術的負い目の記事がすごい(2016.01.03)
- RedmineとGitLabを連携すると、RedmineをGitHub化できるか(2014.10.17)
- 「チーム開発実践入門」が発売されている(2014.04.08)
- 最近、ツールとプロセスを組合わせたソフトウェア開発手法の本が増えている(2014.04.03)
コメント