ObjectSquare [2001 年 3 月号]

[OOエンジニアの輪!]


OOエンジニアの輪!

〜 第8回 杉浦英樹さんの巻 〜

今回のゲストは、富士ゼロックス株式会社の杉浦英樹さんです。 複写機開発を通じての豊富な経験と知識を惜しげもなく話してくださいました。 内容はこれまでとはかなり違ったものとなっています。 現場サイドの組み込み色がとても強い対談となりました。


尊敬する人明治維新の頃の人々
好きな言葉「測れないものは制御できない」 デマルコ

「社内外の信頼を基盤とし、たゆまざる努力と革新によって、卓越した価値を提供し、人間社会の理解と調和の増進に寄与する」 昔の企業理念

はじめに

--- 本日はよろしくお願いします。

よろしくお願いします。

あまり私はアカデミックなことは言えなくてですね。 現場サイドからの見方でぶっちゃけて言っちゃうほうなので。

--- ええ、どんどんお願いします。簡単に杉浦さんの略歴などをお願いします。

86年に入社しまして、そこからずっと組み込み系、ファームウェアですね。 最初はアセンブラから入ってきているわけです。 8ビットの CPU を使って実際にメカトロ制御、ようはサーボモータとかですね、フィードバック系の制御をやってまして。

複写機なんかもだんだんデジタル化の流れになってきますけれども、その影響を受けて、ステッピングモーターとかそういうオープンループっていう制御の仕方に変わってきて、 そこでも相変わらずずーっとアセンブラで、もうなんでもできるよって(笑)感じですよね。 そういう仕事の仕方をずっとしてきました。

で、いろいろ商品開発をしていく上で、流行の言葉で言うとアーキテクチャみたいなものだけでなく、いろいろマネージャ系ですとか、画像処理系とか少しずつ機能を拡張していって。

--- 実際の製品ですか

そうですね。マネージャ系の機能を入れた時から16ビットに変えたんですね。CPU。

--- 最初は8ビットなんですね

1チップで作ってるから、中のペリフェラルな機能を、もうフルでほとんど使いきるわけですよ。 そういう開発の仕方をしてきまして。

で、16ビットにしても中を結構使っててですね、ぎちぎちに作っていく。 で、さらに画像処理とか入れて今に至っている感じなんですけど。

--- お仕事で関わった製品などはコピーですか

コピーですね。最初はライトレンズっていう昔のタイプのアナログ複写機っていうやつをやってまして、 そこからデジタル化、カラー化っていう方向性がありまして、ずーっとカラーまで仕事してきてますね。

--- 今はカラー複写機ということで

そうですね。基本的に複写機関係です。ずーっとですね。

--- 長いですね

浸かりきってますね(笑)

--- これからもずーっと複写機ですか(笑)

これからも、続く限りはずーっとやっていくんでしょうね。 ただまぁ、時代と共にやっぱりやってる人たちが変わってきてますから、そのあたりをどうハンドリングしていくかっていう部分で、見方が変わってきてますね。

今、現場でプログラミングはやってません。 品質をちゃんと獲得して、品質獲得のための仕掛けをきちっと作って、それに沿った形できちっと運営していくっていうようなことやってます。 実装してデバックしてっていう最下流は直接はやってないです。

--- じゃ、もう、基本的な、どうあるべきかみたいなところから発生する必然的なアーキテクチャはこうだよ、ってところには関わってると

むちゃくちゃ口出ししますね。

--- それ以降は基本的には関わらない。

そうですね。 ただ、プロセスの構成から言うと、それが後ろに引きずっていきますので。検査の段階とかですね。 だから、前と後ろをちゃんと押さえてなるべく深くいきたいんですけども、あんまり深く行っちゃうと時間がないので、

--- ちなみに、複写機の開発って何人くらいのものですか

全部でですか。全部で結構いますね。100人とかいますね。

--- 100人くらいですか。ソフト屋さんとハード屋さんはどれくらいの割合ですか。

デジタル化してるので、最近は、ソフト屋さんの方が多くなってきてますね。


組み込みの事情

--- 組み込み機器って言われるところですけど、他の分野の例えば PC アプリとかビジネス系のアプリなんかとここが違うよってところはありますか。

メーカーとしての制約ですね。 QCDS(Quality, Cost, Delivery, Security) を守らないといけないですとか、コンパクトに作らないといけないですとか、そこらへんの制約が非常に大きいわけですよ。

後は、すべて最適化っていうところですか。最初から最適化されていないと入らないわけで。 そこらへんがシビアなんじゃないですか。

--- 組み込みのエンジニアってみなさんドメインについてはすごい詳しいですよね。

ええ、でも最近はそうでもなくなってきてますよ。 アーキテクチャがレイヤーを分けてしまってるじゃないですか。 あれが弊害もいっぱい持っててですね。

OS やってる人はそのシステム詳しいですよね。 ハードウェア自体を。後、ドライバやってる人もとっても詳しくて。 その上に例えばミドルウェアありますよね。 さらにその上にアプリケーションがやんなきゃいけないところがあって。 ちゃんと分かれすぎちゃってるもんだから、アプリケーション屋さんが、ハードウェア解らないんですね。 そうすると、起こった現象に対してハードとソフトの切り分けができなくなっちゃうんですよ。 すると、商品がちゃんと出ないってことになっちゃう。 だから、良し悪しっていうのがやっぱりあって、とっても問題なところですね。

パソコンなんかのプログラマの人も、たぶんドライバ系とかはあんまり強くないですよね。

--- そうですね。組み込みの開発部隊でもハードを知らない人が出始めてる。

出始めてます。

--- 結構ショックですね。

ショックですね。

--- オブジェクトって一方ではなるべく局所化、局所化って進めていくんですけど

やっぱり、コンパクトに作るってことと、局所化するってことを取り違えちゃいけないってところがあって、結構そこらへんが勘違いされちゃう。

