2005年06月06日

記事「技術者を襲うストレスとうつ」

□ ITmediaニュース:技術者を襲うストレスとうつ、原因と対処法は





従業員のストレス問題は経営リスク、らしい。





精神障害関連の労災件数の実に4分の1がSEやデザイナーなどの「専門技術者」だという。


…それは単に、この業界にもともと社会不適合者まがいの人が多いからなのでは…、と思うのは邪推だろうか。





対処法は、自分なりの「ヨン様」を作ること。


まあ、当たり前と言えば当たり前かも。


僕の場合は、へきるたん萌えだし。





社会不適合者の皆様も、妄想・暴走が得意な方は多いかと思います。





しかし、この記事で紹介されているライフバランスマネジメントの社長とかいう人は、僕の大学時代の研究室の教授に似ていて、それがまずウツ。
posted by tsasaki at 13:08| SEライフ

2005年06月03日

できる人間とストレスの関係

□@IT自分戦略研究所「ITエンジニアにも重要な心の健康」





内容は、仕事ができる人間ほど周囲からの期待に応えようとするために負担が大きくなりストレスを受けやすい、というもの。





確かにそうなのかもしれない。


でも、そんなのは「できる人」に限ったことじゃなくて、誰でも一緒なんじゃないかな、と思った。


違うのは環境なわけで、仕事ができるできないに関わらずそれなりのストレスはあるんじゃないかと。





タイトルに惹かれて読んではみたけど、書いてある内容は特別なことでもなんでもなかった、というお話。





僕が仕事ができる人間かというとそういうわけじゃないけど、客先に行けば厳しい立場だし、会社に居てもとりあえず戦力はあるけどほとんど孤立無援に近いし、環境的には厳しい。


ストレスはそれほど強くは感じない方なんだけど、最近いろいろ疲れているので「ストレスチェック」というものをやってみた。





結果は、身体的、精神的なストレス状態は良好だけど、疲労を感じているようだ、とそのまんまの状況が返ってきたし。





んー。やっぱり疲れが抜けないのか…。





会社の人にも「身体だいじょうぶ?」とかよく聞かれる(笑)んだけど、身体は大丈夫なんだよね。意外に。


ただ、慢性的に疲れが抜けないだけで…。


それがヤバイのかもしれないけど。





ちなみに、精神面はとっくに大丈夫じゃないので、ご安心を(?)
posted by tsasaki at 20:41| SEライフ

2005年05月21日

仕様と違うのはバグではない?

先日、こういうことがあった。





現在開発中のバージョンのリリースが間近だということもあり、機能の最終チェックを行っていた。


ある設定の登録処理で、設計仕様を満たしていない項目が1つあったのでそこを修正するように開発者に作業を戻した。





要件はこう。





登録ボタンを押下した時に、以下の入力チェックを実行し不適合であれば警告ダイアログを表示する。





1. (従来バージョンからの仕様) 登録しようとするある番号(入力式)が、既に登録されているデータと重複した場合


2. (今回バージョンでの追加仕様) 登録しようとするある名称(リスト選択式)が、既に登録されているデータと重複した場合(このとき、名称のリストにはある名称群の全リストが出てくることになっている)





従って、今回バージョンからは1か2のどちらかでも不適合であれば、警告ダイアログを出す、というそれだけの機能。





僕は僕で、最新仕様での取扱説明書を作成しているわけ。





で、プログラムが修正されてきた。


チェック項目を追加し、ORで警告を出すようにする、というだけの処理なのでその場でチェックはしなかった。


夜になって、取扱説明書用にその画面をキャプチャしようとして愕然としたね。





上記の要件2のチェック対象になっている名称のリストに、何も表示されねぇー!!





いろいろ検証したけど、どうやら今回の修正でその現象が発生するようになったらしい。





結局、その日は検証作業でほとんど眠れず、明け方に開発者にメールを送った。「重大な不具合ですから修正してください」と。僕にしてみれば、今まで動いていた機能が動かなくなっているので重大な不具合としている。





朝、開発者から返事が来る。





「現象を確認しましたが、これはバグではありません。


 登録できない名称は、はじめからリストに出さないようにした方がユーザに親切だと思いますので、そのようにプログラムしました





さて、皆さんはどう思うだろうか。





開発者の立場に立ったら「その気持ちは分かる。悪いことではない」


僕の立場に立ったら「たまったもんじゃない」


おおかたそんなところじゃないだろうか。





プログラム(システム)が良くなる要素だとすれば、この開発者の作業内容は悪いことではないのだけど、システムにはそれ以前に「仕様」というものがある。





この機能はこういうふうに作りましょう。こういうものが表示されて、こういう操作をするとこうなりますよ、ということが事細かに決まっている(はず)のだ。


みんなその仕様に基づいて開発作業をしたり、試験をしたり、マニュアル作ったり、エンドユーザへの説明資料を作ったりしているわけで、たいてい仕様が変わるということは、多くの人と費用が動くことになるんだよね。





重要なのは、仕様と生成物が異なってしまうこと。





もっと根本的な話をすれば、仕様が変わってしまうにも関わらず誰にも報告・連絡・相談をしていないってこと。いわゆる「ホウレンソウ」ってやつなんだけど。





一人が趣味で開発をする分には、どうぞ好きなように作ってください、良くなるようにどんどん改良してください、と言えるんだけど、組織で作っているのであって、ある一定の思想の元に開発していくわけだからね。





もしこれに誰も気付かずにそのままリリースされてしまったら…?





(恥ずかしい話だけど、実はたまにある。)





もしもユーザがシステムを使っていてマニュアルやらヘルプやらに書かれてある内容とは違う動作をしたらどうだろうか?





ユーザは言うはずだ。


「プログラムがおかしいです」「バグなんじゃないですか?」


と。





開発者からすれば、「自分がそうなるようにプログラムして、そうなっているだけ」なのでバグではないかも知れない。少なくとも、バグとは言いたくないだろう。


でも、ユーザからしたら、仕様や要求通りに動かないのはみんなバグに見えてしまう。





だから、仕様や要求通りに作っていないのは、バグか下手するとバグよりもたちの悪いものかもしれない。





それが腐った仕様だったら、きちんと話すべきところに話をしてなんとかしてもらうべし。


良い考えがあれば、それもやっぱりきちんと話すべきところに話をしてシステム全体が良い方向に向かうようにしてあげれば良い。





