2013年08月02日

SZJ003 「あいつよりましだ」は思考停止のはじまり

今回は3分メモを始めるきっかけとなったネットの記事を紹介します。

http://www.sinkan.jp/news/index_1792.html

内容は大前研一氏の「洞察力の原点 プロフェッショナルに贈る言葉」という本の抜粋なのですが、身につまされることばかりで、これまでの自分の行動をすぐに改めようと気になります。

私が特にグサッときたのが「そのうちに」というやつです。

「そのうちに」やりたいことがあるなら、今やりなさい。というのが大前氏のアドバイス。時が経つにつれて情熱は薄れるもの。「やりたい」と思った時こそが旬であることを忘れないようにしましょう。

この記事から私は、他人や、結果を意識しすぎてグズグズしていてはいけない、とりあえず行動しなくてはと思い。3分メモを始めました。
結果として、形にならなかったとしても、行動することに価値を見出し、次に繋げる原動力として行きたいと思っています。

また、「あいつよりましだ」や「おれもいいと思ってた」も自分的にはかなりグサッときました。
「あいつよりましだ」と自分の方が優れていると慰めてみてもみじめなだけです。人と比較するのであれば一生懸命頑張っている人を目標にして「あいつを超えてやる」みたいな意気込みが必要だと思います。
「おれもいいと思ってた」は、他人の意見に便乗して、自分で考えることをしない人の言葉です。何かを成し遂げたいと思うのならば、しっかり自分で考えて発言すべきです。

まだ3分メモを始めたばかりですが、今後3分メモをどうすべきか、自分の長期的なテーマとして取り組み、少しずつ改善して行こうと考えていますのでどうか長い目で見守っていてください。
よろしくお願いいたします。
posted by j.shiozaki at 00:46| Comment(0) | TrackBack(0) | 3分メモ

2013年08月09日

SZJ004 設計書の書き方@〜読み物としての設計書〜

設計書を書く時に、文章の表現に気を付けていますか?
ユーザーは、開発者とは違った視点で設計書を見るので、開発する側からすると当たり前のことでも、文章の表現の仕方一つで理解できなかったり、違う意味で受け取ったりします。
誤解のないように気を付けて書いているつもりでも、ユーザーに指摘されて設計書を修正するといったことは普通にある事なので、できるだけユーザーに負担をかけないように、設計者は読み物だという意識をもって、文章の書き方に気を付けてみましょう。

■受動的、能動的

日本語は主語を省略しても意味が通じるため、書き方によってはユーザーが混乱してしまいます。例えば下の例で考えてみてください。

「選択した従業員を検索して画面に表示する。」

設計書を見慣れている私たちには、従業員を選択するのはユーザーで、検索して画面に表示するのはプログラムだと感覚的に理解できるのですが、設計書を見慣れていないユーザーは、この区別がつかない場合があります。

「ユーザーが選択した従業員を、プログラムが検索して画面に表示する。」

上記のように主語をつけて書けば誤解はなくなりますが、実際このような書き方はあまりしないです。
もっとシンプルにわかりやすく書くには、操作をするユーザーと、処理を提供するプログラムのどちらかの視点から書いて、受動的、能動的な表現を使います。

@ユーザー視点
「選択した従業員が検索されて画面に表示される。」

Aプログラム視点
「選択された従業員を検索して画面に表示する」

設計書はプログラム視点で書くのが一般的ですので、特別なことがない限りはAの書き方で問題ないです。また、能動的な表現で統一したい場合もあるので、その場合は下記のような書き方もあります。

「ユーザーが選択した従業員を、検索して画面に表示する。」

肝心なのは、ユーザーが混乱しないように操作する側と、処理する側が明確になっていることです。


■体言止め、用言止め

文章を名詞で終わらせる表現を体言止め、動詞・形容詞で終わらせる表現を用言止めと言いますが、この体言止め、用言止めをきちんと使い分けることで設計書が読みやすくなります。

<体言止めを使う箇所>
@処理の見出し

 1.従業員一覧表示処理
  1.1.入力チェック
  1.2.従業員の検索

A注釈
 「※詳細は○○を参照。」

B処理の条件
 「入社年月日がシステム日付以下であること。」

<体言止めを使う箇所>
@処理の説明

 「以下の条件に一致する従業員を従業員マスタより検索する。」
 「取得した従業員を一覧に表示する。」

自分が試した限りでは、処理の説明に関する部分は用言止めで、見出しや注釈など、処理の説明に直接関係ない部分や、処理の条件など動作を制限する部分を体言止めで表現すると全体がすっきりして読みやすくなるようです。