オブジェクト指向で組み込みでやりましょうって言うと、ある程度パフォーマンスが落ちるって言うのは承認されますけれど、 だからといって、無駄なインターフェース、例えば、2つのオブジェクト間でやりとりするのに、どうしてオブザーバーパターンが必要なのとかね、 そういうところの議論がされないまま動かそうとしちゃうんですよね。

いろいろコンサルティングされてきてますから、その辺はどうですか。

--- 難しいところですね、すごく。メンバーの方のモチベーションなどがみんな違ってたりしますので、こうゆうアプローチがいいときと、こうゆうアプローチがいいときと。その辺が難しいところですよね。

最近は不具合の原因のトップじゃないですかね。ソフトがうまく作り込めないっていうのが。

--- そうでしょうね。

で、結果として市場で不具合が発見されると、ダウンロードとかをやりますよね。 弊社の場合はサービスエンジニアが頑張っていますので、まだいいんですが。

--- ソフトを変えられるんですね。

ある程度は(笑)許されるんですけども。 サービスネットワークができてない企業なんかでしたら、回収になるわけですよね。

--- それはでかいですよね。

でかいですよ。

--- 私、昔作ったやつでバグが出て、フィールドから在庫の箱を会社で回収して、庶務の女の人なんかでハンダをはずして ROM をはずして焼いて入れてってラインを組んだことありますね。

そうですか。それはいい経験でしたね(笑)

--- 最悪だーって(笑)

最悪ですよね(笑)。あれはほんとに最悪ですよね。

--- ある程度許されるのはうらやましいですよ。

ええ。ただ、サービスマンも1時間いくらってコストがかかりますからね。 それで勘定されちゃうと、1回トラブルだすといくらだろうっていうのが見えてきちゃいますから、厳しいものありますね。

少し話が飛びますけど、傾向としてフォールトトレーランスとか、 その辺りが昔に比べて今はちょっと弱くなってきてるなーっていうのがありますね。 複写機もソフトがちゃんと制御できていないと危険な部品が結構あって、結構組み込み制御の怖いところを持ってるものですから、 組み込み屋さんっていうのはそういう見方が必要だと思いますよね。

--- そこは、大前提ですよね。

アメリカの方で昔、ワークステーションなんかやってたんですけども、 あそこらへんの評価の仕方っていうのは、ダウン率とか統計的なやり方をするわけですよね。 だけど組み込みはそうはいかないわけです。ダウンしたらもしかしたら火がでるかもしれない。 そういう厳しさもありますね。

でも、組み込みは面白いですよね。

--- そうですね。

あの、動く感動がね。機械が。

--- 最近、オージスではそういうところ見てないんですよね。メーカーにいたほうがそういうところは、なまなましいですよね。

苦労して、苦労してね。みんなでやって汗かいて、結果出せて、コピーショップなんかで使われてるってのを見るとね。ほんとに(笑)

--- いいですよねー。チームの感じがあるじゃないですか、開発しているっていう。私はあれ、結構好きなんですよ。

そうですね。おしりに火が付いた状態が一番いいですね(笑)。 みんなで必死にやってて、テンションが高くて。そういうとき、風邪とかひかないですよ(笑)

--- テンションの高さが半端じゃないんですよね(笑)

半端じゃないですね。

--- カツーンっていっちゃってて。

なんか、とげとげしい言葉を使ってたりするんですけどね。でも、商品が出ちゃうと分かち合えるのでね。 あー、よかったーって。そこが、組み込みってはっきりしてるので。アプリケーション屋さんもそうなんですかね。

--- どうなんでしょうね。そんなに強くチームって感じでもないですね。見てると、今はドライな感じですよ。開発も、開発してる部隊も。

アメリカちっくなんですかね。

--- そうかもしれないですよね。コンサルティング部門とかって、ほんとに隣で何やってるのか解らないような感じですからね。たまに懐かしくなりますね。あのぐわーっていう感じが。ずーっと続けて行かれるんですか。

どうなんでしょう。体力がねー(笑)、結構必要ですからね。体力勝負ですね。

--- ちょっと話が変わりますが、今 Java ってすごいじゃないですか。やられてますか

部署的にはやり始めようとしてるところもあるんですけど、やっぱりパフォーマンスとメモリの問題とかですね、そこがネックになってると思いますね。

--- Java チップのようなものに載るのかもしれないですけど、Java でファームを書く時代がくると思いますか

なかなか想像できないですよね。

--- ええ、できないですよね。

チップとかの作り方が限界にきてるところがあるんでね。ワンチップでどこまでできるかって。 どこまでいけるか、どこまで安く作れるかって辺りが絡んできてるんじゃないかなと思いますね。 そこの次の解決策が見えてくると Java チップっていうのは作りやすくなってくる。 インタプリタ系でメカトロ制御するなんてのは、昔は想像もつかないですよね。 でもかなわないことではないと思います。ただ、時間はもうちょっとかかるような気がしますけどね。

--- うちで受けてるオブジェクトの案件なども、組み込みを除くとほとんど Java ですよ。C++ はもう壊滅状態です。

C++ は難しいからですかね。やっぱり。

--- そうですね。あれだけ簡単にオブジェクトぼこぼこ作れたらいいですよね。私、MS の .NET のセミナーに行ったんですけど。彼らももう、C++ は進めてないですよ。

あ、そうですか。

--- ええ、C# か VB ですね。C# 使えって、C++ は難しいって言ってますね。

そういう状況をお聞きすると、やっぱり Java いくのかなって気がしてきますね。

--- うちでは他の非組み込みの話をよく聞くんですけど、そうするとビジネス系は完全に Java ですね。

昔のアセンブラみたいになってきちゃったのかな。


オブジェクトのきっかけ

--- オブジェクト指向をやりはじめたきっかけっていうのはなんですか。