仕様通りに作るばかりじゃ面白くないからね。





やっぱ、大事なのはスキルとコミュニケーションだわ。





そこんとこ、よろしくっっ!!
posted by tsasaki at 23:59| SEライフ

2005年05月19日

デス様、キター!

不具合対応中に、またまた別件の不具合が発生。


突然、軟禁、拘束。助けてほしいかも。





ひぇぇぇぇ。





しかも、エンドユーザへの納入や出荷のラッシュも重なってててんてこ舞い。





フィーーーーーーバーーーーーーー!!



posted by tsasaki at 23:50| SEライフ

2005年04月29日

仕事とお客と組織と僕のスタンスのアンバランス

どもです。


ゴールデンウィーク突入だったのに仕事しているtsasakiです。


仕事はちっとも無くなりません。むしろ、増える一方。っていうか、僕があっぷあっぷしているためお客さんにも「(仕事を)出すにも出せない」と言われているので潜在的な物量はもっとあるのかも。





そんな状態だってのに、会社はよっぽど人員が余っているのか絶え間なく人身売買を繰り返している。(他の大きい会社のシステム部門や協力会社の開発部隊に派遣ちゅーか出向ちゅーかさせるやつのことね。)





毎月毎月ドナドナみたいに売られていくわけです。


(売られていって、開発案件ひっさげて戻ってくるとか、スーパーサイヤ人になって帰ってくるとかそういうふうになってくればいいんだろうけど、なかなかそれは少ないような気がする)





かといって、そういう人たちを僕の仕事に回してうまくいくかっていうとそうも思えないし。フィールドが特殊だっていうのもあるんだけど、案外周りにマルチプレイヤーが少ない。居るには居るのだけど、たいていそういう人はもう固定プロジェクトに付いているので動かせないっしょ。





じゃあ、一から育成するかってことになったとしても、残念ながら僕にはもうそういう気力は無いわけで。(自分のことだけでいっぱいいっぱいなので)


それこそ、仕様だけ説明すればあとは勝手にほいほいやってくれる人じゃないと今の僕にはつらいッス。





ドラゴンレーダーさえあれば、勝手にドラゴンボールを探しに行ってくれるような人が欲しいわけ。今は。





言うなれば、うちの会社は地球。僕が戦っているのはナメック星。





ナメック星に着いたら、少なく見積もってもドドリアさんとかザーボンさんとかそれぐらいの強さのプロジェクトが待っていたわけ。(しかも、ザーボンさんは変身することでさらに強くなったりするわけ)





で、今一緒に戦っているのが、最長老様に力を引き出してもらう前の悟飯やクリリンなわけ。





キュイぐらいなら軽くあしらえる僕でもさすがにドドリアさんやザーボンさんを相手にするのは苦しいわけ。





せめてピッコロさんが仲間になってくれないときついわけ。





でも、地球からナメック星にはおいそれと来られないわけ。来たところで、栽培マンと相討ちになるような程度の強さでは戦力にならないので宇宙船の中で修行を積んでくるか、界王さまに稽古をつけてもらってこないといけないわけ。








そういう状態。








僕のスキルは社内でもかなりレアリティなものだと自負している。


僕が、某ツールを使った今のプロジェクトに携わって2年。


なぜか、お客さんの部署で何年もこのツールを使ってシステムを作ってこられた方に技術的な問い合わせを受けて回答したところ、「おかげでシステム化にこぎ着けることができそうだ」と深々と感謝された。


(別に大したことはしていないんだけど…)





おかげで、連休中も全く別件で「仕様書作るのを手伝って」とお客さんに声を掛けられた。


僕なんかに直接声を掛けてもらえるのはありがたいことなんだけど、休みがつぶれるので痛みは伴うわけだ。








正直、僕をここまで育ててくれたのは会社よりもお客さんの比重が大きいと思う。そういう意味では、いろんな巡り合わせで今のお客さんと一緒に仕事ができているってことは感謝するべきことだし、最終的にはお客さんに何か恩返ししたいと思っている。





仕事内容に不満は無い。


だけどそれを中心に考えた場合、お客さんもうちの会社も僕自身もその仕事によっていいReflectionを与え合っているとは言えない。どうしたらその三者がうまく機能するかを考えないと見えない傷口は拡がりそうだ。





何のために人は仕事をするのか。


僕は僕が面白いと思ったことをやり続けていきたい。そのためには、何かもっといろいろと考えないといけないんだろうなー。そう思った連休前。
posted by tsasaki at 23:52| SEライフ

2005年04月22日

スケジュール作成+進捗管理ツール

仕事でスケジュール作成と進捗管理をガントチャートでやっている。


これまではExcelで頑張ってスケジュール表を作成していたけど、タスクの割り込みや進捗の遅れによって計画を立て直す時に、スケジュールの再作成作業に時間がかかりそれを何とか短縮できないかと思っているんだけど…。


とりあえずMS Projectと以前のエントリで紹介した記事内で紹介されていた(ややこしいな)OpenSourceのツールを使ってみた。





□ Microsoft Project 2003





言わずと知れたMS製品。多機能で使い勝手も良いと思う。


コスト管理や工数の管理なども出来るけど、個人的にはまだそこまでの機能は必要ない(そこまで偉くない)ので、スケジュール作成と進捗管理の機能さえあれば良い。


しかし、ガントチャートを配布したい場合に、画像形式でしかOutputできない(?)のは不便。(やり方があるのかなー?)


スケジュールを共有するには、Project Serverを立てる必要があるなどいろいろ面倒そう。(プロジェクトファイルをメールでやりとりするのもローテクなので…)





□ GanttProject (1.11)





ガントチャート作成に特化したOpenSourceのソフトウェア。実行にはJRE1.4以上が必要。


Javaで作られている割にはそれほど重くない。


最新版では休日を考慮したスケジューリングができるようになったものの、個別に非稼働日を設定できない(祝日等の設定が出来ない)など、まだまだ痒いところに手が届かない。


ガントチャートは画像形式のほか、PDFで出力も可能(らしい)


Java Web Startによるスケジュールの共有は便利そう。








僕としては、スケジュール作成とスケジュール表の顧客への配布、進捗の管理が出来れば良いのだけど、いい加減Excelではそろそろきついというお年頃。





ま、挙げたら「仕事の上での非効率」っていっぱいあるんだけどね。


