この案件、ぜひ新しいテクノロジでやりましょう！：システム開発プロジェクトの現場から（9）（2/2 ページ）

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

登場、超職人エンジニア

　そういうことで無事、会社の創業以来初の.NETプロジェクトがスタートしました。

　次に私が考えたのは、メンバーの選定についてでした。プロジェクトの本格的な開始までには多少時間があったので、それまでにある程度調査を終わらせ、設計・開発に着手可能な状態にしておく必要があったのです。

　そこで私は、メンバーとしてどのような人を入れるのがいいかな？ と考えました。何人か候補者がいたのですが、結局「かなり寡黙」な「超職人タイプ」の人にお願いすることにしました。

　その人も.NETは初だったのですが、プログラムが3度のメシより好きみたいな感じで、「こんなことできますかねぇ？」という私のさっくりとした質問に常にソースコードで返答してくれるような、とってもすてきな人でした。

　リーダーとしてどういうメンバーの選び方が正しいのかは、正直よく分かりません。ですが、そのときの私の選択が正解だったのは間違いないと思います。後から考えれば、その人のおかげでプロジェクトが無事カットオーバーできたといっても、過言ではないくらいでしたから。

幾多の困難を乗り越えて……

　そして要件も固まり、いよいよ設計・開発フェイズに突入しました。次に直面した問題は、ある程度最初から分かってはいたのですが、.NET開発者が足りないということでした。納期までの期間はそんなに長くありません。正直、育てているヒマなどありませんでした。

　風呂場や電車の中でいろいろと考えた結果、ビジネスロジックについては自社開発したアパレル向け販売管理のパッケージのモジュールを使用もしくはカスタマイズし、.NETからラップするような形で呼び出すことにしました。このようなアーキテクチャにしたことで「超職人」を.NETに専念させ、そのほかのメンバーはパッケージのカスタマイズに割り当てるようにして、.NET技術者不足をなんとか補うことができました。

　余談ですが、設計が佳境のときや課題があるときって、風呂に入っているときや布団に入っているとき、電車に乗っているときでも、「どうすればいいんだっけ？」と常に考えていることありませんか？ 意外と、そういうときにいい考えが浮かんだりします。

　そのほか幾多の困難を乗り越え、無事このプロジェクトをカットオーバーできたことは、私にとって何よりの財産となりました。

　正直、いま考えると、アプリケーションのアーキテクチャはあまり「いけてなかった」ような気がします。例外のハンドリング、ロギング、画面遷移やバリデーションなど、「こうしておけばよかった」と後から思うことも多々ありました。

　また、あまりに便利だったので、ついついPostBackを多用してしまい、カットオーバー後にあまり回線速度の速くない店舗から「遅い」とクレームを受けたこともありました（ちゃんと回線速度とレスポンスの確認ができていませんでした……）。ダブルクリック防止などの機能も、後から無理やり付けました。

　でもそれもこれも、すべて新しい技術にチャレンジしたからこそ学べたことだと思っています。

　既知の技術だけでも、成長はできると思います。でも、未知の領域に足を踏み出すことでしか得られないものがあることを、このとき強く実感することができました。

　ちなみに、このWebアプリケーションは数カ月後、なんとパッケージとして商品化され、数社に導入されることとなりました。

　また、会社主催のフェアにも出展されました。PDA版の商品化なんて話も持ち上がりました（結局PDA版はデモ用システム作成までで、商品化までされませんでしたが）。

　けっこうハッピーな気分になれました。ちょっとだけいけてないアーキテクチャは気掛かりなままでしたが……。

最後に追伸

　どんなシステムを作ったときでも、「こうしておけばよかった……」と思うことが必ずいくつかあります。「こうしておけばよかった……」のない、完ぺきなプロセスで完ぺきなシステムを作れるときはくるのか？ と思う半面、もしそういうふうに感じてしまったら「引退」かな、とも思っています……。

　皆さんは、どう思うでしょうか。

筆者紹介

アクセンチュア・テクノロジー・ソリューションズ

新楽清高

1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス〜要件定義〜開発・テスト〜運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。

「次回」へ

「システム開発プロジェクトの現場から」バックナンバー

• 文書ドリブン開発 テスト文書編
• 文書ドリブン開発 詳細設計文書編
• 文書ドリブン開発 DB設計文書編
• 基本設計文書の質を下げる「4つの心理バイアス」
• 本当は楽しいドキュメント作成
• 新人（3年目）、プロジェクトで「忍耐」を学ぶ
• 新人、集合研修で「伝説」を作る
• 新人（3年目）、先輩デビューで「最悪の振る舞い」
• 新人、アーキテクチャチームで「運命の出会い」
• 1人チームで悩む新人。「この作業って意味あるの？」
• 現場デビューのお供はビジュアル多用の報告書
• 大規模プロジェクトでは「同じ言葉を、同じ意味で」
• 「バッファ込み」の工数がスケジュール遅延の原因
• 運用って、あまりいいイメージはなかったけれど
• 最強チームで挑んだ、「40時間でデータ移行」の壁
• 障害対応とチューニングの危うい関係
• オフショアなんて、怖くない
• 3プロジェクト同時にリード！ どう乗り切る？
• この案件、ぜひ新しいテクノロジでやりましょう！
• 初めてのトラブル対応。これで直ると思ったのに！
• 「できるか！」な設計書に、どう立ち向かう？
• 専門用語で「カッコよく」話すのは簡単だけど
• メンバーとの仕様打ち合わせは海を越えて
• 定まらない要件、ユーザーからのむちゃな要求
• 未経験のデータベース構築に挑戦
• セットアップ全国行脚で九州弁に大苦戦
• 試行錯誤で分かったスパゲッティコード撃退法