SEの仕様理解能力

最近、本業のプログラマ稼業と関係の無い話ばかりだったので、今回はsoftwareな話でも。

外勤がまだまだ続くsugarは、案件の途中段階からよく放り込まれます。それで「どうせなら初期段階から参加させてくれー」なんて思うわけです。

で、なぜプロジェクトの初期段階から参加したいかというと…初期段階に参加できることのメリットと、途中参加によるデメリットを書いてみました。

■メリット
 1.プロジェクトの開始段階なので、決まっていない箇所が多い。そのため自分の意見が取り入れられやすい→自分のやりやすいようにプロジェクトをコントロールできる
 2.プロジェクトの途中(もしくは終盤)から参加した場合に比べて、メンバーの知識差があまり開いていない。
■デメリット
 3. 2.とは逆に、途中参加の場合は他のメンバーとの「案件に関する知識のギャップ」を埋めなければならないため、負担が大きい

さしあたって思いついたのはこんな感じ。(「これだけかよ!」って思う人は、他に何があるか教えて下さい。。)

ちょっと話は変わりますが。優秀な(普通の?)SE、PGは「仕様理解が早い」と思います。sugarが今まで見てきた優秀なSE、PGは、ちょいちょいと仕様を聞いて「あー、わかった。これは○○だから△△したらいいんだね」なんて感じでプロジェクトの途中から参加しても、いきなり活躍していました。

その当時はsugarがペーペー(今もですが…)だったこともあり、「なんで少しの情報であんなに理解できるんだ?」なんて思ったりしました。また、途中参加の案件で仕様がさっぱりわからなくて、上司に無能と揶揄された悲しい思い出もあったりしますが…。てゆーか、新卒に「ODBCで接続」とか、DAOでアクセスしてインデックス使わないといけないから…なんて説明で「さぁ作れ」なんて言われても、何から質問すればいいかも全然…とにかく当時は「こんなんわかるか!」って感じでしたよ。。

少し話がズレましたが、当時からsugarなりに仕様の理解能力は非常に重要だと感じました。sugarも途中参加でいきなり活躍したいと思ったわけでw 

で、当時のsugarは迅速に仕様を理解すべく、打ち合わせなんかも必死にノートをとって、話を聞いて、わからなければ質問して…とにかく全神経を集中させて仕様理解に望みました。

それでも、どうしても壁にぶつかってしまいます。質問に対する回答を得ることで、端的に仕様を理解することはできるのですが、全体から見れば「木を見て森をみず」的な状況が多々あったり、「注力すべきポイント」がわからないため、どの事柄にもエネルギーを注いだあげく、結局重要でなかったり…

書いてて自分が情けなくなったりしますが、上手くいきませんでした。あげくの果てには「自分の仕様理解能力が低いのは、自分の理解力が無いからじゃ…」なんて考えたりする始末。そんな状態のまま、わけもわからずプロジェクトをこなす日々が「しばらく」続きました。

それで、何個か案件をこなした後、当時を振り返ってみて、ようやく何が足りなかったか気づきました。
あー、そこ、「遅すぎ」とか言わないでください。。学習能力低いんですよ…

で、それは何かというと、sugarは基礎知識だと思います。経験とか理解力がどーこー言う前に、必須なのは基礎知識でしょう。当たり前の事なんですが、データベースの知識が無い人に、このテーブルはこのフィールドが外部キーになっていて、それに紐づくテーブルはコレで…なんて話をしたところで理解できるはずがありません。業務仕様も必須ですが、それを理解するための基礎知識を持っていないと話にならないわけです。それこそ、「当たり前」なんです。

そこで結局、仕様の理解能力を高めるには…トコトン基礎知識を身に付ける。これしかないと思うわけです。少しでも未経験、扱ったことの無い技術があれば、基本的な使い方やその概念(≒基礎知識)を習得しておくことで、その技術を使用した案件に対しては、仕様理解の非常に強い助けになるでしょう。

そして、もし新しくアサインされる案件で未知の(未経験の)技術を扱う場合でも、基礎知識を常々収集していれば「あぁ、これは○○みたいなもんだな」のように、これまで習得した知識で「例え」が利くことになります。

逆に言えば、自分の知識がそれほど広くもない場合に、新しい技術の案件の仕様理解に苦労するのは当たり前、ということです。そうならないためにも、常々新しい技術の収集は必要ですね。。。

# 未経験の技術を使った新しい案件にすでに組み込まれた場合、
# その技術の習得だけに注力するのは得策ではないと思います。
# とりあえずその技術が使えるようになれば、あとはプロジェクトに
# 関わっていれば自然と身に付くはずなので。

※もう1点、仕様理解についてsugarが重要だと思うコトがありますが、それはまたの機会に…

スポンサーリンク
本文中広告




本文中広告




シェアする

  • このエントリーをはてなブックマークに追加

フォローする

コメント

  1. m_pixy より:

    デメリットは、周囲の人にも及ぶと思います。分からない人が入ってくるということは、その人のフォローにかかる工数も発生するわけだし。

    また、「基礎知識」ですが、本当に重要ですねぇ。これって直接的に知識として役立たなくても、その思想のようなものが他で生きてくるので、もう捨て去られそうな技術であってもなんでも吸収すべきですね。
    プロジェクトで重要な情報を知っている人(管理者に多い)がホスト系出身だったりすると、その用語で会話できると情報のやり取りがスムーズだったりも。

  2. shadow より:

    初期段階から参加のデメリットは、最初の仕様決定が一番大変なことですかね(w
    まさに実力の世界。ここでデスマーチかそうでないかが決まると思います。
    #一定期間の仕事量ではデスマーチ行進中のほうが大変ですけど(w

    まぁ、上のは冗談として、
    ・勘違いに気付かない。
    ・抜けに気付かない。
    ってのが初期から参加のデメリットですかね。
    どれだけ気をつけていても、自分の記憶で補完してしまいます。

  3. sugarball より:

    あぁー、大変遅れて申し訳ないデス。自分から煽っておきながら。。

    >m_pixyさん
    投入される人以外にも、周囲の人にも影響かかりますね。ということはプロジェクト全体にも影響がかかるわけで…結局はまた予定が遅れたりしそうですね。

    「ホスト系」ですか。sugarはオープン系にあたる(?)ので、そっち方面はよくわかりませんが…
    こんなSE<http://www.sysana.com/opinion/003.html>だったら嫌です。。

    >shadowさん
    んー、あながち冗談とはいえないかもw 初期のうちにタコな仕様が混入するとデスマ率が確実にアップするわけで。大変、というか大事です。。

    「勘違いに気づかない」、「抜けに気づかない」、、これもありそうですね。
    プロジェクト終盤くらいの途中参加だと、他のメンバーが気づいて修正してくれる可能性はありますが、初期段階だと「誰も気づかない」可能性もあるわけですねぇ。

    初期~後期のフェーズに関わらず、
    「抜け(or勘違い)発生」→「あまり間をおかず、発覚」
    ならリカバリは簡単ですが、抜け(or勘違い)が長期間潜伏→浮上 だと目もあてられないのは確かだと。。
    —–