でも、逆に言えばどんな有用なツールも使いこなせなきゃ意味がないってね。(宝の持ち腐れ、豚に真珠、猫に小判…etc)


いろいろ検討してみたものの、結果的にExcelがいちばん、なんてことになったらショッキング。








::関連エントリ::


□ 記事「デスマーチを止める進ちょく管理の現実解」
posted by tsasaki at 23:54| SEライフ

2005年04月16日

データベースと仕様の関係

仕事の話。


よくあるDBの検索条件選択+結果リスト表示画面を作るんだけど。





<仕様>


(1)画面を開いたときに、検索のキーにする項目をDBから取得してプルダウンリストに表示


(2)起動後1回目の表示では、リストの先頭項目を自動的に選択


(3)但し、アプリ起動中は、一度この画面を閉じて再度開いた時に、前回選択した項目を自動選択してほしい(検索条件を保持しておく)


(4)その時に前回選択していた項目がDBからなくなっていた場合は、リストの先頭項目を選択する





<完成品テスト結果>


(1)良好


(2)良好


(3)良好


(4)リスト項目全部をDBから削除したのに、全部プルダウンに残っているんですが、何か?→これによって、自然と(1)もNGに。





上記のテスト結果を踏まえて担当者に修正依頼。





<担当者からの問い合わせ>


「(3)の仕様を満たすために、2回目以降はDBからリストを更新しません。DBが変更された場合を考慮すると、画面を開くたびにDBからリストを取得する必要があります。(3)の仕様はどのようにすれば実現できますか?」





先生、世の中のSEの人たちは、みんなこんなやり取りをしているんでしょうか?_| ̄|○





<そもそも>


毎回、DBからデータを取得してリストを更新しないと(1)の仕様は満たせないわけだから、画面を開くたびにDBからデータをもらわないとだめです。





<なぜ毎回DBからデータを取得するか?>


・次回この画面を開くまでにDBが変わっている可能性がある


・起動後1回目だけDBから取得すると、24時間365日稼働するプログラムだと永遠にプルダウンリストが変わらない





<じゃあ、どうすればいいのか?>


起動後1回目と2回目以降で異なる処理は「プルダウンリストのどの項目を自動選択するか?」だけである。


従って、前回選択項目をどういう形かでプログラムで認識できるようにしておいて、2回目以降はそれを見てリストのどの項目を選択するかを決めるだけ。





(3)の仕様があるからと言って、「リストをまるまる残しておけば大丈夫」という考えになるのはおかしいわけです。(今回の仕様としてはおかしいのです)








とまあ、だいたいこういうやり取り(これができません→この方法だと仕様を満たせないよね→どうすればいいですか→やり方を変えるしか…)を1日に数回は繰り返しているのでスケジュールが遅れたりするわけだけど。





処理を組む前に仕様を検討して、どの方法がBESTなのか考えないとだめだめな訳です。





そして、「仕様変更は必ずやってくる」と思ってフレキシブルな構造にしておかないと、変更作業量が大変なことに…。








んー。この系統をシリーズ化したら、ちょっとは人のためになるかなぁ。ネタは山のようにあるんで。


「人はこうして失敗する」みたいな。
posted by tsasaki at 09:49| SEライフ

2005年04月14日

日々精進

昨日は、2日間の計画で臨んだ受け入れ試験の立ち会いが1日で終わり、ようやっと前倒しで仕事を進められると思って今日出社したわけだけど。


ねぇ。


なんで、徹夜モード突入なんですか、いきなり。





ほかのスタッフに割り振っていた作業も、3日の工程が2日でほぼ100%となったとのことなので、いっちょ気合いを入れてテストするかと始めたら、あれよあれよという間に累積エラー数がテスト前の2倍に…。


なんか不思議な動きをするところが多々ありすぎて、やればやるほどエラーが出てくる状態。





・画面を開いて閉じてまた開くと何かおかしい項目がある


・画面ではばかでかい値を入力できるのに、DBにはデータ型の上限を超えていて登録されてねぇ、ひゃっほー!


・タブオーダーがめちゃくちゃだぁ!→最近の人ってキーボードでタブ移動とかしないからわかんないのか?


・同じようなボタンが縦並びになっていて、サイズが違ったり位置がそろってなかったりするのって、すごく気になるんだけど、僕が気にしすぎなのかな


・同じような動きをするはずのコントロールが、微妙に実装が違うぞなもし→ほかの画面の動き見てないのか?


・条件がそろわないと、あるボタンを押しても何も起こらない。でも、うんともすんとも言わないのってどうなんだろう。自分の名前呼ばれてるのに返事をしないのと一緒じゃないか。


・数値を入力させるコントロールで、単位書かないと何を入力していいんだか分からないんだけど、自分で使ってみておかしいと思わないのかなー。(←というかこれって開発者の思いこみってけっこうあるな)


・文字列入力欄に「'」を入れたら、案の定SQLのエラーが出てきたぜぇ





「よくありがちなエラー」を狙って意地悪なテストをすると、ぼろぼろとぼろが出てくるんだけど、少なくともユーザさんがついやってしまうような動作ぐらいでエラーになるのはなんとかしないと。


まぁ、つつかれてみて初めて分かることも多いので、その辺日々精進していかなければ。





そして、仕様書に書いてある項目が満足に実装できていないのに、なんで仕様書に書いてもいないプラスアルファの機能を盛り込むことにそんなにこだわるんだろう。





うぉぉぉぉぉぉ、考え方から教え込まないとだめなのかーーーーー。
posted by tsasaki at 23:59| SEライフ

2005年04月01日

記事「デスマーチを止める進ちょく管理の現実解」

□「明日からできるプロジェクト管理」(@IT)


見出し「デスマーチを止める進ちょく管理の現実解」に釣られて読んでみた。





すると、こんなことが書いてあるじゃないですか。





引用---


> ■ プロジェクトマネージャ石出さんの悩み


> 「部長には順調ですと報告しているものの、90%終わっていますと報告を受けてから2週間も状況が変わらない。決して、チームのみんながサボっているわけではないのは自分がよく知っている。むしろよく頑張ってくれていると思う。ただ、(作業が)いつ終わるか聞くと3日後と答えが返ってくる。3日後に聞いてもやはり3日後だという。状況を聞けば確かにやむを得ないと思うのだが、いつ終わるか分からず計画からの乖離も大きくなると、何が終わって何が終わっていないかも分からなくなってくる……」。





