エンジニア目線で『エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと』を読んでみた
Amazonでのご購入はこちらからどうぞ
はじめに
『エンジニアじゃない人が欲しいシステムを手に入れるためにすべきこと』（以下、本書）は、ITに疎い主人公が、自分の意向とは無関係にDX室に配属され、悪戦苦闘しながら、なんとかシステム開発の仕事にやりがいを見出していく物語形式のノウハウ本です。
私は、WEB系の受託開発企業に勤めるソフトウェアエンジニアで、普段の仕事は、まさに本書のタイトルのように、エンジニアじゃない人に欲しいシステムを届ける仕事です。
社内で、顧客とのコミュニケーションに悩むメンバーは多く、ならばいっそ発注者側の目線を獲得したいと思い、この本を読んでみることにしました。
以下の感想では、本書を読んで、エンジニア目線で感じた共感や違和感を徒然なるままに書き残しておりますので、何かの参考にしていただけましたら幸いです。
※若干のネタバレも含みます
各章の感想
第１章 IT担当者の心構えの作り方
第１章から、そうそう！と納得したのは、主人公がDX室に配属されるまでのエピソードです。
システム発注側の担当者で、最初からシステム開発を行いたくて入社した、などという人はごく僅かです。むしろ、全くITの知識がないことも珍しくなく、せいぜいエクセルが得意な方だから…程度の理由で任されていたりします。そして、普段は他の担当業務があり、それと兼任する形で仕事をしているので、システム発注はエンジニア任せのサブ業務くらいに思っているのを、エンジニア側からもバレてしまうほどです。そんなわけで、主人公の同僚として描かれる、業務にやる気がなく、とりあえず上司の計画にしたがってベンダーに適当な指示を出すだけのキャラクターも、あるある、と感じさせるものが多かったです。
私たちエンジニアは、システムを開発して、人々の暮らしを便利にすることに憧れ、一生懸命勉強してきた人間ですし、システム開発が本業なので、この温度感の差に落胆してしまうことも少なくないかもしれません。そのため、場合によっては、こういった担当者に「肚をくくらせる」ことが最初の（そして最後までの）仕事になることもあるでしょう。
第２章 業務フローの作り方
第２章では、発注者が、社内の業務フローをまとめ、システム開発要件を炙り出す過程が描かれます。DXやITといった言葉を聞いた瞬間に思考が停止して、それは専門家に任せればいい、と匙を投げる人は、現実にも非常に多いです。しかし、業務のプロ（開発の世界ではドメインエキスパートと呼ばれる人）の存在は、良いシステム開発に欠かせません。なぜなら、会社には固有の業務フローがあり、それが導入され、定着されているのには理由と歴史があり、それをエンジニアが短いヒアリング期間で全てを網羅するのは不可能に近いからです。
本書では、主人公が悪戦苦闘しながらも社内を駆け巡り、何とか納得のいく業務フロー図を作成していきます。それを読んだ率直な感想は「本当にここまでやってくれる発注者なんているのだろうか…」でした（笑）
実際の現場においては、業務フローが事前にまとめられていることなんて稀で、エンジニア側がヒアリングを重ねて、業務フロー図を作っていることも多いのではないでしょうか。エンジニアに限らず、BtoBのビジネスではあるあるだと思いますが、ここまで発注者側にやってもらえていたら、エンジニアは本当にやる気が出ると思います。
また、この章で語られていて、非常に大事だと思ったのは、経営の目的とシステム開発の目的を合わせることです。今のご時世、DXできそうな業務だから、といった半ば思いつきのようなアイデアベースでシステム開発が発注されることも珍しくなく、時間とお金をかけて開発されたシステムが結局のところ無用の長物になってしまうこともあります。そのため、本章で描かれるように、業務フローから導き出された、経営にクリティカルな改善をもたらす課題意識に基づくシステム開発が重要なのです。
第3章 要件定義への関わり方
この章は、エンジニア的には、キツい内容だと感じました。
エンジニアが発注者に望むこと、それは要件定義に責任を持ってもらうことです。第2章でも触れた通り、ドメインエキスパート抜きにして、良いシステムを作ることは不可能です。そんな中、どんなシステムを作りたいのか？（=要件定義）に発注者に全力で向き合ってもらうことが、エンジニアの最大の願いと言っても過言ではないでしょう。
要件定義の段階において、動作するデモもなければ、デザインのモックもない中で、どれだけ具体的にユースケースを想像していけるか、ここが勝負の分かれ目となります。ここでいう勝負とは、発注者vsエンジニアの対決ではなく、発注者withエンジニアで、発注者をビジネスの勝者にするための戦いです。
また、しばしば対立を生むのが、要件定義に書かれていない仕様の扱いについてだと思います。要件定義への追加の記載が一行であっても、それが機能間の連携に関わるものだったりすると、データベースの設計が変更され、既存のデータとも不整合を起こさないようにヒヤヒヤしながらマイグレーションをやり直しつつ、影響範囲の広い改修作業と機能追加を並行して行う…なんてことにもなりかねません。そのような「裏側の苦悩」を発注者側が知らない、分かり得ないのは仕方ないことだと思いますが、せめて業務フロー上の要件の整理についての責任を負い、要件定義にない仕様は実装できない、つまり費用と日数が発生する追加発注となる旨を飲んでもらわないとやってられないというのは、エンジニア側のほぼ全員が思っていることではないでしょうか。
それに対して、本章の内容は、要件定義にない内容でも口頭で触れた機能を実装するように判決の出た判例を持ち出して、ともすればエンジニア側に圧力をかけられるようにも使えるような書き方がされていたので、個人的にはキツいなぁ、と感じてしまいました。
第4章 プロジェクト計画の作り方
この章は、プロジェクトの進行における計画の重要性を描いています。
詳細な計画づくりを怠った結果、プロジェクトが立ち行かなくなり、遂には契約解除にまで発展する…というエピソードです。
計画づくりはプロジェクトの進行において、非常に重要な役割を果たします。それは、誰もが同意することでしょう。ところが、詳細な計画づくりを好む人はあまり多くないように思えます。なぜでしょうか？
おそらく、時間をかけて計画を作り込んでも、プロジェクトが計画通りに進むことがないということを、人生経験から知っているからではないでしょうか。
計画は、当てにならないものです。しかし、それがなくては、プロジェクトメンバーが進捗の遅れや焦りを共有することができません。そのような気持ち悪さを感じさせることが計画の最も重要な役割なのかもしれません。
着手前に作った計画の精度が低いのは当たり前です。計画の精度は、着手前よりも着手初日の夜の方が、1週間後よりも1ヶ月後の方が、正確になります。そのため、当初の計画を守ることよりも、計画（もちろん、そこには「何を作るか」という根本的な問いも含みます）を常に見直し続ける姿勢と決断こそがプロジェクトの成功に求められるものなのではないでしょうか。
第5~6章 ベンダーコントロールの仕方、ユーザーのあるべき姿
第5章と第6章はどちらも、システムを発注する側がどのようにベンダー（エンジニア）と向き合うべきなのか、という姿勢の部分が語られていました。
本書で書かれている通り、お互いに尊重し合い、協力する体制が築けているかどうかは、プロジェクトに関わるメンバーの士気に関わりますし、それが結果として最後の一踏ん張りをするかどうかを左右し、クオリティにまで影響するものです。ただし、現実には"お金を払う側/もらう側"という立場の違いから、発注側が開発側に対して非協力的な態度や無理を強いる場面が多いようにも感じます。開発側の人間は、おそらく発注側が思っているよりも敏感に、発注者がプロジェクトについて、エンジニアについて、どう考えているのか感じ取ってしまっていると覚えておいていただきたいです。
第7章 プロジェクトの手戻りへの対応
手戻り、本当に嫌な言葉です。一度手を動かして進めていた作業を、方針の変更や勘違いなどで一からやり直さなくてはならないことを言います。
このように聞くと、そんな効率の悪いことをしたい人などいないだろうと思うかもしれませんが、世の中には、いとも簡単に手戻りを発生させるタイプの人が一定数存在します。私の個人的な感覚なのですが、手戻りを発生させるタイプの人は次のような特徴があると思います。
- 着手前の段階で、仕様のことを細かく考えていない
- 着手後に突然細かいところまで考え始める
- 気になったことを放っておけない
仕様の細かい部分について考えを巡らせてくれるのはありがたいですし、本当に良いと思ったものを実現するまでこだわるのは大事なことだと思うのですが、如何せん始動が遅すぎるのです。こういったタイプの上司や取引先に何度も手戻りを発生させられると、エンジニアの心はいつか折れます。「手戻り=悪」この認識をシステム開発に携わる全ての人に認識していただきたいです。
最終章 君たちはAIとどう付き合うか
この章は、本書の出版された2024年に非常にホットなトピックとなっていたAIに関して筆者なりの考えを提示している章でした。
具体的な内容としては、「人間の心に触れる仕事はAIには代替されることはないよね」といったもので、特に目新しい意見というわけでもないかな、という印象でした。
全体を通しての感想
エンジニアとして、システム開発を発注する側の心情や事情を理解しようと読んでみましたが、正直、あまり新しい知見を得られたという感覚はありませんでした。
じゃあ、この本は読む価値がないのかというとそうではなく、仮にこの本で提示されている発注側の心得を全て達成している顧客に出会えたら、開発側は間違いなくやる気を出してくれるので、この本はタイトルの通り、システムを発注する側の人にお勧めできる内容かと思います。
もしかしたら、開発側から発注側にこの本をさりげなくお勧めしてみるというのもプロジェクトを円滑に進めるための作戦として使えるかもとも思いました。
Amazonでのご購入はこちらからどうぞ
Discussion