タグ: Amazon Web Services / AWS（製品・サービス）

AWSは米国時間6月29日に、コードレビューツールであるCodeGuruの一般公開を発表した（Amazonリリース）。2019年12月に開催されたAWS re:Inventでプレビューをローンチした（未訳記事）。このツールセットは、機械学習を利用してバグを見つけ、また最適化のアドバイスを行う。

CodeGuruを構成する2つのツールであるReviewerとProfilerは、その名のとおりのツールだ。AWSのチームはReviewerを作るために、GitHub上の1万あまりのオープンソースプロジェクトのコードと、Amazon（アマゾン）自身の内部的なコードベースのレビューでアルゴリズムを訓練した。

今回の発表で同社は「アマゾンのような大きな企業でも、毎日書かれるコードの量は膨大であり、コードレビューに十分な時間を割ける経験豊富な開発者を確保することは難しい。しかも経験を積んだレビュアーでも問題を見逃すことがあり、アプリケーションが顧客の目の前で動き出してからバグやパフォーマンスの問題が現れることもある」と述べている。

CodeGuruを使う開発者は自分のリポジトリに継続的にコードをコミットするが、そのリポジトリはGitHubやBitbucket Cloud、AWS自身のCodeCommitなど何でもよい。CodeGuru Reviewerはそのコードを分析してバグを見つけ、見つかったらバグフィックスを提案する。この過程はすべてコードリポジトリに対して行われるため、例えばCodeGuruはGitHubのプルリクエストを作り、それにバグやフィックスに関する情報をコメントとして付けたりする。

機械学習のモデルを訓練するためにユーザーはCodeGuruにフィードバックを送れるが、それは主に「よい（thumbs up）」と「だめ（thumbs down）」だけだ。

CodeGuru Application Profilerは、目的がやや違う。それはコード中の非効率と思われる部分や、無駄なコードを探し出す。このツールはAWSのLambdaやFargateのようなサーバーレスのプラットフォームもサポートする。

最初に発表されたCodeGuruに後から加わった機能の1つとして、Profilerは最適化されていないコードに対して、その損失をUSドルの金額で表示する。

Amazon Machine Learningの副社長であるSwami Sivasubramanian（スワミ・シバスブラマニアン）氏は、発表で次のように述べている。「顧客は常に大量のアプリケーションを開発して動かしており、それらには何百万行ものコードが含まれている。それらのコードの品質と効率性を確保することは極めて重要だ。バグやほんの数行の非効率なコードでも、とても高くつくことがある。しかし今日ではコードの品質を見分ける方法には時間もかかり、手作業で行われているため大規模で行うとエラーも多くなる。CodeGuruは、Amazonの長年のアプリケーション開発とデプロイの経験に機械学習の専門的能力を組み合わせて、ソフトウェアの品質を改善しアプリケーションのパフォーマンスの向上と、無駄なコードの排除でお客様に喜んでいただけるだろう」。

AWSによると、すでに多くの企業がプレビューの期間にCodeGuruを使い始めている。AtlassianやEagleDream、DevFactoryなどの企業も含まれている。

Atlassianのエンジニアリング、テックチームのトップであるZak Islam（ザック・イスラム）氏は、次のように語っている。 「私たちの開発チームが行うコードレビューは、バグの未然の発見では良い仕事をしているが、強いストレスがあるときや、複雑な構造のデータを管理するときのシステムの振る舞いの予見をいつでもできるとは限らない。私たちのように毎日複数のデプロイが行われているところでは、なおさらだ。しかし完成コードに異変が生じたときでも、Amazon CodeGuruの継続的プロファイリング機能があれば、調査に要する時間を数日から数時間へ、数分へ減らすこともできる。現在では弊社のデベロッパーたちはエネルギーを、他社製品との差別化に注ぎ込むことができ、問題の調査に費やす時間をかなり減らすことができた」。

画像クレジット: TechCrunch

［原文へ］

（翻訳：iwatani、a.k.a. hiwa）

米国時間6月24日、AWSはAmazon Honeycode（アマゾン・ハニーコード）を リリースした。これはAmazon（アマゾン）クラウドサービスへのちょっとした迂回路を提供する、スプレッドシートのようなインターフェースを中心に構築されたノーコード環境だ。

結局のところAWSの目的は、開発者にアプリケーションを構築するために必要なすべてのツールを提供することだが、最終的には開発者がすべての要素を組み合わせなければならない。

一方でHoneycodeは、基本的な業務アプリケーションを開発したい非プログラマーにアピールすることを目的としている。もしスプレッドシートの操作方法を知っていて、それをアプリにしたい場合には、Honeycodeが要求に応えてくれるだろう。

このサービスの背後にあるAWSの動機を理解するために、AWSのVPであるLarry Augustin（ラリー・オーガスティン）氏とAWSのゼネラルマネージャーであるMeera Vaidyanathan（ミラ・ベイディアネイサン）氏に話を聞いた。

「私たちにとって、これはAWSのパワーをお客さまの中のより多くのユーザー方々に拡大することなのです」とオーガスティン氏は説明する。「私たちはお客様から、常に解決したい課題があるのだという声を聞いています。そうしたお客様は、ご自身のITチームや、アウトソーシングを含む他のチームに対して、その課題を解決するアプリケーションの開発を任せたいとお考えです。しかし、問題はそれを解決できる開発者の数よりも、カスタムアプリケーションへの要求数の方が、とにかく上回っているということなのです」と続ける。