まさにそのものずばりの現象を体験している。


自分でも、進捗が80%、90%になってからそこに費やしたのと同じだけの工数をつぎ込んでしまうこともよくやった。プロジェクトによっては今でもある。


で、現在僕がスケジュール管理等をやっているプロジェクトでも本当に上記のような状態で、いつ終わるかと尋ねると毎日毎日エンドが変わる。


僕が見積もったスケジュールで出来そうになかったら、自分で計画出してよ、というといつまで経っても計画も成果物も出てこない。


んー。どうしたらいいんでしょうか。





SEやPGなどの技術職だけじゃなくて、事務職、一般職でもそうだと思うんだけど、自分がやるべき作業に対して見積を立ててそれに対してじゃあ実績とか進捗はどのくらいで、仕事が進んでるとか遅れてるとか判断するのが当たり前なんじゃないかと思うんだけど、話に聞くとそれが出来ない人がやっぱりどこの職場にもいるみたいです。





まあ、問題はそれだけじゃないんだろうだけど。


後で追記〜。(予定)





---


あまり関係はないけど


□ マルチタスク人間は効率がいいか?(スラッシュドットジャパン)


そしてその元記事。


□ マルチタスクで人間の知力が低下する?--情報化時代のアイロニー(CNET Japan)


けっこう興味深い。


というか、個人的には「その通り」。
posted by tsasaki at 13:06| SEライフ

2005年03月24日

突然、大フィーバー

この業界、珍しいことではないが、突然、システムが火を噴いた。


といっても、PCが燃えたわけではない。システムにとんでもないバグが見つかって一刻も早く直さなきゃいけないって状態に突入したということだ。





あっちの炎が鎮まれば、また別の方から火の手が上がる。


最近そんなのばっかり。急ぎ急ぎでやってるから品質も上がらないんだよ、っと。





昨日の午後から延々と対応して、早30時間以上経過。


出てくる出てくる「いつからあったの?」って感じのバグ。





すまん、リリース当初(3年前)からだ_| ̄|○





1つのバグを追っていったら全部で5つくらい大きなバグが見つかった。


どれも今まで動いていたのが不思議なくらい根本的なバグだった。


いたたたた…。





酒は寝かせることでうまみが増すが、バグも寝かせるとこんなに素敵なことになって返ってくるわけで。





そろそろぐったりしてきた。終わりそうで終わらない。


しかも、他の仕事も遅れるわけで、またずぶずぶと悪い連鎖にはまっていきそうな気配。





何はなくとも、風呂に入りたい。


昨日、皮膚科に行って薬出してもらったのに、風呂に入ってないから塗れないよ@塗り薬。あうー。
posted by tsasaki at 21:12| SEライフ

2005年03月21日

コミュニケーションを取りましょう

休日出勤してまでやる僕の作業は、ソースコードの統合。


開発ソースがバイナリフォーマットのため(テキストベースの言語ではないため)通常のツールは使えず、マージ作業は手作業だ。





今回は、僕がしばらくお客さんのところに詰めていて不具合の修正をやっていて、社内に残ったAさんとBさんには追加機能の開発を進めていてもらっていたんだけど、そのそれぞれの担当部分の統合作業なのである。





僕の担当部分は変更箇所が片手で数える程度の量なので、たいした作業じゃないと思っていたんだけど…。





経緯


1.AさんとBさんにはそれぞれ別の機能の開発を指示(二人ともお互いがやる機能についても理解してもらうため、仕様書は1本にまとめてある)


2.Bさんが休暇の日に、Aさんにソースコードのメンテナンスを指示。作業箇所が膨大なので、翌日からBさんと手分けしてやるように。


3.修正したソースをそれぞれまとめて僕にくれるように





まあ、1のことがあるから、お互いに修正した範囲は分かっているだろうと勝手に思いこんで指示を徹底しなかった僕がバカだったのかもしれません。





結果としては、


・2の作業はなぜかAさんが一人で全てやってしまった


・でもAさんは1でのBさんの修正分をもらわずに2の作業をやってしまった





そして、Bさんが作業した部分には、修正前の時点から1だけが終わっているものと、2だけが終わっているものの二通りのソースコードが出来てしまった。





開発ツールの特性上、二人が同じソースコードをいじってしまうと統合作業が大変になるため、お互いの作業範囲を明確にして自分の担当以外でも誰がどこを担当するのかを通知はしてきた。


だから、あとはちゃんとコミュニケーションを取りさえすればこういうことは防げるはずなのになー。


そもそも、なんで二人で分担してくださいと指示した作業をAさん一人でやっているのかなー。


何か考えがあってそうしたのならいいんだけど、それならちゃんとBさんから最新のソースをもらうか、そうじゃなければBさんが作業中の部分だけはBさんに任せるとか、そういうことが出来なかったのかな。





いまやバージョン管理ツールで、ちょいとコマンド投げれば最新のソースコードが手元に揃うので、「他の開発者に最新のソースがないか確認する」という原始的なことはしないのかもしれないけど、ツールを使おうが使わなかろうと開発者同士、ミスを未然に防ぐためにコミュニケーションを取るのはあたりまえの話なんじゃないの。





ってことを、僕は半年くらいAさんには教えてきたつもりだったんだけど(それこそ、作業がロールバックするとどれだけ損をするかとかも含めて)、時たまこういう初歩的なミスが生まれてしまうんである。


どうしたもんかね。





僕の教え方が悪いのかも_| ̄|○


これが教師とかだったら「指導力不足」とか言って再研修に送り出されたりするんでしょうか。





人間、同じ過ちを繰り返すのは恐ろしく非効率です。


コミュニケーション、ちゃんと取りましょう。


To 自分を含めた全ての技術者さん
posted by tsasaki at 17:20| SEライフ

2005年02月01日

鞭の使いどころ

プロジェクトメンバが出来てから、飴の使いどころと鞭の使いどころはなかなか難しいものだなぁ、とつくづく思う。


ソロ活動の時期も挟むけど、僕が指示を出して作業をしてもらう人がついてから2年になる。


良いところがあれば誉めるし、悪いところがあれば注意なり叱咤なりしなければならない。しかし、これがなかなか難しい。





昨日も、朝からお客様に手厳しいメールを頂き、慌てて社内の開発スタッフにメールを出した。


