組織や管理職が技術革新のボトルネック
とある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はなかなか馴染んでくれない。
自分たちの過去のやり方に固執して、新しい技術を取り込んでくれないのだ。
第三者から見れば、過去の成功体験、過去の習慣が新しい技術の導入を阻んでいるように見える。
そして、組織全体へ拡張していこうとすると、それぞれの現場の問題は異なるので、一つのツールで全てが解決できるわけではないから、適用方法を考えないといけない。
すると、ドキュメントを作ったり、説明会を開いたり、実際に手取り足取り説明したり、色々と手間はかかる。
経営トップはこういうツールの導入はあまり違和感はないみたい。
現場が上手く回って、結果的に売り上げが出るなら問題ないのだ。
でも、管理職層は今までの自分たちのやり方が新しいツール導入で変わってしまうため、変化を恐れる時が多いみたい。
計画→実行監視→測定というサイクルが従来は手作業だったのに、ツール上で行うようになってしまうため、そのやり方に慣れるのが大変だからだ。
「アジャイル開発の本質とスケールアップ」では「スクラムチームは常に改善し続けるために解決されなくてはならない組織的な阻害要因に直面し続ける」という言葉があるけれど、それを連想させる。
開発環境も含めた開発プロセスを改善しようとすると、組織と緊張関係をもたらす場合が出てくる。
そういうこともそろそろ考えないといけないのかなと思っている。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「Redmine」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
「Jenkins」カテゴリの記事
- 第12回東京Redmine勉強会の感想 #redmineT(2017.05.14)
- 技術的負い目の記事がすごい(2016.01.03)
- RedmineとGitLabを連携すると、RedmineをGitHub化できるか(2014.10.17)
- 「チーム開発実践入門」が発売されている(2014.04.08)
- 最近、ツールとプロセスを組合わせたソフトウェア開発手法の本が増えている(2014.04.03)
コメント