■句読点

句読点の使い方に、初歩的・基本的なミスのある文章は、それだけで読むのが嫌になってしまいますので気をつけなければいけない重要なポイントです。
句読点についてユーザーに指摘されるような恥ずかしい思いをしたくはないので、たかが句読点となどってはいけません。

特に目につきやすいのが、句点「。」の使い方です。句点をつける箇所と、つけない箇所を明確に区別しておかないと設計書がとても読みにくくなります。
基本的に文章の終わりには句点「。」をつけますが、一覧形式で処理を説明したりすると句点「。」をつけ忘れてしまいます。




あと、カッコつきの文章に句点「。」をつけるかどうかですが、一般的にはつけないそうなのですが、コンピュータシステムの設計書では文字列をカッコで表現することが多いので自分は句点「。」をつけてもいいと思っています。

文章のお作法で句点「。」をつけないの一般的
 「従業員番号が入力されていません」

エラーメッセージなどを記載する場合などには句点「。」を付けてもよい。
 「従業員番号が入力されていません。」


<参考文献>
 よい文章の書き方
  http://www.h3.dion.ne.jp/~urutora/bunshoupeji.htm

 ちょっとおかしな文例
  http://www.h3.dion.ne.jp/~urutora/bunreipeji.htm
posted by j.shiozaki at 00:27| Comment(0) | TrackBack(0) | 3分メモ

2013年08月19日

SZJ005 リスケジュールについて考える

リスケジュールと聞くと、ネガティブな印象を受けます。それは、ほとんどの人が「リスケジュール=トラブル」という概念を持っているからです。なので、多少作業が遅れていても、何だかんだと理由をつけてスケジュール通り完了しますと顧客に説明するのが常です。
しかし、よく考えてみてください。

作業が遅れているのになぜスケジュール通り完了しますと言い切れますか?

よく言い訳に使われるのが「人を増やします」とか「作業に慣れて後半は早くなる」とかですが、実際こんな事はスケジューを作成する際に考慮しておくべきで、人が足りないのは自分の見積もりが甘かっということなので、この時点ですでにスケジュールは破たんしています。
進捗が50%ぐらいまでは、こんな言い訳でも顧客にはなんとか納得してもらえますが、進捗が50%を超えるあたりからこの言い訳も通用しなくなってきて、最終的に顧客からリスケジュールを指示されてしまいます。
顧客からリスケジュールを指示されたということは、開発側がスケジュールが遅れているのに適切な対応を怠ったと顧客に判断されたということなので、顧客からの信頼は失われています。

だからといって、安易なリスケジュールを推奨しているわけではないです!!!

あまり頻繁にリスケジュールを行うと、何を前提にして作業を見積もっているのか不明瞭になり、結果、顧客が不安になりこの場合も顧客からの信頼を失う結果となりかねません。
あくまでも、リスケジュールは、スケジュールが破たんしている場合の話で、スケジュール通りに作業を進められる余地が残されているのであれば、体制の強化などを行いスケジュール通り作業をこなす努力をしなければいけません。

リスケジュールを考慮しなければ行けない状況はいろいろあるとは思いますが、いつくか例を上げておきます。

<顧客起因>
@仕様追加や、仕様変更の要望が出た場合。

<開発起因>
@想定外の問題が大量に発生して調査に時間がかかる場合。
A見積もりが甘くて、体制の強化だけでは対応しきれない場合。


リスケジュールの判断はとても繊細であり、開発者としての技量が試されるポイントでもあります。
そして、決して忘れてはいけない重要な事は

『顧客も開発者も良いシステムを作ろうという気持ちは同じ』

ということです。進捗会議などで厳しい事を言われると時々このこのことを忘れてしまい感情的になってしまったりしますが、顧客と開発者の根本にある物は同じだという事を決して忘れないでください。
そして、リスケジュールが必要と判断した場合は積極的に顧客に提案してください。私たちが良いシステムを作ろうと誠意ある対応をすれば必ずきっと顧客もそれに答えてくれるはずです。ただし、リスケジュールにかかるコストの話については別ですが...
posted by j.shiozaki at 01:49| Comment(0) | TrackBack(0) | 3分メモ

2013年08月24日

SZJ006 顧客に誠実に対応する事の重要性

顧客の信頼を一度失うと、それを取戻すのは並大抵なことではありません。信頼がないと、ちょっとスケジュールの遅れや、プログラム不具合に対しても敏感に反応し、徹底的に叩かれてしまいます。
では、どのような時に顧客の信頼を失うのでしょうか?

