富士通、人工知能を使ってソフトウェアの品質向上を図るシステムを開発へ 40
ストーリー by hylom
こんなところにもAIブームが 部門より
こんなところにもAIブームが 部門より
あるAnonymous Coward 曰く、
富士通が人工知能技術を使ったシステム開発支援ツールを導入しているという（日経ITpro）。
このシステムで提供されるツールの具体例としては、設計書の自動推敲、素材の検索性の向上、部品のレコメンド機能、読みにくいコードの抽出など。11月に50件の開発プロジェクトで導入するという。
「ん～、この辺気持ち悪いねぇ、なんとかならない？」が言えるまでは人間の出番 (スコア:2)
白い金属製のロボがけだるそうにコードを眺めて、だるそうに指さして
「んー、この辺、気持ち悪いんだけどなんとかならない？
なんていうか、ここ、ほら、この辺」
とか言って分析結果を伝えてくれるコード分析システムが開発されるまでは
まだまだ人間様の出番はある！
＃人間でもいらねぇ
Re: (スコア:0)
「読みにくいコードの抽出など」はモロそれになる可能性を秘めている。
基準が明確だったらそこまででもないんだろうけど
そういうハードコーディングされたルールに基づく動作を人工知能と呼びたくない人は結構いそう。
いやそもそもこのシステム自体を人工知能と呼びたくないやつもそれなりに居そうだけどさｗ
一方ユーザーは (スコア:1)
AIにベンダー選定させた結果富士通は漏れるのであった
Re:一方ユーザーは (スコア:2)
AI同士にもコネとか血縁(?)とかになったりするんですかねぇ…
富士通とNECのAIは仲が悪いとかどっかのはgoogleのOEMなので…とか
人間には見えない符牒で仕様書に通信文が刷り込まれてたりして
Re: (スコア:0)
そのうちコネまで解析されるとか...
Re: (スコア:0)
そうか、ネコを解析するのか。
＃ＮＮＮに気を付けて
Re:一方ユーザーは (スコア:1)
AI: 値段が一円！？ ダントツに安いからここにしよう！
「働かない社員」を抽出 (スコア:1)
そして、社員はいなくなる、ということか。
Re:「働かない社員」を抽出 (スコア:1)
働かない古典的プログラマー経験老害を「レビュー用ロボです」といって
ロボコップみたいなガワつけて出荷するってことですか！！？（違う
「ゼンタイテキニ、コメントガスクナイデス」
「1ショリノギョウスウガオオスギマス」
くらいは判定できそう。
Re: (スコア:0)
それの出力は，むしろ
「ムダナコメントガオオスギマス」
「ショリノブンカツガオオスギマス，1ファイルニマトメルベキ」
となるんじゃなかろうか(偏見
# 古典的プログラマー経験老害が働かない＝余計な事・口出しをしない，なら大歓迎の人は多いはず
Re:「働かない社員」を抽出 (スコア:1)
老害じゃなくむしろ年下だったけれど、前の会社を辞めた引き金は
管理系の役職に上がった彼（会社的には高評価）の
「ドットネットノヒキスウハ、スベテサンショウワタシガフツウデス。
ゼンブヘンコウスベキデス」
だったなぁ。これが上に上がっていく会社だとアレだな、と思って転職活動開始した。
古典プログラマーに教えを受けた元若手もバイタリティだけ持ってるから厄介。
Re: (スコア:0)
事故で手足が切り落とされた老SEが運び込まれた。
「バランスが悪いから、ついでに頭も切り落として。」
そして最凶のロボSEが誕生した。
Re: (スコア:0)
いや、「ビジネスユニットのトップ」が交代させられるんですよ。
ソースコードを画像化して判定！ (スコア:0)
本文では触れられてないけど、このニュースのキモはやっぱここでしょう。静的解析ツールではいけないのだろうか…？
Re:ソースコードを画像化して判定！ (スコア:5, すばらしい洞察)
・関数名や変数名にちゃんと連番が振られているか。
・修正部分の履歴や差分がコメント内に残っているか。
・ポインターやクラスなどの理解し難い言語機能を使用していないか。
富士通製のツールならここいら辺もチェックしてくれると思う。
Re: (スコア:0)
> ・ポインターやクラスなどの理解し難い言語機能を使用していないか。
これ↑が抽出対象の「読みにくいコード」ですね！
Re:ソースコードを画像化して判定！ (スコア:4, 興味深い)
そんなツール使わなくても
1. エディタの倍率を下げて字を小さくする
2. 黒っぽく固まってるあたりがヤバイところ
という判定方法でだいたいやばいところはわかる。
あと、縮小しても数十画面にわたるくらい縦長になるソースはだいたいやばい。
あと、「すでにシステムはあるんですけどサポート切れで…」と言われて出てきた画面の
画像を判定したら表計算ソフトか簡易DBソフトのようなマス目ベースの映像が映っていた場合もヤバイ。
Re:ソースコードを画像化して判定！ (スコア:3, 興味深い)
冗談で書いたつもりが意外にマジで読まれててww
「すでにシステムは有る」の件は、聞いてみたら
・職場で昔に「できる人」が作った秘伝のAccessシステムだった
・同上でExcel VBAパターン
・近いものでVB4とかで作ったアプリが今頃発掘された
という、なんというかシステム開発や移行案件っていうよりは遺跡発掘に近い案件のイメージです。
こういうのってユーザーさんに「これはやばい」と説明してもだいたい納得してもらえない上、
ヘタをすると「昔にこれを作った、尊敬するデキる先輩の作品を馬鹿にするんですかー！！」みたいな
ことになりがちなので、むしろ「いや、＊＊＊社の人工知能が判定した結果なんですよー」と言って
煙に巻く材料としてどっかが「考古学的システムのソース評価AI」を作ってくれないかと思ったりする。
Re:ソースコードを画像化して判定！ (スコア:2, おもしろおかしい)
> そんなツール使わなくても
> 1. エディタの倍率を下げて字を小さくする
> 2. 黒っぽく固まってるあたりがヤバイところ
> という判定方法でだいたいやばいところはわかる。
富士通のシステムは，まさにこの作業をデープラーニングで自動化しています
つまりソースコードを画像に変換して
> 2. 黒っぽく固まってるあたりがヤバイところ
と判定しています
こういう感じで「そんなツール使わなくても…だいたい判る」系のプログラマは今後どんどんAIに置き換わると思われます
Re: (スコア:0)
＞つまりソースコードを画像に変換して
＞> 2. 黒っぽく固まってるあたりがヤバイところ
＞と判定しています
に対抗して，意味のない改行やスペースを多めに入れて，
モノリシックな「黒っぽい塊」を，複数の「小さな塊の群れ」へと分割することで、
F痛AIに「読み易いコード」と誤認識させるテクニックが広まるんですね、分かります。
Re:ソースコードを画像化して判定！ (スコア:1)
「I.C.A.（Intelligent Code Analyzer）」に対抗すべく空白や無駄コメントで
ソースを調整する「A.I.C.A（Anti Intelligent Code Analyzer）」が登場し、
AICA対策として「AAICA」が出てきて、熾烈な電子戦がリポジトリーサーバーで
繰り広げられるという未来が見えます。
Re: (スコア:0)
流石にその作業しかしてない訳じゃないだろうと真面目に書くべきなのかどうなんだ
Re:ソースコードを画像化して判定！ (スコア:2)
そんな簡単なこと・・・は、ベテランだからわかる。
素人には分からないでしょう。
そんなベテランの勘所をAIで真似るというあたりか。
Re: (スコア:0)
これぞエキスパートシステム
Re:ソースコードを画像化して判定！ (スコア:1)
いわゆる人工知能をやれと言われて素人がサムネのクラスタ分析以外に手を出すと手間の割に結果も出ないから
必要機材を買わず事務用ノートとMNISTサンプルコードで済ませることだけを考えるのは会社人としては正しい
Re: (スコア:0)
それをどれだけの速度でやれますか？ってのがツールを利用する目的なのですが。
人間ができるのは当然で、低コストで大量に処理できるかどうかが問題。
Re: (スコア:0)
その人工知能は低コストで大量に開発できるのですか？
言語や環境が変われば、一から学習し直しだろうに。
Re:ソースコードを画像化して判定！ (スコア:1)
本文に対応言語が書いてなかったが.
それなら,読ませてみたいものとして
1)古い(固定書式の)FORTRAN/COBOLで書かれたコード
2)whitespaceで書かれたコード
3)パンチカードとか紙テープで出力されたコード
4)プログラムの仕様書
Re: (スコア:0)
技術的にはCASEツールの発展版でしょう。パターン解析で不具合が頻出するパターンを列挙するんでしょう。
Re: (スコア:0)
これ、下手をするとバグを作りまくってきた人の癖や、
バグを作りまくってきた人を教育した教育課程の癖を学習して局所解に陥ってしまう可能性はないだろうか。
いざ現場に導入するとバグを作りまくってきた人のコードは何を書いてもアラートまみれで、
癖を変えようと妙ちくりんなコーディングスタイルに変えた結果さらにバグが増殖したり、
教育課程側が根本解決を行わずにスタイルだけ変更して、しばらくすると標的が移行するだけになったり、
それを繰り返した結果様々なスタイルが入り乱れて可読性が落ちてやっぱりバグが増殖したり。
発送が斜め上 (スコア:0)
> 具体的にはソースコードを画像化した上で、ディープラーニング（深層学習）で分析。
> ネスト構造が深い、コメントが少ないといった、可読性が悪いソースコードをAIが診断する。
ネスト構造が深いとか、コメントが少ないというのはAIで当たりをつけなくてもレビューアが見ればすぐ判るような...
それにコメントは書けばいいではなくて、ロジックに対する「理由」とか「副作用」とかがちゃんと書かれていることが大事であって、それってAIで判定できんのかね
大前提として、プログラムの構造に問題があるのであって、その段階まで来てたらAIとか関係なしにもう炎上は見えつつあるような気がします。
> 集中的にレビューすることによって、レビューの効率化と品質向上を両立できる」
富○通さんの場合、レビュー対象のソースではなくて、レビューする人の方をAIでちゃんとチェックした方がよろしいかと
Re:発送が斜め上 (スコア:1)
見ればすぐ判ることに見て判ることが担保される賃金の高いレビューアを使うなということだよ
Re:発送が斜め上 (スコア:1)
レビューアのコストを減らすためのツールですよ、と。
まあ、FindBugとかPMDとか古典的な静的解析でも分かるけど、深層学習で違う方向性から探すのも悪くはない。
少なくとも人間が見ればすぐわかることを人間が見なくても分かるようにするのはとても大事だし効果的
Re: (スコア:0)
お前、死神の目もってないの？
見ただけでわかるようになるんだぞ。
Re: (スコア:0)
お前、死神の目もってないの？
そこは直死の魔眼デジタル版じゃろう
Re: (スコア:0)
寿命を半分にしたくないので…
Re: (スコア:0)
コメントが多い時点で構造の問題を疑いますね。
くだらないコメントが多い場合は作成者の練度を疑います。
作成者が設計を信じてない場合もコメントは多くなりますね。
Re: (スコア:0)
> 富○通さんの場合、レビュー対象のソースではなくて、レビューする人の方をAIでちゃんとチェックした方がよろしいかと
富○通さんの場合は一目でヤバイと分かるあいまいな用件定義書やスカスカの仕様書をなんとかしろ。
Re: (スコア:0)
富○通さんの場合は一目でヤバイと分かる案件を売上げ額だけで引き受けてくれるバカ営業や、そんな営業活動の結果の架空の売り上げが実開発で大赤字に変わるのを開発サイドの問題としか考えないバカ経営陣をなんとかしろ。
Re: (スコア:0)
一つのファイル（メソッド）に全部書く、ネスト深くするのはココの「基本」だったぞ。
参照関係というモノ自体理解出来てないのがほぼ大半と判ったのは、.source,.o,.lib,.dllが「コレは何？」「なんで"別ファイルの命令"が呼べるの？」だったから。
そんなのがコード見て「改善」（と言う名の改悪）指示ですからね。