« 「実用と鑑賞に堪えるモデル作品」を待望する | トップページ | いつまでもプログラミングを楽しむために »

2005.03.05

システム設計は「成果物を他人にジロジロ見られるハズカシイ仕事」

◆設計図を見られたくない設計者たち

筆者もパネラーとして参加した「DOA+コンソーシアム第三分科会」の第1回会合「データモデリングって実際どうなの?(2005.2.15)」の議事録が公開された。読み物としてもなかなか面白いのでお勧めしたい(ただし閲覧するためにはDOA+への会員登録が必要)。

とくに興味をそそられたのは、基調講演をしたテプコシステムズの國澤(くにさわ)氏のパネルディスカッションでの発言だ。社内での設計事例を集めたモデルライブラリーを作ろうとして挫折した理由として、彼は次のように語っている。

プロジェクトをやっている人自身が自分のつくったモデルを公開したがらないということがより大きな問題でした。自分が作成したモデルを公開して、周りから文句をつけられたくないというメンタリティが非常に強いようです。

◆テクニカルレビューの困難

筆者も同じような経験をしたので彼の無念さがよくわかる。一昨年まで働いていた職場で、筆者は実装が始まる前の「テクニカルレビュー(開発企業内の技術者を集めての設計レビュー)」を励行していたが、ついに社内全体の習慣にはならずじまいだった。なぜなら、大勢の前で自分のモデルを解説したいと考えるようなキトクな人間(つまり変人)は、筆者くらいのものだったからだ。

テクニカルレビューの有効性に異を唱える者はいなかった。実装前にこれをやることで、設計品質が高まってプロジェクトの利益率が向上するし、個々の経験が共有されることで技術者の成長が速まる。また、公開されることがわかっているので、普段からの設計作業の真剣さも生まれる。

しかし、年季を積んだ技術者の多くにとって、テクニカルレビューは敬して遠ざけたいものだった。「まだ仕様が固まっていない」とか「もうユーザが承認したからレビューしても意味がないし、そもそもそんな時間がない」といった理由で実施が見送られることが少なくなかった。じっさい、開発の現場にはそのような「テクニカルレビューをやらないための理由」はごろごろしているので、よほどの強制力がなければ続かない。

あわてて補足するが、筆者は自分の設計に自信満々だったわけではないし、同僚のスキルレベルが低いわけでもなかった。筆者としては恥を忍んでモデルを見せることで設計ミスを指摘してほしかったし、なによりも彼らの仕事から学びたかった。親しい職場の仲間を人前で侮辱するつもりなどさらさらなく、彼らの優れたスキルを羨望していてマジでそれを盗みたかった。

◆見せなれていないものを見せるのは誰でも恥ずかしい

けっきょくそれを妨げたのは、國澤氏も指摘しているように「自分の設計を他人に見られるのがイヤ」という抑えがたい感情だったのだと思う。そして、その感情はどこから来ているのかというと、「仕事に対する自信のなさ」などではなく「仕事の出来不出来を他人からとやかく言われる経験の欠如」だと筆者は考える。ただの慣れの問題。

じっさいのところ、システム設計の世界には「周囲から評価・批判されながらスキルを磨く」という工学分野ではあたりまえの育成スタイルが根付いていない。先輩の設計にもとづいてプログラミングを何年か経験したあとに、新人は見よう見まねで設計を始める。その過程で設計の妥当性がまわりからとやかく言われることはほとんどない。とやかく言われるのは「進捗」だけ。そんな育てられ方をした設計者がいきなり「みんなにモデルをさらして評価してもらえ」なんて言われても困ってしまうだろう。

◆「わかりやすく見せるためのツール」と「見せ合う社風」が必要

では、他人から設計の妥当性をとやかく言われることがなかったのはなぜか。単純だ。前回の記事でも説明したように、システム設計の成果が一般に複雑膨大で、第三者にはなかなか了解できないものであったからだ。かつて設計書は手書きだったが、それがワープロソフトや表計算ソフトに移行した後でも、他人にとっての設計のわかりにくさは改善されなかった。それは設計情報の「構造」そのものが複雑だったからだ。

これは、「構造」を管理してくれるようなツールを用いれば、他人であっても仕事の成果を楽に読めるようになるということだ。XEAD(ジード)のような設計情報の専用管理ツールが役に立つ。

しかし、そのようなツールを導入しさえすれば技術者同士のやりとりが自動的に根付く、ということにはならない。開発プロセスの中でモデリングツールを明確に位置づけるいっぽうで、「自分のモデルを見せるは一時の恥。隠すは一生の恥」、「ひとりのモデルはみんなのため。みんなのモデルはひとりのため」といった組織文化を育てていかなければいけない。

そして、システム設計が「図面や文章や知識や考え方がひと様にジロジロ見られる仕事」であることを、新人には伝えておいたほうがいい。そのようなハズカシサを忍んでまで自分をスキルアップしたいと望むキトクな人間(つまり変人)であればこの世界に入って来い、ということだ。

|

« 「実用と鑑賞に堪えるモデル作品」を待望する | トップページ | いつまでもプログラミングを楽しむために »

コメント

はじめまして、よしといいます。
バンコクのIT業界におります。
当方営業しか経験がなく、現在独学で設計の
勉強してますが、渡辺先生の本が一番しっくり
来ており、勝手に尊敬させていただいて
おります。
XEADもまだ使い始めたばかりですが非常に
使いやすいです。ただ英語版がない為、
タイ人のプログラマーとの共有ツールとして
使えないのが残念です。
是非英語化お願いいたします。

