これ作るのにお幾らかかりましたか

えっと、なかなか記事の内容がアレな感じなので捨てておこうかと思ったけれど。

以下、引用は全て元記事からです。

 

itpro.nikkeibp.co.jp

 

気持ちはわかるような今ひとつ大丈夫かな、と思ってしまうのが狙いのところ。

時間を浪費しがちな開発業務をAIで効率化し、システムエンジニア(SE)が、開発業務の様々な作業や成果物の品質の向上に充てる時間を捻出する狙い

いつも書いていますけど、品質の向上という概念がおかしいのです。それでは品質がない状態に対して事後対策をするということです。

品質は、プロジェクト化した目的である業務要件を実現するためのプロジェクトの目的そのものなので、品質を備わったものを作る活動をするのです。

モグラ叩きを永遠に続けたいのかな、と思いますね。

開発プロジェクトの作業や成果物の品質の低さが課題になっていることがある。「品質を現場の人任せではなく、技術で底上げする。それによって品質が原因の不採算の案件を減らしたい」

事象は認識できても真因にたどり着けなければそれにかかる労力は徒労でしかないです。お金をドブに捨てるようなものですよ。

システム開発において、不採算案件につながる要因は様々だ。設計書の不備による手戻りが発生したり、ソースコードの品質を高めるのに多くの工数がかかったりするのはその典型だ。

不採算案件なんて生温い言葉で表現しているから一向に収束しないのですよ。赤字、でしょう。あ・か・じ。

赤字になる1番の源泉、起因となる工程は設計書の、じゃないですよ。要件定義でしょう。それを設計工程でまるっと一括りにしてしまうセンスにはどうかと思うけどなぁ。

上流工程は問題ないけど下流工程、つまり外注にアウトソースすることろに問題があるといいたのではないかと勘ぐってしまうなぁ。

それが事実であったとするならば、アウトソースの調達プロセスに何かしらの問題があるのだろうし、成果物の受入検査の仕組みに問題があると捉える方が自然じゃないかしら。

スキルが高いSEであれば、品質で問題を起こすことは当然少ないという。ただし、こうした高スキルの人材には負荷が集中しやすく、リソース不足に陥りやすい。

そりゃメンバで不出来なエンジニアを採用したままで作業品質をモニタリングしていなければ、自然とプロジェクト最適化が働いて出来のいいエンジニアに仕事が集中するのはスループットが出るからだけど、出来るエンジニアのHPが削られてクマまで放置するというかタスクを積み上げるのでSPOFとなってポシャるだけのことですよね。

そこでKIWareを導入し、「高スキルのSEの作業負荷を下げる」「若手SEのスキルを底上げする」という2つの効果を狙う。

高スキルのSEはリソース不足になりがちなところを下げるためには不出来なエンジニアの不出来を正さないといけないんだけど。

あと、いきなり若手SEのスキルを底上げとあるけれど、まず何が底上げされるのかねぇ。技術的な経験知でしょうか、それとも技法的な形式知でしょうか。それとも基礎スキル的な人間の性質に深く依存するところでしょうか。

どれも無理っぽいですけど。

これによって開発の作業品質、成果物の品質を高め、品質が原因の不採算プロジェクトを減らすことを目指す。

作業品質の前に、プロジェクトの作業プロセスやプロジェクトマネジメントとしての基本的なところに欠陥があるから赤字になっているのではないのかしら。

実現できるプロジェクトの作業プロセスを設計しないと計画作成時から赤字に至るリスクをプロジェクト自ら負うのですよ。

成果物の質を高めるのではなく、作業プロセスの中で品質を持てるように作業させるのですよ。いったいそれはどこで表現されているのかしら。

成果物の品質に影響しやすくSEの負担が多い作業にAIを適用し、ソースコードや設計書の品質向上を目指したものが目に付く。

きになるのはやはり手を付けやすい下流工程の成果物からやっているところですね。

要件が実装されいているかどうかが品質を備えているかどうかにつながるのでトレーサビリティをどう考えるかがポイントなんですけれど。

さらに言えば、多分に現状の下流工程の成果物を変えることをしないでなんとかしようとしているところでしょう。リポジトリを統合せずにドキュメントで分解していたり、人が理解できるドキュメントに分けた状態を AIでやってもダメですよ。

全然ダメ。

これらのツールで効率化する作業の多くは、「システム開発のプロジェクトで必要だが、付加価値の低い作業」

いやいや、多段階で要件をコードに変換するのは顧客もエンジニアも要件を翻訳する実用があるから、そういったシステム開発手法を取っているのでしょう。そうでなければいきなりコードを書いて見せて要件満たしているかを顧客にテストさせればいいのだから。

ということでいつまで使われるのかなーというか幾ら掛かったのかなー、これ作るのに。

 

エンジニアのためのデザイン思考入門

エンジニアのためのデザイン思考入門