前回に引続き、エンジニアリング業務の分類について説明します。
まず分類とシステムのライフサイクルを再掲します。
- スクラッチ開発
- エンハンス開発
- 更改
- リプレース
今回はエンハンス開発について説明します。
エンハンス開発
エンハンス開発はスクラッチ開発によってサービス開始されてからシステムをブラッシュアップすることです。わざわざエンハンスと言わず、スクラッチでない開発をまとめて運用保守開発と呼ぶことも多いです。ライフサイクルでは運用フェーズが該当しますが、プログラムに修正が入る作業については再び開発フェーズの手順を踏んで作業を進めます。各タスクの詳細についてはライフサイクルの記事を参照してみてください。
スクラッチ開発ではそのシステム開発の構築するための確固たる仕組みを構築することが重要だと説明しました。一方でエンハンス開発で問われる能力は異なります。エンハンス開発に要求される能力は以下の通りになります。
- システムの仕様を理解する能力
- 他人が書いたコードを理解する能力
- 既存のコードに改善を加える、またはその判断をする能力
- リスクを考慮したスケジューリングをする能力
前提として、すでに稼働しているシステムとは言え、その全貌を理解し伝達できる人はそのプロジェクトにはいません。もしスクラッチ開発時のメンバが在籍していたとしても簡単にシステムを理解できるような説明や資料はないものと思ってください。予定通りにいかない、という意味において、スクラッチ開発の大半は失敗します。そんな混乱の中、整合性のとれた設計書を作成したり、引継ぎや受入れの資料など作成する時間はないものです。そしてあとからきた運用メンバ（つまりエンハンス開発メンバ）がその後片付けするのは、なんというか、もう使命だと思ってください。
これを念頭に各項目について説明していきます。
システムの仕様を理解する能力
徐々にシステムが構築されているスクラッチと異なり、エンハンスではシステムに必要な登場人物（サブシステムやソフトウェア）がすでに存在しているため、それらの登場人物とその特徴を同時期に理解する必要があります。漫画「ワンピース」を『ウォーターセブン編』からみるようなものと理解するとよいでしょう。（僕が実際そうでした）
エンハンス開発では専門のインフラチームがすでに解散していることも多く、専門のインフラ要員がいないことがしばしばあります。そのため、プログラミング言語だけでなく、インフラや外部サービスなど幅広い知識が要求されます。これは業務の経験もさることながら、普段の学習も役立ちます。IT スキルをジャンル分けして覚えることを推奨している記事もありますのでよかったらそちらも参照にしてみてください。
システム全体を知ったからなんだ、と思うかもしれませんが、自分がメンテナンスするシステムがどのような構成で、どのように動作しているか理解することは非常に重要です。例えば、本番で HTTP エラーが発生した場合、それがどこで、どのような理由で発生するか、システムの全貌を理解しているとある程度あたりをつけることができます。サーバ（OS）そのものの問題なのか、ロードバランサか、Web サーバか、アプリケーションか、など構成を知っていることで、容疑者が絞り込むことができるということです。
他人が書いたコードを理解する能力
スクラッチの開発ではゼロからシステムを構築するため、いかに悪いコードを混入させないことが肝になります。それに対しエンハンスの開発では、すでに稼働しているシステムをメンテナンスしながら進めるため、改修の際、既存への影響を調査し、デグレードさせないように注意が必要となります。デグレード（degrade）とは劣化や退行を意味する言葉で、改修の影響により、それまで正常に動作していた機能に不具合が出ることです。レグレッション（regression：回帰）とも呼ばれます。日常会話では「デグレ」とか「デグる」なんて言い方をします。尚、デグレードはシステムメンテナンスにおいて、最もやってはいけないことのひとつです。これは覚えておきましょう。
スクラッチとエンハンスで要求される能力が異なるのと同様に、要求される実装スキルも異なります。ここで言う実装スキルとは特定の言語というより、その先にあるスキルのことです。例えば、スクラッチがゼロベースで最善のコードを書くことを要求されるのに対し、エンハンスでは人が書いたコードを正確に、可能な限り素早く読み解くことが求められます。ゼロベースで最善のコードを書くためには、コーディングのセオリーの他にも、言語の特性、性能（処理速度）、セキュリティなど無数の要件に関する知見が必要です。一方、人が書いたコードを読み込むためには、すでにある長大なプログラムから、どの画面でどのクラスが起動するか、という基本的なことから読み解く必要があります。また、大半のプログラムはユーザの無茶な要求に応えるべく、残念な仕上がりになっていることが多々あります。要するに読みづらいのです。逆に読みやすいコードを書くということはそれなりに高度なことであると認識してください。ともあれ、一般的にスクラッチ開発のほうが高度とされていますが、エンハンスにおいてもコードを読むという重要な能力が問われます。
既存のコードに改善を加える、またはその判断をする能力
エンハンス開発においてよく議論といいますか、迷いどころになるのが既存のコードをどこまで踏襲するか問題です。これまでも何度か触れていますが、優秀なプログラマ、優秀な SE は少ないものです。例えば 4人のエンジニアチームだったとして、優秀な SE は 2名もいれば充分精鋭部隊と名乗ることができます。つまり、システムがサービス開始した段階で多くのバグや汚れたコードが無数混入されている可能性が高いということです。汚れたコードを妄信的に踏襲すると、コードの汚染が拡大されるため、そこは踏襲するか適宜判断が必要になります。あまりに汚染が拡大したシステムは、最悪の場合リファクタリング（振る舞いを変えず、コードを整形にすること）に数ヶ月費やすることになります。少しでも汚染率を下げるために、忙しい毎日のタスクの中に、部分的にもコードを改善していく勇気と行動力に加えて、プログラムに関する一定の知見が必要になります。
余談になりますが、キャリアの浅い SE をスクラッチ開発にアサインして、無理やり成長させようとする企業がありますが、その思惑は間違いなく大間違いです。なぜなら、自分軸が定まっていない SE にオリジナルのコードを書かせるには能力の面から難しく、そもそも実装ができないこともあれば、仕様を満たしていてもバグや悪いコードを無数混入させるため、レビューにも非常に労力を要します。本人に無茶を強いるうえ（尚、本人の能力を遥かに上回るタスクは成長には繋がりません）、周りもサポートに苦労するでしょう。若い SE は比較的枯れたシステムのエンハンス開発で諸先輩のコードを読み込ませることで着実にステップすることが可能です。また、稼働しているシステムだとシステム全体も把握しやすく、その分仕様のキャッチアップも捗ると思います。
ただ、コードを読ませるばかりだと眠くなるので、バランスよくアウトプットさせることも極めて重要です。
リスクを考慮したスケジューリングをする能力
スクラッチ、エンハンスにかかわらず、プログラムを実装する前にはどれほどの期間が必要か見積り、それをもとにスケジューリングします。作成されたスケジュールによって一日一日で完了させる必要があるタスクが明確になります。スケジュールなくしてわれわれの業務は成り立ちません。
但し、エンハンス開発ではほとんどの場合、保守業務を兼務しているため、緊急メンテナンスや障害が発生するとそちらが優先されることになります。特にサービス開始して間もないシステムであれば、提供している機能も限られているため、緊急のメンテナンス（例えばデータを手動で操作するなど）が頻繁に発生します。それら緊急のタスクが割り込むことで、予定している開発に遅延が発生する可能性が高いということです。スクラッチと異なり、エンハンスにおいては、見積工数より余裕を持ってスケジューリングする必要があります。
最悪のケースでは、リリースをユーザに告知しているような場合です。リリース日が延ばせないため、余裕がないと、緊急の際には割り込み作業を行いながら、開発をオンスケ（オンスケジュール＝スケジュール通り）で進める必要があります。このような場合、作業時間はどう捻出するか？もちろん、残業や休日出勤で賄うことになります。実際告知しているような場合は相応にリスクを積んでスケジューリングすることになりますが、クライアントがモーレツで IT ベンダをこき使うような傾向があると無茶なスケジュールを要求を飲まざるを得ないことになります。ここはプロダクトマネージャの腕によりますが、作業者としてはどうすることもできません。そのようなプロジェクトであればまず改善されることはありませんので、早いうちに退散しましょう。
次回に続きます。