もともとは忙殺ですよね。ほとんど死ぬんじゃないかってぐらい忙しい状況で。 メカとかハードの部分は共通なんですね。ところが、ソフトは変わってくる。 一人で何プロダクトもやってないといけない状況がありまして、この調子でやってたら死ぬなと。

で、どうにかしなきゃって思いついたように考え出したのが、ちゃんと工学的手法みたいなものを自分の身に付けて、 間違いなく良くなる方向に進んで行きたいという、そこがスタートポイントですね。 だから、最初にやったのは構造化分析なんですね。

--- とりあえず、アドホックにいかずにちゃんとやろうってことですね。で、今あるのは構造化ってことで

そこから分析が始まったわけですね。いわゆる機能分割系です。あれが結構ヘビーでですね、くるんです。 くる割りには後段の設計とのつなぎがあまりよくないと(笑)。

その当時、同じようなものをいくつか作ってたので、再利用についてもいけるんじゃないかって踏んでたんですが、ところがどっこいで。 仕様変更って機能にかかってくる場合があって、それをやられると再利用ができなくなっちゃうんですね。 すると余計な構造図みたいなのがバンバン起こってきちゃって、結局ぜんぜん再利用になってないなっていうところが見えてきちゃいまして。 かつ接続性の悪さから定着しないんですよね。現場のエンジニアがなかなかやろうとしない。 ということもあって、あーこりゃいかんなって思ってたわけですね。

--- それはどれくらいやられてたんですか

だいたい、4年間くらいはそうゆうことやってましたね。

--- 結構やられてましたね。

やってましたねー。結構突っ込んでそこはやってましたね。

--- そのころって、周りでやってる方ってそんなにいらっしゃらなかったんじゃないですか

そうですね。周りは普通の、いわば場当たり的な作り方ですね。 ある程度経験者がソフトの構造なんかを考えて進めていくやり方でしたね。で、人海戦術が中心ですよね。

構造化の活動を継続的にやってきてる中で、オブジェクト指向っていう言葉がどんどん聞こえてくるわけですよ。 で、ちょっと突っ込むんですが、ところがですね、もうたくさんやり方があるわけですよ。 アメリカの方の情報見ていろいろ探りまわっても、ぜんぜん落ち着き所が解らないっていう。

--- 収束してない状況ですね。それって、OMT や Booch や Shlaer-Mellor っていう。

ええ。

--- 本位田さんが比較して日経から1冊出されましたよね。あの辺りですか。

その前ですね。 なので、調査も手間取ったりしてたんですが、これはちょっと収束傾向にない、まだ発散するんじゃないかっていう。 いろんな流派が、亜流が出てきちゃって、どうにも解んなくなっちゃうんじゃないかっていうことで、あきらめてたんですね。

そこから何年か経ってきたときに1つきっかけが見えてきてですね、統合化の動きがありまして。 その時にたまたま、福富さん(OOエンジニアの輪の次回のバトンを受けてくれた方です)がこうゆうやり方があるぞって、彼は彼で見つけ出してですね。 ちょっと実験をしてみたということで持ってきてくれたんですね。お、そうかっていうことで、そこが最初ですね。 本格的にやり始めたきっかけっていうのは。

--- それって、今からどれくらい前になりますか?

そうですね。5,6年前ですね。 そのときは、彼は画像処理のところをやってましたので、いわゆる、普通の構造化言語、C で作ったようなところを置き換えてきたわけですね。 モデル化して置き換えて。 こういうモデルで、こういう風に動かしたら動くじゃないですかってことを実機に突っ込んで、動きますっていうやり方をしてきたわけですね。

私の方は私の方で、仕事の量が増えてきて、今のやり方では構造化分析も定着できない。 ぜんぜん改善されてなくてですね、相変わらず、 夜遅くまでやってぎりぎりでものを作っていくって状況がなにも改善されてなくて、いいかげん腹が立ってきたところで。 よし、じゃいっしょにやりましょうってことでモデリングをしてくっつけて、ってそこから始まったんですけども。

われわれはそれをパイロットプロジェクトって呼んでるんです。 だから、その時は、従来の方法と並行で走らせてましたよね。 流用しながら一応安パイは確保しておこうと。

--- 一応、保険掛けとこうと。だいたいそのパターンじゃないですか。怖くてやれないですよね。

ええ。 やっぱり自分自身、パラダイムシフトに時間が掛かってましたので、半分は信じてなかったんですね。半分は信じてたんですけども。

それで、そこから、本当にボトムアップの活動で、役員の前でレビューしてですね。 こういう風にやって自分たちで課題を設定して、達成していることを評価した結果、わかりました、こっちでいかせてくださいと。 その結果、予算も付けてもらって、本気で立ち上げようじゃないか、商品にしていこうじゃないかってことで、動き始めましたね。

--- 並行でやったってところは最後まで同じ機能を入れ込んだんですか

いえ、やらなかったですね。

--- あ、じゃあ特定の部分だけで、そこでパフォーマンスを見てとりあえず問題ないなってことで

ええ。

--- 私なんかも、始めオブジェクトやったときは同じような感じでしたね。やっぱり、今までやってたやつをとりあえず作ってしまって、保険を作っといてから同じ内容をオブジェクトでやってみましょうって感じですね。結構、組み込みをオブジェクトでやろうって方が、どこからアプローチしたらいいのかって話を聞くんですね。やっぱりすぐに製品に入れていくとメーカーなのでちょっと心配だよってことで、パイロットプロジェクト、同じやつと並行してやるっていうのはいいやり方ですね。

そうですね。それでね、ちょっと悔いは残ってるんですけどね。 最後までっていうか、ある程度同じ機能を作ってるので、きちっと両方ともまとめて比較してやればよかったんですけども、 その時間がちょっと取れなくてですね、結局、今もまとまってないですね、そこの部分は。 その辺はちょっと悔いが残ってるんですけど。

--- それがあると、他の人に説得力がありますね。

