甲府では猛暑の日々が続いておりますが、皆様におかれましては如何お過ごしでしょうか。 独立のためにこちらへ引っ越してきたときは、同じ盆地でありながら会津より一段格上の暑さに驚いたものですが、そんなことも今は昔。 五年目ともなれば、さすがにこちらの気候にも慣れ、炎天と熱帯夜を凌ぐための心得と工夫ができるようになってきました。

仕事においても、当初こそは営業回りや他社様のオフィスに入って仕事をさせて頂くことに戸惑うことも多々ありましたが、近年ではそれらの見通しや段取りをある程度は付けることができるようになり、時間・体力の過剰な消耗を避けることができるようになってきたところ。 ただし、こうした「慣れ」はともすれば「慢心」や「油断」につながる危険を多分に含んでいるため、今後も初心を忘れることのないようにせねば、と気持ちを新たにしております。

独立4周年まとめとして昨年公開したエントリでは、ソフトウェア開発における「組織」が果たす役割とその必要性について私が経験した範囲で思ったことを幾つか述べました。

ある程度の規模以上のソフトウェア開発には、設計や実装以外にも多くの職能を持つ人間が携わります。 その際、個人で賄うことが特に難しいのが、全体の調整と金銭まわりの処理、そして顧客 (発注者) との遣り取り。 例えば、各機能をどの順で、それぞれいつまでに作るかというスケジュールは技術的な要因だけでなく、他部門のスタッフやレビューの実施計画によって応じて決める必要があります。 また、開発中に仕様変更などがあった場合には、スケジュール変更や予算の調整なども必要になるでしょう。 スタッフの雇用契約に関する処理も適切に行わなければならず、そのためには各種の法律に関する知識やある程度の実務経験が欠かせません。 また、仕入れに関して発注者からの前払いが受けられない場合は、その分を立て替えなければなりませんが、個人事業主のレベルでは不可能なほど大きな金額になることもしばしばです。

そして何より、そうした大規模なプロジェクトの業務は個人の事情で遅滞させることは許されず、誰かが職務を遂行できなくなった場合に代替の人員を充てる (場合によっては新たに雇用する) ことが必要となるわけですが、そうしたバックアップ体制は組織にしか持ち得ないもの。 そうした「確実性」「信頼性」の有無こそが、個人と組織の達成しうる成果を分ける要因であり、また、趣味的なソフトウェア開発とビジネスにおけるそれの違いでもあるわけです。 会社あるいは担当者によって、そのこなし方の上手い/下手の差はありますが、いずれにせよ、20年前であればいざ知らず、現代のソフトウェア開発はそうした「組織の力」なしには成立しません。

The 4th Anniversary

しかしながら、そこには「組織」であるが故に生じる問題もあり、良いことづくめというわけではありません。 今回はそうした問題が発生する要因と、それらへの対策について思うところを述べてみたいと思います。

私自身、一人で開発を行う際は詳細なドキュメント (例えば仕様書や詳細設計書) を作成することは殆どありません。 「何を」「どのように作るか」はすべて自分が把握しているのに、それをわざわざ文書として出力するのは無駄だからです。 もちろん、それらを作成しておけば役立つ場面もあるかもしれませんが、それに費やした時間の分だけ工数が増え、納期が伸び、最終的な請求金額の増大に繋がることを考えると、どうしてもドキュメント作成に割く時間は最小限に抑えたい。 開発中に必要なのはデータベースの定義書や、外部システムとの連携に関するメモ書き程度。 それに加えて開発が終了、あるいは区切りが付いた時点で、操作手順やモジュールの構成・依存関係などを必要に応じて書き起こしていきます。

ところが組織で行う開発では、そうした「省力化」を行うことは不可能です。 開発に携わる者すべてが、要求仕様や各員の担当するモジュールの連携について共通の認識・理解を得ておかなければ、実用に耐えるシステムを作り上げることなど到底望めません。 それどころか、見かけ上動作する程度のプログラムを組むことさえ極めて困難。 そこで、作るべきソフトウェアに関する情報を開発メンバーが齟齬なく共有できるよう、以下に示すような各種のドキュメントが作られることになります。

• 要件定義書
• 基本 (概略) 設計書
• 詳細 (プログラム) 設計書
• テスト仕様書
• 環境構築・納品手順書

