デザイナー職からプログラマー、そしてアジャイル開発へ

──これまでどんなキャリアを歩んできたのですか？

元々美術を学び、グラフィックデザイナーとして7年ほど、印刷物やWebのビジュアル制作に携わってきました。当時の会社ではデザインだけでなく、バックエンドのコーディングも手掛けていました。先輩で、仕事ができるプログラマーの方がいまして、私もプログラミングに触れる機会があり、この仕事へのあこがれが強くなっていきました。やがて転職を志すようになり、職業訓練などでプログラミングを学び直して中規模のシステム会社に入り、そこで業務経験を積んだのちに当社に入社しました。

──富士ソフトを選んだ理由、そして今の仕事の内容を教えてください。

前職では、大型案件の三次請け四次請けや、中小規模の案件がメインでしたが、プライムの大型案件にチャレンジしたい想いがありました。当社は、大きな案件に直接携われるチャンスがあることが魅力でした。現在は札幌にある自社オフィスで、北海道のお客様、主に製造業、大型精密機械などの組み込みソフトや、装置の付随ソフトを開発する部所で管理職を務めています。装置の稼働ログを集めてそのビッグデータを解析・可視化したり、製造レシピの設定値を管理・チューニングするソフトを提供したり、製造現場とソフトウェアを一体で支える仕事です。

──最初からアジャイルだったのですか？

はい、入社一発目の案件がアジャイル開発だったのです。中途で入社し、初日からお客様のところへ常駐となり、最初の案件が大型精密機械メーカー様でした。製造装置のビッグデータを解析し、チャートにしてWeb画面に出力するソフトウェアの開発案件でした。右も左もわからず、ドメイン知識もなくアジャイルも初めてで。PL経験としても多くて10人のチームで、“何でも屋”的な動きをしていたなかで、「さぁアジャイルでいきましょう」という状況に置かれたのです。

──お客様側の状況はどうだったのでしょうか？

お客様内でも装置開発の大半はウォーターフォール型でしたが、PoCなど先行系の現場では徐々にアジャイルが用いられるようになってきました。当社にアジャイル開発のノウハウがあるのか未知数でしたでしょうし、また秘匿性が高い情報の取り扱い方など、いろいろとトライアル的なスタートだったと思います。

お客様から教わりながら積み重ねた日々

──最初はどのようにアジャイルに取り組みましたか？

最初は正直、書籍の知識をなぞるだけの“なんちゃってアジャイル”でした。スクラムだ、スプリントだと言葉は知っていても、テクニックが先行してマインドセットが追いついてない状態でした。チームとしてのあり方や価値観・原則を身につけないでフレームワークをなぞっていて、お客様から「それじゃあアジャイルとは言えない」とご指摘を受けたこともありました。

──そこからどう変えていったのですか？

私自身のマインドチェンジですね。「あなたはスクラムマスターをやってください」と1冊の入門書を渡され、スクラムの三者の役割、「プロダクトオーナー」「スクラムマスター」「開発チーム」を改めて理解し、スクラムのフレームワークを学び直しました。また社外の勉強会に通ったり、モブプロの手法や心理的安全性などマインドセットの知識も得て、以降は試行錯誤しながらプロジェクトを実践していきました。チームで「なぜこうしたか」「次にどうするか」を話し合う習慣を徹底し、少しずつ、形だけでない価値を出せるアジャイルへと進化させていきました。

私を導いてくださったお客様は、元々ご自身でアジャイル開発を実践してこられた方です。私にとっての恩師で、アジャイル開発の魅力を教えてくださった方でもあります。その方との出会いがあったからこそ今の私があり、大変感謝しています。

アジャイル開発に必要なマインドセット、チームビルディングとは

──アジャイル開発とは、そもそもどういう手法なのでしょうか？

アジャイル開発は、少しずつ作っては検証し、軌道修正していく開発手法です。最初にソフトウェアに求められる必要最低限の機能を実装し、短期間にOODAを回しながら枝葉の機能を追加していきます。
具体的にどのような案件に向いているかというと、スタートアップやプロトタイピングがあげられます。また、変化の激しい市場環境に置かれている案件、ユーザーフィードバックを重視する案件、新技術を使う案件など、不確実性が高いプロジェクトに向いています。スモールスタートで開発して、PoCを経て事業化の是非を判断していくような場合が多いです。
逆に、要件が明確に定まっていたり、予算やスケジュールがかっちり決まっていて期限をずらせない案件、非常に大規模な案件などでは、アジャイル開発が不向きな場合もあります。

──では、アジャイル開発にはどんな人、チームが求められますか？