ええ。ありますね。 一所懸命勉強し始めて、だいたい2年くらいは解んなかったですよね。 何がいいんだ、どうしてだと、それがどうしたんだと。こうやったほうがいいだろって案を、また、経験的に持ってましたから。 それに対してオブジェクト指向が与えてくれる本当の良さ、そういうのが解んなかったですよね。 2年くらいは。

--- やりながらですか

やりながらでもわからない。で、3年くらい経ってくるといいかげん見えてくるんですよね。

--- 最初にオブジェクトをやられたときの使われた手順は何でやられたんですか。

最初はですね、InArcadia さんにきていただいてですね、 助けてもらいながらやったんですけども、ユースケース駆動のやり方で、モデリングが OMT ですね。

--- OOSE プラス OMT という感じですか

そうですね。やっぱり、プロセスがうまくできてなかったんですよね。最初は。 プロセス定義がちゃんとできたのは、その商品を出す直前くらいですかね。 なんとかプロセス定義をアクティビティ図で描いて、成果物とプロセスを明確にして押さえどころはどこだっていう分析をしてやって、 工程毎のレビューをしながら進めるっていうアプローチを作ったんですよね。 それはそれなりに問題はあるところはあるんですけども、レビューの工数の掛かり方ですとか、 その辺りはもっと工夫しなければいけないところはあるんですが、品質としては押さえられるようになったので。

--- UML の前ですよね。OOSE って辺りが、結構珍しいかなと感じますね。

珍しいですよね。ユースケースって、とっつき易いけど使いにくいんですよね。 いろいろ想像しちゃうんですよ。悪い方向に想像が膨らむんですけど、要はきっちり捉えてしまう、 もう決め付けてしまうと、実はそこにノウハウが入れ込めたり、 設計とか実装の段階で起こった問題のよりどころになったりするんですね。

--- 一番最初にユースケースを見たときに、あまりにも要求がアドホック過ぎるっていうか、出し方とか、あれですべての要求が押さえられるっていう確証が得られないじゃないですか、構造的じゃないっていうんですかね、そこにすごくいけるんだろうかっていう疑いがあったんですけど、どうでしたか。

ユースケースは構造化分析系だなって思うんですよ。

--- そこはやられてたんですよね。

やってましたね。徹底的にやってましたから、だから、これは簡単に機能系でいけばいいなと。 ただし、オブジェクトは違うよってところが大事で、そのまま、オブジェクト作られちゃうと困るんです。 やっちゃうんですけどね。それをやらないように注意して。 オブジェクトっていうのは解るような書き方をしないと、直感的に解りづらいモデルになっちゃいますので、 オブジェクト図、クラス図、そこら辺の関係付け方が難しいところですね。

ただ、一回出来上がってしまうと割り切れるんでね。 プロトタイプっていうモデルが出来上がってしまえば。 そうするとどういう関係なのかっていうのは結構ロジカルにつながってくるんですよ。 で、要件が上に向かって抜け漏れがないかっていうと、おっしゃる通りでちょっと心配なところはありますね。

--- OOSE に最初に行くっていうのは、初めて聞きましたね。結構新鮮でした。もう、翻訳が出てたときですか

そうですね。ちょうど出た後ですね。最初は、分析は結構苦労しましたね。

--- 苦労しますよね。

やっぱりね、どういう風に元のものが設計されてるとか解っちゃってるから。 どういう風な設計思想があるかってことが。そうするとユースケース書くと細かくなっちゃうんです。 200個も300個も最初から出ちゃうんですね。

--- なりますね。

それは、分析のユースケースじゃないわけですよね。

--- 今やってるもの、今やってることになっちゃいますね。

そうすると、上流下流の一貫性から外れてしまって、じゃそれの元はなんなのって、解んないんですよね。

--- それは結構よくありますよね。ユースケース書いていただくと、結局今のソースリバースそのままになってしまって(笑)

そうですよね(笑)

--- 巨大なドキュメントができてしまって、なんでここでこれをやってるのかっていうのが誰も説明できないっていう、変な要求仕様ができてしまって(笑)

そこが困るところですよね。ユースケースの落とし穴ですよね。

--- 最初に取り組んだときの結果としては結構いいものが得られたんですか

いろいろなものの見方があって、オブジェクト指向的に言うとぜんぜんいいものではなかったですね。 だから、まず、ステップ1として、ビジュアルモデリングができた、というところが最初ですね。 それ以上を望むとたぶん、破綻してたと思うんですよね。

--- そう、そうなんですよ。

そこらへんは割り切ってですね、物事はやっぱり階段を上っていかないといけないっていう考え方ですよね。 欲張りすぎると絶対に失敗しますから。

--- そうですね。まず、ソースベースからモデルベースに移れたってところで得られるものがありますからね。

ありますね。大きいですね。 他の部署でも展開があってですね。面白いですよ。 最初ソフトの作り方の話なんてぜんぜんしてないでカタカタやってた連中がですね、モデル図を照らして、これはこうじゃないか、いやこうじゃないかって議論できるようになる。 興味がそっちに向くっていうのが、どう作るべきなのかっていうことをちょっとでも考えさせてくれる。 そこがいいところだと思いますね。

--- いきなり再利用ですとか、保守性が上がるですとか一気にいけないですよね。

おっしゃる通りですよ。

--- とりあえずの向かう方向とか、やり方は示せるんですけど、そのできた成果に対してがっちりいけよと言われるとわれわれも結構つらいものがあって

いやー、きついと思いますよ。

--- それを踏み台にしていっていただければ、一番幸いなんですけどもね。われわれもお客様のところでコンサルやってると、一ヶ月くらいすると四角とか点線とかを引いてアーキテクチャがどうだこうだという話ができるようになるんですね。その瞬間とかが結構、ステージが1個上がったなって感じますよね。

そうですよね。自分で言うのもなんですけど、結構慎重なんですかね。 革新したいんですけど、革命的に動きたいんですけど、結構慎重なのかな。

