Be Engineer, More Agile. ── 生成AI時代に淘汰されない「意思決定の筋肉」と学習デザイン

はじめに

こんにちは、株式会社メンバーズ Cross Applicationカンパニーの田原です。

株式会社メンバーズのデジタルサービス開発事業では、「Be Engineer, More Agile.（変化に強い、よりよいエンジニアであろう）」というスローガンを掲げています。これは、単なる労働リソースの提供に留まらず、クライアントと共に「最高の開発現場」をゼロから創り上げるパートナーでありたい、という私たちの決意を言語化したものです。

このスローガンは、会社が一方的に「こう動け」と命令するものではありません。むしろ、パートナーとして価値を発揮するために、エンジニアが自律的にどう在るべきかという「問い」を、私たち一人ひとりの主体性に委ねているものだと私は捉えています。

「エンジニアとしてどう在りたいのか？」「この変化の激しい時代に、どうやって価値を証明し続けるのか？」

こうした一人ひとりの主体性や「個」としての覚悟を問う言葉は、現代の目まぐるしく移り変わる時流において、すべてのエンジニアに等しく要求されている本質的な問いでもあるはずです。

会社が定義する枠組みを理解した上で、自分というフィルターを通してそれをどう体現していくか。「技術を磨き続けること（Be Engineer）」と「変化を柔軟に受け入れること（More Agile）」。 この両輪を回すために、私自身が日々の学習をどうデザインし、どのようなマインドセットで技術に向き合っているのか。組織の見解に閉じない、一人のエンジニアとしての解釈を書き記してみたいと思います。

Be Engineer | 生成AI時代の「深掘り」と、エンジニアの真価

私は「Be Engineer」という言葉を、「エンジニアという職能に対する誠実さ」の現れだと捉えています。

会社から「この技術を習得してください」と言われるのを待つ受動的な姿勢ではなく、一人のプロフェッショナルとして、目の前のプロダクトやクライアントにとって「何が本質的な解決策か」を自ら考え抜くこと。効率や流行に流されず、その本質を追求する姿勢こそが、私の「Be Engineer」のスタートラインです。

「AIに書かせる」時代だからこそ問われる、エンジニアの「眼」

生成AIの登場により、コードを書くこと自体のハードルは劇的に下がりました。プロンプト一つで「なんとなく動くコード」が瞬時に出力される。この生産性の革命の中で、私たちの「Be Engineer」という在り方も問い直されています。

私は、これからのエンジニアに求められるのは、「AIが出力した答えの妥当性を、自らの知識と経験でジャッジする力」だと考えています。

確率論の中の「正解」と、エンジニアの「意思」

AIは過去の膨大なデータに基づき、確率的に「正解に近いもの」を導き出しますが、そこには「意思」がありません。一方で、エンジニアの本質的な仕事とは、プロジェクトの文脈に沿った「意思決定」そのものです。

AIは「それっぽいコード」をくれますが、それが全体のアーキテクチャと整合しているか、将来の保守性を損なわないか、セキュリティの脆弱性を含まないかまでを100%保証してはくれません。その最後の責任を引き受け、意思決定の根拠を語れるのは、AIではなく人間である私たちエンジニアの役割です。

「意思決定の筋肉」を衰えさせないための学習デザイン

AIが生成したコードをそのまま受け取り、コピペし続けるだけでは、意思決定の拠り所となる「判断の筋肉」は衰えていく一方でしょう。だからこそ私は、現代の学習において「思考のショートカットをあえて拒絶する」ことが、エンジニアとしての矜持だと考えています。

AIとの「徹底対話」で根拠を血肉化する

AIが出したコードに対し、「なぜこのライブラリが最適なのか」「この書き方のデメリットは何か」を徹底的に問い直します。納得いくまで「根拠」を深掘りすることで、AIの回答を自分の知識として血肉化します。

あえて「AI抜き」で設計の「意図」を固める

ロジックの核心部分は、まず自分の頭で考え、ホワイトボードに書き出します。AIはあくまで、自分の意図を具体化するための「清書」の道具。主従関係を逆転させないことが重要です。

「壊す」経験から、泥臭い「意思決定の土台」を得る

AIが作った「完成品」を眺めるだけでなく、あえて自分で試行錯誤してエラーを出し、その痛みの中で「なぜ動かないのか」を肌感覚で理解する時間を大切にします。効率化で削ぎ落とされがちな「泥臭い試行錯誤」の中にこそ、意思決定の土台となる経験が宿るからです。

こうした主体的な深掘りこそが、AIに代替されないエンジニアの「芯」を作ると確信しています。

More Agile | 変化を味方につける「適応のイテレーション」

「Be Engineer」がエンジニアとしての「芯」を作る活動だとしたら、「More Agile」はその芯を柔軟にし、変化の波を乗りこなすための「動き」の指針です。