お客様の指摘としては、「何回直してもらってもまだミスがある。もう少し考えて納品してくれ」というもの。僕が試験をする時間を十分に取ることが出来たら問題はこれほどまでに大きくならずに済んだのだろうけど、本気でそんな余裕がなかったので、開発スタッフにもうそろそろ笑って済まされる話じゃなくなったから徹底して試験してくれとお願いしてやってもらったのに、まだこういうメールをもらってしまうのである。(根本的にやり方がまずいのは分かっているのだけど)





とりあえず、もう本気で不信感を抱かれていてやばい状態であることを前置きし、これまでの方法じゃだめだと思い別の試験の仕方を指示する。煽られているからか、自分で読み返してみても棘のあるメールになってしまった。(自分自分、そのスタッフに同じ注意を何度もしていることも手伝ったのであるが)





しかし、いくらお客様に「今回作成しているものは重要なデータであり、間違いがあれば最悪、損害賠償請求にも発展しかねない」と言われたからといって、それをそのまま開発スタッフに投げることはなかったんだと後悔した。


午前中から賠償うんぬんとかそんなヘヴィな話をされたら(いくら自分のミスとは言え)士気はは下がるよなぁ…(実際どうかは分からないけど) そういう「最悪のケース」の話は自分のところまでで止めておいて、あとはいかにもう少し頑張って作業をしなければいけないのかだけを伝えれば良かったのだ。





びしっと言うときは言って、気を引き締めてもらわなくちゃならない。


でも、やっぱり物は言い様、なんだよなー。





こういう脅し文句みたいな言葉で、危機感をもって頑張れるか、それとも逆にモチベーションが下がってしまうのか、それは人それぞれだとは思うけど、もう少し状況を見極めたいものです。





教育の分野でも、「誉められて伸びる子」と「叱られて伸びる子」ってよく聞くけどこれって大人になってもたぶんそうなんだろうな。


僕はどっちの要素もあるなぁ。誉められれば(おだてられれば?)なんでも出来る気がするし、逆に、自分でもどうかなと思っている部分については叱られたい(叱ってそれがやっぱり間違いなんだと気付きたい)、というのはあるかも。(Mっ気ありですか、そうですかそうですか)





一緒に仕事をするメンバがどういうタイプの人間で、どうすればその人の能力や効率を最大限に引き出せるのか、興味は尽きません。





この辺についても、日々精進ですな。
posted by tsasaki at 02:33| SEライフ

2005年01月29日

デファクトスタンダード

仕様として明確になってなくても、Windowsで出来ることが、自分が作ったソフトでは出来ないとなると「なんかこれおかしくね?」と言われる。


「自分で使ってみて使いづらくないの?」と言われると凹むわけだが、いや、使いづらいんですけどあの工数じゃ無理ですよ、とか、だってそんな要求出てなかったじゃーん、とか言いたいんですが、いい加減いい大人がそんなコドモみたいなことは言っちゃいけない。





やっぱり良くも悪くもWindowsがデファクトスタンダードになっている感がある。


お客様が普段使っているのはWindowsであり、Wordであり、Excelであり、Internet Explorerであるわけだから、どうしてもそれらで出来ることは「出来て当たり前」という認識があるようだ。





Ctrl+Cで選択文字列をコピーすれば、Ctrl+Vでメモ帳に貼り付けられる、といった基本的なものから、設定ダイアログは「登録」ってボタンを押すと「登録した上でダイアログを閉じる」という非常に細かい動作までも「標準実装」を要求されるのだ。





僕が普段使っているものもWindowsであり、Wordであり、Excelであり、Internet Explorerであるわけだから、「普通こんな動きしないよね?」とか「これって、使いづらいよね?」とか言われたら確かにそうだと頷くしかないのである。





ところが、ソフトウエア開発の業界では(というか、うちの会社では)なかなかそういう認識が定着しない。それどころか「要求仕様に無いから」とか「やるのであれば機能追加で…」な〜んていうスタンスのほうが多いのではなかろうか?


なかなかユーザとベンダの意識が合致しない業界なのだ。


ソフトウエア業界っていうのはある意味サービス業だと思う。しかし、だとしたらそのサービスの品質っていうのははっきり言って数あるサービス業の中でも最低クラスだと思う。お役所の自称サービスといい勝負である。





理由のひとつは分かり切っている。


開発してみると分かることだが、その「普段使っているソフトの動作」を再現しようとすると、いろいろと面倒なのだ。


開発環境にもよるが、現在僕が使っている開発環境の一つには、複数列リストボックスと呼ばれる部品に「ソート」機能がついていないものがあり、「ヘッダ行をクリックするとその項目でソート(しかもクリックするごとに昇順と降順を入れ替える)」という機能を実装するのに丸1日かかることがある。そういった手間とかを考えたら「Windowsではあたりまえの動作でも、ソフトで実装するのはタダじゃない」という考え方になってしまってもおかしくない。





しかしユーザが求めているのは案外「あって当然」の機能だったりする。ユーザからしたら、他のソフトで出来ることが出来ないというのは「バグ」以外の何でもないのだ。


「要求に無いから作ってません」というベンダと「そんなの言わなくても付けるのが当然だろ(Windowsでは出来るんだから)」というユーザの温度差は相当なものだと思う。僕はベンダ側にいるからユーザ側のそういう思想に対して「んな無茶な」と思ったりするのだが、確かに「あって当然の機能を、言われてないから付けない」というのはぼったくり行為に近くて、技術屋としてそれでいいのか?と感じさえもする。





事実、「その辺のところをこの金額で吸収してもらえないようなら、あなたのところの単価は高いですよ」というニュアンスでちくりと言われたことがある。


その通りなのだ。


別のお客様に「別の協力会社では、本当に言われたことだけをやる会社で、あなたの会社よりン十万円安いです」と聞いたことがあり、確かに「言われた機能しか作らない」のならうちの会社の単価は高いなと思ったことがある。





正直なところ、うちの会社には僕も含めて、システム開発を勉強してから会社に入ったわけじゃない社員が多くいるので、前述のような「サービス」を提供することはなかなか難しいかもしれない。


でもそういう方向に持って行かないと、今の若い世代が(技術者として)会社の中核になっていったときに非常にまずいのではないかという危機感を覚えている。


システムの付加価値がどうのこうのと言っている場合じゃない。ユーザにとって本当に便利なことを日々研究していかなければ。