こうして書き出してみると、厳格に標準化された開発プロセスに見えるかも知れませんがそれは幻です。 これらのドキュメントの区分やそれが記述すべき内容について業界内で統一された実用的な規格は存在せず、それぞれの企業やプロジェクトごとに独自の様式と作成プロセスがある、というのが実際のところ。 そしてまた、自分でこれらのドキュメントを書いてみれば、バラバラな職能や知識背景を持つ開発メンバに間違いなく伝わる「厳密」な記述を行うことが以下に困難かが分かるでしょう。 例えば、「商品マスタ一覧画面のリスト上の "削除" ボタンを押したときの動作」について、

という単純な説明を書いただけでは大抵の場合情報不足で、実装担当のメンバから様々な質問を投げかけられることになります。

• 「削除」というのは物理削除 (データベースから消去) か論理削除 (削除フラグを立てる) か?
• その商品についての注文が存在する場合はどうするのか?
• 商品写真やカタログPDFといった関連ファイルの扱いはどうするのか?

そうした不明確さは、製造工程における確認や手戻りとなって工期の空費・品質の低下を引き起こします。 では作成するドキュメントにあらゆる情報を微に入り細を穿って書き込めばよいのかと言えばさにあらず。 現実の開発ではそんなことをやっている時間はありませんし、何より膨大な情報を詰め込まれた文書はそれを読むメンバの時間と集中力を無駄に食いつぶすだけの代物と成り果てます。

それらすべてを挙げ連ね、その経緯について事細かに記述することも原理的には不可能ではありませんが、実際にそれを行ったとすれば、おそらく管理しきれぬ程に莫大な量のドキュメントができあがるはず。 (軽く見積もっても、現在のオーダから二桁は上の量になると考えられます。) その情報の洪水の中にあって、本来の仕様書や設計図に書き込まれていた重要な情報は、その他の数限りない、瑣末な情報に埋もれて見えなくなってしまうことでしょう。

抜け落ちるもの

必要十分な情報を含み、かつ無駄がなく読みやすいドキュメントを書くというのは、プログラミングと同等あるいはそれ以上に技術とセンスが要求される仕事。 オフショアが進み、海外企業への発注が増加している近年では、言語をはじめとした異なる文化背景を持つメンバにも理解できるようなドキュメントを作る必要があり、要求されるスキルの程度はさらに高まりつつあります。 これを行うことができるだけの人材と工数が確保されていない状態で始められた開発プロジェクトは、多くの場合、納期遅れや不具合の多発などによって「炎上」状態になることが多い、というのは改めて言うまでもないことでしょう。

私は技術に関しては割と保守的な志向 (嗜好) の持ち主で、話題・流行の言語やフレームワークを積極的に試したり取り入れたりする方ではありません。 しかし、そんな私から見ても「これはないだろう」と思うくらいに旧いスタイルで行われているソフトウェア開発に遭遇することもしばしば。 さすがに「昭和の」とまではいかなくとも、控えめに言って10年、率直に言えば15～20年ほども昔の設計思想や業務フローが、今現在でもあちらこちらの開発現場に生き延びているのです。 バージョン管理システムが導入されているにも関わらずソースコードの変更履歴をコメントとして残すことが義務付けられている (そのため、ソースコードの半分以上がコメント行になっていたり) などというのもさほど珍しい光景ではありません。

このような時代錯誤じみた状況は何故に発生するのか。 考えられる理由は色々とありますが、その中でも最も大きな要因は「分業」によるメンバー間での知識･技術の分断にあります。 プロジェクトの規模などにもよりますが、要件定義や基本設計等いわゆる上流工程に属する作業は、実際にプログラムを書く下流工程の担当者とは別に人員によって行われることが通例。 その場合、上流工程の担当には下流工程の業務の経験者が割り当てられることになりますが、これは必然的な人員配置だと言えるでしょう。 しかし、ここに大きな問題が。 大抵の場合、下流工程から上流工程への移動は「昇進」の形態を取ってなされることもあり、ひとたび上流へ配置されたならば、以後下流の業務を手掛ける機会は殆ど与えられません。 従って、当人の下流工程の業務に関する知識の更新はこの時点で停止されることになります。 その後も独学を続け最新の技術情報にキャッチアップしていくエンジニアもいますが、上流工程に関する知識・技術を培うというより優先度の高い業務をこなした上でなお、余力で独習を続けられることのできる人材はそう多くはないのが現実。 斯くして上流工程で行われる要件定義や設計は、遅れた知識・技術を以って為されることを宿命付けられることに。 そして、そのギャップは上流工程担当としてのキャリアが長くなればなるほどにその幅を増していくのです。

