2018.05.18
カテゴリ： ソフト開発日誌
仕事を始めた先で新しいソフトウエア開発手法を導入するという流れになった。「何だろうな、合わないな...」という何となくな言葉が思い浮かぶ。もう少し、具体的な言葉にこの感を置き換えられないだろうか。
久しぶりにダラダラと日記を書くことになりそうだ。
手法が要求している事項: 「チームメンバーの誰もが同じスキルを持ち、誰にでも仕事を割り振ることができて、開発工程の全てを短期間でできる。」... 何だろう、基本的な生産工学の観点無視な手法は。人間で無くても製造装置には能力差があり、できることに違いがある。使用可能な資源割り振りは、基本的な課題のはずだ。そんなの無視で「上手くいきますよ」と... 正直言えばこの時点で手法の有効性に疑問が出てくる。
ソフト開発はほぼ人間の手による。お互いの相性、気持ちの持ちよう、疲労度、作業内容の伝達解像度、ほか色々、製造装置には無い特性がある。この特性も加味して仕事の割り振り、進捗管理、打ち合わせ(あるいは議論)を持たないとチームは半年もすれば暗い雰囲気になる。
おおよそ最近の手法論ではコミュニケーションをすれば、人間的特性が開発進行に与える影響は軽減されるとの立場を取っている。本当だろうか？ 自分も既に 40 才台後半、性格は変わらないし、人との相性も変わらない。色々と高齢者達を話す機会を持った経験からすると、一生変わらない、あるいは加齢に伴う認知能力低下でさらに難しい状態になる。
正面切って「開発チーム内のお互いの相性重視でプロジェクトを進めるよ」といった手法論は無いのだろうか？
手法が要求している事項: 「要求の受付・変更は 2 週間程度のインターバル単位で行う」。そうですか、外部要因(内部要因も多くある)はほぼ時間軸で無視して上手くいきますよ。ですか。理想論を押し通しだ。現実に目を向ければリリース後に行われる外部の途中評価、徐々に完成・変化する結合対象となる周辺状況は、自分たちのチームとは非同期に変化する。こういった変化を自分たちが決めたクロック・エッジで入力、出力するのか(出力はクロック・エッジには乗せないのかも)。
チーム外部とのやりとりに使われる時間間隔はどんなものが有っただろうか、定時 → 翌朝一、午前終わり → {午後一, 定時前}、月→{水|金}、1週間後、最小単位くらいで 3 時間くらいか。2 週間のサンプリング周期では周囲状況に追従することはできない。なんだろう、標本化定理とか制御理論とか難しいことは言わなくても、おかしな想定だと分かりそうなものだ。
応答性が悪い人・チーム・組織はどうなるのだろうか？似たような手法を導入して、一度経験したことが有る。恐ろしいことに会社の中で組織ごと浮いてしまう。組織単位で周囲は離れていく。個人は首にできない、一方、組織はリストラできる。組織全体で誰も口にせずとも恐怖感が共有されるのだ。誰かが口にしたときは相当に深刻な状況だ。
手法が要求している事項: 「作業内容は 2 ～ 3 時間単位で区切る」、「2 週間単位の大まかな仕事内容は 1 つにする」「2 週間後には完了・動作可能なものになっている」。開発手法を考えた人、何作っていたんだろう？ 自分が開発をしている現場では部分ビルドだけで少なくとも 30 分は掛かる。フルビルドで 3 時間だ。
その間、「ただ待っている？」そんな段取りはしない。次週から 3 週間後くらい先までの作業予定内容の勉強、前終わった作業結果の再確認をする。終わったのに何故に再確認？単発的なテストは済ませている。その後は 1 日から 1 週間程度の連続稼働テストを実施する。ループ・スクリプトを組み自動実行を続ける。出力結果の確認、メモリリークやプロセッサ負荷に異常が無いかの確認、最も影響が出やすそうな結合対象の状況変化、その担当者の感触の再確認、おおよそ 2 ～ 3 の作業内容を同時に進めている。
2 週間で動作可能に持ち込むのも難がある。自分はデバドラ屋だ。デバイスを Read/Write して、DMA を動かして、file operations を実装して、部分部分は動くかもしれない。それは結合相手にとっては何も動いていないのと同じだ。
デバイスのデータシート読み、ハードウエア設計部門からの制御指示を熟読し、ステートマシン設計(他色々)、破綻を起こさない排他制御、OS 由来の制約条件、全てを満たすように実装していく。デバイスの Read/Write だけをして、「言われたとおりの動作をしました。ウレシイネ。」なんてストーリーは無いのだ。
ここだけ動けばいいや的なインクリメンタルな開発をしていくと、考えもしなかった排他制御矛盾に陥ったり、ステートマシンの遷移不良を起こしたり、リソースの解放不良を起こす。気づいたときには後戻りする方法すら思いつかない状況だ。
電池ドライバ屋だったときの思いを重ねると、インクリメンタルな開発で、充電しっぱなしで電池爆発、放電しっぱなしでセット文鎮化なんてとてもできないからな...
色々と考えを巡らせてみた。まだスッキリしない。新しい手法を思いついたら人間の現場に持ち込んでメトリック(計測)して評価するなんて、古いのではないか？モデルで表現した(具体的に言えばイベントドリブンで変化するステートマシンで表現した開発者、成果物、外部、内部、を使って表現した)開発現場で有効性と適応できない状況を検証してから、人間を動かすために使って欲しい。摩滅する肉体を持ったもので実験をするなんて勘弁して欲しい。
自分が大学で「ソフトウエア工学」を学んだのは 20 年以上前だ。あれから、何らかの進歩は有ったのだろうか？
モデルができるなら、開発者そのものを置き換えれば良いって？ FPGA の上で「開発者」という回路が動いて「成果物」ができる。ああ、それが一番の願いだ。
久しぶりにダラダラと日記を書くことになりそうだ。
手法が要求している事項: 「チームメンバーの誰もが同じスキルを持ち、誰にでも仕事を割り振ることができて、開発工程の全てを短期間でできる。」... 何だろう、基本的な生産工学の観点無視な手法は。人間で無くても製造装置には能力差があり、できることに違いがある。使用可能な資源割り振りは、基本的な課題のはずだ。そんなの無視で「上手くいきますよ」と... 正直言えばこの時点で手法の有効性に疑問が出てくる。
ソフト開発はほぼ人間の手による。お互いの相性、気持ちの持ちよう、疲労度、作業内容の伝達解像度、ほか色々、製造装置には無い特性がある。この特性も加味して仕事の割り振り、進捗管理、打ち合わせ(あるいは議論)を持たないとチームは半年もすれば暗い雰囲気になる。
おおよそ最近の手法論ではコミュニケーションをすれば、人間的特性が開発進行に与える影響は軽減されるとの立場を取っている。本当だろうか？ 自分も既に 40 才台後半、性格は変わらないし、人との相性も変わらない。色々と高齢者達を話す機会を持った経験からすると、一生変わらない、あるいは加齢に伴う認知能力低下でさらに難しい状態になる。
正面切って「開発チーム内のお互いの相性重視でプロジェクトを進めるよ」といった手法論は無いのだろうか？
手法が要求している事項: 「要求の受付・変更は 2 週間程度のインターバル単位で行う」。そうですか、外部要因(内部要因も多くある)はほぼ時間軸で無視して上手くいきますよ。ですか。理想論を押し通しだ。現実に目を向ければリリース後に行われる外部の途中評価、徐々に完成・変化する結合対象となる周辺状況は、自分たちのチームとは非同期に変化する。こういった変化を自分たちが決めたクロック・エッジで入力、出力するのか(出力はクロック・エッジには乗せないのかも)。
チーム外部とのやりとりに使われる時間間隔はどんなものが有っただろうか、定時 → 翌朝一、午前終わり → {午後一, 定時前}、月→{水|金}、1週間後、最小単位くらいで 3 時間くらいか。2 週間のサンプリング周期では周囲状況に追従することはできない。なんだろう、標本化定理とか制御理論とか難しいことは言わなくても、おかしな想定だと分かりそうなものだ。
応答性が悪い人・チーム・組織はどうなるのだろうか？似たような手法を導入して、一度経験したことが有る。恐ろしいことに会社の中で組織ごと浮いてしまう。組織単位で周囲は離れていく。個人は首にできない、一方、組織はリストラできる。組織全体で誰も口にせずとも恐怖感が共有されるのだ。誰かが口にしたときは相当に深刻な状況だ。
手法が要求している事項: 「作業内容は 2 ～ 3 時間単位で区切る」、「2 週間単位の大まかな仕事内容は 1 つにする」「2 週間後には完了・動作可能なものになっている」。開発手法を考えた人、何作っていたんだろう？ 自分が開発をしている現場では部分ビルドだけで少なくとも 30 分は掛かる。フルビルドで 3 時間だ。
その間、「ただ待っている？」そんな段取りはしない。次週から 3 週間後くらい先までの作業予定内容の勉強、前終わった作業結果の再確認をする。終わったのに何故に再確認？単発的なテストは済ませている。その後は 1 日から 1 週間程度の連続稼働テストを実施する。ループ・スクリプトを組み自動実行を続ける。出力結果の確認、メモリリークやプロセッサ負荷に異常が無いかの確認、最も影響が出やすそうな結合対象の状況変化、その担当者の感触の再確認、おおよそ 2 ～ 3 の作業内容を同時に進めている。
2 週間で動作可能に持ち込むのも難がある。自分はデバドラ屋だ。デバイスを Read/Write して、DMA を動かして、file operations を実装して、部分部分は動くかもしれない。それは結合相手にとっては何も動いていないのと同じだ。
デバイスのデータシート読み、ハードウエア設計部門からの制御指示を熟読し、ステートマシン設計(他色々)、破綻を起こさない排他制御、OS 由来の制約条件、全てを満たすように実装していく。デバイスの Read/Write だけをして、「言われたとおりの動作をしました。ウレシイネ。」なんてストーリーは無いのだ。
ここだけ動けばいいや的なインクリメンタルな開発をしていくと、考えもしなかった排他制御矛盾に陥ったり、ステートマシンの遷移不良を起こしたり、リソースの解放不良を起こす。気づいたときには後戻りする方法すら思いつかない状況だ。
電池ドライバ屋だったときの思いを重ねると、インクリメンタルな開発で、充電しっぱなしで電池爆発、放電しっぱなしでセット文鎮化なんてとてもできないからな...
色々と考えを巡らせてみた。まだスッキリしない。新しい手法を思いついたら人間の現場に持ち込んでメトリック(計測)して評価するなんて、古いのではないか？モデルで表現した(具体的に言えばイベントドリブンで変化するステートマシンで表現した開発者、成果物、外部、内部、を使って表現した)開発現場で有効性と適応できない状況を検証してから、人間を動かすために使って欲しい。摩滅する肉体を持ったもので実験をするなんて勘弁して欲しい。
自分が大学で「ソフトウエア工学」を学んだのは 20 年以上前だ。あれから、何らかの進歩は有ったのだろうか？
モデルができるなら、開発者そのものを置き換えれば良いって？ FPGA の上で「開発者」という回路が動いて「成果物」ができる。ああ、それが一番の願いだ。
お気に入りの記事を「いいね！」で応援しよう
[ソフト開発日誌] カテゴリの最新記事
-
商用電源監視サーバー更新 - 閏年 2/29 以… 2024.05.31
-
Futaba M202MD10B アプリ と コマンドシー… 2023.09.05
-
Intel Core i5-10600K 偽物説 - 近所の HA… 2023.09.04
【毎日開催】
15記事にいいね！で1ポイント
© Rakuten Group, Inc.