コントロールひとつの動きをとってみても「結果として出来てるからOK」ではきっと済ませちゃいけないんだろうなぁ。


その辺の技術的な意見交換が積極的にできるような組織でありたいですねぇ。


管理職とかリーダーシップを取るとかには興味がないし自分をその器とも思わない(というと、大学で学祭の実行委員長やってたのは何だったの?と言われそうだけど)。やるからには自分が出来ることを突き詰めたい。





うーん。課題は山積みだな。
posted by tsasaki at 12:51| SEライフ

2005年01月24日

やっぱり技術者として幸せになりたいわけで。(2)

というわけで、前回の続きであります。


□ やっぱり技術者として幸せになりたいわけで。





さて、前回は僕がかなり危険な案件に取りかかっているというところで話が終わったわけだが。(というか脱線したわけだが)


今日もとりあえず、お客さまに暗に釘を刺されてきました。「失敗できない」と。これでこけたら本気で出入り禁止になるかもしれません。ぐふぉ。





もともと、スケジュールとしては同じお客さんの別の案件を進める手筈だったのだが、そうも言っていられない程の案件なのである。なんせエンドユーザが某大手自動車メーカの品質検査や性能検査を行うところ。下手なシステムを納めたらM菱自動車みたいなことになりかねない。





そんなわけで、「今かかっているプロジェクトを止めてまで」お客様の監視の中で作業をすることになったわけです。正確には僕がソフトの開発、お客様がハードの開発。今回はかなり要求と品質チェックが厳しい。ただ、その分、今まで僕が手がけたシステムのどれよりも要求が明確になっているってのはあるけど。


シビアだけどやりがいはあるかもしれない。





僕がそんな状態になるものだから、今まで3人(+α)体制で開発していたプロジェクトは社内に残る二人の中国人に任せることになるわけだ。


これまでの開発の実績から、お客様も僕を欠いた場合の進捗は期待していないようで、「少しでも進めておいてくれればいい」的な雰囲気なのである。(実際、僕自身それは言われて当然と思っているのだが、やはりお客様に技量を見抜かれてしまうのは、ソフトウエア開発のプロフェッショナルとしては哀しいし、恥ずかしいことだ)





普通の技術者ならこの時点でプライドはズタズタになるわけで。


僕も、こうなる前に二人を教育できなかったこと、そして僕自身の技量の足りなさに腹も立ったりする。メンバの力量の不足分は、本来なら僕がカバーしなければならなかったはずなのに、それが出来なかったのはすごく悔しいし、何よりもあれだけ時間を費やして、休み無く働いても結果がついてこないことは僕自身とても情けない。





ただ、逆にこれはチャンスとも考えられる。


二人に再度勉強してもらう時間が取れるというもの。


早速、二人のうちうちの社員の方を呼んで打合せ。(もう一人は協力会社)





とにかく、今かかっているプロジェクトの仕様を徹底的に読み直すこと、また、使用している開発環境のさらなる理解の為にそのトレーニングに行くことを指示する。彼の日本語能力はまだ充分とは言えないあたりに一抹の不安はあるが、もういい加減日本語をネックにして欲しくない。彼がどう考えているかは分からないが、折角日本で働いているんだし、他の日本人に負けないくらいの仕事をして欲しい。そう思っている。





これが今のプロジェクトを今後少しでも円滑に進める為の策。


正直に、お客様から今「進捗」と「品質」の面でクレームを受けていることを伝え、もうこれ以上失敗はできないというプレッシャーをかける。とにかく、これが功を奏すかどうかは別にして、もう少し危機感を持ってもらいたかった。技術者として今のままでいいのか、という思いもある。どんなに難しい業務についても、結果を残せなければ評価につながらない。技術者だからやはり成果を出してそれを評価して欲しいと僕は思っている。


「開発速度」と「品質」はストイックに(?)追い求めてより良い“商品”を提供しなければいけないのは、どんな技術者でも同じだと思う。








だけど、彼が本当は別の位置で活躍したいということを僕は知っている。


彼は本来はJavaをやりたくてうちの会社に中途で入ってきたのであるし、彼が今いちばん力を発揮できるのはJavaというフィールドではないかと思う。


何より、興味の向くもののほうが誰だって力を注ぎやすい。





だから打合せの席でこういう話をした。


とにかく、今スケジュールとして入れている分は最後までやってほしい。もしそれが終わったときに、本当に自分がやりたいことがあるのなら上司に相談するべきだと。


やっぱり、自分が不得手なことを続けて思うように成果が出せずに評価を下げるより、自分が得意とする分野で成果を出して評価をもらった方が後々自分のためになるのではないかと思う。





もちろん、今の仕事が出来ないから(あるいは嫌だから)別な仕事に変えてくれと言えば、それは単なる我が儘だと捉えられるかもしれない。


やりたくてもその仕事が出来ない人は大勢いる。


特にうちの会社は、「これからはデザインに力を入れていく」と言ってその方面の人材を採用しておきながら、仕事がないのか、単に営業活動していないのか、その辺の人材が(デザイン屋としては)宙に浮いている。システム開発も出来てデザインも出来る、そんな人材がいれば得するに違いない。だけど、それはあまりにも酷だ。何よりデザイン関係を手がけられる人材のスキルが上がらないし、そんな状態でいざデザイン関係の大型案件とかを受注したとしてうまく機能するのか?(とにかく、いろんな意味で言っていることとやっていることが違うのだ、うちの会社は)





でも、(逆に、だからこそ、)自分が伸ばしたいスキルを伸ばすことは必要じゃないのかな。


自分が本当にやりたい技術を伸ばしてそれを評価してもらうのが、技術者としての本懐ではなかろうか。(もちろんそれだけが全てじゃないってことは分かっているけれど。)





せっかくだからさ、やっぱり同じ技術者同士Win-Winの関係になりたいわけですよ。


やるからには、僕は僕と一緒に仕事をする人みんなに幸せになって欲しいわけですよ。


だから、その辺の意図を伝えて彼には選んでもらうことにした。


技術者として本当に自己実現できる道を。





真面目な話、僕は彼を僕の片腕として育てようとしていたから、もし僕のプロジェクトから離れるとしたら寂しいことだが、やっぱりやりたいことをやれるのがいちばんいい。





まあ、実際居なくなってしまったら僕はまた大変になるわけだけど。


