こんにちは！エンジニア、佐藤です。

最近関わった２案件で、お客様評価が

• 改善せず終わったもの
• 改善したもの

の比較記事を依頼されたので、反省点も込めて振り返りながら書いてみたいと思います。
まずは２案件のご紹介（とはいえ、詳細はお話できないので雰囲気だけ）がこちらになります。

A案件

aws案件。9月にプロジェクトが開始され12月リリース（結局伸びた）を予定していて、私（佐藤）が投入されたのは12月。案件的にはすでに燃え上がっていた時期でした。かつ、どんどん人員を追加されていたので受け入れる側も非常にバタバタしており、ピリピリした状況からのスタート。
結果、こちらは酷評のまま改善は見れず終わってしまいました。「追加要員はプロジェクトの助けになりづらい」を体現した形になりました……申し訳ない。

B案件

同じく、aws案件。半年前から設計フレーズが開始されており、私はPOCの開発中に投入され、そのまま商品版のリリースまで携わりました。
投入された時の雰囲気としてはA案件と同じく、スタート時期の会議はピリピリしていましたが、私が１年間携わった中では、後半とても和やかに終わりました。
結果、こちらは評価が改善したのでした〜（パチパチ！👏

ちなみにこちらも中盤に人員追加がありましたが、非常にスムーズでした。なので人員追加自体がダメだということは決してないと思います。追加時の受け入れ体制として、仕様説明や勉強時間をしっかり取れていたと思います。

では早速比較していきたいと思います！

1.知識面、技術面の不足

A案件は完全にお客様主導だった。そしてそうなったのも、こちらのawsの知識が圧倒的に不足していたからだと思います。
例えば「AWS Step Functionsを使用してください」という風に、こちらの意向を挟む余地なく、基本的に使用サービスはお客様から全て指示がありました。
そして私たちはそれを使用するのが初めてなので、知識がない →調査から始める →スケジュールが遅れる　の悪循環…。

一方B案件はどうだったかというと、A案件の後だったのでawsの知識が豊富でした。言われたことだけではなく「改善するには」を考慮して、こちらからも提案することができたのが大きな違いだったと思います。

ただ実装（言語、開発環境）はどちらの案件も私は初めて触ったものだったので（フェリックスあるある。）、そこは知らない言語だからだ！とかは関係ないと個人的に思ってます。

2.不具合が多かった

忘れている部分が多かったので、A案件の振り返り会で記載した内容を見直してみると問題点にこんな記載が！

実装者が多く、それぞれの思想でプログラムが実装され、統一性を持たせられなかったこと。（後々のバグに繋がる）

思い返せばA案件、不具合がかなり多かったです。その理由が上の記載で、頷くばかり！
入った時はもうすでに「どちらのコーディングを参考にしたら良いの？」現象が起きてて…。そうはいってもスケジュールは遅れている！とにかく動けば良い！というスタンスだったのでした。これが不具合につながり、A案件では非常に不具合多かったです。
不具合に忙殺されてオンスケに戻らない、そういう悪循環からずっと抜け出せませんでした。
・不具合が多い
・スケジュールが遅れる
この2点がお客様評価が悪い最大の理由だと私は思っています。

一方B案件、実装者自体は自社だけではなく複数社一緒に開発していたのでA案件より多かったです。
一部、確かに統一性がない実装されていた所もありますが（思えばその部分、非常に不具合多く遅れも多かったた…）、フェリックスが関わる範囲では基本的に他社さんと相談し、実装を合わせたと思います。「私の担当部分は、こういう設計思想で実装します」という話を実装前に話し、開発開始しました。
確かに不具合は出していますが、A案件のような不具合連発、というようなことは決してなかったと思います。

試験に関しても、B案件は試験者が仕様をきちんと把握しているメンバーがしていたことが大きかったと思います。
A案件は追加メンバーを試験者に迎えていて、仕様把握していない →その時点で不具合を見つけられない →リリース後に不具合発覚ということが多かった印象です。これがお客様評価を下げていた一因ですよね。

3.コミュニケーション不足

社内はコミュニケーションは活発だったのですが、社外とのコミュニケーションは圧倒的にB案件の方がありました。時には口論となることも多々ありましたが、より良いものにしていきたいという熱意があったからだと思います。
そしてコミュニケーションツールですが、A案件はメールだったのに対してB案件はslackでした。これは断然、slack>メールです。テキストベースではなく、会議で口頭で意識合わせをする方がより良いです。B案件は、少しでも認識齟齬が見受けられた場合、すぐに関係者が集まりweb会議がスタートしていました。

しかしA案件にも会議はあることはあったのですよ…。ただすごく長くて、途中から「参加を見合わせたい」と申し出たような気がします。全てはスケジュールの遅れを取り戻すため！そして、みんな残業に残業しても全然取り戻せなかったのですよね。

比較を通して

今見返してみても、A案件は「ソフトウェア開発におけるQCDが全てダメだったな、そりゃお客様の評価もダメだよな」とちょっと納得する結果になりました。

ここまでの事を踏まえて私たちエンジニアができることは

• まず知識、技術を身につける
• プログラムに統一性を持たせ不具合のない汎用的なシステムを作成する
• 不具合を持たせないよう試験し、現状をしっかり報告できるコミュニケーション能力を身に着ける

なのかなと思いました。
フェリックスではうまくいかなかった案件ともしっかりと向き合う仕組みがあるので（顧客アンケートや振り返り会など）、そこを強みに変えられるよう次期改善のバネにして、更に進化したチームでお客様の期待に応えて行きたいなと思っています。

炎上案件の結果に左右されないチーム

結果は二分しましたが、どちらのプロジェクトもすごく勉強になりました。
ただ、どちらのプロジェクトを通しても共通だったのは「チーム内の関係性は悪くならない」ということでした。悪い結果が出ていたとしても、です。

炎上案件というと、社外 / 社内 両方のやり取りで揉めがちで、プロジェクトが難航するストレスからコミュニケーション面でギスギスしてしまったり、チームの人間関係が悪くなってしまう事ってままあると思うんです。経験則としてそう感じていたのですが…、フェリックス内ではそういう事が無かったのが、これまで自分が（フェリックス以前に）経験してきたチームとは違うな、と感じる所でした。
現在はフルリモートで働いている私ですが、出社するメンバーとの差異なく良好なコミュニケーションが取れていると思います。

もちろん、社内で問題を話し合いハッキリと意見を言わなければいけない場面などで、意見の食い違いが起こったり議論がヒートアップして言い負けたような感じになってしまう時もあります。けどそんな時は、横から誰かが助け舟を出してくれたり、違う意見を理解しようとするフォローがあったりして、やはり皆の軸に助け合いや思いやりがあるなと気づかされます。（そういうメンバーに囲まれると、自分もそうあろうと思えるのも良い所かも知れません）

最後に

プロジェクトが上手くいっていても、いなくても、チームの関係性を良好に保ちながら開発に携われるというのは有り難いことです。関係性の悪化とか変なギスギスとか…そんな所に時間を使ってる場合じゃない！っていうのがフェリックスの本質かも知れませんが。笑
それよりもとにかく結果を出すこと。結果が振るわなくても皆で協力して精一杯開発に注力できること。そんなチームが良いなと思った方は、是非私たちと一緒にやりましょう！興味が湧いた方はフェリックスの募集記事も見てみて下さいね。

それではこの辺で！