そうした点ではHoneycodeの背後にある動機は、Microsoft（マイクロソフト）がPowerAppsローコードツールで行っていることとそれほど異なっているわけではない。PowerAppsも結局のところ、Azureプラットフォームを必ずしもフルタイムの開発者ではないユーザーに開放するものなのだ。しかし、AWSはここでは少しだけ異なるアプローチをとっていてHoneycodeのノーコードの部分を強調している。

「Honeycodeに対する私たちの目標は、ビジネスの中心で基幹業務に関わる人、ビジネスアナリスト、プロジェクトマネージャー、プログラムマネージャーといった人たちが、自分たちの問題を解決できるカスタムアプリケーションを、コードを書く必要なく、簡単に作成できるようにすることでした」とオーガスティン氏は語る。「それが重要な要素でした。コーディングは必要とされていないのです。そこで私たちは、出発点として多くの人々がなじみのあるスプレッドシートのようなインターフェースを提供することで、それを実現することを選択しました」。

多くのローコード、ノーコードツールたちは、開発者に「コードに逃げ込む」（オーガスティンの言葉）ことも許すが、それはここでは意図されていない、例えばHoneycodeからコードをエクスポートして他の場所に移動するためのメカニズムは存在していない。

「Honeycodeを開発しているときに、私たちの心をよぎったのは、ああ、もし人々にやりたいことがあって、私たちが彼らにコードに逃げ込むことを許すことでそれ実現できるようになるのならという考えでした。私たちは何度も振り出しに戻って『うーん、じゃあどうやってコードに逃げ込むことを強制せずにそれを可能にできるのだろう』という問に答えようと努力し続けたのです。そこで私たちは、コードに逃げ込むことなく、大きな力を人びとに与えたいというマインドセットへと、自分たちを真剣に追い込んだのです」と彼は述べた。

とはいえ、経験豊富な開発者が他の場所からデータを取り込むためのAPIは用意されている。オーガスティン氏とベイディアネイサン氏は、企業たちがプラットフォーム上のユーザーのためにこれを行うか、AWSパートナーがこれらのインテグレーションを作成することも期待している。

ただし、こうした制限があったとしても、かなり複雑なアプリケーションを作成できるとチームは主張している。

「私たちはAmazon内で、さまざまなアプリを構築している多くの人々と話し合ってきました。そして私たちのチームの中でさえ、私は正直に言えば、まだ不可能だと思える事例に出会ったことはありません」とベイディアネイサン氏は言う。

「複雑さのレベルは、あなたがビルダー（構築者）としてどれくらいの専門家であるかどうかに本当に依存していると思います。アプリの中でデータを特定の形式で表示しようとすると、（スプレッドシートの中に）非常に複雑な式が現れることがあります。そして、決して作り話ではありませんが、入れ子に入れ子がひたすら重なって30行にも及ぶ複雑な式を書く人を見たこともあります。ですから、それはビルダーのスキルに依存していると私は本当に思っています。また、一度Honeycodeでビルドを開始すると、私自身もそうですが、単純なものから始めてだんだんと野心的になって、このレイヤーを追加したい、そしてあんなこともしたい、という具合になることに気が付きました。それは本当に私が目にしてきた、ビルダーたちの進歩の旅なのです。たった1つのテーブルと2、3の画面から始めて、意識しないうちに、ニーズに合わせて進化し続けるはるかに堅牢なアプリが得られるのです」。

Honeycodeを際立たせるもう1つの機能は、スプレッドシートがユーザーインターフェイスの中央に配置されることだ。そうした点からは、このサービスはAirtableのように見えるかも知れないが、その先それぞれのスプレッドシートがまったく異なる方向へ向かっていくことを考えると、見かけ上の比較は意味がないと思う。Retoolも比較の観点からも眺めてみた。こちらの方がより意味のある比較だと思う。しかしRetoolが相手にしているのはもっと高度な開発者であり、コードを隠すこともしない。とはいえ、これらのサービスがスプレッドシートを中心に構築されたのには理由がある。それは、誰もがそれらの使用方法に精通しているからだ。

「人びとは何十年もの間スプレッドシートを使用してきました」とオーガスティン氏は語る。「誰でも良く知っています。また、非常に複雑で、深く、非常に強力な式を記述して、とても強力なスプレッドシートを作成することができます。Honeycodeでも同じことができるのです。人びとがその比喩に十分に精通していることを私たちは感じたので、それをアプリに変える能力とともに、そのフルパワーを彼らに与えることができたのです」。

チーム自身もHoneycodeのリリースを管理するために、そのサービスを利用しているということを、ベイディアネイサン氏は強調した。そして製品名を投票するためにも用いたことも（ベイディアネイサン氏とオーガスティン氏は他にどんな候補があったのかは明かしてくれなかったが）。

「AWSの力を引き出し、それをプログラマーではない人びとの手に渡せるという点で、私たちはある意味、本当に革新的な製品を手に入れたのだと思います」とオーガスティン氏は語った。

［原文へ］

（翻訳：sako）