2005年04月21日 23時58分30秒

議事録の書き方

テーマ:エンジニアリング
こうしてブログを書いていたりしますが、ちゃんと言いたい事を伝えていられるかが、結構心配です。

最近、会議の議事録を作る事が何回かあって、参加者にメールで投げるのですが、結構駄目出しが多くてへこみます。

人の議事録を見てよっぽどの事が無い限り、駄目出しはしませんが、書き手の感情が入っていたり、話していない内容とか、こういうのは良くないなぁ、と感じるところは自分でも気をつけているのですが、それ以外の所を突っ込まれてしまいます。

さて私の突っ込まれポイントは、当然の事と割り切ってしまって、あえて書かなかった部分が多いです。後は誤字とか。

部署もまたがっているし、メンバーのキャリアも全然違うミーティングなので、この当然の事の部分の線引きが、かなり難しいです。私的には掲題として書いておくので柔軟に受け止めて欲しいのですが…。あまりうまくいきませんね…。

考えて見ればこの歳になるまで、ろくに議事録なんて書いて来なかったので、そんなに上手く無くて当然と言えば当然なのですが…。

まぁ、言い訳ですが。

AD
いいね!した人  |  コメント(4)  |  リブログ(0)
2005年04月20日 00時13分25秒

仕様書の書き方 3

テーマ:エンジニアリング
若手SEのためのシステム設計の考え方―システム企画から要件定義、システム設計書の作成まで

モジュール仕様書について、もう少し詳しく書いておこうかと…。

具体的な構成は以下の様になります。

(1)機能概要
(2)インタフェース仕様
(3)動作仕様
(4)エラーケース
(5)テーブル構造

まあ、こんな感じで、機能概要はそのままですね。インタフェース仕様というのは、この機能を、他の機能ブロックから使った時の入力と出力、呼び出す関数をまとめた物です。これをモノの本では、外部I/F仕様とか言って、別のドキュメントにまとめたりしています。

ところで「外部」ってなんだ~っ!?って気がしません?"外部" からのインタフェースって事なんでしょうが、インタフェースって外部からでしょう。普通。なんか気持ち悪くて、私はこの言葉を使えません。

動作仕様。ここはそのモジュールの動作の仕様を書きます。状態遷移図とか、状態遷移表とか、フローチャートとかを必要に応じて書きます。例えば状態の無いモデルなのに、状態遷移図なんて書けませんよね。あと、フローチャートは細かく書きすぎるとそのままソースコードになってしまうので、あまり詳しく書かなかったりします。でも書かないよりは、書いた方が良いと思います。

エラーケース。異常な処理、他のモジュールのエラー終了とかが返って来た時の振る舞いをまとめます。

テーブル構造は使ってるグローバル変数とか、他のモジュールが参照するテーブルとか、そんなのをまとめたものです。

と、一応これだけ書けば最低限の材料は揃ったって感じなんですよね。本当はここから実際のコードに近付ける為に、定義、定義を繰り返していくのですが、さすがに端折っています。適当にやっていると、仕様書からかけ離れたものがコードとして、生まれてくる事がありますんで、出来るだけその距離が開かない事を意識して書くというのが、必要なのかなぁ…と。そう思います。

んで、最後になりますけど、多分一番重要なのは、なんの為に仕様書を書くのか?残しておくのか?って事を考えて書く事が重要だと思います。それは、顧客の要望を具体的な仕様に定義するための要求仕様書だったり、レビューを行う為の機能仕様書だったり、自分の中で構造や設計をハッキリさせる為の詳細設計書、構造設計書だったりするので、きっと仕様書とは、あるフォーマットにしたがって記述すれば、それなりのものが出来上がるというものでは無いと、今は、感じます。

書き方について語ってきたのに、最終的には、そんなところです…。

ソフトウェア開発 で伸びる人、伸びない人 (技評SE新書002)
Software people―ソフトウェア開発を成功に導くための情報誌 (Vol.6)

AD
いいね!した人  |  コメント(0)  |  リブログ(0)
2005年04月19日 00時41分47秒

仕様書の書き方 2

テーマ:エンジニアリング

Software people―ソフトウェア開発を成功に導くための情報誌 (Vol.3)

仕事でこれしかやってない所為か、ついつい仕様書の書き方について考えてしまいます。今更そんなに必要なのかって意見もあると思います。最近では…というか、かなり前から Case ツールとか、仕様書作成ツールとかの性能が上がってきて、コードから仕様書を吐いたり、UML で書かれたクラス図からコードを吐いたりと、メチャメチャ便利になってます。Visual Studio 2005 も発売される事ですし、なんて言ったって21世紀ですもんね。まったく。

