「反復」の語義は、多分野で異なる意味を有しうるので、「反復的」と訳すと曖昧な感覚が残る。単なる繰返しではないので、「繰返し」と表記するのも割り切れない。ある処理にかけた結果を、再度同じ処理にかけるという点で、イテレーションは、反復的ではない。Wikipedia日本語版は、日本工業規格における「統計」の「レプリケーション replication」にも言及しているが、この「反復」は、「イテレーション」とは明確に意味が異なる。
実は、国際連合の『一般化統計ビジネスプロセスモデル』（Generic Statistical Business Process Model, GSBPM, v. 5.0, 2013）に係る「イテレーション」の訳し方がここでの課題であった。このため、実験計画分野にいう「反復」だと、「サイクルを回す中で良いものに仕上げていく」という意味が含まれないことになってしまうのである。この訳だと、PDCAやスパイラルモデルの印象を押し出せないのである。これは瑣事ではあるが、わが国の行政組織が失敗から学習するという過程を有していないのは、統計を活用するというプロセスが軽視されているために生じたことではないか、という私の見立てを提示する上では、なかなか大事な部分なのである。
作業を繰り返す中で良いモノが仕上がる、という過程は、試行錯誤を含むことはもちろんであるが、対立関係まで含みそうなので、ヘーゲルのいう総合に相当する、とこじつけてみたい。ビジネスモデルや設計プロセスにおいて、ヘーゲル哲学を導入するという考え方は、暗黙知の中でも、常識の部類のようであり、ソフトウェア開発手法の歴史自体がヘーゲル哲学で説明されている。このため、ウェブ上の日本語のページ内で、「イテレーション」と「ヘーゲル」が共起する事例が見られない訳ではない。が、アカデミックな公式発言として記録されているかといえば、そうでもなさそうである、おしゃべりの部類でそのように明言されている、隙間案件であるように見受けられる。
ここまでに見た概念のつながりを学術的な品質に仕上げるのは、系統的な教養を有する専門家でなければ手に余るであろうし、私の手に負えるものではない。道の険しさだけ見えたので、これで脱落する気である。よって、本記事は、メモ扱いである。本当ならば、なぜ、統計の公表が戦争末期に行われなくなるのか、とか、そのときの責任はどこに求めれば良いのか、とか色々と考えておくべきことはあるのだが。
反復 - Wikipedia
https://ja.wikipedia.org/wiki/%E5%8F%8D%E5%BE%A9
日本語環境下では、異なる工学分野の用語がひとまとまりに記載される機会を最も有すると見なしうる点で、Wikipediaさんは、頼りになる存在である。『JIS Z 8101-1』は、「統計―用語及び記号―第１部：一般統計用語及び確率で用いられる用語」である。日本工業規格は、ウェブ上で立読み可能であるが、直リンが消えてしまいがちなので、「部門別一覧」から辿ると便利かもしれない。
JSA Web Store - JIS Z 8101-1:2015 統計―用語及び記号―第１部：一般統計用語及び確率で用いられる用語
http://www.webstore.jsa.or.jp/webstore/Com/FlowControl.jsp?lang=jp&bunsyoId=JIS+Z+8101-1%3A2015&dantaiCd=JIS&status=1&pageNo=0
JSA Web Store-JIS部門別一覧
http://www.webstore.jsa.or.jp/webstore/JIS/html/jp/CartegoryList.htm
KPT - HaxeFlixel Wiki
http://haxeflixel.2dgames.jp/index.php?KPT
このまとめ主は、明確にKPTというイテレーティブな活動を、ヘーゲルと関連付けて記述している。言われてみれば当然の感覚と言えようが、言われてみないと、気付かないものであるかもしれない。
KPTとは、行ってきた仕事や活動を振り返る際に、
の3つの視点で整理するフレームワークのこと。
- K：Keep＝今後も続けること
- P：Problem＝問題なので、やめること
- T：Try＝今後、試してみたいこと
アジャイル開発や反復型開発ではイテレーション（繰り返しの単位）ごとに作業の振り返りが推奨される【...略...】
ヘーゲル「人間は歴史から何も学ばないということを、歴史から学んだ」
独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター
平成23年3月31日（平成24年3月26日改訂）
非ウォーターフォール型開発WG活動報告書（000004613.pdf）
http://www.ipa.go.jp/files/000004613.pdf
ドイツの哲学者ヘーゲル（Hegel, G.W.F.）は、「真理とは、基本的に主観的なものであり、歴史を貫く思考の鎖、すなわちテーゼ（定立）、アンチテーゼ（反定立）、ジンテーゼ（総合）というトリオの連鎖の中にひそむ法則の認識である」と述べている。ソフトウェア現場が生き残るためには、定立、反定立の渦の中で、自己を見失うことなく、ソフトウェア・エンジニアリングの歴史的流れを弁証法的に分析し、洞察によって真理を主観的に見極め、それに導かれて事業を進めることが望ましい[1]。
ベーム(Barry Boehm)は、2007年のIEEE International Conference on Software Engineering において、弁証法的手法を使って、ソフトウェア・エンジニアリングの歴史を、図表5-1のとおりまとめている。ベームの見方によれば、定立（上辺）はいわゆる「計画駆動手法」であり、それに対する反定立（下辺）は、1960年代の現場の職人気質、および1990年代のアジャイル手法であるとしている[2]。
[1] [Matsumoto09] 松本吉弘編，「ソフトウェア現場力ハンドブック」，オーム社，2009
[2] [Boehm06] Boehm, B., A View of 20th and 21st Century Software Engineering, keynote address at ICSE 2006, May 25 (2006)
これは、完全にヘーゲリアンな見方ではあり、学術上の成果に明記されたものであるから、これを参照しておく価値は一応のところ、あろう。他方で、下記の釘本氏のメーリングリストアーカイブのように、学術的文章の一歩手前の状態において、ソフトウェア開発と総合とを関連付けた言及が数年前に見られる以上、明確な先取性を追究する作業は、面倒臭いこときわまりなさそうである。社会システム×ヘーゲル＝マルクス主義だから、何かとヘーゲルを掛け合わせてみるという態度は、至るところに生じそうであるからである。およそ科学的社会主義の研究になるというオチが認められそうで、いやはや、私の好きな話ではない。その先、わが国の官僚機構という組織構造において、なぜこの話が致命的なまでに機能してこなかったか、という点に興味の中心があり、その手前で止まりたくはないからである。
Article 3764 at 03/10/14 23:13:07 From: ********@**.*****.**.** Subject: [oosquare-ml:03764] Re: 概念モデルに責務を書いても良いですか？
https://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200310.month/3764.html
Hiroki Kugimoto氏から赤坂英彦氏への14 Oct 2003のメールの返事。
情報処理技術者試験対策の参考書で有名なITECの
「データベーススペシャリストのためのデータベース技術」ISBN4-87268-312-9
の一番初めに、データモデルに関しての色々なテキスト（方法論）での用語の対比があります。
今手元にある2002年版では、11ページに「図1-2 さまざまなデータモデルの考え方」として表が載っています。
この表でスッキリ整理がついた覚えがあります。
この表によると、
・多くの方法論では、
企画：概念データモデル、
要求定義＆外部設計：論理データモデル、
内部設計：物理データモデル
・ANSI/SPARCの3層スキーマアーキテクチャでは
企画：外部モデル、
要求定義＆外部設計：概念モデル
内部設計：内部モデル
となっています。
私は「3層スキーマ」と聞いても「ふーん、ヘーゲルね、アウフヘーベンね」としか考えてません。うわ突っ込まれそう。
阪井和男（明治大学）ほか,(2012/12/15). 創造技法としてのワークショップの作り方～交流制約法の理論と実践～, 第77回次世代大学教育研究会.
http://www.kisc.meiji.ac.jp/~sakai/presen/ne77-ehime-ws-transactional-contraint-20121215.pdf
阪井和男氏の発表は、私の主張したいことに随分と被る分野のものであるが、イテレーションと止揚とを明確に関連付けたものになっている訳ではない。一つのファイル内に両語が並記されているが、相互に意味上の連関のある共起関係とは見なせない。また、スライド46にベルリン大学に係る記述として、大学長であったヘーゲルの名が示されているが、これが発表において用いられたか否かも分からない。連絡不可能な場合こそ、私の考察対象となっているので、ここはあえて伺わないことにして、勝手に解釈することとする。
【スライド4】
- 理想
- アジャイル授業・アジャイル講演の試み
- 情報組織論（明治大学法学部）、阪井ゼミ「復興支援プロジェクト」
【スライド5】ソフトウェア開発ライフサイクルの進化
ジム・ハイスミス［著］，山岸耕二・中山幹之・原幹・越智典子［訳］，(2003).『適応型ソフトウエア開発（変化とスピードに挑むプロジェクトマネージメント）』，ウルシステムズ監訳，翔泳社，
- ウォーターフォール型（Waterfall）
- イテレーション型（Iteration）（進化型・スパイラル型・RAD）
- 適応型（Adaptation）
原著：Highsmith, James A., "Adaptive Software Development: A Collaborative Approach to Managing Complex Systems", Dorset House, New York, 2000.
【スライド46】世界の大学モデル
1810年：ベルリン大学（ドイツ）
言語学者でプロイセンの政治家としても有名だったフンボルトがその骨格をつくった（フンボルト理念）
- 業績
- 国家からの学問の自由を志向し、研究を大学の重要な機能とした
- 各国の大学モデルとなり、その産業形成を支えた
- 初代の学長がフィヒテ、2代目はサヴィニー、1830年にはヘーゲルが後任
- 日本からも森鴎外・北里柴三郎・寺田寅彦・肥沼信次・宮沢俊義らがベルリン大学に留学している。
http://ja.wikipedia.org/wiki/大学（2008年12月27日アクセス）
http://ja.wikipedia.org/wiki/ベルリン大学（2008年12月27日アクセス）
経済学がどうにもうっとおしいので偏見を整理してみる - TuvianNavy’s port
http://d.hatena.ne.jp/TuvianNavy/touch/20101102/1288723212
TuvianNavy氏のメモは、何となくイテレーションがヘーゲル哲学的であることを感じさせる内容になっている。マルクス主義がヘーゲルに基礎を置くのは公知であるが、ヘーゲルの思考の枠組が経済学を貫いており、結構イテレーシブであるという考え方までは、あと一歩なのであろうか。この点を、本人が明確に指摘している訳ではない。ただ、産業連関表をイテレーションと説明しているのは、その通りであって、イテレーションを説明する際の事例として取り上げるに値しよう。
イテレーションは、理系では普通に大学の学部生時代に習う概念である。現在では、高校生であっても、情報の時間に、用語こそ用いることがなくとも、学習はするであろう。ごく普通にカタカナ語で利用するがゆえに、あらゆる世代の日本語話者が理解できるように、という要請は、気付かれないままに終わるのかもしれない。
0 件のコメント:
コメントを投稿
コメントありがとうございます。お返事にはお時間いただくかもしれません。気長にお待ちいただけると幸いです。