私にとってのアジャイルとは、単なる開発プロセスではなく、「不確実な状況下で、いかに早く学び、いかに早く価値へ変換するか」という適応のプロセスそのものです。

学習のイテレーションを「極小化」する

具体的な技術習得においては、私は数ヶ月かけて完璧を期す「ウォーターフォール型の学習」を避け、学習そのものに「MVP（Minimum Viable Product）」の考え方を応用しています。

長大なドキュメントを隅々まで理解するのを待つアプローチは、変化の激しい現代ではリスクでしかありません。最初の数ページで得られた「最小限の知識」を手に、即座に手を動かし、コードを書き、実行へと移します。 

実践を通じて得られたフィードバックを元に、知識をリアルタイムで補強していく。この「実践 → フィードバック → 修正・学習」という極小サイクルを高速で回し続けることこそが、最も実戦的で血肉となるスキル習得に繋がると確信しています。

アウトプット駆動学習 | BEMAへの寄稿

この「極小イテレーション」を完結させるための重要なプロセスが、アウトプットによる言語化です。

私自身、このプラットフォーム（BEMA）への記事寄稿を積極的に活用しています。これは単に知見を披露する場ではなく、「学んだ直後の、まだ熱を帯びた情報を短期スパンで公開し、外部（他者）の視点に晒す」という、学習イテレーションの最終工程です。

記事を書く過程で、曖昧だった理解は強制的に再構成され、論理的な「知」へと昇華されます。公開によって得られるフィードバックは、次なる学習への貴重なインプットとなり、独りよがりな解釈を防ぐ自浄作用として機能します。

個人の学びを「チームの適応」へ変換する

パートナーとして「最高の開発現場」を創り上げるためには、私という「個」が速く走るだけでは不十分です。個人の学習で得た「確信」をチームの「共有資産」へと変換すること。それこそが、スローガンの真の体現です。

私が試行錯誤の末に導き出した意思決定の根拠や、技術的な落とし穴の知見をチームへ還元すれば、組織全体の不確実性を一段下げることができます。 「一人の学び」を「チームの武器」へと繋ぎ、現場全体の適応力を底上げしていく。この連鎖が起きて初めて、私たちはクライアントと共に、真に変化に強いプロダクトを創り出すことができるのだと信じています。

組織の枠を超えた社会での挑戦

私の「Be Engineer, More Agile」は、組織という枠組みの中に閉じるものではありません。一人のエンジニアとして、OSS（オープンソースソフトウェア）への貢献や技術発信を行うことは、技術に対する誠実さを再確認するための重要なプロセスだと考えています。

世界中のエンジニアがどのように課題を解決しているのか、OSSを通じた対話と協働のプロセスは、自分一人では経験できなかった視座を与えてくれます。それは、技術に対する解像度（Be Engineer）をより高め、多様な価値観を柔軟に取り入れる適応力（More Agile）を育む経験になっています。社内の枠を超え、社会という広大なフィールドで価値を証明すること。それこそが、一人のエンジニアとして私が体現したい「Be Engineer, More Agile」のひとつの形です。

技術挑戦を、組織という場で加速させる

この「個」の想いを、単なる理想で終わらせない環境が今の組織にはあります。 私が所属する株式会社メンバーズのCross Applicationカンパニーでは、OSS開発を通じて技術コミュニティへの貢献活動を、組織の重要戦略として明確に打ち出しており、個人の技術的な挑戦を後押しする土壌が整っています。

その一つの事例として、自社開発のパッケージ『qr_image_exporter』を pub.dev に公開しました。これは、私たちが現場で磨き上げた知見を、一つの形にまとめたものです。

磨き上げた技術がパッケージとして誰かの役に立ち、フィードバックが返ってくる。このサイクルを組織の支援を受けながら実践できることは、私に大きな確信を与えてくれました。

個人の主体性が組織を通じて社会の推進力となり、その経験がまた自己の成長へと還流する。この健全な循環の中に身を置くことが、私にとっての「Be Engineer, More Agile」をより深く、実践的なものへと磨き上げてくれています。

おわりに：私たちが目指す「最高の開発現場」 

「Be Engineer」として自らの判断軸を磨き抜き、「More Agile」として変化を可能性へと変えていく。このサイクルは、決して個人一人の成長という境界線で完結するものではありません。

私の学びがチームの共通知となり、チームによる果敢な試行錯誤が、クライアントへの確かな価値へと昇華される。このポジティブな連鎖の先にこそ、メンバーズが掲げる「最高の開発現場」の姿があると確信しています。

生成AIという巨大な変革期において、「Be Engineer, More Agile.」というスローガンは、私たちが羅針盤として持ち続けるべき本質的な問いです。 この言葉を自身の「問い」として掲げ続け、私はこれからも変化を楽しみ、主体的なエンジニアとしての挑戦を続けていきます。

この記事が、生成AI時代を生き抜くあなたの学習デザインの「問い」となることを願っています。

最後までお読みいただき、ありがとうございました！