ウェブアプリケーションを例に取ると、ハードウェアの性能が (現在と比較して) 低かった時代には、(当事の水準において) 大量のリクエストが発生した場合ウェブサーバの負荷が高くなることで応答遅延やダウンといった障害が発生することがよくありました。 そうした問題を回避するため、無料で利用できるレンタルサーバなどでは、リクエストに対してプログラム呼び出しによる処理を行いレスポンス (ページ内容等) を動的に生成するCGIなどの技術をサポートしない、あるいはその動作を制限・限定するサービスも多く見られました。 商用ウェブサービスで利用されるようなサーバは、相対的に高いハードウェア性能を備えていたものの、それでも単位時間当たりに処理できるリクエストの数には限界があった (もちろん現在でも限界はありますが) ため、動的レスポンス生成を避け、バックエンド (管理システムや定期実行処理) の操作で静的に生成されたページ内容をファイルとしてウェブサーバにアップロードしユーザに提供するというシステムの需要も高かったようです。 しかし、その後の10年間でハードウェア性能の向上や負荷分散技術の普及などによって、ウェブサーバが単位時間当たりに処理できるリクエストの数は劇的に増大しました。 たとえ動的なレスポンス生成を行ったとしても、通常業務の範囲で発生しうる程度の数のアクセスでは (プログラムが適切に書かれてさえいれば) サーバはビクともしませんし、想定を上回る数のリクエストが送りつけられた場合でも、(ある程度までならば) ファイアウォール等のセキュリティ機構により、システムそのものがダウンするような事態は回避されるようになっているのが一般的です。

そうした状況の変化はひとつのパラダイムシフトをもたらしました。 以前はソフトウェアシステムの開発・運用において最も大きな価値を有していたのはサーバのハードウェア的な資源、すなわちCPU稼動率やメモリ・ディスクの容量だったわけですが、性能の向上に従ってそれらの希少性は相対的に小さなものとなったのです。 では、それらに代わって貴重になったものは何かと言えば、それは開発・保守に携わる人員がかける「手間」つまり労働力に他なりません。

もともと、コンテンツの静的生成を行うシステムには、動的生成を行うそれにはない特有の複雑さがあります。 例えば、生成したHTMLファイルをウェブサーバにアップロードする処理が何らかの理由で失敗した場合、管理側で保持されているデータ (通常はデータベースに格納されている) と公開領域に置かれているファイルの間に内容の食い違いが発生することになりますが、それをどのようにして検出・修復するのか。 また、コンテンツの量が多くなればアップロード処理時にCPUやディクスI/Oの負荷が急増することになり、その間ユーザからのリクエストへの応答は鈍くなるでしょう。 さらに、アップロード処理が想定の時間内に終了しなかった場合、次の定期処理と「被る」といった問題も発生します。 もちろん、これらはいずれもプログラムの工夫で対処できるものですが、その設計・実装はなかなかに複雑なものになり、当然バグも入り込みやすくなります。 その点、動的生成ならば、ひとつひとつのリクエストへ対応するのに必要な処理だけを記述すればよく、しかも管理側と同一のデータを参照するため、内容の食い違いが発生する恐れもなし。 そうした理由から、レスポンスを動的に生成するシステムの開発および運用にかかる労力は、静的生成を行うシステムのそれと比較して格段に小さくなります。

けれども、自分が製造業務を担当していた頃の「動的生成は重い」という「常識」に捉われた設計担当者は、仮にそれが時代遅れになっていることに気付いたとしても、自分が確実に理解および達成できる静的生成をベースとする手馴れた設計手法を「安全策」として選択する傾向があります。 それが製造工程に余分な手間を強いるものであっても、その結果としてプロジェクトの工期が伸びプロダクトの品質が下がることになっても、自身が「失敗」をしないことが何より重要。 そのように考える上流工程担当者も、残念なことに少なからず存在するのです。