--- 最初は、モデルベースでちゃんと作れば解り易くいけるんだよってところですね。

そうですね。


オブジェクトのいいところ

--- その後、何回かオブジェクトでやられたんですよね

そうですね、ずーっとやってますね。

--- その辺も通して、オブジェクトのいいところっていうのはどの辺ですか

なかなか難しいですけどね。モデルとして出てきて、議論ができるっていう辺りがとってもいいところで。 それから、プロセスをまとめたので、品質の押さえどころが解ってきたってところですね。 今までの作り方でやってきたことに対して、やっぱり、品質が取れるですとか、見積もりがしやすいですとか、 工程全体を通して再利用ができるようになってくるってところが少し見えてきてますので、そこはいいところですね。 少なくとも Q と D は向上してると。なりよりも、私はマネージャみたいな立場なんですけども、私が解るわけですよ。

--- 管理する側としてってことですか

実際に、どういうモデルを作ってきて、それはどういうバックボーンがあるからこうなってきてるなっていうのが透けて見えてくるんですね。 人が入れ替わり立ち替わりしたとしても、やろうとしていることが必ず見えてくる。モデルを通じて。 管理する側としては、なんでそんな事したの、変えたのかと、チェックが掛けやすいです。

--- それは、やっぱり、今までだとそういうモデルがなかったということですか

なかったですね。

--- 構造化のモデルではやっぱりだめだったよってことですか

だめですね。 ようは直感的に、構造図で見て取れるものとクラス図で見て取れるものの質が違いますよね。 そこが大きいと思いますね。

--- そうですね。それはやっぱり、モデルを書くってところに集約されるんですかね。モデルによって、その人の意図が見えることが、最終的に大きいと

つながってくると思いますね。 あと、モデルが見えてこないと、そのモデルに対して経験者が自分の経験を付加することができないんですよ。 だから、経験を付加するためのモデルとしての役割も持ってますよね。 今までだと構造図を見ても、そこから、いやここはこういう構造にしたほうがいいよって言えないですよね。

--- 構造図って書いた瞬間にソリューションになっちゃいますからね。

ソリューションになっちゃってますよね。

--- オブジェクトはソリューションの基ですからね。登場人物ですからね。そこが違いますよね。

違いますね。そこら辺だと思いますよね。 とにかく書いてしまって、そこに対してみんなで議論しながら進めてやっていけばみんなもどんどん成長していきますから、いろんなことが解ってくると。 結果として、こういう風にシンプルに持っていったほうが、よく使い回しするときにいいだろうっていうところに落ち着けるっていう流れがあって、そういう流れを作るためにもクラス図なんでしょうね。 まあ、静的なことしか見えないじゃないかって言われたりしますけど。

--- それが結構大事なところですね。

あんまり、アカデミックな皆さんが考えているような、パターンがどうしたとかって部分は、どっちかって言うとどうでもいいところなんですよね。

--- よく言われるのは、2つあって、アーキテクチャを解りやすくしたいっていう方向と、再利用性、保守性、拡張性上げたいよってところと。再利用性とか保守性ってところはどうですか

そうですね。ぶっちゃけてしまえば、ほんとのおいしいところ、 差分継承で書けばいいでしょってところで、なんでっていう仕事をみんなしてくれちゃってるわけですね。 だから、それを気づかせないといけないので言うんですけど、結局は今あるものに対してメンテナンスするってことは、 今あるものの、検査工程まで含めた品質も再利用しないといけないですよね。 それをいじってしまうってことは、そこでもう検査をすべてやらないといけないってことで、重たくなるんですね。 とにかく骨までしゃぶっちゃう。 差分継承でできるんだったらどんなつまらないことでも差分継承でやるっていうことを言ってますね。 今のところ。で、現実にそれが少しずつはできてきてますね。

差分で作ったところは差分の網羅テストだけしてやれば上のインターフェーステストはしなくても動くわけだから、そのまま出せばいいでしょっていう説明を具体的に始めてますね。 余計なテストはもうわれわれはしない。 商品として出すときはもちろん会社のシステムがあって、そちらでテストしてもらいますけれども。

--- その辺が、最近は有効になってきたっていうか、形になってきたっていうか

そうですね。はい。それでもいじりたがりますけどね。

--- そこって、結構永遠の課題ですよね。アーキテクチャが終結することってないですね(笑)

ないですね(笑)。すぐに入れたがりますね。

--- 時間があると、いじりたくなりますね

なります。

--- 工業製品っていうのは、どっかでそれを止めるのも必要ですよね。

それをいじる暇があったら、他の非オブジェクト部分をオブジェクト化するとかですね、そういう方向に人をうまいこと回していかないといけないですね。

--- 職人としてはとことんまで追求したいんですよね(笑)。それをどこかで止めないといけないですよね。品質のために

難しいところですね。

--- 工程全体に対するインパクトを考えて、ここで止めなきゃいけないってところがありますよね。

ほっとくと、インターフェーステストとかですね、サブシステムのテストですとか、 下をいじったところに関連するところ全部抽出し始めちゃうわけですよね。 もう一回やるって言うんですよ。 それじゃ意味がないわけでね、効率上がらないですよ。 せっかくオブジェクト指向でやってるのに。 そこをきちっと割り切れるかってあたりがね。

--- 最近はやりのリファクタリングの話と微妙に食い違うところですよね。

食い違いますよね。実はね、リファクタリングをしたんですよ。 一発でっかいのをしたんですけど。もうだめですね。工数が掛かる掛かる。 最初に作るのと同じ位掛かるわけですよ。

--- それは規模が大きいからじゃないですか

それもありますね。 ただ、いじらないでやってる使いまわしをしてるものと、リファクタリングをしたものと2種類あるんですけど、 リファクタリングしたほうが、5倍くらいかかってますね、工数が。すると、もう勧められないですね。 リファクタリングなんて流行の言葉ですけど、アカデミックにやってくださいという感じですね。 われわれはやりませんと。なぜなら、こんなに投資が必要だからです。

