成功体験は、くどい自慢話にならないことに注意すれば語ってもよいかなと思うんです。
田中 伸明 さんの垢を煎じて飲ませていただくために宅配お願い中。鵜飼敬幸さんと、水野智仁さんにもお願いしたいかな。
清水 吉男
清水 吉男「"硬派"のホームページ」のおすすめ記事12選
https://qiita.com/kazuo_reve/items/bce7522fa2cca0995b85
今は亡き、派生開発推進協議会 代表 清水 吉男さんが、
http://affordd.jp/about_affordd.shtml
SWESTでの講演でソースコードから書いちゃダメという話をされた時。
https://swest.toppers.jp/SWEST12/abst.html
たまたま、同じ部屋での宿泊だったため、
自分はソースコードが設計書だと思っているので、ソースコードからしか書いた事がない。
ソースコードに設計情報をすべて書くという話を差し上げた。
清水さんは、にっこりして自分の場合はとご自身の成功体験を話された。
お互いの成功体験の中身が違うように感じる人がいるとしても、
制約条件は激しく違うはずで、相手を尊重すれば、制約条件を詳しく教えてもらうまで、
相手の話に疑問を挟むのはダメだと思う。
自分の仕事での打ち合わせでは、ソースコードで話ができる相手は、ほとんどがプログラマ。
自分はプログラマ相手の仕事が中心。ソースコードを最初に書いてもいい。
清水さんの場合には、そういう仕事はあまりされていないのだろうと推測しながらお話しをお聞きした。
自分の成功体験は語っても、自分の成功体験が、どういう制約条件の下で、ほかの人はそうでないかもしれないという姿勢が清水さんにはあった。
例えば、自分（小川清）は、主にプログラマが使う道具類(端末シミュレータ、エディタ、コンパイラ、通信測定）を書いているため、いきなりソースコードを書いた方が、顧客であるプログラマとの議論がしやすい。そこで、清水さんに、SWESTで同じお部屋に宿泊した際に、「派生開発でもソースコードをいきなり書く」場合についてご説明さしあげた。清水さんは、自分の場合は、と背景などを教えてくださった。条件が異なれば、やることが違うことはあたりまえのこと。「モデルベース開発はよくわからないので若い人に任せている」とも仰っていた。
田中伸明
自分は通信関係が仕事。時系列図(sequence chart)、刻時図(timing chart)をまず書く。
設計する場合には、状態遷移図(state chart)から書く教訓はえた。
クラス オブジェクト図から書く人の気持ちがわからなかった。
COBOLのお仕事や、DB系では、データが存在することが前提で仕事をする。
データ中心設計では、クラス図から書くのだろうと推測はしていた。
田中伸明さんは、いつもクラス図から書くと言われていて、書いた図を拝見したことがある。
自分なら、振る舞い図(時系列図(sequence chart)、刻時図(timing chart))から書くという話を差し上げた。
ちょうど、国の研究所である電総研（現在の産総研）に研修生として在籍していたのが同じ頃らしいということを以前お聞きした。
自分は、言語研究室の研修生で、OBJという抽象データ型の言語の論文を渡されてコメントが欲しいといわれ、
OBJのシンタックスチェッカを作って考えて、抽象データ型の継承方法を体系的に構想するのは無理だという話をした。
その後２０年以上後に、北海道工業試験場の堀武司さんが、EventBで記述する際に、システムの継承は必然性はないという趣旨の話をされたような気がする。
田中伸明さんが書かれた道具を、道具の国際規格に基づいて評価することになった。
安全工学シンポジウム＠日本学術会議 一般セッション 7月4日（木） 第2室 2階
https://www.anzen.org/html/program.html
10:00〜11:40 GS-5 システムの安全性と信頼性（２）
5-3 安全分析の図的表現方法、及び設計文書と親和性の高いツールの提案
○田中伸明（ガイオ・テクノロジー），小川 清（名古屋市工業研究所）
既存のデータをうまく生かして、道具の発展系のプログラムを田中伸明がちゃちゃっと書かれて、やられたと思った。
データ中心設計であれば、既存のデータをうまく生かす方法に長けている。
道具の処理時間なども、測って短くされたとのこと。
使わせていただいて、評価をさせていただいた。
柏原一雄
清水吉男、田中伸明とくれば、次は柏原一雄。
Qiitaに記事を書いてくれるようになり、
そこそこ内容的にはよい記事もあると思っていた。
なぜ、もっと評価されないのだろうと思い、
整理してみた。
@kazuo_reve の Qiita記事の分析
https://qiita.com/kaizen_nagoya/items/81e3519e3740fa766d6a
そしたら、来たは。それまでいいねが９以下だったのに、
100越えの151, そしてstockは236。
新人の方によく展開している有益な情報
年齢は、私や田中伸明さんよりも若いから、来るとは思ってたけど。
なぜ、Qiitaで人気が上がらないのか疑問に思っていた。
だから「@kazuo_reve の Qiita記事の分析」を記事を整理してみた。整理したら、途端に100超えしてた。
因果関係はないが、何か鍵を掴んだのだろう。単なる偶然の確率は５０％くらい。半々。
この記事の標題、「成功体験は語っても、成功体験に頼らないために。」は、清水吉男 さんを紹介した際に、柏原一雄さんの行動を語っていたかもしれない。成功体験に依存せずに、常に新しい舞台に、少しづつ進んでいく姿を。
@kazuo_reve の Qiita記事の分析
安全分析における HAZOP による想定外の洗い出し
Unexpected Identification Using HAZOP in Safety Analysis
小川 清, 柏原 一雄, 田中 伸明 2020 年春季大会 学術講演会 講 演予稿集, No.78-20 (2020/5) 頁数 p.1-6.
佐々木 眞一
清水吉男を見習える人なら、佐々木 眞一を見習えるような気がする。
トヨタの自工程完結 佐々木 眞一
https://qiita.com/kaizen_nagoya/items/dd2de8bd9d884c16911d
参考文献の参考文献は参考文献だ「「派生開発」を成功させるプロセス改善の技術と極意」を超えて
https://qiita.com/kaizen_nagoya/items/562a0cf784cf92bc0ebb
佐々木 眞一 を見習えば、清水吉男 を超えていくことができるだろうという予感
自己体験
道具類
ある道具(tool)をMS-DOSのあるエディタのシェル(child process)でコンパイルして動作させていた。
ああ、うまく動いたと思って、できた実行プログラムを、直接MS-DOSで実行しようとした。直接実行すると暴走した。
あるエディタのシェル上では暴走しないが、そうでないと暴走するプログラムを作ってしまった。
「エディタのシェル上では暴走しないが、直接実行すると暴走するプログラム」という仕様をもらっても、自分ではよう作らなかったと思う。
シンタックスチェッカ
田中伸明さんが、電総研の研修生で筑波におみえになったころ、
私も電総研で三ヶ月だけですが、研修生をしていた。
OBJという抽象データ型のシンタックチェッカや、Cコンパイラの拡張などを書いていた。
自分の書いたソースコードは、当時、静的検査の道具にかけておらず、デバッグモードだと動くが、リリースモードだと暴走する状態だった。
Pascalで書かれたコンパイラを、自分でC言語に移植したソースコードを元に書いていた。今になって思えば、配列の領域超えが原因だったことが推測できる。
ソースコードから書いても、単体試験、静的試験など必要なソースコードの試験の道具類があるとよい。また、各種設計図面、例えば状態方程式、状態遷移図、時系列図などを模擬試験したり、ソースコードを自動生成する道具類など、道具が整備していることが最低条件だということに気がついた。
ソースコードから書くとよいのではなく、必要な試験の道具類が完備しているかどうかが鍵であることに気がついた。
その後、機能を削除すると暴走するプログラムに時々遭遇する。単体試験、静的試験だけでなく、動的試験をすると原因がわかるかもしれないと思うようになった。しかし、削除しなくてはいけない複数の機能があると相互依存関係が複雑すぎて、もう一度、基本設計(architecture)を一から見直した方がいいかもしれないと思うようになった。
まとめ
成功体験は語っても、成功体験に頼らないことがやっぱり大事だと思った。
最終利用者(end user)としてプログラムを書き始め、水道料金の模擬試験(simulator)などで賞をいただいた頃は、最終利用者が書けば１の労力、組織の情報システム部門が１０の労力、外部に委託すれば１００の労力がいることを経験則として体験した。
１の労力でできる最終利用者は最終利用者１０００人のうちに１人くらいの能力。組織の情報システム部門で１０の労力で作成する人は、１００人に１人くらいの能力。外部に委託すれば、１０人に１人くらいの能力が担当することになるからかもしれないということに気がついたのはうん十年後だったような気がした。
一時的な状態を一般化しなければ、見えてくるものがあるかもしれない。
自分の成功体験は語っても、成功体験に頼らなければ、人の成功体験の制約条件が聞けるか、人の成功の手伝いができるかもしれない。
参考資料(reference)
算譜(program)が計画(plane),設計(design)である３つの理由
https://qiita.com/kaizen_nagoya/items/34daa0403eaca5e8b5a6
仮説(71) 設計図・表はいつ(when)書くか、何を(what)書くか、どうやって(how)書くか
https://qiita.com/kaizen_nagoya/items/7fddfa5d8bfb5a947db8
安全（１４）設計図によるHAZOPの進め方の展開
https://qiita.com/kaizen_nagoya/items/9fdda3edaead39d3690c
系建築家(system architect)になるには
https://qiita.com/kaizen_nagoya/items/8c341e69233cb32f6275
プログラマの思い込みの激しさは強みであって弱点ではない３つの理由
https://qiita.com/kaizen_nagoya/items/bc5dd86e414de402ec29
通信エミュレータの移植
https://qiita.com/kaizen_nagoya/items/ce505bbea4229b83e93b
VZエディタ移植に当たって実施したことと成果
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949
Qiitaで組立語(assembler)・機械語(machine language)・CPU「アセンブラへの道」
https://qiita.com/kaizen_nagoya/items/46f2333c2647b0e692b2
参考文献駆動執筆(references driven writing)・デンソークリエイト編
https://qiita.com/kaizen_nagoya/items/b27b3f58b8bf265a5cd1
参考文献の参考文献は参考文献だ「「派生開発」を成功させるプロセス改善の技術と極意」を超えて
https://qiita.com/kaizen_nagoya/items/562a0cf784cf92bc0ebb
文書履歴(document history)
ver. 0.01 初稿 20190625 昼
ver. 0.02 参考資料追記 20190625 午後
ver. 0.03 クラス オブジェクト図 訂正 20190625 夕
ver. 0.04 自己体験等追記 20200215
ver. 0.05 柏原一雄 追記 20210504
ver. 0.06 佐々木 眞一 追記 20210811
ver. 0.07 「派生開発」を成功させるプロセス改善の技術と極意」を超えて 追記 20210821
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.