スケジュールが遅れた時?
不具合が発生した時?

いえいえ、こんなことでは信頼は失いません。
この程度のことはシステムを開発する上で当たり前のことなので、顧客も織り込み済みです。
ではどんな時かというと、

スケジュールが遅れた時の対応。
不具合が発生した時の対応

です。
つまり、スケジュールの遅れや、不具合などの、問題が発生した時に適当な対応をすると顧客の信頼を失ってしまうということです。
信頼を失った後に、いくら頑張って挽回しても一度失った信頼は決して元の状態には戻りません。そこで、顧客の信頼を失わないように普段から発生した問題への対応には最大限の注意を払う必要があります。

では次に、問題が発生した時にどのような対応をすればよいでしょうか?

<問題が発生した時>
問題が発生したらすぐに回答します。問題を放置することは絶対にやってはいけないことです。
できれば問題が発生した翌日に回答を返すのがいいでしょう。
すぐに解決策が見つからないものは、何時までに調査して回答しますと期限を提示しておきます。
また、問題の内容が不明瞭で顧客と調整が必要な場合は、時間を空けずにすぐにレビューの依頼を出します。

<問題への対応>
問題の原因が、開発側にあるのか、顧客側にあるのか明確にしておく事は重要です。
追加要件など、顧客の都合による物は、工数をしっかり出して、顧客に提示して承認をもらう必要があります。開発側の問題でないものはきちんと顧客から追加の工数のコストを負担してもらって下さい。

開発側の問題の場合には、しっかりと原因を調査して顧客に報告し、対策方法を提示します。その時に、類似箇所もしっかりと洗い出して同様の問題が他の箇所で発生しないようにするのが大変重要です。一度指摘した問題が他で発生することを顧客は大変嫌います。これを繰り返すと信頼関係は崩壊します。
また、問題が発生した場合の管理体制を明確にしておくと顧客は安心します。顧客との問題管理に専属の担当者を割り当て、常に顧客とステータスを共有して、問題の取りこぼしがないように目を光らせておきます。


最後に問題発生時の対応手順をまとめておきます。
全てがこのケースに当てはまるわけではないですが、問題に対応する際の基本的なプロセスを理解するのには役立つと思います。

1.問題発生
   ↓
2.問題点をまとめて、台帳で管理する。
   ↓
3.問題の発生元が顧客側にあるのか、開発側にあるのかを明確にする。
   ↓
4.問題の対応策を考え即時対応可能な物から着手する。
   ↓
5.対応に時間がかかる物は、期限を決めて顧客に提示する。
  また、追加要件の場合には、工数を出して顧客の承認をもらう。
   ↓
6.問題が大量に発生した場合には、体制の強化を図る。
   ↓
7.体制の強化だけではどうにもならない場合には、リスケジュールする。

問題の責任が、開発側にある場合には、それに伴うコストは当然開発側負担する必要がありますが、、追加要件などに伴うコストは顧客に負担してもらうのが筋です。
ただし、顧客との信頼を失っている場合には、追加コストの請求もままならなくなり、本来顧客に払ってもらえるはずのコストも自腹を切らざるを得ない状況に追い込まれる事もあるので、顧客に誠実に対応して、良い信頼関係を築くことは大変重要です。
posted by j.shiozaki at 16:10| Comment(0) | TrackBack(0) | 3分メモ

久しぶりにアップデート

超久しぶりに J.S Draw をアップデートしました。おそらくJ.S Draw をいじるのもこれで最後になると思います。
元々 J.S Draw は、自分のスキルアップのために作ったもので、普段の仕事では絶対にやらないような、かなりトリッキーなコーディングをしています。そのため、数行のコーディングに1ヵ月かけたり、難解なバグに悩ませられたりといろいろ楽しませてもらいました。
作成には2年以上かかりましたが、おかげで目的は十分果たしてくれました。

ホームページで J.S Draw のソースを公開していましたが、描画を行う本体である J.S Draw ControlLibrary は dll のみの提供としていたため、数人の方からソースコードを提供してほしいと問い合わせがありました。
そこで、今回は、J.S Draw ControlLibrary のソースコードもダウンロードできるようになっています。
僭越ながら私のスパゲッティ状態のソースコードが何かのお役に立てれば嬉しく思います。

posted by j.shiozaki at 16:27| Comment(0) | TrackBack(0) | J.S Draw

ジョギングアイテム

