みつばちエンジニア

SEの閉塞感のすごい日常の打開を夢見て、日々のモヤモヤを綴ります。

ハレとケのシステム開発モデル

2024-06-16 08:57:08 | 日記
プロジェクトマネージメントはアメリカでソフトウェア開発に適応して発達してきた手法を体系的に整理したものと言える。
GAFAに代表されるアメリカのハイテク企業が圧倒的なソフトウェア開発力を武器にしていることからも、このアメリカのプロジェクトマネージメントが発展していることが伺える。
ところが、文化や雇用形態、商習慣を考えたときそれを日本でそのまま当てはめることができないのではないかと言う話。

日本古来の価値観にハレとケと言うものがあると言う。

ハレとは
晴れ、非日常、冠婚葬祭

ケとは
褻、日常

日常は質素倹約に暮らし、晴れの日には多くの人が集まり、賑やかな瞬間を楽しむと言う価値観だ。
ハレは瞬間的なものだが、定期的に繰り返すことで持続的な活動となっている。
日本には長く続いているお祭りがたくさんあることからも持続的な活動であることがわかる。

さて、これをシステム開発に当てはめてみよう。

プロジェクトのスケジュールを作るとき、目標となる日程(マイルストーン)を定義する。そのなかで特に大きなマイルストーンをハレとする。
経験的には、システムのリリースに向けた最後の作業がこれにあたる場合が多いのではないかと思う。
システムが多くの人に解放される名実共に晴れ舞台だ。
そして、それ以外の期間をケとする。
ケの時は質素倹約に過ごしながらハレに向けての準備を進める期間だ。

ケの期間のプロジェクトの進め方は以下のような考えかたとなる。
・最小限(もしくはそれ以下)の小さな体制で推進する。プロジェクトのリソース消費を押さえ質素倹約に過ごす期間だ。
メリットは、人数が少ないためコミュニケーションコストを最小限に押さえることができる。また、リソースの制約が大きく、できることが限られるため、余分な仕事を増やさない。担当者一人あたりの責任が重くなり、一人一人が主体的に活動するようになる。細かく役割分担できるほどのリソースでもないため、全員が割りと何でも業務をする必要があり仕事の全体像を学ぶチャンスとなる。
一方、デメリットもいくつかある。個人ごとの負荷が上がるため、各個人の業務時間が長くなる。日頃からリソース不足がたたり、プロゼクトの課題を解決する速度が課題が発生する速度に追い付かず課題が山積みの状態となる。まさにケガレがたまっていく期間だ。

さて、こうしているうちにシステムのハレの日が近づいてきている。
ここで温存しておいたプロジェクトリソースを一気に解放する。最大限の人員をアサインし、溜め込んでいた課題を同時並行で一気に片付ける。やるべきことは課題表に明確になっているため、不要なコミュニケーションコストをかけることなく、担当者をアサインし、対策に着手させることができる。このタイミングになるとプロジェクトオーナーの関心ごとも目下のシステムのリリースであるため、急な仕様変更を思い付く余裕もない。システムのリリースと言うハレの日を共通の目標として、多くの人が集まり皆でラストスパートをかける。
そして、なんとか当初に定義した通りのマイルストーンを達成し、ハレの日を迎える。
集まった皆でその喜びを盛大に共有することができた。このように後がない状況で同じ目標を共有することで仲間意識を情勢させることができる。そして次の祭での再開を誓って解散する。

ここまで書いて気づいたが、この手法は、メテオフォール型開発と非常に相性が良い。
ケの期間を最小限のリソースで過ごすため、メテオフォールによって失うコストが、最小限となっている。また、黙示録があることも都合が良い。ハレの日の日程が決まっていることとなる。

残されたメンバーが、プロジェクトリソースが想定以上に消費されてしまったこと、出来上がったシステムがパッチワークだらけだったことに気づいたときには、既に後の祭りとなっている。

あれ、目指していたのと違う結論となってしまった。もっと良いマネージメント手法とできるように組み立て直さなければ・・・


生成AIの意味

2024-06-13 23:46:34 | 日記
生成AIが作り出したものに意味があるのか

コミュニケーションとは人と人が情報交換して、知識や知見を広げたり、深めたりするもの。

通信とは、テクノロジーを活用して離れた人と人のコミュニケーションを可能にするもの。

放送とは、テクノロジーを活用して一人から大人数に向けた情報伝達を効率化したもの。

インターネットとは、テクノロジーを活用して場所を超えて多対多のコミュニケーションを可能にするもの。

最近の生成AIの発達によって、インターネットの情報が、生成AIによるもので埋め尽くされ、元々の人の意思がわからなくなったり、結果として違ったものになったら、その情報を求める意味はどこまであるのだろう。

みた感じ美しい。
みた感じ正しいっぽい。
みた感じ合理的っぽい。

でも、その意味はあるのか、無いのか・・・
そう思うと、きっと生成AIにより大量生産された頃には見飽きるのではないかと思う。
生成AIによってインターネットのコンテンツは色の無い退屈なもので埋め尽くされるかもしれない。

ならば考え方を変えて、人の意思をより簡単に早く伝えやすくするテクノロジーが生成AIと考えたらどうだろうか。

イメージを文にするのは時間がかかる。
イメージをイラストにするのは時間がかかる
イメージを動画にするには時間がかかる

