新しいプロジェクト

最近、まったく日記を書いていなかったが、書く気がまったくしなかったのだ。理由はおそらく、今までのプロジェクトではほぼ自分の考えられる理想的な進め方がされていたような感じがして、それで、問題を感じていなかったので、問題を解決する手段を検討したり、誰かに伝えなければ、などと思うことが無かったのが原因のような気がしている。(営業的には問題はありました。)

さて、久しぶりに日記を書いているのは、実は今年から新しいもうひとつのプロジェクトを掛け持ちで担当することになり、そのプロジェクトがいろいろ問題があると感じているからなのだ。

たとえば会議。会議は大勢を集めて行っているが、実際に参加しているのはそのうちの数名でほかの人はぼやっとしているか、ヒソヒソほかの話をしていたりと、よくある会議のアンチパターンに陥っている。まだ参加して1週間もたっていないが、改善したい点はたくさん出てきている。

まだ入ったばかりなので、積極的に改善に乗り出してはいないが、草の根的に徐々にプロジェクトを改善していきたいものだ。

まずはWikiの共有と朝会からはじめてます。

Opera9.60

ブラウザやメーラーは以前からOperaを使用しているのだが、9.5以降、SMTP認証のパスワードが失われてしまうという不具合に悩まされていた。不思議なのは、1回目のメール送信は問題なく行えるのだが、2回目以降はSMTP認証用のパスワードを再入力しないと送信できなかったのだ。(Operaを再起動するとまた1回目だけ送信できる。)

メーラーを変えようかと思っていたが、先日でた9.60で修正されているようだ。(修正履歴には見当たらなかったような気がするのだけど、自分の環境では何度も連続してメール送信ができるようになった。)

JavaScriptでreadonly

JavaScriptでtextフィールドやtextareaフィールドをすべて入力不可にしたい場合がある。その場合、



  <input type=text disabled=true>

とdisabled属性を使うことも可能だが、disabledを指定すると背景色は変更できるが前景色が変更できない。今回、入力画面と参照画面で同じJSPを使用し、参照画面の場合は、textフィールドを背景色を灰色、前景色を黒にしたいという仕様を満たすためには、readOnly属性を使うと良い。

このreadOnly属性はreadonlyではNGでreadOnlyでOが大文字でなければならない。ちょっとハマったので書いておく。

たとえば、入力画面とまったく同じで参照画面を作るときは、



 <body onload="javascript:readOnly()">

として以下のJavaScriptを呼び出すとすべて入力項目が入力不可になるので便利だ。(checkBoxなどは今回は対象外。もちろん、JSPは入力用と参照用で同じにするため、onload部分を入力用と参照用でパラメータを渡すか、function名を変えるかなどの工夫は必要。)





/**

 * すべてのtext, textareaフィールドをreadonlyにする

 * 

 * @return

 */

function readOnly(){

  for(i=0;i

営業と開発

営業と開発リーダーを同じ人間一人で行うというのはどういうものだろう。

状況にもよるが、「聞いていない」とか「そんなことも対応するのか？」という問題がどんどん出てきて来る場合が多い。解釈の仕方によってはどちらにも解釈できる問題は、請負側がかぶるのがやはり常だろう。強行に要件にない、と言い続けることも可能かもしれないが、それでは良好な関係で要件を満たすことはできなくなるし、受注そのものすらなくなってしまうかもしれない。開発側としては、ある程度は意見を言うがそれ以上言うのは逆効果になるので、自重しなくてはならない。そういうときに立場の違う営業がサポートするのが、システム開発をスムーズに進める鍵になるだろう。これを同じ人間が一人でやるのはとても無理がある。もちろん、はじめからお客様と面識があり、過去にお付き合いがあれば相手の考えや対応方法がわかるので、一人でもできるかもしれない。しかし初対面のお客様に対して営業役と開発役を一人でこなすことは、それだけでリスクが非常に大きくなる。

沢田マンション

アジャイルプロセス協議会の5周年セミナーに参加してきました。

http://www.agileprocess.jp/modules/eguide/event.php?eid=18

沢田マンションというある意味特殊な状況をIT業界に適用して考えようとしたという点が中々奥深い気がした。IT業界に置き換えれば、

  • 不具合を思いつきで修正する

ということになるだろう。しかし、IT業界ではそれはやってはいけないタブーだったはず。安易にシステムを改造すれば、必ず不整合や不具合が起きるものだ。しかし、なぜそれをIT業界に適用しようと思ったのか。

自分の推論ではあるが、

  • 沢田マンションは現実としてリアルに存在している(ITの理屈が成り立つなら、存在できないはず)

というのが建築からITへの従来のアナロジー以上になんらか考察できる点があるということなのかな、と感じた。実際、思いつきで改築や増築をしていたら、いろいろ問題もおきやすいだろう。たとえば、耐震強度やガス漏れなどそういう点はどう考えたらよいのだろう。セミナーではその点について質問したところ、講師の方からは「リスクは考えていない。問題が起きないのは何故なんでしょうね。」と逆に不思議がられていた。しかし、「住んでいる人はある意味特殊です。」という言葉を聞いたときに、

  • 「求められている品質でサービスを提供している」

のではないか、と感じた。システムでも不要なサービスや品質を提供することは多いものだ。実際、沢田マンションの品質を求める人々が多いかというとそうではないだろう。しかし、現実に存在するということは確実にそのサービスを求める需要もあるということだろう。

全国どこにでもあるわけではないのでそれでよいのだろう。

システム開発だって同じように考えれば、同じような品質の需要もあるのだろう。とにかく、この建築をIT業界に当てはめて考えようとしたこと自体がおもしろい発想と感じる。

仕事が無いのに忙しい

保守案件のリーダではあるのだが、今回の保守案件は工数が足りなく、ほぼメンバ一人で対応してもらうことになった。なので、自分はリーダではあるが、未アサインという状況だ。案件自体はいろいろ仕様の不整合や過去の不具合などが明らかになり、かなり厳しい状況ではあるが、なんとかオンスケを保ち、もうすぐ納品できそうだ。

不思議なのは、未アサインであり、実際にプロジェクトにダイレクトにかかわる作業にはあまりタッチしていないのだが、忙しいのだ。まあ、仕様の不整合の確認や過去の不具合のまとめ、そして顧客への問い合わせなど様々な作業が発生している。

もし、自分が本当に未アサインで、この保守案件にかかわっていなかったらどうなるのだろう、と考えてみた。

担当するメンバにもよるだろうが、不整合などには目をつぶり、やはり納品自体は問題なくできるのではないだろうか。

では、自分がいる価値は何なのだろう。おそらく、不整合を不整合としてメンバと共有したり、不具合を不具合としてチーム内で認識する、などということができるかどうかなのだろう。

そういう意味では、最近不整合や過去の不具合に対して、メンバとの会話がかなり多い気がする。もし効率だけを求め一人で作業をしてもらうと、どこかにひずみができる気がする。そういう意味では、自分がいて不整合や不具合の話をメンバとすること自体が重要な気がする。未アサインの自分にも存在価値があるということかもしれない。