--- 多分ね、XP とかあーいうのは、できる人がやるんですよね。

そう、おっしゃる通りですよ。 あるレベルから上の人たちはね、いくらでも好きにやれっていう話なんですよ。 そこから下の人たちはガラス細工いじるようなところがあってね、解らないでいじったりしますからね。 その人たちがほとんどのソフト作ってますから、彼らが楽できるようなやり方を考えないといけないですね。

--- 組み込み業界で仕事をしてると、ソフトウェアエンジニアの人が自分がプロのソフトウェア屋だっていう意識が、多少薄いと感じるところがありますね。もの作りはしてるけど、ソフト的に本当に好きじゃないんだよって方とかもそこそこいらっしゃるので。やっぱり、少数のすごいできる人と、普通の人の集まりっていうのがメーカーさんなのかなって感じがあるので、そういうところに、XP とか最新の技術をいきなり持ってっても絶対うまくいかないよっていうのは私も持っていて

いかないですよ。ええ。ただ、XP の中のペアでやりましょうっていうのがありますよね。 あれはこの間ちょっと試したんですよ。 片一方は手法に通じているやつ、片一方は使いこなすにはもう1歩というやつでペアにして、いっしょにやれ、 二人の責任だって言ってやらしたんですけども、多分、効果があったんじゃないかなと思います。

--- 割りと OJT の世界になっちゃいますね。

そうですね。

--- それって、よくデバッグの時にやりませんでした?私はよくデバッグをペアでやっていて、一人が煮詰まったときにもう一人がブレイクスルーを与えてくれる

いいですね。

--- ええ、あれに似てるのかなって思ってますね。デバッグの時にはまりますからね。

ええ、視野が狭くなりますからね。横からツンって言われただけで、あっ、ここだって。


オブジェクトの苦労

--- オブジェクト指向でうまくいかなかったところとか、苦労されたところってありますか。

そうですね。 モジュールのパッケージを分けて作ったときにですね、パッケージ間のやりとりを持ちつつ、 時間制約があるときの対処が思ったほどうまくいかないっていう場面がありましたね。 未だにそれは引きずってまして、前のプロダクトでもそうだったのにまたかよっていうような部分が残っちゃうんですよね。 モデルをそのまま継承して作っていっちゃうもんですから、問題は問題としてそのまま残ってくるわけですけど(笑)、 そういうところがすっきりしないですね。

そこだけ、そこを最優先にしてモデルを書いたら、それはすっといくと思うんですけど、そうじゃないわけですよね。 なんていったらいいか、ビューが違うんですよね。 こっちからみたらこういうモデリングでああいいですね、ってなるんですけど、そっちからみると、 みんな透かして見ないと向こうが見れないっていうことなんですね。 だから、こっちから見たときにやっぱりうまくいかない。 だから、特別な関連が増えちゃったりっていうことが起こっちゃう。 ただ、こっちから見たときは整然としてる。

--- 表と裏があるんですね。表に合わせて作ったけど、裏にもやっぱりちゃんと守らないといけない制約がある。そこは今はどうやって対処されてますか

そこは、やっぱり特別な状態になっちゃってますね。

--- そこだけ特別区みたいな感じで

ええ。まあ、しょうがないだろうと思ってるんですけどね。 そういう場合はしょうがないからモデルを崩そうという風にみんなで決めてやってるんでね。

--- 私はそれ賛成ですけどね。

ただ、もうちょっと解があってもいいかなって思いますね。

--- 全員が少し役割がボケちゃっても8割ぐらいはしっかりしてればいいですよね。

ええ、こっちから見たらしっかりなってればそれでいいですよね。

--- 必ず言われるのが効率の話とリソースの話なんですけど、そこらへんはやられててどうですか

そうですね、自分がやってないとこの問題なんかも入ってくるんですけど、やっぱり、 virtual で思いもしない静的なメモリ容量が取られちゃってるとかですね、そういうことはしばしばですね。 それをなくしちゃうと本当のいいところが使えなくなっちゃうので、まったく意味がなくなりますからそれはしょうがないと思ってます。 ですけど、例えば new とかですね、動的な生成してコントロールするなんてのは、基本的に禁止してます。 静的にちゃんと確保された状態をまず作ってやって、コンストラクタは頭に集中して、みんな知った状態にしてやって、それでやると。

--- オブジェクトのプーリングもやられてないですか

やってないですね。

--- 単純に興味の話で申し訳ないんですが、コピーって、バッファみたいに動的なアロケーションって多発するような気がするんですが。

オブジェクト指向でやろうとすると、そうやったほうが考えやすいと思います。 ですけど、メモリの制約ですとか、リンクしたときに固まっちゃいますから、その状況を作ってしまうと火事になるわけですよ。 それは作れないっていうのが現在の状況です。 ちゃんとだから、メモリをコントロールする人が余裕を持ってコントロールできるだけのパワーを持つ CPU を使って GC なんかの機構を持って、 例えば紙が流れたら紙をオブジェクトとして new してやって、その属性の変化でもってトラッキングして行きましょうなんていうシステムを作ると、 すーごく楽にできるとは思いますね。

--- 私がこの前やったやつなんかは、new やりましたね

僕のところじゃないところではやってます。 ただ、あれをやるのも、例えばイベントを受けるためのインスタンスが先に消えてたとかですね、 そういうつまらない問題をいっぱい起こしてくれるので、

--- 賢いデータくらいにして使ってますけどもね。プールはちゃんと管理して

それだと、ぜんぜん問題ないですね。 ただ、メモリを管理するだけのオブジェクトが余計に必要になっちゃうわけですよね。 そこは、組み込みとしてはつらいところです。

--- 効率とかはどうですか、チューニングですとか

