言いっ放しよりエンピリカル(実証) #xpjugkansai #AgileJapanOsaka
言葉の再定義だけでは実践できない
ブランディングの狙いもあるのでしょうが、一見、興味を惹く、いわゆるキャッチーな発言をされる方が増えている様に思います。「アジャイルはXXだ!」「プロジェクトはこうあるべき」「XXの役割はYYだ」など、など、多くの言葉が再定義され、広く合意を得ないままに言い放たれています。
そのような発表・発言は聞いていて面白いのですが、自分の仕事や考え方に当てはめようとすると、細かなところでわからない事が出てきます。言いたい事はわかるのですが、なぜそれが重要なのか背景(コンテキスト)がわからないと実践できないのです。
どこかで聞いたような、、
キャッチーな発言を聞いていると、既視感のようなものを感じます。ソフトウェアエンジニアリングが始まった頃がそんな感じだった様に聞いていますし、最近では要求工学がメジャーになる前に同じような発言で議論をされていました。
ソフトウェア工学は工学足りえるか、要求工学は工学か、開発はこう行う、要求はこう扱う、などなど。新しい世界が切り開かれるときは、言いっ放しであってもインパクトのある言葉が大勢の指示を受け易いのでしょうね。
言葉の定義
既視感に基づくと、この次にくるのは言葉の定義です。面白い話で空中戦を繰り返しても技術が発展する訳も無く、「言葉は定義してから使いましょう」と言う事になります。
言葉の定義が進むと体系化されて、BOK(Body of Knowledge)や教科書といった本が生まれます。そして、これが基準になって「XXではこう定義されていますが、我々のところではこういう背景からYYを中心に勧めています」などと、コンテキストが明らかになって議論が進み易くなります。
このように議論をする際の基本的なアプローチとして、言葉の定義は重要です。
定義の限界
しかし、技術の実践が進むといちいち定義に戻って、そこから議論を始めることが煩わしくなります。現実は多様性にあふれているので、定義から演繹的に説明する事が困難になるからです。
先日のXP祭りin関西2015とAgile Japan 2015 大阪サテライトのパネルが消化不良だったのは、定義の議論によって参加者が期待する実践的な内容ができなかったからだと思います。ある程度実践が進むと、前回のRxTstudyやredmine.tokyoのように、どのような実践をしているか、参加者を含めて帰納的に議論を進める方が良いのでしょうね。
まれに20世紀のソフトウェア工学を指して「役に立たない」などと言われる事がありますが、これは当時のソフトウェア工学研究が、言葉の定義を重視して演繹的に議論していたからで、役に立つ研究であっても問題領域が限定されていたからだと思います。
エンピリカル(実証)の世界
ソフトウェア工学の世界では21世紀になる頃から、エンピリカル(実証)ソフトウェア工学などという言葉が使われる様になりました。言いっ放しではなく、一般的な定義を基礎にした、実際に役に立つ事を実証する事が重要だというのです。これはアカデミア全体の傾向で、基礎的な研究だけでなく、実践的な研究も経験論文として受け入れようという動きが生まれました。
経験論文では必ずしも新規性は求められません。すでに知られている事であっても、それを実践する事で得られた知見が、広く知らしめるにふさわしい、役に立つ、正確な情報、であるか、いわゆる、一般性、有効性、信憑性、が評価されます。
そこでは新しい言葉の再定義ではなく、一般的な言葉の定義で、役立つ技術が実践によって得られた実証データに基づいて語られます。
my ベストプレゼンテーション
このように考えると、Agile Japan 2015 大阪サテライトでのモノタロウの牛島さんの講演は、ベストプレゼンテーションでした。
スクラムをやり始めた頃は何も考えていなかったが、アジャイルコーチになぜそれをするかをしつこく尋ねられ、考えて開発を進める様になり、やがてチームも考えて作業をする様になった。その効果がバーンダウンチャートで定量的に示されていました。
この発表はいかにも実証的です。経験した思いが根底にあり、一般的な言葉でコンテキストと経験を伝え、わかってもらうためにデータで示されていました。この発表は聞いていた人に届いただけでなく、データで示された「なぜか」によって実践が可能になったのです。
今後もこのような発表がどんどん増えて、多くの技術が積み上げ可能になることを期待しています。
« [#AgileJapanOsaka] コミュニティは相互扶助 | トップページ | [#TiDD] ウォーターフォール型開発をアダプタブルにする3+1 »
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
この記事へのコメントは終了しました。
コメント