ここまで、「ドキュメント作成」と「設計パラダイム」の問題について述べてきましたが、これらはいずれも、組織によるソフトウェア開発における根本的に避けて通れない課題であると同時に、コミュニケーションの不全によって生じる問題であると私は考えています。

ドキュメント作成の難しさは、要求仕様や設計者の意図を如何にして開発メンバーに過不足なく浸透させるかにあります。 書かなくても分かること、書かなければ伝わらないこと。 少人数で付き合いの長い、気心の知れたメンバのみで構成されるチームであれば、細かいニュアンスも阿吽の呼吸で伝わるのかもしれません。 しかし、そうした情報共有の手法は、従業員の採用や社外への発注といった「外部」との関係の変化に晒されることでたちどころに機能しなくなります。 組織としてのソフトウェア開発の現場で求められているのは、そうした内輪だけで通じる符丁ではなく、誰もが理解できる/誤解しない説明・記述を行う技術を身に付けることなのです。

設計パラダイムの問題も突き詰めて考えれば、上流工程と下流工程の担当者間の健全なコミュニケーションが断たれていることに原因が求められます。 先に「上流工程の担当者は下流の作業に関して古い知識しか持ち合わせていない」と書きましたが、よくよく考えてみれば、下流工程に関することは、それについて他の誰よりも詳細な知識・技術を持っている担当者に諮るなり任せるなりすれば良いのです。 それにも関わらず、部下に「意見を聞かせてくれ」「君に任せた」と言えないのは何故か。 その理由が個人の資質によるものか、互いの関係性によるものか、あるいは制度や規則といった環境によるものなのかはケースバイかと思いますが、いずれの場合においても何らかの対策が必要であることは間違いないでしょう。

とは言え、こうした問題は組織の「内側」からではなかなかその所在を把握することが難しいもの。 現在の環境を「当たり前」のものとして順応してしまった視点・思考からその歪みを認知するのはなかなかに難しいことなのです。 それはちょうど、自分で書いたプログラムからバグを探し出すことが難しいのに似ているかも知れません。 そのため、「外部」から異質な視点・思考を招き入れることは、組織が抱える問題を洗い出すの有効な手段のひとつとなります。 中途採用や派遣で新しい人員が入ってきたときなどは絶好のチャンスなのですが、新入りや下請けというのは立場的に弱いため、なかなか「それっておかしくないですか」といった指摘はしにくいでしょう。

しかしながら、技術コンサルタントとして業務を依頼されたならば話は別。 萎縮することなく問題点の調査・分析を行うことができます。 (むしろ遠慮して言うべきことを言わないことは職務怠慢に該当する。) そんなわけで、独立5年目にして業務内容に「技術コンサルティング」を加えてみることに。 実を言うと、私は今まで「コンサルタント」という業種を胡散臭いものだと考えていましたが、あちこちの開発現場に潜む　「ちょっとした工夫」で改善できる (ように思われる) 問題を目にするにつれ、コンサルティングという業務にもそれなりの意義と需要があるのではないか、と考えを改めた次第。 当然まだ何の業務実績・経験もないわけですので、ご依頼の際は通常の開発業務と並行して発注頂くのがベストプラクティスかと思います。

これまで慣れ親しんできたやり方を変えることなく墨守していくというのも、勿論ひとつの考え方としてありでしょう。 しかし、ITの分野は未だ技術革新が盛んであり、開発現場を取り巻く環境の急速な変化の中では「昨年の常識が今年の非常識なる」ことも然して珍しいことではありません。 その変化は当然、システムの発注者である顧客にも及びうるものであり、業者に対して「常識」の見直しを要求する動機となります。

「もし顧客の担当者が異動などになったとするな。で、新しい担当者が、システムを見て驚くんだ。あれだけ金をかけて改修してきたわりに、この程度の性能しか出ないのか、とな。そのとき失うものは、エンジニア個人の信頼じゃない。会社全体の信頼だ」

罪と罰 (40) 白か黒ではなく、善か悪でもなく : Press Enter■ : エンジニアライフ

改めて言うまでもないことですが、世の中には当方よりもずっと経験・実績豊富なコンサルタントが数多存在しています。 自覚症状はなくても実は大病が見つかって命拾いしたりする「30歳過ぎてから受ける健康診断」のようなものだと思って、健全な業務維持のためこうしたサービスを利用してみるのも良いのではないでしょうか。