効率もいろいろとあると思いますが。 うちの組み込み系の開発チームは伝統的にコンパイラの最適化をなかなかしたがらなかったんですよ。 ようはデバッグしてるときと同じオブジェクトじゃないと信用できないだろうっていう話がありまして、そこは乗り越えましたね。 今は最適化かけます。 あるものはメモリサイズで最適化するし、あるものは実行効率で最適化するし、結構コンパイラを信用し始めてますね。最近。

--- オブジェクトで作って ROM に入らなかったとかって話ありません?

(笑)別の所で問題が起こりましてですね、調べましたね。

--- 大きくなったらなるだけ機能を入れたがるので、追いかけっこみたいになりますね。

そうですね。なりますね。 その割に、オブジェクトサイズをちゃんと管理できてないとか、まぬけな所があったりしますよね。

--- サイズって、最初のイテレーションで作った分に対して計って見通しを取るみたいな形ですか

そうですね。 ただ、最初にオブジェクト指向でやるってなってしまった場合は、やっぱりわからないじゃないですか。 見積もりようもないわけで。フィードバックかけて行くしかないのでね。 そういう意味では綱渡りってところがありますね。 メモリも、このランクの上はこのランクだよって、とたんに値段も上がりますから、そういう意味では少し怖いですね。

--- 自動車屋さんとかだと、結局なんか全部1チップにしないと、ノイズとかの問題でだめだとかあるんですが、すごい厳しいですね。

そうですね。


プロセスは3種の神器で

--- 分析ってされてますか?ドメインがいっしょだとその辺どうなのかなって私は思うんですけど

ユースケースの切り出し方をすごく柔軟に考えてるんですよ。 例えば、トラブルとか起こるじゃないですか。 そのトラブルに着目したユースケースのシナリオを書いちゃうとかですね。 そうすると、本来どういう風に設計してるのかなっていうトレースになるわけですよ。 それにあわせてクラス図持ってきて、シーケンスダイアグラムを書いちゃうんですよ。 すると、あっ、って。

--- ユースケースの中のエラーシナリオっていうわけではなくてですか

違います。トラブルが基本系列です。トラブルが起こる状況ですね。 各モジュールごとに責務割り当てがあって、そこの責務割り当てであなたは何をやるはずですねって、1個ずつ確認していきますね。 シナリオごとに。 そうすると、この人がなんか変なことしてるなって、結構見えてきたりするところがあるんですよ。 だから、もう柔軟に柔軟に、ユースケースに対してはなるべく柔軟に考えて、特例的なユースケースもちゃんと残して置いとく。 こうゆうところで、こういう問題が起こったことがあると。

--- それって、ユースケースって形で切り出せるものですか

無理やりですけどね。ええ。切り出してしまっていいと思いますよ。

--- その辺が杉浦さんが言われてる、プロセスに入ってきてるんですか

そうですね。

--- プロセスについて簡単に説明していただけますか

教わってきたことを実践してきてやっぱりそうだってところと、補強したほうがいいねっていうところを考えながら、自分で作ってきたわけなんですけど。

3種の神器って呼んでるんですけど、要求を司るユースケースと、静的な構造を示してるクラス図と、後は動的なもの1つですね。 で、今のところその1つはシーケンスダイアグラムってことにしてるんですけども。 その3つでもってですね、相互に補完にするような形で。工程的には、分析にまずその3つが出てくる。 設計に3つが出てくる。 設計は実装を配慮してますから、そこからずっと詳細化していけば、コードまでいっちゃうって状況になります。

分析の段階では、要求元が言ってきてる事が、代替系列も含めてあんた何言ってるのってところを、3つのモデルを使って補完しながら検証して行くわけですよ。 矛盾があったり、おかしいんじゃないのってことがあったら突っ返す。要求元に。 このときにこういう矛盾が起こるけど、それはどうゆう風にしましょうかって逆提案をしたり、決めさせたりっていうのが分析のステージとしてやってますね。 分析のクラス図なんかは、もう教科書なんかでよく載ってますけど、キーパターンを出すためのものであって、 このドメインの本質は何だってところが見えるようになればいいと思ってます。

そこから、設計の段階にすぐつなげたくなっちゃうんですけど、それはやっぱり役割分担をどうするかってところがあって。 出てきたキーパターン、それごとにモジュール分割するべきなのか、それともどうするべきなのかってことをやらないといけませんので、 そのモジュール単位で結局役割が分かれてきますから、そこに対して上のユースケースの結果がどうマッピングされるか、 そこで、再度ユースケースで押さえる。

そのユースケースと上のユースケースの関係っていうのは、きっちり作らないといけない。 で、責務範囲の中でクラス図ができてくれば、われわれはこのユースケースに従ってこういう仕事をすればいいんだねってことでまた、 3種の神器の検証システムが入れ子で一つできてくる。

--- どんどんネストしていくような感じですね

ということです。 僕がやってるようなサブシステムだと、2段くらいでだいたい実装まで結びつけられますので、それで、テストまでいっちゃいます。 厳密に状態とかを考えないといけないところ、あと、抜け漏れを防止しなきゃいけないときには、やっぱりステートチャートがでてくるんですけど。

オブジェクトとかクラスごとのステートチャートって言われるんですけど、あんまり賛成じゃないですね。 パッケージとしてとか、システム全体としてどういう状態があるのっていうのを探っておかないと、抜け漏れの防止にはあまり役に立たないので。 そういうステートチャートを準備しておいて、ユースケースの抜け漏れとか、結局シナリオの抜け漏れですけど、 そこをちゃんとチェックしていけばちゃんと作り込むことができる、というのが概要ですね。

--- われわれもステートチャートはパッケージごとですね。サブシステム全体の制御をするやつですね。

それでいいと思いますね。ユースケースごとにあってもいいかもしれないですね。

--- よく、ユースケースの代替パスを表現するのにステートチャートを使いますね。概要に。

コラボレーションなんかはあんまり使わないですね。

