俗な言い方すると「技は盗むもの」。私の基本もそうです。
しかしこれには、落とし穴があって、自分が疑問に感じない事柄の知恵/知識は増幅しなくなります。
業界滞在期間が長い割りに、初歩的な知識が欠落していることも多々あり、入門書に教えられる事も少なくありません。
よきリーダー/師匠の仕事に何が欠落しているか指摘することもあると思うのです。
知識を吸収方法は色色あり、Netの会議室なんかも有効な手段です。(質問する前にするべきことはして下さい)
開発現場での情報は開発テクニックとアプリの仕様 の2分野があります。(他にもあるが)
開発テクニックは、この徒弟制度的な伝達手段でも良いのですが, アプリの業務仕様の伝達をこの手法でやっている箇所があると聞いて、如何なモノかと感じたのです。
例: File一覧作成. 仕様
------------------------
| folder : \xxx\xx\xx |
| file : xxxx.dat |
| 内容を印刷する |
| |
-------------------------
||
VV
-------------------------
| 帳票 |
--------------------------
要件定義書はこの絵の描いた紙一枚。(他にもパワーポイントのタイトルのみの表とかもあった)
うーん! Another Worldな世界。
仕様は言葉で伝えるもの..は共通ではなかった。....256歩さがって黙認しよう。
次に指示されたことは, 「この仕様書をみて疑問に感じたことは説明するから聞きに来い.」
これだと,冒頭の例のように,担当者が疑問を抱かない限り仕様は伝わらないことになる。いいのか!!
この場合は帳票レイアウトも無かった。聞きに行けば教えてくれるらしい。渡した方は、疑問に感じることを期待しているらしい。
私など捻くれているので,疑問は感じずに, File=>帳票とくれぱ 16進ダンプを作ってしまいそう。(これで文句を言われるのはおかしい)
"要件仕様は言葉で記述するものだ"と進言したときの返事は、
Fileレイアウトをみて, 更新日.更新者などの管理項目をはずして印刷する. 集計単位はレイアウトをみれば判断が付く
一覧表印刷なんだからこの絵だけで解かる筈。
絵で解かることを言葉で書くのは冗長だ
とのこと。
仕様などは言葉で一意になるように表現すべきもので、絵などの受け手の感性に依存するような記述はまずいでしょう。
社内開発なら許されるのかもしれないが,一般開発に入ってくると混乱を招く例ですね。
世の中いろんな ,SI業者がいるのものです。