シェア
はてブ
ソフトウェア開発の現場で品質保証に携わる傍ら、ビジネスの視点から組織づくりや人材育成にも取り組む河原田政典（Mark Ward @mkwrd、以下Mark）さん。QAエンジニアにして経営学修士（MBA）を修めた異色の経歴の持ち主です。
Markさんは「QAエンジニアはビジネスとテクノロジーの架け橋になれるのではないか」という仮説を持ち、これまでさまざまな取り組みを行ってきました。MBAを修了されたのもその一環だといいます。
単に不具合を出さないだけでなく、ビジネス価値のあるプロダクトを作り出すための品質保証を追求する。QAエンジニアから見たソフトウェア開発の課題、ビジネスとテクノロジーをつなぐ取り組み、そして今後のQAエンジニアに求められる姿勢について伺いました。
「メイドインジャパンの品質」に憧れてQAエンジニアに転身
── Markさんは、ソフトウェア開発の現場でチームを品質面でリードしているほか、品質文化研究会「Markin' Quality」を主催するQAブレインとして活躍中です。しかし、QAエンジニアとしてキャリアをスタートしたわけではなかったそうですね。
生活にパソコンが入ってくるのは同世代の中では遅い方でしたね。実家にインターネット回線が開通したのが大学1年生になってからでした。数学が好きで情報技術の底流にある哲学への関心もあり、併せて2000年代のインターネットの世界に触れたことが人格形成にも影響しましたが、それでもソフトウェア開発に携わろうなどとは思ってもいませんでした。
大学では文系の学部に通いました。国家公務員になろうと思っていましたが狭き門に阻まれ、文字通り「大学は出たけれど」状態になりました。そこで、さらに専門学校の1年制コースに通って就職活動をしました。半年間でちょうど80社受けまして、ようやく1社だけ内定がもらえたのがSES企業のシステムエンジニア（SE）でした。
専門学校を卒業するまでの残り半年間は、職種別カリキュラムでIT系職種のトレーニングを受けました。C言語をポインタの扱い方まで学んだほか、卒業研究ではWebアプリの作成に取り組み、要件定義から受け入れテストまで、ウォーターフォール型のプロジェクトを経験しました。プログラミングの上手なメンバーがいましたから、プロジェクトリーダーを引き受けました。毎日の朝会で進捗を確認し、予定通りに進まない中でなんとかリリースにこぎつけ、卒業研究の発表会も乗り切り、2012年4月に晴れて就職しました。
── SEとして働く中で、QAに興味を持つようになったのですか？
新卒で入った会社では、JavaやC言語を使った開発の仕事が中心でした。エンタープライズの仕事も組み込みの案件もありましたが、あるとき、バスの運賃箱のシステム開発プロジェクトに携わったんです。バスの運賃箱はとても機能が多く、内部構造もきわめて複雑で、センサーと物理構造で硬貨の種類を判別して別々の場所に振り分けたり、乗降者数や精算のデータを蓄積したりするほか、両替もすばやくできるようになっています。その運賃箱をテストしたときに、両替機に100円玉を入れるとエラーが出るバグを発見したのが大きなきっかけです。
そのバグは「装置内で回るチェーンから、あるタイミングで特定の音がするとき」にだけ再現する非常にレアなものでした。説明しても他の人には再現できない、ぼくにしか見つけられないバグだったんです。しかも、バスの運行中に発生したら運行がストップして損害と大クレームを招くS級の不具合。それを見つけて改修できたことは、やはり成功体験になりましたね。
この経験がきっかけで、品質保証の仕事に興味を持つようになりました。考えてみたら「メイドインジャパン」の製品が高品質で知られてきたのは、それを支えるプロフェッショナルの存在があるからです。日本人として品質に貢献するという生き方には意義があるのではないかと思ったのです。また、現実的には日本国内だけでも自分よりプログラミングスキルの高いエンジニアがごまんといますから、このまま漫然と仕事をしていてはとても太刀打ちできないと考えてもいました。ドラッカーの『経営者の条件』を改めて読み、自分自身の責任で人生の舵取りをしなくてはと気づいたこともあり、転職を決意したんです。
── QAエンジニアになったきっかけは、バスの運賃箱のテストだったんですね。
今はソフトウェアの仕事が中心で、パソコン上で完結することが多いですが、ハードウェアの品質保証の仕事は面白いですよ。実際に目の前の製品がフィードバックをくれますから。ソフトウェアエンジニアになった今でも、ハードウェアの品質保証に対しては、次元が異なる世界への憧れのようなものがあります。
「何のためにテストをやるのか」を語れるようになりたい
── Markさんは以前、「品質文化試論」というブログ記事の中で、「品質はソフトウェアのためだけの概念ではなく、ソフトウェアを作る人・組織の品質に目を向ける必要があるのではないか」という問題意識を持っている、と書かれていました。QAエンジニアとして働く中で、ソフトウェアの品質だけでなく、組織にも目を向けるべきだと思うようになったきっかけを教えてください。
QAエンジニアを目指して転職したのはテスト・品質保証のSES企業、いわゆる第三者検証サービスの会社で、テストの専門家集団でした。しかし、品質よりもテストという工程と作業そのものに関心が強い人が多く、会話の内容もテストの話が中心だったんです。しかも、その「テスト」はQAエンジニアが行う総合テスト・受け入れテストなどを意味することが多く、開発エンジニアが取り組む単体テスト（ユニットテスト）については我関せずなことも少なくありません。川の下流で水質調査をしていて「水質が悪い！」と声を上げる割に、上流に赴いて自分たちで水質汚濁の原因を調べたり取り除いたりしようとはしないのです。役割分担という意味では正しい姿ですが、融通が利かないようにも思えます。上流から流れてきたゴミを下流で待ち受けて拾うよりも、上流でゴミを流さないような処理をした方が生産的ですよね。
もちろん、テストを通じて見つけた不具合を修正することでプロダクトの品質は向上します。テストは価値ある取り組みです。しかし、開発プロセスの工程の、しかも下流に位置するテストだけが品質保証の唯一の方法のように扱われているというのはおかしな話ではないでしょうか。
加えて「何のためにテストをやるのか」という目的の話があまりされていないことも気になりました。会社員であれば、会社の事業に貢献しなければならないはずです。テストのSES企業に身を置いてみて、この疑問に誰も答えない、いや、誰もそんなことをわざわざ考えたりしないようでした。しかし、会社の目標であるお金を儲けることにつながらなければ、テストの実施も品質の向上も価値がありません。それが前提でなくては仕事になりません。
そこで気づいたのは、テストを仕事にするのは人間であり、組織だということです。なぜテストをし、どうテストを活用していくのか、そのためにどんなテストをどれくらいやるのか……こういう意識を持ち、議論し、推進するのがプロフェッショナルであり、プロダクトやサービスを提供することを真剣に捉える組織のあり方ではないかと、ある意味では当たり前のことに思い至ったのです。
品質には、プロダクトの品質（Product Quality）や、そのプロダクトを開発するプロセスの品質（Process Quality）があると言われています。ぼくはそれに加えて人と組織の品質（People Quality）があると捉えています。人と組織の品質が高くないと、プロセスやプロダクトの品質を向上させるにも限界があります。プロセスを経てプロダクトを生み出すのは、人であり組織ですからね。そして、自社の目指す品質を思い描き、語ることのできる組織づくりを進める、すなわち良い「品質文化」の醸成をリードすることも、品質を向上させる重要な取り組みですから、実はQAエンジニアに期待される役割ではないでしょうか。品質という言葉の意味やQAエンジニアという職種の在り方について、ぼくの認識がこのように変化していったのは、SES企業から事業会社に転職してからでした。
ビジネスとテクノロジーのバイリンガルを目指してMBAに挑戦
── SES企業から金融事業会社に移られた後、現職のグロービスに転職されました。QAエンジニアでありながらMBAを取得しようと思ったきっかけや、決定的な出来事はあったのでしょうか？
グロービスは「経営に関するヒト・カネ・チエの生態系を創り、社会の創造と変革を行う」ことをビジョンに掲げ、グロービス経営大学院やGLOBIS 学び放題、ベンチャーキャピタルなど各種事業展開を進めてきました。そんな環境ですから自己能力向上の意識が高い社員が集まっており、もちろんMBAを修了した社員も数多く在籍しています。
ぼくがMBAを目指すきっかけの中で大きかったのは、2冊の本との出会いですね。1つは2020年のグロービスのリトリートで全社員が読んだ『イノベーション・スキルセット』、もう1つが『LEADING QUALITY』です。
『イノベーション・スキルセット』を読んで、ビジネス（B）とテクノロジー（T）とクリエイティビティ（C）の3領域のスキルを兼ね備えたBTC人材という概念を知りました。書籍ではCの重要性が強調されていましたが、それ以上にエンジニアの実務から考えてみると、特にTからBへのアプローチ、つまりエンジニアがビジネスの言葉を理解することが重要ではないかと考えました。
一般的にエンジニアはビジネスの言葉や考え方に馴染みがありません。逆もまた然りで、営業やマーケターなどビジネス側の社員からすると、エンジニアに対して近寄りがたさを感じることがあるようです。同じ会社の社員なのに溝が生まれてしまうのです。これを解消するために、エンジニアがビジネスの感覚や言葉を学び、共通言語ができるといいだろうなと思いました。
さらに、ぼくはQAエンジニアですから品質という専門領域があります。これを総合して考えて「ビジネスの言葉を話すQAエンジニアがいれば、品質をビジネス価値を高めるものと位置付けられるのではないか。QAエンジニアこそがビジネスとテクノロジーの架け橋になれるかもしれない」という仮説を持つようになりました。
── ビジネス側との溝を埋め、一緒に品質を高めていくためのハブになろうと考えられたのですね。もう1冊の『LEADING QUALITY』はいかがですか。
『LEADING QUALITY』には、品質向上には組織的なアプローチが必要で、ビジョンを持ち、品質をリードできる人材が欠かせないと説かれています。この本には具体的なテストの手法は出てきませんが、その代わりに経営の視点から品質の重要性が説かれています。品質がお粗末だったことで倒産に追い込まれた事例や、不具合を1件修正したことでプロダクトの販路が国中に急拡大した事例などが紹介されています。以前はビジネスにとって「諸経費」でしかなかったテストが今ではビジネス戦略の中心となっている、と書かれたまえがきには非常にインパクトがありました。
この2冊との出会いがMBAを目指すきっかけとなったわけです。MBAで経営の知識を学べば、ビジネスの言葉を話せるようになる。そうすれば、QAエンジニアとしての専門性を活かしてもっと強力にビジネス価値を高められる。そして、MBAホルダーのQAエンジニアとして第一人者、ファーストペンギンになるだろうと。吉と出るか凶と出るかは卒業までわからないけれど、それはきっと人生の2年間を賭けるに値する挑戦ではないかと、そんな風に思いました。
まぁ、実は、以前にMBAを修了されたQAエンジニアの方が何名かいらっしゃるので、ぼくはファーストでもなんでもないのです。ただ、当時は不勉強で存じ上げず、自分の人生で実験を始めるワクワク感がありました。無知とは恐ろしいですが、同時に、志に対して純粋でもありました。
── Markさんは『LEADING QUALITY』の翻訳もされています。やはり、翻訳しようと思うだけの魅力がある書籍だとお感じになったのでしょうか。
『LEADING QUALITY』は日本人に広く読まれるべき本だと思いました。QAエンジニアや技術系の職種の方はもちろん、ソフトウェア品質が関わるすべてのビジネスパーソンのための本です。そう考えたので、ぼくは『LEADING QUALITY』をビジネス書として翻訳しました。
日本で出ているソフトウェア品質に関する本の多くは、具体的な方法論を説明した専門職向けの書籍が中心です。対して『LEADING QUALITY』は「なぜ品質が大事なのか」というWhyの部分を語っており、品質の重要性を経営者の視点から説いています。VUCAの時代と言われて久しいですが、めまぐるしく変わるビジネス環境下でアジャイル開発もそれなりに浸透しているのに、いまだに伝統的「品質の番人」と捉えられることが多いのがQAエンジニアの実情です。その状況を、品質を経営課題と捉えることによって、ドラスティックに変える力がある本だと思いました。
── 翻訳に力を入れているエンジニアは珍しいのではないでしょうか。翻訳に至るまでの思いや経緯を伺えますか。
外国語があまり好きでないエンジニアは多いと感じますが、海外プロダクトの技術文書が英語で書かれているなどはよくあることです。もっとも、外国語を読まずに済むよう、なんとか日本語訳を手に入れようと工夫する方が多いですから、翻訳出版をしようとまで考えるエンジニアは少数派とは思います。
ぼくは翻訳の世界への志を昔から抱いていました。日本という国の躍進は、海外の文物を柔軟に取り入れてきたからこそ成し遂げられ続けてきたのだと学んだことで、ゼロから生み出すのと同じくらい価値がある仕事なのだという憧憬がありました。学部時代の卒業論文はドイツ語をいかに日本語で表現するかという翻訳論でしたし、大学を卒業してからもリーナス・トーバルズが語るTEDのインタビュー動画を日本語で書き起こして社内公開するなど、英文を訳す機会を継続的に得てきました。SES企業で英語を訳したがる社員というのは扱いにくかったようで、当時の上長には苦言を呈されましたけどね。
『LEADING QUALITY』の翻訳を思い立ったときは、書籍の商業出版の経験がありませんでした。まずはできそうなことを、ということでサンプルを作って出版社に持ち込んでみましたが、さまざまな事情があり、残念なことに実現には至りませんでした。
それで、企画した翻訳出版が頓挫したことをTwitter（現X）でつぶやいたところ、t-wadaさんからメッセージをいただきました。「アスキードワンゴの編集長とつなげますよ」と。2020年6月のことです。
「ぜひお願いします！」とお返事して、改めて企画書を作成。その甲斐あって、めでたく翻訳プロジェクトをスタートできたというわけです。
ぼくは2017年から年に1〜2回ほど海外カンファレンスに行っています。その経験から、世界の知を日本にもたらす翻訳の仕事には非常に価値があって、明日につながる学びや気づきを界隈にもたらすことができると感じてきました。それで『LEADING QUALITY』を日本に届けるのは自分がまっとうすべき仕事であり、使命であるとさえ感じてきました。翻訳の過程やこだわりはこちらのブログ記事にまとめてあります。多くの方々の助けを借りながら、2023年11月に出版にこぎつけました。
ビジネス側を巻き込みワンチームで品質に向き合う、MBAの知見を生かした取り組み
── MBAで得たスキルを生かして、具体的にどのような取り組みを行っているのでしょうか？
スクラムチームでのプロダクト開発にあたって、ステークホルダーを巻き込んで品質向上につなげました。スクラムチームの課題を検討してみて、ステークホルダーの意見をうまく反映する仕組みが必要だなと感じました。この現状を解消して、もっとステークホルダーの見解を活用できれば、プロダクトをもっと顧客が利用しやすい、すなわち高品質なものにできるのではないかと考えました。
そうは言っても、ステークホルダーに単にプロダクト開発にフルタイムで加わってもらうのは現実的ではありません。そこで、プロダクトのα版を検証環境に用意し、営業のチームや顧客問い合わせに対応するチームにもテストに参加してもらうという取り組みを始めました。一般的にアルファテストと呼ばれるものです。スクラムチームでも機能のテストは行いますが、そのプロダクトやサービスが本当にエンドユーザーの求めているものなのかという視点は意外と見落としがちです。アルファテストはその落とし穴をうまく埋めることができる方策でした。
アルファテストで得たフィードバックはチケットとして扱われてトレースできるようになりました。ステークホルダーの意見がスクラムチームでどう扱われているか、透明性が上がったのです。
これはMBAで学んだ知見がなければ実現できなかったと思います。MBAに通う前でしたら、スクラムチームとの中だけで話を進めようとして、ステークホルダーと一緒にプロダクト開発を成功させるという発想が出ず、最悪の場合、業務上の利害対立が深刻になっていたかもしれません。社内で対立するのではなく「問題」 VS 「私たち」という構図で捉えることができたこの経験から、ビジネス側を巻き込んで仕事をするマインドがチームに自然と芽生えてきました。
── MBAの知見を取り入れた活動を通して、QAエンジニアはビジネスとテクノロジーの架け橋になれそうでしょうか？
手応えは確実にありますね。『LEADING QUALITY』の仕事に掛けるわけではありませんが、ビジネスとテクノロジーの架け橋というのもある種の翻訳であり、翻訳にはスタンスがあります。ぼくのスタンスはチームへのアプローチです。
アジャイル開発が広がる中で、異なる専門性を持つメンバーがワンチームで働く必要性が高まっています。それには、チームパフォーマンスを高め、働きやすい環境を作ることが重要です。こういったチームマネジメントに関する知識は、MBAで学ぶ人材マネジメントや組織行動とリーダーシップなどの科目が大いに役立っています。一方で、ファイナンスや経営戦略といった、いかにもMBAらしい科目の知見を直接使うような機会は実務上あまりありません。ものを考えるときの切り口としてはかなり便利ですが、今の立場で実践できる範囲は限定的です。
誤解を避けるためにお伝えしたいのですが、MBAの学びは「今・必ず・直接役立たねば価値がない」という次元のものではありません。抽象的な思考力を駆使したり、物事の構造を捉えて問題解決に導いたり、自身の志を再発見して人生を加速させていくような、人間の底力を高めることに真価があるのです。
いずれにせよ、MBAを修めるQAエンジニアがもっと増え、事例も出てくると盛り上がってくるでしょうね。もっとも、界隈で目立っている先行事例がぼくでは力不足で、皆さん二の足を踏んでしまうかもしれませんけれども。
── 「品質文化」を根づかせるために実践されていることはありますか？
いきなり「品質文化をつくろう」というのは無理筋です。チームのメンバーが自分たちなりのやり方を模索し、前向きにチャレンジしていく中で少しずつ根づいていくもの、それが文化ではないでしょうか。トップダウンならともかく、ボトムアップでやろうというなら、最初から文化を目的に動いてもうまくはいきませんよ。そもそも「品質」を大切にするという目線を揃えるところからかなと思います。
ぼくが伴走しているスクラムチームでは、全員で一緒にデザインレビューやユーザーストーリーの作成に取り組んでいます。つまり、誰かが作ったものを全員でレビューします。そうすることで、各自がユーザー視点や技術的な観点など、多様な視点からフィードバックし合えるようになり、課題を早い段階で発見できるようになるんですよね。たとえば、デザインのプロトタイプを見て「このデザインはCSSで実現するのは難しいな」と開発エンジニアがコメントして、ではどういうデザインなら実現しそうか議論するなどです。
こうしてメンバー全員の意識が「よりよいプロダクトを作ること」に向かっていくのです。プロダクトオーナーもスクラムマスターもデザイナーも開発エンジニアもQAエンジニアも、それぞれ何をすべきかを考え、行動するようになり、その結果として高品質なプロダクトが生まれます。ですから、QAエンジニアだけが後工程でテストを消化して品質の責任を負えばいいなんて話ではありません。
そういえば、ぼくたちのチームでは「品質」という言葉を自然と使わなくなりました。品質向上のためにレビューをするというよりは、チーム全体でプロダクトを良くしていこう、顧客満足を実現していこうというマインドが根づいてきたからだと思います。そういう「品質文化」が醸成されてきましたし、その結果としてビジネス価値の向上につながっているのです。
ソフトウェア開発に必要なのは日本の「ものづくり精神」
── 今、日本のQAにおける課題は何だと感じていますか？
多くの会社で共通の課題があると感じています。それは、テストや品質保証という活動を開発チームの外部に丸投げしてしまうことです。
── それがなぜ問題だと考えるのですか？
これまでお話ししてきたように、ソフトウェア開発において、品質はビジネス価値と直結しているはずです。しかし現状は、開発対象の機能とビジネス価値の紐づけが重視される一方で、品質とビジネス価値の関連性が見過ごされがちでしょう。QA部門はビジネス価値に直接貢献しないコストセンターと見なされることが多く、開発以上にアウトソーシングの対象になりやすいのです。
これはあるべき姿とは異なります。プロダクト開発はものづくりです。本来、ものづくりというのは良いものを自分たちの技術で作り上げるという話のはずで、職人たちが協力しながら責任を果たして成す仕事ではないでしょうか。磨き上げてきた技術の中にプライド、職人気質ともいうべき品質へのこだわりが根づいているのが日本のものづくりです。
ソフトウェア開発においても、品質を開発プロセスの中心に据え、チーム全体で品質に対する責任を持ち、自分たちで良いプロダクトを作り上げるのだと考え、取り組むことが重要です。丸投げの思想とは対極にあるのではないでしょうか。
確かに、テストは専門技術ですから、委託先に全面的に頼りたくなるかもしれません。もちろん委託先の企業をビジネスパートナーとして信頼できるような関係性が構築されていくのでしたら、それはすばらしいことです。しかしその場合でも、たとえば委託先が行っているテストの内容を自社の社員が理解しやすい体制にしたり、チーム全員参加の勉強会を業務時間内に開いて意見交換したりするなど、丸投げにならないやり方が検討されるべきだと思うのです。
気に留めておきたい点もあります。品質がクリアしなければいけない厄介なハードルみたいに扱われてしまうと、社内での責任の押し付け合いや、ひどくなると品質検査の不正などにつながりかねません。逆に、クリアしていればなんでもいいと捉えるのも誤りで、課せられた品質水準を満たしていても、ユーザーにとって魅力的でなければ、やはりものづくりとしてはお粗末です。それぞれの組織および職業人の倫理観・創意工夫が問われますね。
プロダクト開発は難しい現実に向き合い、一歩ずつ進めていく仕事です。だからこそ、内製化に取り組み、自分事として扱う事業会社が増えているのは良いことだと思います。それをさらに加速させるべく、日本の「ものづくり精神」に立ち返ることが、これからのソフトウェア品質向上にとって大切ではないでしょうか。
ソフトウェアは0と1で構成されていますが、プロダクト開発という人間のプロセスはゼロイチでは済まないのです。そのプロセスの中で品質保証という軸から価値創造していくエンジニア、それがQAエンジニアなのだという認識が広まるといいなと思います。
── Markさん自身は、今後はどのような目標を描いていますか？
少ない時間で大きな結果につなげる動き方ができるようになれたらと考えています。今はスクラムチームに伴走するインプロセスの形で取り組んでいますが、全部自分でやるのではなくメンバーの力を借りながら、複数のチームをコーチングする形でレバレッジを利かせていけたらと思います。携わるチームを増やしていきたいですね。
また、本業のかたわら、アドバイザーとしていくつかの企業の品質改善に携わったり、社内講演をさせていただいていますが、その活動を継続していければと思っています。品質に関する課題は各社で異なりますが、品質をビジネス価値に結びつけて捉える考え方を広げたいです。地道な取り組みを続けることでクライアント企業の、ひいては日本の産業界全体の品質意識を高められたら、そのために微力ながら貢献できたらと考えます。
── 最後に、これからのQAエンジニアに求められるスキルについて教えてください。
大きく分けて2つあると考えています。
1つ目は、広い視野を持つことです。これまで触れてきましたが、QAエンジニアは自分の担当領域や主な専門であるテストだけでなく、チーム全体や部門全体の最適化を考える必要があります。プロダクトがどのように使われ、どんな価値を生み出すのかを俯瞰する力が求められるのです。客先常駐の準委任の業務に就いている方も、視野が狭い状態では仕事として貢献できる範囲にも自ずと限りがあると、経験上思料します。
そのために役立つのがクリティカルシンキングです。物事を抽象的に捉えて観点を表現したり、逆に具体的に捉えてテストケースを書き出したりと、柔軟に思考を切り替える力がQAエンジニアには欠かせません。特に具体的に物事を捉える習慣がついている方が多いので、抽象思考を意識的に鍛えるとスキルアップに直結するでしょう。
2つ目は、自分がテストのプロフェッショナルであるという自覚を持つことです。これまで「品質」の話をしてきましたが、ぼくは決して「テスト」を軽視しているわけではありません。むしろ、テストはAIでは代替できない仕事の1つです。たとえAIがテストを行ったとしても、それを人間が信用できるかどうかは別問題です。テストはこれからも人間が責任を負うべき仕事であり続けるでしょう。
QAエンジニアは自分の仕事の専門性が持つ価値に意識を向け、自信を持つべきです。そして、なぜ品質が大切なのか、そのために自分たちのテストがどれほど重要なのかを他者に説明できなくてはなりません。それができるQAエンジニアが少しずつでも増えていけば、QAエンジニアという職種の価値が認知され、ものづくりの精神で品質をエンジニアリングする、真のプロフェッショナルとして扱われるようになっていくかもしれません。
QAエンジニアという職種の可能性と期待値は、アジャイル開発が浸透してサイロ化が否定されていく中で、拡大しています。チームと共にプロダクトと顧客価値に向き合い、ビジネスへの貢献実績を示すことで組織内での存在感を上げ、テストや品質保証に対する世間の評価を変えていかなくてはなりません。QAエンジニアはそれができるだけの仕事をしています。
