市販のプロジェクト管理ツールが使いづらい理由
市販のプロジェクト管理ツールが使いづらい理由を的確に指摘しているつぶやきを見つけたのでメモ。
ラフなメモ書き。
【追記】@kaorun55さんから「 (TFSも使ってみてください)」のご意見もあり、文章を修正しました。
どんなソフトウェアにもプロセス(手順)が混じっている。
ソフトウェアを使いこなすには、そのソフトウェアの機能に沿った手順に、ユーザは必ず従わなければならない。
つまり、ソフトウェアの機能に込められた開発者の設計思想に、知らず知らずのうちにユーザは従属させられる。
WindowsPCしかり、CentOSしかり、iPhoneしかり、iPadしかり。
新しいツール、新しいソフトウェアは、従来のやり方とは違ったプロセス(手順、やり方)に慣れる必要があり、それに慣れなければ、期待する効果は出てこない。
逆に、ソフトウェアを使いこなすのが目的になってしまい、ツールに振り回されてしまう場合が多い。
市販のパッケージ製品、特にプロジェクト管理ツールが使いづらいと思う時が多い理由は、その会社のプロセスが組み込まれており、そのプロセスを取り入れるのが難しいから。
過去にたくさん出てきたCaseツールは特にそうだろう。
オープンソースのツールが優れている点の一つは、オープンソースのツールの機能に、数多くの開発者の要望を取り入れられているからだろう。
ユーザ自身が機能を追加したり改善するパッチをコミッタに送ってもいい。
特にGitHubが普及してから、PullRequestという手法によって、パッチを簡単に送付してマージするのが簡単になった経緯もある。
つまり、コミッタだけでなく、ユーザ自身もソフトウェアを「使う」立場だけでなく「改善する」役割を担うことができる。
オープンソースのコミュニティという場で、コミッタとユーザが有意義な議論を行って、ソフトウェアを漸進的に育てていく。
ソフトウェアのあるべき姿がアジャイル開発と重なっているように思える。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
- パッケージ原則とクラス原則の違いは何なのか(2023.10.14)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- QAエンジニアの役割は開発チームのガードレールみたいなものという考え方(2023.08.21)
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
「Agile」カテゴリの記事
- 概念モデリングや設計原則は進化しているのか(2023.10.21)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 日本のアジャイル開発の先人による話が良かった(2023.07.15)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
コメント