(新しくスタッフを補充するにしてもまた教育からやり直しなわけだし)


自己犠牲が過ぎるのかも。





佐祐理「舞も…tsasakiさんも…自己犠牲が過ぎます」





佐祐理さん、萌えっ
posted by tsasaki at 23:46| SEライフ

2005年01月23日

「C++の設計と進化」

「C++の設計と進化」


Bjarne Stroustrup・著/岩谷 宏・翻訳(ソフトバンクパブリッシング)


某MLで紹介されていたので気にはなっていたんですが、目次を見て面白そうだったので購入しました。


C++の設計と進化





一応C++技術者としては、けっこうためになりそうだったので。


プログラムの指南書というよりは、どちらかというとC++という言語の思想について語られているようで、入門レベルから上級レベルまでどんなレベルの技術者にとっても役立つような内容かと思いました。





さて、あとはこの本を読む時間があるかどうかだが…。





□ Amazon.co.jp





□ SOFTBANK Publishing
posted by tsasaki at 23:59| SEライフ

2005年01月13日

やっぱり技術者として幸せになりたいわけで。

さて、今週から新しい案件に取りかかっている。


新しいと言っても、昨年担当したシステムのカスタマイズである。


ところが、これがお客様に「納期遅れやバグが出たりしたら、ここ(お客様の部署)の存続自体が危ない」とまで言わしめるほどの危険な案件。なんでも、部署の他のシステムでもいろいろ問題が起きているらしく「納期厳守。品質徹底」を念押しされた。(まあ、その問題にうちの会社がけっこう絡んでいるってのはおそらく正解だろう…。)


そのため、僕は来週から当面お客様のところで半ば監禁状態で作業なわけです。


このプロジェクトでこけたらたぶんもう仕事もらえないかも。(もらえない方が幸せかもしれないけど(爆))





実際、これが本気でこけたら、最悪うちの会社、お客様のところに出入り禁止とかになったりして。とか考えたりしてけっこうびくびくしております。





こんなにびくびくするのは、新人の頃、先輩社員と二人でお客様のところに詰めて作業していたときに、先輩社員がよく居眠りをする人だったんだけど、それがお客様に見つかって「あなたのところの社員は作業中に居眠りをしている姿が多々見受けられ、『なんでそんな外注を使っているのか』と部署内で問題になっています」というようなメールがお客様からうちの上司に飛んだとき以来である。あの時は焦った。(自分も居眠りしていなかったわけじゃなかったので余計焦った。)





まあ、その人もアトピーとかが夜眠れないほどひどいことがあるっていう、身体上の都合があったわけなんだけど、お客様からしたら居眠りしていることには変わりないわけで。例えば、これが電車の運転士とかだったら大問題なわけですよ。人を乗せている(人の命を預かっている)わけだし。会社の信用問題になっちゃうわけです。