--- シーケンス図ですか

ええ、シーケンス図になっちゃいますね。ただ、あれを描くのが大変ですね。

--- あと、プロセスについて何か言っておきたいことってありますか

結構ここに書いてますね(Interface 3月号 CQ 出版社)。

--- そこを読んで下さいってことで

ぜひ読んで下さい。

--- 特に強調したい部分ってありますか

プロセスを追って順番に説明してるのでだいたいオープンになんでも書いちゃってますね。 今話してる内容なんかも書いてありますね。

大事なところはやっぱり、目標意識。何を目的に作るのってことを結構すぐ忘れちゃいますよね。 組み込みのソフトエンジニアって特に、突き抜けるような視線で深く見る力と、ばっと広げて全体がどうなってる、 その中のどの位置付けで自分は何をしないといけないかっていうことを見定める両方の力が必要だと思うんですよね。 そこはうまいことフォーカスのバランスをつけていって、で何がしたいのっていうことを忘れないでやっていくことが大事だと思ってますね。

後、工程っていう見方であんまりソフト屋さん動いてないですよね。 工程がないとノウハウがぜったい蓄積されないので、結局個人のスキルであの人呼んでくればうまくいくよって方法になっちゃいますので。

--- そうですね。

ええ、組織としてやっぱり、プロセスを作らないといけないと思いますね。


休日の過ごし方

--- 趣味ですとか、休日はどうされてるのかお聞きしたいのですが。休日は執筆ですか。

いえ(笑)、休日はですね、家はまだちっちゃい子がいるんでね、なるべくいっしょに遊ぶようにしてるんです。 なかなか、かまけて金曜日に飲み会だったりするとつぶれちゃったりしますけどね。

--- ご趣味はなんです

若いときは多趣味にいろいろやってたんですけど、最近ちょっと疲れ気味ですね。

--- 充電ですね

そうですね。近所の公園ですとか、子供を二人乗せてですね自転車をこいでいったりですね。 そういうことはやってるんですけども。運動不足になりがちなので、少し気をつけてます。

結構いろんなことに手を出すんですけど、そんなに、最近深くやれなくなってきちゃって。 仕事は深くやるんですけど、趣味のほうは浅くなっちゃって。それは悩みですね。 もっと熱中できて、深くいっちゃうといいんでしょうけど。

--- ディープに行っちゃうと、今度は仕事の方にね。

そう、影響しちゃうんですよ。

--- やっぱりディープに行かないといけないですからね。その辺どう成り立たせるかっていうのは難しいですよね。

という意味ではバランスが取れてるのかもしれないですね。 趣味のほうはそこそこいいかげんになってきて。 でも、健康とかは注意しないといけないなって思いますね。 弊社の向こうの方にエアロビなんかがあってですね、行って、終わって、着替えて、また仕事なんて。 結構やってたんですよ(笑)

--- そこはビールですよ(笑)

そうですね(笑)。ビールはサイコーですね(笑)


司馬遼太郎に日本人を見る

--- 尊敬する人とかっていますか

尊敬する人ですか。あんまり居ないですけど、漠然と明治維新の頃の人々とかですね。 無血って言われてて本当は人がいっぱい死んだんですけど。明治維新の辺りですね。 志士って人たちは、なんでか知らないけど日本を背負って考えてましたよね。 良くしよう、良くしようって。

それは司馬遼太郎先生がそう書いちゃったからかもしれないですけどね(笑)

--- あの人の本を読むとそうかもしれないですね。

司馬遼さんはいいですよね。日本人という人種が好きでしょうがないですよね。あの人は。

--- 緻密じゃないですか、話のもって行き方が、納得できる書き方をしますよね。

納得できますよね。血が騒いじゃいます。

--- 多分最初に「竜馬がゆく」を読んだ人は、維新のころが好きになりますよ。私、「国盗り物語」なのであの辺のどろどろした戦国時代が好きなんですよ。

そうですか。私「坂の上の雲」ですよ。司馬さんは

--- それは誰がでてくるやつですか。

日露海戦の時の話で、秋山大尉かなんかで。

--- それ知らないですね。読んでないなー。

参謀をやった人ですね。面白いですよー。徹底的に考えてるんですよ。作戦とか。 徹底的ですよね。 徹底的に考えて考えて、もう裏の裏の裏の裏まで想像してシミュレーションを頭の中でかけてそれで参謀として海戦に挑むわけですよ。 どういう状況でも対処できるように。

--- それで勝った。

そうなんです。

ちょっとそれちゃいますが、江戸の頃から明治維新だとか明治の頃の人ってのは、ずーっと、 もっともっと粋で、文化的で、ちゃんとプライドがあって、そういう民族だったねってところがありますね。 第ニ次大戦に負けた後に今みたいになってきてますけど。

今、江戸なんて見直されてますよね。環境の面から。 膨らまないし縮まないっていう町の作り方っていうのが。 ISO14001 じゃないですけど、環境にやさしいですとかね。注目されてるんですよ。 日本人は注目しないで、だいたいヨーロッパの方の人なんですけど。

そういう意味じゃ、もっと、日本人はプライド持っていいんじゃないかなって思いますね。 戦争に負けてからどうもちょっとうつむき加減ですけどね。 司馬さんの本なんか読んでると、うーんって思うんですね。


--- 最後になりますが、何か宣伝されたいことはありますか?PR したいことなど

そうですね。雑誌書きましたから、皆さん読んでくださいというところですか。(Interface 3月号 CQ 出版社

--- 記事がちょうど一ヶ月後くらいになっちゃいますね

じゃ、次の号になっちゃってるかもしれないですね。

--- バックナンバーで読んでくださいと言うことで(笑)

(笑)取り寄せてくださいね。他にはあんまり宣伝することはないですね。複写機ですかやっぱり(笑)。買ってください。


© 2001 OGIS-RI Co., Ltd.
Prev Index Next
Prev. Index Next