一緒に働いてくれる人を募集とか呼びかけてみる - 山本大の日記についてトラックバックで質問をいただきました。
これはとても有難い反応ですので、感謝の気持ちと共に、僕なりの答え方で答えさせていただきます。
【トラックバック】
採用募集について、幾つかの質問 - @katzchang.contexts
Q
「大中規模の〜」とありますが、規模とは何のボリュームをさすのでしょうか（ユーザ数？データ数？ステップ数？）？
また、どの位が中規模以上となるんでしょうか？
A
僕らが携わっているシステムは100万ユーザであり、大規模といえるでしょうね。
それに対して僕が1年前に携わったシステムは、総ステップは100万ステップ以上ありましたが、
保守プロジェクトで、2人で追加機能をつくっただけなので小規模プロジェクトでしょう。
じゃあ、何が正しい答えなの？と思うかもしれませんね。
僕らが提示した「条件」は応募者に対するひとつの質問です。
質問には”正しく答える”必要はなく、質問者が期待する回答を答えられたら良いと考えています。
この質問では僕らは、僕らの考える大規模システムの仕事に耐えうるかどうかを聞きたいと思っています。
10人のユーザのトランザクションと100万人のユーザのトランザクションでは設計方法はまるで違います。
100万ステップのコードはソース管理だけでも1チームできるぐらい複雑な管理になりえます。
その課題に対して打開策を持っているかどうかを問いたいと思って条件を出します。
だから答える基準は「応募者にとって大規模システム」で良いのです。
しかしながら、「大規模システム」を乗り切る策は用意しておいて応募して欲しいです。
質問の先にある、質問者の意図を汲み取る能力を見定めています。
この能力は、どこへ行っても必要とされる能力であり、
要件定義などで顧客へヒアリングを行う者が最低限もっているべき能力です。
さて僕らに限らずでしょうけれど募集をするとき
「100万人以上のユーザを持つシステム」とか、「10万ステップ以上」とかいう明確な基準の聞き方はしません。
答えやすい質問を作って答えてもらうなら、僕らはその人のセンスを見抜くための材料を減らしてしまうことになります。
4〜5人程度で構築したシステムを大規模と呼ぶなら、その人のセンスは僕らの常識とは合わないかもしれません。
ある程度あいまいな質問や条件に対して「条件が明確でない」と憤る人がいるなら
その時点で「１＋１＝」というような答えのある質問にしか答えられない人ではないかと僕らは察知できます。
まぁ、そういう意地悪な目でばかり見るわけではないですが、
意図を汲み取る能力は、本当に重要だと思っていて見極めポイントの重要な1つです。
Q
「32歳まで」という年齢制限を設ける理由について教えて下さい。
A
チームの主要メンバーがだいたいそれぐらいの年齢だからです。
「年齢」はチームビルディングをする上で無視したくない要素です。
本人が「年齢は関係ない」と思っていても、周りは違います。
目下のところ僕にとって、応募者よりも僕のチームメンバーのほうが大切な存在です。
もちろん採用させてもらった段階で平等に大切な存在になりますが、今は今のチームが大事です。
僕はチームを円滑にまわすために年齢も性別も経験年数も性格上のフィーリングも重視します。
ちなみに僕は32歳です。
Q
「システムエンジニア（Java - 共通機能開発）」について、
自分の経験上、フレームワークはオープンなものを自分達で組み合わせる、もしくは客先から指定されるパターンのどちらかです。
後者では、提供されるフレームワークはオープンなものに比べ大きく劣っていることが多く、開発を進める上で大きな障害要因となっていました。
原因としては、フレームワーク構築チームとアプリ開発チームのコミュニケーションが足りずに必要な機能が盛り込まれなかったり、
使いにくいAPIしか提供されなかったり、そもそもフレームワーク構築の予算や体制が十分に確保されていなかったり、という感じです。
おそらく、こんな状況は「良くあること」だと思います。これらの課題について、どのようにお考えでしょうか？
A
「与えられた環境」の中で、制約を乗り越えて結果を出せばよいと考えています。
環境や自由度に制約のない仕事などはなく、その中で理想を実現するべく進めることに意義を感じます。
与えられた環境については「今回のゲームのルールだ」と考えるようにしています。
ルールのないゲームほどつまらないものはありません。
トランプでポーカーをしていて、何度でも入れ替えられるルールだったら誰でも強い手をそろえられますね。
僕は、与えられた環境がどのように劣悪と思えても結果を出せる能力を重視していますし、自分自身もそうでありたいと考えて行動しています。
それでなければ、システム開発の仕事などケースバイケースが多すぎてやっていけないことでしょう。
それに、環境が最高でなければ真価を発揮できないチームなどは、常勝のチームにはなれません。
たとえば今、僕らのプロジェクトでは「Oracleの型としてCharとDateしか使ってはいけない」という、前代未聞のルールの中でシステムを構築しています。
まずは、この環境や制約と戦いました。
敵は、プロジェクトの長い歴史の中で育った文化でした。
プロジェクトの統括マネージャーにもネゴって各部署と調整をして、
VarcharやNumberといった普通の型を使えるようにしようと奔走しました。
しかし、結果としてこの制約は崩せませんでした。
崩せないというよりも、崩さないほうが正しいという判断ができるほどの情報が、奔走の中で貯まったのです。
今では、この方針がこのプロジェクトの環境の中では優れた設計だと思えるようになりました。
その後、僕らはDBのすべてのテーブルに対応するJavaオブジェクトを生成するマクロを書き、DAOの中で桁埋めや型変換をするフレームワークを構築しました。
これによって、ほとんどのプログラマーはDBの型がCharだけだという制約を意識しないですむようになりました。
環境と戦ううちに、与えられた環境について分析することになり、意義を知り、メリットが明確にわかりました。
その上で、自分が回りに与えられる最大の施策を考えることができるようになったのです。
与えられた環境について、改善策を提示してプロジェクトを引っ張っていけるなら与える側になることができます。
根本的には、僕は常に「与える側に立っている」という意識を持って仕事をします。
Q
「システムエンジニア（Java - 要件定義〜設計）」では、実装まではしないようですが、
今後、アジャイルやXPなどの方法論を採って開発を進めていく、というようなお仕事はできるのでしょうか？
また、従来のウォーターフォール開発での問題点について、どのようにお考えでしょうか？
A
今、僕らが参画しているプロジェクトは全般的に見ると典型的なウォーターフォールです。
問題点もありますが、見積もりや予算や体制といったことまで考えると理にかなっているとも感じます。
アジャイルのやり方は個人的にとても好きで参考になるアイデアが詰まっていると思います。
しかし、総合的に考えて今の大規模なプロジェクトで全体がアジャイルになることは考えられません。
200人ものメンバーをまとめてミッションクリティカルなシステムの開発をまわし続けるには、どうしても秩序立った工程管理が必要だと感じます。
僕は思うに、ウォーターフォールというやり方も、アジャイルというやり方も、
仕事の進め方の”定石”でしかないと考えています。
プロジェクトを進めているとどのような方法論をとっていても困難にぶつかります。
そのときに、いろんな定石を知っていれば、その場にあったアイデアを出すこともできるでしょう。
たとえば今回、実装部隊が遠隔地に居たために、実装フェイズはアジャイル的なやり方を取り入れました。
テスト仕様書をプログラミングよりも先につくって、レビューをして認識齟齬を無くしてから実装に入るというような流れです。
ペアプログラミング、イテレーション開発などなど、アジャイルなアイデアは色々活用が可能です。
基本的に、変えられるルールは変えるように動けばよいし、
動いてみて変えられないならその中で最も良いと思えることをすればよいと思います。
ウォーターフォールが駄目だと感じれば、アジャイルの契約に変更するぐらい動けばよいと思いますし、過去そう動いてそうなった事案もありました。
契約までひっくるめて上手い提案ができなければ、小さく初めて大きく育てればよいと思います。
環境を一気に変えることはできなくても、土壌を作って種を植えて育てることはできるはずです。
その環境作りもできないなら、ずっと与えられた環境に不満を漏らすしかないと思います。
でも良い環境を探し回って、いろんな会社を転々とする人もみかけますが、
僕は良い方法だとは思いません。
たとえ、すばらしい環境を見つけたとしても、環境なんて小さな要因で壊れてしまうものです。
そしたらまた転々としなくてはならなくなります。
それよりは僕は、自分の好む環境を作り出す能力を養うことをお勧めします。
自分で環境を養う能力を持てば、どこへ行っても最高の仕事ができます。
最後に繰り返しのようになりますが、
与えられた環境をただ嘆く人は不要です。
環境を与えてもらおうと考えているなら、それも的外れかもしれません。
与えられた環境と戦う中で、自分ができる最高の結果をだす人と共に働きたいと思っています。
与える側に立つ意思のある人募集。
いまは立てていなくても、意思を持っているならOKです。
最後に、id: katzchangさん質問ありがとうございます。