うちの会社はシステム開発が主な仕事だから、人命に関わったりするようなことはまず無いけど、それでも、やっぱり自分の席で居眠りするのは良くないよな。と、僕はこの一件がトラウマになって、それ以来ほとんど居眠りしてません。ほとんど、というのはときどき5秒とか意識を失ったりすることがあるから(汗





こういうときは、かつてのY印乳業の社長みたいに「寝てないんだよ!」と逆ギレしたくなりますが、さすがに大人としてそれはどうかと思うので(笑)


実際、この一件以来、僕の居眠り体質も改善したようなので、要は気の持ちよう、というか、単に緊張感が足りなかっただけかと。(もしくは本気でトラウマになってるか。) 今ではたとえ徹夜しようとも、平均3時間睡眠の日が続こうともデスクで居眠りはしなくなった。やればできるじゃんか。(←そもそも基準が低すぎます)





幸いお客様からもオフレコ的に「どうしても眠いときはあるので、そういうときはトイレに行って寝てくれば問題ないです。見えるところで寝るのだけはやめてくれ」ということを言われたので、客先で作業中にどうしても眠くなったときはトイレに行くようにしています。(しかし、客先のトイレは基本的にこまめに消灯なので、男子便所で個室に入っていると個室に居ることに気付かれずにうっかり電気を消されてしまうことがありますw これはこれでトラウマになるんだなw)





以前、取締役のNさんからも「寝ている奴は絶対に許すな」とのお達しを受けているので、僕のプロジェクトでは居眠り禁止です。(Nさんも居眠りに何かトラウマがあるらしい…)


その代わり、適度な気晴らしは自由です。あー、将来的に裁量労働制にならないかなー。(とあるお客様に言わせれば、「裁量労働制も問題ありだよー」とのことですが。要は結果を出せていないと自分が思えば、いくら働いていても超過勤務時間とか付けづらいらしい)





「居眠り禁止」とか言って、実は今の上司、たまに居眠りしています(w


いや、あれは、深く考え込んでいるだけなのかも…。


その辺はいまだに謎。








# 実際、僕は僕のことを叱ってくれるような先輩社員の下についたことがなかったので、いきなりお客様に叱られたのは相当こたえた。


# 社内で叱られているうちが華なんだな、と思った。





やっぱり、どんな理由があろうと、やっちゃいけないことについてはそれが一緒のプロジェクトのメンバだろうと、同期だろうと、後輩だろうと、新人だろうと、上司だろうと、社長だろうと言わなきゃいかんと思うわけです。


そういうことをやらない組織だとN○Kみたいなことが起こっちゃうんじゃないかと。





そうは言いながら、僕もやっちゃいけないこととかけっこうやっているので(コラ)、見かけたら叱ってください。叱られたい。そんな、年頃。(←えぇ?)





# 組織ってのは馴れ合いじゃないから、組織のメンバがそれぞれ人間としての鑑であるべきかと思う(疲れない程度にね)。それが理想の組織かな。そしたら、組織って勝手に成長していくんじゃないかな。(理想論だけど)


# いい組織に属することで人間としても成長できそうな気がする。組織の成長が個人の成長につながるのはいいね。(これも理想論)





でぇ!!


話が大幅にずれてしまったが、要はそのお客様に勤務態度のことでクレームをもらったという一件ぐらい、今のプロジェクトにはびくびくしているという話です。下手なことはできんな、と。





んで、本当は、その新しいプロジェクトの話から本題である「やっぱり技術者として幸せになりたいわけで。」という話に展開する予定だったんだけど、脱線しすぎたのでまたの機会に書くことにします。





気が向いたら…。
posted by tsasaki at 23:35| SEライフ

2004年12月07日

Windowsコネタ(2) - コマンドプロンプト関連

客先で作業をしていて、会社のファイルサーバ内のとあるディレクトリの内容一覧が欲しかったので、会社に居る人に「そのディレクトリをコマンドプロンプトでdirした結果を送って下さい」とお願いしたら、普通に「エクスプローラで表示した画面をキャプチャしたBMPファイル」が送られてきました。


しかも、rar圧縮……。解凍できねぇよ!(結局、窓の杜からLhaplusをダウンロードしました)





コマンドプロンプトでdir使ったことないのかなぁ…。





dir : ディレクトリの内容をリスト(unixで言うところのlsかな)





(入力例)


C:\temp>dir






(出力結果)


ドライブ C のボリューム ラベルは Windows2000 です


ボリューム シリアル番号は FC29-D047 です





C:\temp のディレクトリ





2004/09/14 14:05 <DIR> .


2004/09/14 14:05 <DIR> ..


0 個のファイル 0 バイト


2 個のディレクトリ 54,504,820,736 バイトの空き領域



で、この出力結果を任意のテキストファイルに出力する方法があって、


C:\temp>dir > C:\result.txt



これで、dirの結果をファイルに残せます。





ちなみに、上記の場合は、ファイルは置換になりますが、


C:\temp>dir >> C:\result.txt



こうすると、追記モードで出力できます。





知らなくても困らないけど、知っておくと遙かに便利ですょ。
posted by tsasaki at 22:39| SEライフ

2004年12月04日

Windowsコネタ

僕は、PCをキーボードだけで操作できることにそれほど美学を感じないんだけど、知っていた方が便利なショートカットキーがあるので紹介。


Windows2000/XPで「タスクマネージャ」を呼び出すときにCtrl+Alt+Deleteを押す人が多いような気がするんだけど、「タスクマネージャ」を表示するだけならCtrl+Shift+Escの方が便利よ。



posted by tsasaki at 05:05| SEライフ

2004年11月27日

貧弱コミュニケーション

今、僕が抱えているプロジェクトで、中国の人(広島とかじゃなくて)2人に開発をしてもらっているものがある。


一人は、うちの会社に中途で今年入った社員。経験年数は3年だけど、前の職場には中国人が多くいたらしく、日本語はあまりうまくない。


もう一人は、北京の協力会社から常駐という形で来ている。こちらは経験5年で、日本向けシステムも経験あるそうなんだけど、日本語は読み書きがまあまあ出来るが、会話となると少し難しい感じ。


で、僕はというと、日本語はまあ問題ない(たぶん)。しかし、英語がへたれだし、中国語は当然話せないし、じゃあ、やっぱり日本語中心でコミュニケーションを取るしかないわけだ。





んまあ、英語も話そうと思えば話せるのかもしれないけど、日本人らしく(?)発音が怪しいのと、実際、そんなにまじめに勉強してきたわけでもないので、英語で意思疎通を図るのは無理ってもんですよ。というか、効率が悪い。





もちろん、時間があったら英語も、この際だから中国語も勉強したいんだけど。





もともと、意思疎通に時間を掛けられるほど余裕があるプロジェクトじゃないんですね、実際。だから人が欲しいと言っているわけで。


これは日本企業(ってか、日本企業で働く僕)の傲慢かもしれないけど、「ローマに入れば、ローマに従え」。つまり、まともなコミュニケーションができるレベルまで日本語を使えて欲しいわけです。で、基本は日本語で、わかりにくいところを補助的に英語とか中国語を使えるようになれればそれがベストかな、と思います。





こんな状態なもんだから、つい先日も、ソフトの仕様に関する質問を受けて説明を聞いたんだけど、まず、「実際のプログラム」と「本人の説明」が違う…。





実際のプログラムを見ながら、一つずつ確認していくんだけど、そうすると本来のプログラムに沿った説明になる。





ん? これは、単純に日本語で説明ができていないだけなのかなー。


それとも、本人がちゃんと理解していないだけなのかなー。


どっちにしろ、開発終盤でこれは怖いぞ、と。





なんつー貧弱なコミュニケーションなんだ。


って、僕がばりばり英語が話せたら問題なんて無いのか_| ̄|○
posted by tsasaki at 11:12| SEライフ

2004年10月22日

えっ!?ラジオボタン制御が出来ないの?

ソフトウエア開発の話。


Windowsプログラミングだと、


たいていの開発環境ってラジオボタンのグループ化が出来て、


何も意識せずに「どれか1つだけを選択」って出来るんだけど、


そのせいなのか、グループ化の概念が無い開発環境で


ラジオボタン風の制御の実装が出来ない…なんて、


それは開発ツールの使い方以前にプログラム論的思考が足らないのでは?


なんて思っちゃいます。





「どれか1つが選択されているのが当たり前」なんだから、


「どれか1つの値が変更された」場合に、


変更前の値と変更後の値のXORを取ってそれを各ボタンの値に戻してあげれば、


「どれか1つだけが選択されている状態になる」でしょっての。





ソフトウエア業界って、


開発ツールを使いこなすだけでプログラマーになれるところが怖いですね。





今やっているのは既製品のカスタマイズなんだけど


既に他の画面で実装しているからそれを参考にしてよって言ったのに


Webからサンプル見つけてきて「こっちの方が簡単ですね」とか言うのでソースを見たら、


だから、それ、実装している処理と全く同じなんですけど。


(というか、オレが参考にしたサンプルだw)





んー。なんだ、この齟齬は。





まるで、プログラム関係のメーリングリストでのやり取りを実体験しているようです。


Q「○○ができないんですー」


A「××すればできますよー」


Q「××じゃなくて○○がしたいんですー」


A「え。だから、××すれば○○するのと同じことでしょ」


Q「Webを検索したらサンプルを見つけたので、それを採用しました(解決)」


A「だから、さっき提示した方法と同じでしょー」





たいていこの手の質問者はプログラマ向きではないので、この業界から早く足を洗った方がこれから先迷惑をかけるであろう多くの人が助かります。


プログラム以前に、日本語(場合によっては英語)の読解力が必要な職業です。





まあ、今一緒に仕事している人、中国の人なんですけどね_| ̄|○


中国語、覚えるか。
posted by tsasaki at 22:13| SEライフ