でも、なんで私がそんな事をやってるのかと言うと、そういうツールが高くて買えないというわけではなく、結局そういう話ってハイエンドのシステム開発 SE のお仕事だったりするわけですよ。Java とか Visual C++ とかその辺の Windows アプリ。私の様な SE 界の雑草の様な、組み込みエンジニアからはちょっと遠い話なのです。(あ、別に組み込みエンジニアリングを愚弄しているわけでは無いです。なんだかんだ言っても私はこの仕事に誇りを持っています)

さて、前置きが長くなってしまいました。ちょっとノッて来たので、仕様書、設計書に具体的に何を書いたらいいのか、という話をしようと思います。

私が書いている仕様書の種類は以下の様になっています。

(1)基本設計書
(2)システム構成図
(3)モジュール仕様書

基本設計書はシステム全体で、どんな機能ブロックがあって、どんな構造になっていて、それぞれの構成なんかをざっくりと書いています。あと OS の共通 API なんかはここでまとめてしまいます。

システム構成図では、文字通り"図"で、タスクとメッセージ(キューとか)のつながりを書きます。タスクには優先度とかを記述し、図を見るだけで、まあ、モジュール構成の矛盾が無いかどうかを確認します。1つのキューから2つ以上のタスクが、メッセージを取ってたり、1つ前のタスクの方が優先度が高い時などは注意が必要です。

で、モジュール仕様書。これは機能ブロックごとの仕様を、それなりに突っ込んで書きます。状態遷移図・表、フローチャートとかを使って、その機能が、ちゃんと動くモデルであるという事を書きます。あと他の機能ブロックからのインタフェース(入力と出力とグローバル関数)なんかもここに書きます。ちなみにクラスの場合もここ。

まぁ、ざっくりとそんな感じなのですが、いろいろ流儀があるらしく、仕事でいろいろ調べてみたら、結構、楽しめました。…と、ドキュメント作りにどっぷりと浸かってしまって、最近コードを書いていません…。コードを書いている時が一番楽しいのですけどね…。

仕様書の書き方 3 へ続く

管理者になったとき困らない 実践的ソフトウェア開発工程管理
図解でわかる ソフトウェア開発のすべて―構造化手法からオブジェクト指向まで
AD
いいね!した人  |  コメント(0)  |  リブログ(0)
2005年04月16日 22時54分20秒

ドキュメントについて

テーマ:エンジニアリング
えーっと、機能に引き続いて仕様書の書き方です。

実は私が一番気になるのはフォントです。私が何かしらのドキュメントを書くときは、フォントはMSゴシック(日本語)、Arial(英語)を基本に使っていて、ソースコードとかを貼り付けたりする時は、半角のMSゴシックを使うと…。

なんでそういう事をするのかというと、読みやすくして読んでもらう為なんですよ。ブラウザで見ている文章の殆どは、MSゴシックなので見慣れてるから可読性は高いかなと…。あと縮小したり、斜体にしたりした時でも、かなり可読性の高いフォントなのですよ。

まぁ、そんな感じで、それなりに、字さえにも気を使ってるのですが、これがまた悩みの種で、人の書いたドキュメントって殆ど Word のデフォルトで書かれているのです。フォントはMS明朝+Century で、もう、字の隅の方がひんまがってて、ホント読みづらいのですが…。私だけでしょうか?しかも私の書きたい内容とちょっと同じ様な事が書かれているから、コピーしようなんて思った日には、私のフォントに統一性の取れたドキュメントに、にっくきMS明朝+Century フォントの文章が、そのままベターッとくっ付くのです。

これはもう、ヒーッて感じなので、一生懸命貼り付けた文章のフォントをMSゴシック+Arial に書き直すのです。

まぁね…。良いのですよ。デフォルトのままってのも…。面倒でしょうし…。もしかしたら見にくいと思っているのは私だけかもしれませんし…。でもね。これだけは勘弁して下さい。

ソースコード貼り付ける時に Century 使うのやめて下さい。

もう、インデントとか変数名とかぐちゃぐちゃです。だって、Century でプログラムしてないでしょ?ゴシックでしょ?なんでドキュメント書く時だけ、Century なんですか?もう、面倒でフォント変えてられないか、そもそもドキュメント書く気が無いとしか思えませんよ。

…と言いつつこのブログはMS UIゴシックという、また、違うフォントで書いています…。
いいね!した人  |  コメント(4)  |  リブログ(0)
2005年04月15日 23時17分22秒

