開発会社の方であれば、仕様書は作成すると思います。受託開発のころ、元請けの会社の方が仕様書をきり、それに沿って開発をしたりしていたのですが、開発を進めていくうちに徐々に問題が出てきます。

via A pile of paper on Flickr - Photo Sharing!

よくありがちなのが、納品物に対する仕様書を盾にして意見が押し付けられることです。読み違いや勘違い、前提知識など様々な要因があるのですが、仕様書は絶対と言わんばかりの態度をとられます。

そして、さらによくありがちなのが仕様書の間違いです。しかしこれは前者の逆でありながら、スルーされることが多いようです。絶対なのか、または逆なのか…勝手に解釈を加えて欲しいのか否か、よく分かりません。

後、もう一つありがちなのが、最初の方の仕様こそきちんとしているのですが、後の方（システム的には重要視される部分）になるとドキュメントが希薄になっていくという現象です。開発のスケジューリングの問題なのかも知れませんが、差別化要因を生む箇所にこそ、力を注がないといけないのですが、そうでないことが多いようです。

ということで、解決策は以下に。

Read the rest of this entry »

極力ユニットテストを書かずに品質を確保する方法 - ひがやすを blogを読んで、ちょうど先日同じ話をしていたので。

via Cocoa Code - 1 on Flickr - Photo Sharing!

テストファーストで書かないと、と思いつつも工数や納期に押されて書けずにいる人は多いと思います。プログラマにとってみれば、自分の書いたところにバグはないと信じる気持ちもあるので、あまり気が進まないということもあります。

そこで、書くべき場所と書かない場所を決めてしまうのが大事かな、と。

Read the rest of this entry »

答えから言ってしまえば必要でしょう。全てのデータは最終的に会計へと収まっていきます。何らかのデータがあった時、それが会計上必要ないのであれば削除できる可能性もある位です。

via Busy with these ! on Flickr - Photo Sharing!

バックオフィスの方で、なぜこの入力を行わなければならないのだろうと思うようなことが時々あります。それらは企業内の歴史の中で培われたもので、存在意義を誰も知らないことがあります。そうしたときに重要なのが、会計上利用しているか否かです。もし利用していない場合、そのデータは消しても問題ない可能性が高まります。

逆に、例えば顧客管理にあるデータが売掛元帳の顧客名として使われていた場合、安易にデータの削除処理を行うとリレーションの具合によってはデータは抽出できなくなり、会計の不一致を起こしかねません。削除処理の前に、売掛残が存在するかチェックしたり、漏洩するとまずいデータ（会社名、メールアドレス、住所など）だけ塗りつぶして他は削除フラグを立てるだけにしておくといった処理にすることを考えつきます。

会計のデータは決算書へと反映され、企業が存続する上で重要な要素になります。このシステムへと入るデータは全て最重要です。その観点でデータ構造の定義をしていくと、実は担当者の個人的な思いであったり、既に不要なものであったりということが分かるようになってきます。

さらに大事な理由は以下より。

Read the rest of this entry »

今のネット社会では情報が膨大に溢れ返っています。日々新しい情報が次々と舞い込んで、目移りしてしまっているのではないでしょうか。その所為で、数ヶ月前には「あれをやろう」と思っていたのに今は「これもやらなきゃ」と以前の決意はどこへやらという状態になっている人も多いのではないでしょうか。

via madrid 05. on Flickr - Photo Sharing!

そこで、敢えて情報を遮断してみる勇気を持ってみるのはどうでしょうか。遮断された中で本当に必要なもの、すべきことを見つけて、それだけを探求すると決めてしまうのです。

Read the rest of this entry »

会社組織ではよく、先輩が自分の仕事を下（というと語弊があるが）の人に教えてあげないということが起こる。原因は簡単で、下の人に自分の仕事を与えてしまうと、自分の仕事がなくなってしまうのではないかという不安にかられてしまうからだ。

via gravity on Flickr - Photo Sharing!

会社人である以上、自分の専門性が会社内での地位につながっているというのは分からないでもない。だが、下の人に任せるべき仕事に固執しているのは周囲から見てどう思うだろうか。そこで、そんな不安を解消する方法を紹介しよう。

簡単に言えば、得意分野を二つ持つのだ。それは平行して持つのではなく、さらに一段上の技術を習得するのだ。

Read the rest of this entry »

常時接続のネットが当たり前になって、ブログやソーシャルブックマーク、動画サイトなどCGMなリッチメディアが多くなってきている。そのためインターネットを使って過ごす時間が増えているはずだ。

via Every year is getting shorter, never seem to find the time on Flickr - Photo Sharing!

個人の趣味であれば良いが、仕事中はまずい。RSSリーダーをついついチェックしてしまって、気がついたら数時間経っていた…なんて経験はないだろうか。