生成AIによって、これらのテクニカルな障壁を無くすことがてきるかもしれない。
それにより、今まで世に出てこれなかった小さなひらめきが形となってインターネットの上に突如として現れて来るのかもしれない。

そう考えたら生成AIによってインターネットのコンテンツはよりカラフルになるように思えてきた。何だか楽しみになってきた。

それでもやっぱり生成AIに頼らない人の手作業によって手間をかけて丁寧に仕上げた作品は、特別な価値を認められ続けてほしいとも願う。


再発防止ノイローゼ

2024-06-11 16:10:10 | 日記
障害、不祥事なにかと良くないことがあった際に謝罪と共に使われる使われる言葉
原因を究明し再発防止に努めていきます。』

最近、聞くだけでめまいがするようになってきました。
ここからはSEの人為的ミスによる障害を想定して書きます。
システム障害の大半は人が何らかの手を加えた時に発生する。そうであれば、システムに手を加えなければ良いのではないか?当然、そう言うわけにもいかない。電子機器であるハードウェアは寿命が短いし、ソフトウェアはすぐに時代遅れになってしまう。システムがシステムとしての機能を維持し続けるには、常に人手による変更を加えながら運用していく必要がある。当然、人のやる作業なのでミスが発生する危険が至るとこに存在する。

用意した手順の通りに作業を実施しなかった。別の方法でも結果が同じだと思った。(やろうと思ったことが違った:ミステイク)

用意した手順の通りに作業を実施したつもりだった。しかし、結果的にできてなかった。(思ったような操作がてきてなかった、手がすべった:スリップ)

用意した手順を飛ばして実施した。実施し忘れた。(実施内容の漏れ)

用意した手順で作業が開始できなかった。(前提条件が違った、現状の調査不足)

設計時に正しい設計方針を理解できてなく、結果的にデタラメな設計だった。(やろうと思ったことが違った:ミステイク)

設計時に正しい値を記入できていなかった。転記したつもりだが実際は別の値が書き込まれてた。(思ったような操作がてきてなかった、手がすべった:スリップ)

設計時に設計対象箇所が足りてなかった。(実施内容の漏れ)

設計時に設計した値がすでに別用途で使われていた。(前提条件が違った、現状の調査不足)

ここでは、作業実行時と設計時のふたつの工程と、4つの失敗モードで例を考えてみた。
こんなイメージで、あらゆる工程でいろいろな失敗モードが発生する。

『そんな馬鹿な』
と思うかもしれない。
それでも実際に仕事と言う普段と違う精神状態の中では日常茶飯事である。

いずれにしても1人でやると絶対間違える(人間なので)。なので、2人で確認する。

それでも失敗したら・・・

3人で確認する?
それだと、コスト(人件費)に対して得られる効果が薄い。

人を責めずに仕組みを責めろと言うセオリーがあるというので、仕組化を行う?

作業のタスクリストや手順、チェックリストを整備することになるが、細かく具体的に書くと、ボリュームが増える割に、ピンポイントでの対策となり効率が悪い。すぐに類似の失敗が発生する。
逆に幅を持たせて抽象的に書くと、一部のメンバーが内容が理解できずチェックできなかったり、読み飛ばしたりしてこちらの場合でもすぐに類似の失敗が発生する。

そして失敗が発生する度に再発防止を考える。
仕組みの作り込みがある一定ラインに到達すると、再発防止を検討した結果、得られるものが非効率性だけに収束してしまうのかもしれない。

それでも、SEは失敗を振り返り再発防止策をたてなければならない。

それは答えの無い永遠の課題とも思える再発防止に取り組み、傷ついて、疲弊して、その結果でようやく仕組みの重要さや注意深さ、失敗の予感の感度が身に付くのだから。

あえて鋼の錬金術師から言葉を借りよう

『痛みを伴わない教訓には意義がない。人は何かの犠牲なしには何も得ることはできないのだから。』

人類はまだ痛みを伴わずに、自分のこととして教訓を得られる境地には到達できていないのではないかと思う。


DX廃墟

2024-06-01 15:44:48 | 日記
2025年、崖から転げ落ちるようにDXバブルが崩壊し、急速にデジタル市場が縮小した。
2020年代、多くの企業が変化に遅れをとらないようにと突貫工事で開発に着手した新サービスは、デジタルインフラの指数関数的な複雑化を招き、システムを維持運用するコストの増大に耐えられなくなった結果だった。
多くの開発に中だったデジタルシステムは、中途半端な稼働状態で放置されることとなった。

予算削減に伴って人員を削減されたSEチームは、バスタブ曲線を降下した古いハードウェアの置き換えと、頻繁に更新されるソフトウェアのセキュリティパッチへの対応、たま、日々発生する様々な不具合への対応に追われていた。
しかし、複雑化した巨大システムをあるべき状態に保つのに十分なリソースはなく、対応しなければならない課題に対して優先度をつけて日々対応していた。

業務の中核を担うようなシステムのメンテナンスはなんとか続けられているが、あまり使われることの無い、かつて先進的だったDXシステムにまで手を掛ける余裕はなく、数年間の間ほぼそのままの状態となっている。

言ってみたらDX廃墟が立ち並ぶ状態となっている。

荒廃したDXシステムは多くのセキュリティホールがそのままとなっており、一部の中核システムに向けた抜け道も隠されている。そのため、インターネットの探索者達の格好のアトラクションとなっていた。