仕様書の書き方

テーマ:エンジニアリング
管理者になったとき困らない 実践的ソフトウェア開発工程管理

さて、この1週間何が忙しかったのかと言うと、かなりの量のドキュメントを書いていたので、連日晩くまで、仕事をしてしまい、なかなか家にも帰れず、ブログも書けずな毎日でした。こっそり会社からブログを更新する事もできるのですが、さすがにそんな余裕もありませんでしたよ…。

はぁ…。

何を書いていたのかというと、プログラムの設計仕様書なのですが、これがまた書くのに苦労するんです。詳細であれば良いってもんでもないですし…、最近はデザインレビューと言って、チームのみんなで確認し、チェックする様な体制に遅ればせながら、ウチの会社もなって来ましたので、こう、他人が見ても理解がしやすく、かつ、私のイメージを伝え、飽きさせないような資料にしなければなりません。これが、なかなか難しいのです。

教科書通りに書いてしまうとなんか項目を埋めただけの様な、味も素っ気も無いドキュメントになってしまいますし、適当にさっぴくとレビューの必要性が薄れると…。絶妙なバランスが必要なんですね。

で、何枚も何枚も書いて気が付いたのですが、結局ドキュメントに書かなければいけない事ってのは、自分が知りたい事、という考えに至りました。なんとなく客観的にみて、自分が書きたい事ではなく、知りたい事を意識してまとめてみると、それなりに自分で納得できる形になりました。

新人さん達のドキュメントを見ると、どうも迷いみたいな物が見え隠れしていて、この辺の感覚がまだまだのような気がします。なんかそういう事を伝えて行けたらなぁと思う今日この頃です。

仕様書の書き方 2 へ続く

Software people―ソフトウェア開発を成功に導くための情報誌 (Vol.5)
いいね!した人  |  コメント(0)  |  リブログ(0)
2005年02月19日 23時45分45秒

組み込みとは…

テーマ:エンジニアリング
「組み込みって何?」という記事がありまして、組み込みを生業としている自分なりに考えを巡らせてみたのですが、なかなか上手くイメージできませんでした…。ちょっと自信無いですが、自分の思いを書いてみました。

まず、組み込みって言うのは、Windows とか MAC とかの上で動作するアプリケーションやシステムとかとは違って、カーナビとか携帯とか、最近ではエアコン、湯沸かし器とかの家電に入ってるソフトウェアの事だと思っています。ユーザインタフェースから、デバイスの制御まで全部作る必要があるわけですね。

また「普通の SE と何が違うのか」という観点で行くと、設計では、ASIC とかメモリとかをじかに触って制御する必要があるので、ある程度ハードウェアの知識が必要になってきますし、コーディングはそれに引きずられて、Cがメインになります。また、リソースや実行速度がシビアなので、機能や見た目よりも、動作をとにかく重視する。みたいな視点が必要になってきます。まあ、これに関しては普通の SE の仕事をした事が無いので、実際の所は自分の視点がずれているかもしれません。

話題が変わりますが、そういった意味では組み込みのエンジニアの方は、所謂普通の SE に憧れと羨望を抱いています。「SE の仕事術」みたいな本が巷に溢れかえっていますが、読んでみると自分の仕事にそぐわない内容だったり、雑誌とかの「画期的な開発手法」もそのままでは使えなかったりするからです。組み込みエンジニアだけを対象にした本って、かなり少ないです。でも実はこの辺は応用を利かせて、自分なりに解釈する事ができるのですが、肩身の狭い思いをし続ける事に変わりはありません…。

ITRON という組み込み向け OS の第一人者である坂村さんという方が、いらっしゃるのですが、この方が去年「組み込みのエンジニアにもっと愛の手を差し延べてください」みたいな事を言ってました。ご本人は給料とかの事を指して言っていたように見えますが、実はもっと、インフラとか、この業界全体に言える事だよなぁと思いました。まぁ、エンジニアの人口区分では、システム開発をやってる人の方が、組み込み開発よりも 10 倍くらい多そうですが。でも、実際そんなに仕事は変わらないんじゃ無い?と思っています。逆にそんな風に分けるから、変に区分ができてるような気がしています。

組み込みと言えど、実はかなり高レベルな技術力や応用力が要求されますし、最近では、ネットワーク関連の知識も非常に要求されている所です。エンジニアと一言に言っても、システムを作るだけじゃなくていろいろあるという事です。