それを防ぐためにいい方法が会ったのでご紹介しよう。

Read the rest of this entry »

個人的にメールはあまり好きではありません。FAXと同じで相手は好きな時間に読めば良いはずなのに、なぜか即時性を求められます。Notifierを使って、作業中に「新しいメールが届きました」なんてメッセージが出たりすると集中力が途切れてしまいます。

via Google Notifier for Mac on Flickr - Photo Sharing!

なのでメールは極力使わないようにしているのですが、それは別なときに。今回は新着を教えてくれる、いわゆるNotifierの方法についてです。

Read the rest of this entry »

最近個人的にはまっているのがA4プレゼンです。これは単純に言えば、A4一枚にプレゼン内容を全ておさめるということです。だらだらと長いプレゼン資料や、余計や前置きがあるよりもよっぽども分かりやすく、インパクトもあります。

via Looking glass on Flickr - Photo Sharing!

重要なのは「何を訴えるか」をきちんととらえることです。つまりコンセプトを明確にすることで、プレゼンの軸をぶれないようにします。大抵のプレゼンはこの軸がいくつもあり、言うことがあちこちに飛ぶために全体としてよく分からないものになっていきます。

プレゼンで大事なポイントはせいぜい3つまでにしておかないと聞き手は理解できません。むしろ眠くなります。また、プレゼン資料に色々書いてあるとそれだけで概ね理解できてしまい、プレゼンターの言うことなど殆ど聞かなくなります。プレゼン資料丸読みのプレゼンも最悪です。

A4プレゼンの場合、もちろんそんな一語一句書けるわけはありませんので、プレゼン資料にはアイコンをちりばめて、後は言葉で説明していく必要があります。そのため、聞き手も熱心にきいてくれて理解度が高まります。ただし、これはプレゼンターの実力次第で、どもったりしているようでは全く意味のないプレゼンになってしまいます。

プレゼン資料を作るときにも、狭いA4だけのスペースでどう訴えるかを考えていくと、本当に訴えるべきものが見えてきます。だらだらと枚数を重ねるのではなく、あえて1枚という縛りを設けることでより高純度なプレゼンテーションができるようになります。

さらなる利点が、紙資源の節約にもつながってエコであるということです。つまらないプレゼンほど紙を消費して、二度と読まれないものばかりです。A4一枚に凝縮した、高度なプレゼン技術の賜物こそが有意義でクライアントの記憶にも残るプレゼンを生み出すはずです。

いきなり1枚というと辛いのですが、例えば普段使っているプレゼンテーションテンプレートを見直して、枚数を半分にしてみるというのをやってみると面白いかもしれません。

物はふとすると増えてきます。机の上はごちゃごちゃしていないでしょうか。引き出しに余計なものは入っていないでしょうか。不要な物は目に入ると集中力を妨げたり、探し物をするときに邪魔な存在になります。不要な物はどんどん捨てていきましょう。

via Lego Blogger Picture on Flickr - Photo Sharing!

私の捨てる基準として二つの軸を持っています。

• 書籍：読んだら捨てる。またはデジタルスクラッピング
• その他：三ヶ月使わなかったら捨てる

この二つです。それぞれ説明します。

Read the rest of this entry »

Appropriating and Adapting eMail - ProcessRight Workflow Poster on Flickr - Photo Sharing!

マルチタスクで動くという人がいるのですが、本当でしょうか。私自身が色々実験してみた結果からすれば、マルチタスクで動くはまず不可能でした。例えば開発をしながら、人の評価を考えつつ、メールを気にする…なんてばらばらなことをやっていると気が散ってどれも未達になります。が、何となくどれも進んだような気がして、仕事をやった感が感じられます。

しかし過程は対して重要ではなく、結果が出せることが第一です。そのためにはいずれであっても、まず終わらせることが重要です。そこで大事になるのはシングルタスクではないでしょうか。

シングルタスクの場合、すべきことは一つしかないので単純です。が、それだけをやっていると集中力が続きません。そこで、一つのタスクをさらに細分化します。できれば10分単位くらいで終わるくらいに分けます。例えばあるシステムの開発であれば、

• 作業内容を考える
• テストを作る
• 大枠を作る＆テスト実行
• 中枠を作る＆テスト実行
• 詳細を作り込む＆テスト実行
• 画面を作る
• 手作業のテスト

といった感じでドリルダウンしていきます。そして、順番に終わらせていきます。これによって短い時間単位で達成感を感じつつ、次の作業に移っていくことができます。

とは言え、一つのことだけをずっとやって仕事が終わる訳ではありません。いくつもの作業を抱えたとき、どういう風にこなしていけば良いのでしょうか。

Read the rest of this entry »