当方もブログ始めておりますので
よろしければ覗いて見てください。
では!

投稿: よし | 2005.03.08 20:25

初めてお目にかかります.渡辺様の本を読ませていただいております.配慮の行き届いた,素晴らしい本だと思います.

成果物のレビューをしあうのは,プログラミングでは当たり前のことですが,データモデリングでは普及していない習慣なのですね.作業の重要性を考えると,この習慣が広がることを願ってやみません.

投稿: no-name | 2005.03.08 23:36

よしさん、ありがとうございます。ブログ見ました。ほんと、バンコクの渋滞はハンパじゃないですよね。XEADの多言語対応、なるべく急いでやります。

NO-NAMEさん、ありがとうございます。もっと設計者は露出趣味に走らないといけませんよね。

投稿: わたなべ | 2005.03.09 13:15

>渡辺先生

こんにちは。
XEAD練習中のよしです。

先生の”生産管理システムのためのモデリング”本の
中で、在庫推移監視方式というのに興味を持ちました。
ただBOMの一番下のレベルまで部品展開して
中間品まで含めた製造要求や購買要求が
作られるMRPと違い、在庫推移監視方式の場合
カンバン方式同様に前工程の要求のみが計算されますよね?そうなると監視する方は品目ごとに不足して
いるかどうかをいちいち確認しなければならなくなり、
担当者の負荷が高くなりませんでしょうか?

では!

投稿: よし | 2005.03.14 02:10

よしさん

たしかに多くの品目の中から不足分を人が探し出すのはたいへんですよね。そこで「何をもって在庫推移の異常とみなすか」を指定すればそういう品目を一覧してくれるようなプログラムを用意します。生産管理本の153ページをご覧ください。

投稿: わたなべ | 2005.03.14 08:09

>渡辺先生

失礼しました!見直したら
載ってましたね^^;

ちなみにこの手法を適用する際の
注意点や導入事例ってあるんでしょうか?

投稿: よし | 2005.03.14 15:34

よしさん

あのままではありませんが、過去に似たようなシステムをいくつか作りました。作ってみるとMRPよりずっと実際的だったので、そのコンセプトに制約工程の考え方を組み合わせて発展させたものが「在庫推移監視方式」です。

注意点としては、この方法を銀の弾丸(万能の特効薬)と思わないことです。部品構成や工程特性上の適合性や、全社レベルの取り組む姿勢がないとうまくいきません。設計時からじゅうぶんシミュレーションすることをおすすめします。

銀の弾丸ではないにせよ、「在庫推移監視方式」は生産管理システムを発想するための基本的な素養になるのでじっくり学ぶ意義があります。その過程でMRPや製番管理やカンバン方式の限界も理解できるというオマケつきです。

投稿: わたなべ | 2005.03.14 23:14

よしさん
>ちなみにこの手法を適用する際の
>注意点や導入事例ってあるんでしょうか?

 一番の注意点はお客様がいわゆるパッケージの「機能」に騙されない事だと思います。

 普通のPKGでは「生産計画-指図-実績-在庫」という風に説明されます。でもその通りカットオーバーすると在庫が合わなくなります。部品在庫が合わないMRPって考えただけで願い下げですよね。まず部品表と在庫(実績)だけをカットオーバーして、在庫が合う事を確認してからその前を考えるという思想を理解してもらう必要があります。

 説得する自信がなければ、そこまでわかっているお客様だけを相手にするしかないかも^^;

 それだけパッケージの「機能」だけ見ると良く出来てるって事でもあります。でもまともに使えている会社は私の知る限りほとんど居ないのも実態です。

投稿: HAT | 2005.03.14 23:19

>渡辺先生・HATさん

親切に教えていただきどうもありがとう
ございました。
やっぱり万能特効薬ってないもんなんですね^^;

HATさんのおっしゃること、とても良く分かります。
タイでよくあるのはBOMに抜けがありまくるとか
在庫管理担当者がめんどくさがって入力し
ないので在庫があわず、なかなかMRPの
カットオーバーにたどりつかないという現象です。

投稿: よし | 2005.03.15 02:27

よしさん

>なかなかMRPのカットオーバーにたどりつかない

 お客様の管理レベル次第ですが、普通でもBOMはMRPの6ヶ月以上前に本番した方がいいです。BOMだけ本番しても放置プレイになるだけなので、生産実績を入力してもらい、所要量展開から部品在庫の実績管理を本番にします。在庫調整だけ出来るようにしておけば、多少合わなくても大丈夫ですから、その間にBOMを奇麗にしてもらいます。

 設変(設計変更)管理をどう行うかがSEの腕の見せ所です。頑張って下さい。

投稿: HAT | 2005.03.15 21:03

HATさん

いえてますね。まずBOMを整備するのが一大プロジェクトです。それも、言われているようにBOMを整備すればユーザーがさっそく何かトクしてしまえるような仕掛けが要ります。(ブログ記事とは関係ない話でもりあがっちゃいましたね(^^;)

投稿: わたなべ | 2005.03.16 06:42

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: システム設計は「成果物を他人にジロジロ見られるハズカシイ仕事」:

» 仕事は見せるべし。 [成功する仕事・失敗する仕事]
「設計者の発言」ブログを見て「そーなのよ!」と強くうなづきました。 これまで自分は自分の仕事の成果を人にとやかく言われるのを恐れてはいなかったか。避けては... [続きを読む]

受信: 2005.03.10 20:42

« 「実用と鑑賞に堪えるモデル作品」を待望する | トップページ | いつまでもプログラミングを楽しむために »