…と、なんかそれなりにまとまりました。…か?

いいね!した人  |  コメント(0)  |  リブログ(0)
2005年01月04日 23時54分04秒

加湿器を買ってみた、家電に見るエンジニアスピリッツ

テーマ:エンジニアリング
羊姫がですね、エアコンを付けると乾燥してのどが痛むと言って、暖房を付けさせてくれなかったのですよ。1年中エアコンを付けて常温で生きてきた、文字通りの温室育ちのわたくしですから、それはもうこの冬が無事に乗り切れるか不安でしたが、ついに加湿器を購入しエアコン全開モードに本日から突入することに、あいなりました。

同棲を始めて結構問題になるのは、エアコン事情ですね。1人ですんでいた頃は、夏は冷房をこれでもかというくらいにかけて、冬がけの布団で寝ていたのですが、やっぱり乾燥するらしく、去年の夏もエアコン無しで生き抜きました。知人も奥さんとエアコンの温度でもめるらしく、会社でぼやいていましたよ。

一緒に住むようになっていろいろ買いました。最近の家電はすごいなぁと思う日々ですね。まずエアコン。除湿、加湿機能は勿論の事、マイナスイオンやゆらぎ機能(さっぱり分かりませんが、癒し系の効果があるらしい…)なんてのもついていますね。

その後には浄水器を買いました。これは至ってシンプルなもの。他の製品では電解水を作るものとかあって、pH コントロールとかできて、洗顔とかにも使えるらしいです。

で、今回の加湿器ですか、ただの湯気を出す機械と侮るなかれ、ハイブリッドとかスチームとか様々な形式があるのです。水を含ませたフィルタに風を当てて加湿する「気化式」、従来どおりの水を熱して湯気を出す「スチーム」、その中間のフィルタに温風をあてる「ハイブリッド」と、加湿器業界の奥の深さが思い知られます。省エネ具合がそれぞれ違うとか…。ウチは普通のスチーム式を買いました。

しかし、家電業界。エンジニアスピリッツを刺激されるものが多くて、見てると面白いです。

いいね!した人  |  コメント(4)  |  リブログ(0)
2004年11月13日 20時55分04秒

本物のエンジニア?

テーマ:エンジニアリング
ITmediaニュース:エンジニアが憧れる「本物のエンジニア」23人のトップは?

Tech総研/エンジニアのための「いつかは転職」ブレーン[リクナビNEXT]

衝撃的です。個人的にはエンジニアじゃないと思う人が結構入っていると思うのですが…、本当にアンケート対象はエンジニアでしょうか…。というか、どんなエンジニアにアンケートしたのか気になります。

ただエンジニアと一括りに言っても、私の様に IT 関連のエンジニアもいれば、自動車工場で働く技師さんもいるわけで、今はもう幅広く指し示すような言葉になってしまったので、いろいろだと思います。ですので、なんと言うか「技術者」というか、もう少し対象と範囲をを絞らないとレポートにならないのではないでしょうか。

レポートの目的は多分エンジニアランキングを決める事ではなくて、「本物のエンジニア」とは?むしろ本物とは何か?という内容だと思われます。さっと読む限りでは。でも、なんかこのランキングがクローズアップされてて、違和感があるんですよね。

Track back to :
Iced Double Tall Caramel Latte:“エンジニア”が憧れる「本物のエンジニア」?

いいね!した人  |  コメント(0)  |  リブログ(0)
2004年11月06日 15時52分29秒

ソフトウェア技術者へ

テーマ:エンジニアリング
IT Pro の記事を読んで、思うところがあるので記事にしておきます。簡単な会員登録が必要なので、すぐに見れないかもしれませんがリンクは下記。メールアドレスの登録が必要ですが、広告メール等の類いは別に届きませんので、エンジニアの方は会員登録をお薦めします。

「日本のソフト産業にもう学ぶものはない」、品質管理の専門家が苦言

日本のソフト産業界が、全体的に品質低下してきていると記事には書かれています。私が生業としている組込みソフトウェアも例外では無い。日本の全てのソフトウェアが品質低下を起こしている可能性がある。

日立製作所などがメインフレーム向けに開発するアプリケーション・ソフトは、1000行あたりのバグ発生件数が、現在のオープン系システムの水準より2ケタ少なかった。 (記事中の斜体部は上記 IT Pro からの引用です)

これは驚異的じゃないですか?今よりもバグが2ケタも少ないなんて。仕事のほぼ全てをバグ修正に追われてはいませんか?それが2ケタも少ないなんて、こんな幸福なことはありません。