まず大切になるのが“マインドセット”です。ウォーターフォール開発と違い、変化に応じてスコープを柔軟に切り替えることが前提なので、変更に強いチームであることが重要です。私はチーム全員が、つねに技術習得をし続ける必要があることを、最初にメンバーに理解してもらうようにしています。マインドセットについては、プロジェクトを遂行しながらじっくりと習得していくものなので、ある程度時間がかかることも頭に入れておかなければなりません。

そして、チーム全体が成長し続けることです。イテレーション（短い開発サイクル）1～2週間のなかで、レトロスペクティブ（ふりかえり）をしています。アジャイルのポイントは、チームの成長を測定しながら進めることなんです。開発においては当然最善を尽くし、イテレーションを繰り返すなかでできることが増えていきます。そして見積もりにもチームの成長を反映します。ウォーターフォールのように人月や工数を推定して工期を見積もるのではなく、アジャイルでは相対見積もりといって、ボリュームや難易度で相対的に作業量を測り、チームに投げかけます。あらかじめ楽観値と悲観値を設定し、悲観値を下回らないレベルで、かつチームがそのイテレーションで完了できる作業量を加味して見積もりを行うのです。
チームメンバーによって意見が分かれることもありますが、そうした多様性も不確実性の中においては逆にメリットとなることもあります。多様な背景や技術スキルを持つのがチームであり、異なる視点から得られる発見がチーム自身の財産なんです。お客様自身もはっきりとした答えがない課題を解決するには、チームメンバー一人ひとりに、プロジェクトやチームの一員として課題を解決する意志が求められます。

技術的にも、今は「AIと効率的に協業するにはどうすべきか」が大きな課題です。「ペアプロ」、つまりドライバーとナビゲーターにわかれて共同でプログラミングを行う手法ですが、ゴールを示し、必要なインプットを共有し、成果をレビューする、これをAIとペアでまるでチームのように行うのです。アジャイルでなじみのある手法が、思いがけず活きてきました。
チームメンバーのマインドチェンジを促しながら、技術的なレベルアップも必須となる。もちろんマネージメントする側の私も、まだまだ勉強していかなくてはなりません。

参照：アジャイルソフトウェア開発宣言　https://agilemanifesto.org/iso/ja/manifesto.html

お客様との相互理解がなければ成り立たない

──アジャイルを進めるうえで、お客様の理解は必要でしょうか？

はい、それもとても重要な要素です。たとえば私たちは、相対見積もりを使ってスプリントごとにまた見積もりをし、ベロシティ（チームの作業速度）を見ながら進めていきます。お客様自身に答えがない、あるいは答えがあったとしてもより良い方法が眠っている可能性。不確実性コーンにあるプロジェクトの初期段階で16倍のブレ、つまり今の段階では見えていない価値の探求に意味があると考えます。
お客様側にもアジャイルの考え方、すなわち“最初からすべてを決めるのではなく、少しずつ検証しながらより良い価値を見出していく”という進め方を理解していただかなくてはなりません。理解がないまま進めると、見積もりやスケジュール、納期で大きな齟齬が生まれる可能性があります。

──日本のSIer構造では、どんな難しさがありますか？

日本では、お客様、SIer、開発会社という三者構造でプロジェクトを進めることが多く、それぞれ立場や条件、文化も異なります。たとえ我々SIerがアジャイルを理解していても、お客様や開発会社の文化やモチベーション、役割分担の理解が整っていなければ、「なんちゃってアジャイル」になってしまう恐れがあります。だから、初期段階で目的や進め方、期待値を丁寧にすり合わせ、共通認識をもつことが大切になってきます。チームが成長するにつれて生産性が高まっていくことについても、お客様にご理解いただくようにしています。

つねにポジティブに、リスペクトできる関係をつくりたい

──個人として、仕事をする上で大切にしていることを教えてください。

リスペクトできる関係性です。スクラムをやっている以上、職位や年齢などに関係なく、尊敬や理解は大事だと思います。若手であっても、会話のなかに“金の粒”――つまり価値あるアイデアや改善のヒントが潜んでいるかもしれない、そう考えています。だからこそ、若手が安心して意見を言える場、失敗しても許される場をつくりたいと思っています。チームの誰もが安心して挑戦できる環境を整え、みんなで改善と成長を続けられるように努めていきたいです。

また、「経験は思考から生まれ、思考は行動から生まれる」という言葉を大切にしています。失敗を恐れて悩むよりも、実際に行動に移す。学習し、次の行動につなげる。そのために、できる限りポジティブ思考であるように心がけています。
とはいえ、まだまだ道半ばで、試行錯誤の真っ最中です。業務についてチームで意見の衝突があっても、目的思考と心理的安全性が理解できていれば、最後にはノーサイド。みんなでベストを尽くして終われる――そんな仲間をこれからも増やしていきたいです。

※記載の会社名、製品名は各社の商標または登録商標です。