ダイエットのためにジョギングを始めて早3ヵ月た経とうしています。最初は2Kmも走れば息が上がってしまったのですが、今では歩きなしで4Kmを普通に走れるようになりました。
しかし、90Kgを超える体重を支えるにはひざに負担が大きすぎてひざの痛みに耐える日々を過ごしています。
走り始めて1ヵ月が経過して3km 走れるようになった頃に初めてひざに痛みが起きるようになりました。
走っている時はアドレナリンのおかげなのな、あまり痛みを感じないのですが、走り終わって落ち着いてくると不意にズキッときます。
特に、朝起きてベットから起きて立ち上がる瞬間が恐怖ですね。今日は痛くありませんようにと願いながら立ち上がります。

そこで、周りのジョギング愛好家の方々にいろいろ相談にのってもらい、いくつかアイテムを揃えました。
まず始めに買ったのがジョギングシューズです。ジョギングを始めた時は、近所の量販店で4000円程度で売られている安物のシューズを履いていたのですが、そんなシューズではひざを痛めるのは当たり前だとみんなに注意されました。
当初私は、ちょっと走るだけなのに高価なシューズは必要ないと思っていたのですが、とりあえずひざの痛みがおさまるのならばと思いシューズを買い直すことにしました。その時のみんなのアドバイスは、

@日本人の足には国内メーカーのアシックスか、ミズノがいい。
Aネットで買ってはダメ、必ずスポーツ用品店でためし履きすること。
B重くてもクッション性の高い物を選ぶこと。

の3点でした。ネットで調べても同じような事が書かれているので、これはジョギングをやる時の基本中の基本のようです。自分は何も知らずにがむしゃらに走っていただけなので、キチンと下調べをしておくべきでした。ふらふら

で、購入したのはアシックスの GT-2000 です。店員の話では、幅広でクッション性が高く初心者向けだということでこれに決めました。前使っていたシューズの3倍の値段でしたが、その価値はありました。

始めは半信半疑でしたが、翌日のひざの状態がすこぶるよくて、朝起きてひざが痛むということがなくなりました。シューズでこんなに変わるなんてちょっと驚きでした。

そこで、ジョギングのペースも良くなり、距離も少しずつ伸ばせるようになってきたのですが、2ヵ月を経過したころ、距離も4km に届こうという時にまたひざが痛むようになりました。そこで週4回走っていたのを週3回に減らして回復期間をながくして対応しましたが、また最近4kmランが普通になってくると時々ひざが痛むようになってきました。

これ以上ジョギングの回数を減らすのも、距離を短くするのもいやなので何かいい方法がないか考えていたのですが、その時いいサポーターがあるという話を聞いてさっそく購入しました。
ZAMSTというメーカーのもので両ひざで7000円となかなか高価なポーターです。


まだ試していないのですが、明日のジョギングの時にさっそく使ってみようと思います。
いままで膝が痛くなって4kmどまりだった距離が5kmまで伸ばせるようになればうれしいです。
posted by j.shiozaki at 18:10| Comment(0) | TrackBack(0) | 日記

2013年08月25日

ZAMST RK-1 ランニングヒザサポーター

昨日スポーツ用品店で買った ZAMST の ランニングヒザサポーターを、さっそく使ってみました。
まず使ってみた感想は、大変GOODでした、いつも4Kmあたりで、ひざの感覚がなくなって力が入らなくなってしまっていたのですが、今日は4Kmを超えてもしっかりしていて初めて5Kmを走り切りました。



注意点としては、走る直前に装着することです。自分は着替える時にサポーターをシッカリと装着してしまい、そのまま準備運動をしたのですが、このサポータはかなりひざの動きを束縛するため、ふくらはぎのならしが不十分で途中で足がつってしまいました。
着替える時は、ひざ下のふくらはぎあたりにずらしてつけておいて、準備運動をシッカリした後にひざに装着するというのがいいやり方かと思います。
走っている時には、適度に反発力があって、確かにひざのねじれを防いでくれている感覚があります。使い始めはちょっと上につけすげて若干太ももに痛みがあったのですが、ひざ上ギリギリにつけ直したら解消しました。適正サイズを買ったのですが、若干きつめなので、装着には若干神経をつかいます。
走り終わってサポーターをはずすと、若干ひざの痛みがありましたが、5km を走り切った事を考えると上場だといえます。
後は体重を減らしてひざの負担を減らすようにがんばります。
posted by j.shiozaki at 23:18| Comment(1) | TrackBack(0) | 日記