マシンの高速化でコンパイル時間が短縮されたこともあり、「とりあえず組んで、バグが出たら直せばいいや」といった安直な考え方が開発現場に染み付いてしまった。

耳が痛いです。正直、(1) 単純で静的な、ほぼテストサンプルに近いコードを最初に作成→ (2) 例外も含めて思いつく動作パターンにおける処理の作り込み → (3) テストを実施し気が付かなかった例外処理に対する処理を作成(バグフィックス)という工程でプログラムを作成してしまいます。プログラムの完成までは、このプロセスを行う事で最短で作成できるものの、品質を向上させる箇所がありません。エンジニアの経験によってバグに気が付く、気が付かないの差が発生しますし、プログラムの質が最初に作成したサンプルコードに依存するので、最後に根本思想の誤りに気が付いた時に後戻り出来ない状態に陥ります。

改善のポイントは三つある。まずは、開発の各段階でシステムの完成度を評価し、確実に不具合を潰す「評価技術」。二つめは、ユーザー企業の意図を汲み取り、用件定義をうまくまとめるための「要求分析」。三つめは短期開発に即した「プロセス・マネジメント」である。

「要求分析」と「プロセス・マネジメント」については、Software People という雑誌の Vol.4、Vol.5 で特集として取り上げられており、大変参考になります。Vol.4 は既に絶版ですが、バックナンバーを抱えている書店はまだあると思います。「要求分析」と「プロセス・マネジメント」について書かれた本は、それなりに販売されていますが、今ひとつ現場の業務に即していない気がして、あまり面白くないのですし、また、インターネットを探しても参考になる様な文献が見つかりませんが、Software People は、内容が現場よりなので、実際に手を動かしている現場の方にはお薦めです。

必要なのは危機感を共有することだろう。

私は開発とバグ修正に追われて、それ以外の事をしている暇なんて殆どなくて、まだまだですが、ちょっとでも空いている時間を見つけて本を読んだりして、品質向上の為に勉強を始めた所です。

後は、体たらくな会社やチームを動かす方法とかを教えてくれる参考書があればいいんですけどね…。

いいね!した人  |  コメント(6)  |  リブログ(0)
2004年11月03日 04時58分07秒

はてなダイアリーの開発

テーマ:エンジニアリング
いい感じに夜更かしをしている羊雲です。私のストレス解消法の一つでもあります。しかしながら、平日に支障をきたすのでなかなか大変です。まぁ、いいか。

たまには仕事の話をしたいと思います。仕事日記なので。

ヌーベルブログ: 80件 ベータテスト中に追加した機能・改善項目数

正直参りました。

私は1人でやってる仕事が多いので抜けましたが、一時期、6、7人で一つの製品を開発していました。そのプロジェクト、人数をかけているわりには進捗が悪くて、ミーティングとか、仕様決定に必要以上に時間がかかっている気がしていました。

なんとかしなくては…、と思ったものの自分がプロジェクトリーダでない事、また、自分のかかえてるプロジェクトが持ち上がり、チーム開発へ専念出来なかった事から、無念ですが諦めてしまいました。

どの辺のに問題があったかと言うと、ゴールがいまいち不明瞭だった事と、意思決定、仕様決定をするのにいちいちミーティングを開いたり、全員参加のレビューを行ったりと結構、無闇に時間を使っていたという点にあると思います。

そういうやり方がまずかったと言いたいのでは無くて、今ひとつ態度が不真面目というか、仲良しというか結構、話がわき道にそれたり、雑談交じりのミーティングに問題があったかなぁ…と。まあ、それが悪いわけでは無いと思ってたんですよ。ギスギスしていても嫌ですし、仲が良いのは良いチームワークを生むかな?…と。でも、やっぱり普通に考えて製品作ってるんで、もうちょい真面目にならなくちゃいけなかったかな、とも思います。

で、上のヌーベルブログの記事を読んで、ちょっと打ちのめされました…。やり方とか、ちゃんとすれば出来るじゃん。やっぱり私達のやり方がまずかったのかな?…と。更に

その方法に対して全員がいかに真面目に、真剣に取り組むことができるか、そういった企業文化が根付いているかが大きく影響します。

と、ウチの会社の弱点を突く一言…。あぁ、そうだよな。こんな開発体制は文化だもんな。文化的に改革が必要だ。私らは。

…で、更に著者の伊藤直也さん。年近いじゃんかっ!何に参っているかと言うと実はこの事が一番だったりします。
いいね!した人  |  コメント(2)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。