なに！？マスタメンテナンスが1日で5本できたって？

　マスタメンテナンスほど時間をかけて作ってはならないものはありません。
（ちなみに、Webシステム。）
1本目はちょっと時間かけてもよいけどそれを真似れば一瞬にして何本も完成するほどにマスタメンテナンス機能の標準化をすれば良いだけです。

　隣の人が1日で5本できたという報告をプロジェクトリーダに報告してリーダは「えぇー」とびっくりしていたけど、「そりゃ、俺が基準になるマスタメンテを作ったんだからそれくらいのスピードでやってもらわないと困るわ」と心の中でつぶやいておきました。

　その隣の人もびっくりしたんじゃないですかね？
どこを触れば良いかがわかったときは、スルスルできるので。
（いや5本ではなくもっと作れるはず。他にもあれば進捗が一気に上る。）


　マスタメンテナンスはそれで良いですが、他の機能はてんでバラバラで作っているのでまとまりがないんだろうと思っています。
　多分モジュール分割の概念がないのか、めんどくさいのかわかりませんがコントローラ内でSQL発行したり共通化できる部分を共通化して外出にしたりすらされていないのを見ると他人事ながら腹が立ってきます。

　でも自分がメンテナンスするわけではないのでほっといていますが。

老婆心ながらリハは必要ですよと言いたい

リリースやデータベースの移行の練習もせずに客先でやるみたいな話し声が聞こえてきて大丈夫か？この人達と他人事ながら心配になった。

客先でのリリースとかの作業は一回以上はリハーサルしないとだよね。

あと、今時点のソースをGitにPushしておいてくださいという声も聞こえてきたけど大丈夫かね？バックアップ場所ではないんですよ。
そのあと誰かに言われたんだと思うけど、「動く時点のものをアップしてください」と言ってました。
（そもそも当たり前にそういう運用をしないとダメなんだけどね）

Gitというかバージョン管理のツールとかあまり使ったことのないチームのようでとっても心配。
他人事ながら…。


メンバーがなんらかの問題点をリーダーに説明してるけど、リーダーは何を言われているか理解できていないと説明をしているメンバーはリーダーが理解できていないことに気づかずに専門的な言葉をならべて喋り続けているのがなんか滑稽な感じ。


多分トラブル。その頃自分はいない。

Googleカレンダーでバグなのか仕様なのか？

Googleカレンダーのバグを発見しました。

2日に渡るカレンダーの設定をして、開始の時間が終了の時間より大きいとカレンダー上に帯がでない。
仕様なのかバグなのかわかりませんが、多分バグ何だと思います。

なぜなら、3日以上だと帯が出るので。

コミットログに。

　今、手伝っているプロジェクトでは、ソース管理にSubversionを使っています。
それはそれで全然問題ないないです。

問題点はそのSubversionにコミットしたときのコメントがすごい。

• 「障害修正(10/18)」
• 何も書いていない

まぁ、その組織の問題なのでなんか言ったところで変わらないと思うし、もう少しで終了なのでなにかをいうつもりもないんですけど。
とても、残念です。
でも、昔から知ってる人で昔々にそのあたりの話しはしたことがあるので言わなくてもいいかなとも思っています。

なぜかっ！
特に困っている様子もないので。

でも、自分のプロジェクトのときは厳しく対応はしてもらいますけどね。

IT技術者の人は（だけではないですが）

　IT技術とか変化が激しかったり、いろいろな技術があって日常業務ではできないようなことを身に着けるためには、長い休みはとても良い時間だと思います。
　日頃の疲れを癒すために過ごすこともとても大切ということも認識しています。

ですが、通常業務中にできないようなことは長期の休みの間にいろいろと学習や挑戦をしたほうが良いと思います。
というか、しなければなりません。

業務時間中に与えられた作業をこなすことが仕事と思っている人は「なぜお金ももらえないことをしなければならないの？」となるかもしれませんが、目先の利益よりももう少し先の利益を考えてもよいのではないかと思います。

新しい技術（自分にとって）を覚えたことによって新しい面白いことができるかもしれませんし、今やっていることが楽になるかもしれません。


まぁ、こんなことはIT技術者だけではなくて全部の仕事に言えることですけどね。

そのツールを使うのはただの手段とはいうが。

　システム開発や管理をする為に有料無料を問わずにいろいろな製品が発表されています。
当然何かの問題を解決する為に開発された製品達ばかりです。

自分たちが抱えている課題を解決するために導入したツールがマッチするととてつもない効果を発揮してくれます。

　ですがマッチしなかったり、どう使っていくかも考えずに導入していくと逆に足を引っ張ってくれるものになります。

　で、よく「ツールを使うことが目的では無いんだっっっ！」と声高々にいう人が居ますが、これは一般的には正解です。間違っているとも言いません。

　ですがなんですよ。
そのツールが自分たちの課題を解決できるものかどうかを評価しているは、「ツールを使うことを目的にする」ということもしないと正しい評価だったり判断ができなくなってしまします。

※ここで間違ってほしくないのは「本来やらなくてはならないことをならなくても良い」ということにはなりません。

新しい何かを導入するときはそれなりのコストを代償として払う必要があるということです。
お金だったり、時間だったり。（一番大きいのは時間だと思いますが）


もし自分が新しいツールを導入しようとした時は、現状(現在のやり方)を維持しながら新しいことも同時にやっていきます(時間というコストを支払っています)。
そうしないと自分のものにならずに一番よくない「使うことが目的」になってしまいます。

よくあるパターンが下請けの仕事をする時にこんなパターンになってしまう場合があります。



ここから現在の自分の状態ですが。

ある会社のプロジェクトに参加していて、プロジェクト管理のツールを使っているのですが、(自分も相手の会社も)初めて使うものです。※全社で同じものを使って管理をしたいそうです。
結局使い方を調査したり、どうやって運用していくかを決めているのは自分なんですよね(自分もそれを使って管理とかをしたいので何の苦でも逆に嬉しい)。
相手の会社の人と話をしていると使い方だけ(それらしい答え)を習得したいらしいです(時間という代償は払わない)。

多分、なぜこういう使い方にしているとかを知らないので全社に展開したあとに最悪の「使うことが目的」みたいになってしまうのではないかと感じています。


まぁ、自分の血肉が強化されていくので問題は無いんですけどね。

AWSで開発してるのになぜ？

　んー。
なぜかわかりませんが、せっかくクラウド上(AWS)でシステム開発をしてるのにその機能を精一杯使って開発をしないのかがわからない。

　サーバの設定を変えてテストをする必要があるようなので新しいサーバを立てて、そこで動作確認をすればいいのに。
　でも、運用しているサーバにちょこちょこと何かを設定して頃合いを見て再起動とかしようとしているらしい。

　もしうまく行かなかったらどうするつもりんなんだろう？（まぁ、対して使われていない管理サーバだけど）

　もう、効率悪いというか、なにも考えられないというとか、外から見ていてイライラするっす！


EC2 → AMI → テスト用の新しいEC2でテストする。
とすればいいだけなんだけど？

　うーん、何もしらな過ぎませんか？なんか、勉強してるんだよね？

だめだ、考えるだけでイライラする。

「電子申請サポートシステム for Wordアドイン」って結構ずさん？

　陸上無選協会は、無線機の免許の為の申請書を「電子申請サポートシステム for Wordアドイン」というのを使ってシステム化しやすいようにしてくれています。
利用者としてはとてもありがたいと思っています。

ページと項目毎のフィールドに名前を付けてあるのでシステムで管理しているデータをテキストファイルに出力することで簡単に連携できます。
システムで出力したテキストファイルを提供されているテンプレートのWord文書に読み込ませるとそのフィールドに値を設定してくれます。

ですが、ですがですよ。
フォーマットによっては恐らく作りが良くないんでしょうけど、テキストファイルに項目名が存在しないと全然関係の内フィールドの値を設定してくれます。

例えば、「無線設備の設置場所4」というキー項目がないと勝手に「かがみ申請者名前フリガナ」という違う項目の値を設定してくれます。

「無線設備の設置場所4」というキー項目を準備すれば問題無いんですけどね。

でも作る側としては出力するテキストデータを共通化して楽チンしようしているので項目は無視してほしいわけですよ。

もうちょっと使い勝手よくに作って欲しいです。

または、フォーマットのメンテナンスの仕事受けますけどね。

「取り急ぎ」ということば禁止令

メールの「取り急ぎ」という言葉を廃止してほしい。

その「取り急ぎ」の後のフォローとかいつ正式にとかのことが書いてあればまだいいんだけど大抵は書いてない。

何かの作業をお願いした時に目についたとこだけ作業して「とりあえず返しておけ」程度。
全部やってから返してほしいのよ。か、いつ正式なのを出すかの明記を。

この言葉を書いて終わるのは大抵「ちょっとめんどくさいから後回しにします。でも、言われなかったらやらないけどね。ははっ。」という言葉が見え隠れしてるんですよ。

こういう人と何かをつくりあげようとするとこんなのばっかりでやり直しが繰り返される。

通常の自分の仕事もやり直しばっかりしてるんだろうなと想像される。

で、叱られてもその場では反省したようなふりをするし。

ダメなんだよ、話になりません。

Oracleでエラーが出たから教えてほしいといわれ

　もうちょっと(いや、もっと！)、調べることを覚えたらどう？

 VB.NETのアプリケーションでストアドプロシージャを呼び出したらあるエラーが出ているようです。
なんかすごく奥が深い話でヒントがほしいのかと思ったら、返却されているエラーコードは何を意味するものかすら調べないで答えだけほしかったようです。

　「まずは、エラーコードが何を意味するのから調べてください」と言ったら、Google検索でOracleのエラーコード検索しました。
　まぁ、エラーコードの意味を知るためには、これが一番手っ取り早い探し方だと思うので良いと思います。

　で、検索結果をさーっとみて、適当なリンクをクリックして中をチラ見してました。
「なんかよくわからない」と発しましたよ。

「はぁ…、まずは、エラーコードが何を意味するかを調べてから、解決方法を探ればいいんじゃないですか？」と答えたあげましたよ。

何なんだろ？自分が何を探しているのかわからない状態で答えだけを求めようとする姿勢にちょっと腹がたちました(自分の中で)。

　エラーコード見たら、「更新できないビューを更新しようとしている」というものででしたので、ストアドプロシージャを見てみたらどうですか？とこれで終わりです。
　ストアドプロシージャを見てみたら、サマっているビューを更新していたそうです(Oracleの環境を作るのをミスっていただけ)


　もう、超ベテランなんだから答えだけ聞きたがるんじゃなくてもうちょっと、何が問題かを考える力を付けてほしいものですよっ。
　超若手だったらどういう手順で調べていくのかはちゃんと教えますけどね。


まずは、エラーコードの意味を把握してから調べましょうね。

急ぎだったのか、実績が欲しかったのか？

　お客さんからの要望なので対応してほしいと言われて、内容を詰めて対応してリリースまでしたのに受け入れテストを2Wたってもやっていないとはどういうことでしょうか？

　もし、本番ギリギリで操作確認して思ったのと違うの言われたらなんで2Wもそのままにしていたのか？とか急に修正してくれと言われてもできるわけがないと突っ返そうか？

　これがエンドユーザでシステム開発というのを分からないのだったらまだわかるが（その前に、予め釘は刺しておきますが）一応システム開発のことを知っている人なのに大丈夫か？
　忙しいとは言っているけど、こういったのが続いているのでやる気が無いのでしょう。

ざんねーん、早く変わってもらったら？どう？
無理だったら、ヤメれば？楽になるよ。

マネジメント2人体制って…。

　マネジメント2人＋サポート1人＋担当1人って、どんな大掛かり？

マネジメント2人で何がマネジメントのするのか不思議でならない。きっと、相手任せになる。
サポートって、何をサポートする？多分他人事になる。

まぁ、意図がわからないのでど表面的なことにたいしての批判みたいなのになってしまいますが…。

新しいことを聞きたがるのはいいが

　知らない情報を聞きたがるのはいいですが、それを聞きたいだけの人は困る。
無いよりあったほうが良い理論では、教える方、聞く方はただの時間の無駄です。

聞きたい方は、聞いた時点でわかった気分になるだけで聞いたことを深掘りすることもなく忘れていく。

教えた方は、聞いたほうのなにか改善がされるのだったら良いが、聞きっぱなしでそのままになるので話損の感じになる。ひどくなると、同じことをまた聞かれたり、自分で深掘りして理解しないから使えない情報として片付ける。


自分が知らない情報を得たら、新しいことの入口に立たせてもらったと思ってそこから自分で歩き出さないと何も良いことはありません。
ただ情報が古くなっていくだけです。

皆さん気をつけましょう。新しい情報も教えてもらえなくなりますよ。

セミナーってそういう認識なんですよね

　先日、東京の某所でITのサービスのセミナーを受けてきました。
無料なんですが、中の人も出てきて話していたのでとても有意義でした。

　その時に、前の会社の元上司から電話が来て「今、東京なんですよー」って言ったら「遊びか？」って言われたんで「いや、セミナーに参加しにきてます」って言ったら、「なんだ、やっぱり遊びか」と言われました。

　うーん、セミナーと言うのはそういう認識なんですね。
内容も聞かずにそういう判断をするということは、自分が所属している会社でも何かのセミナーに出席するときは、仕事の息抜き程度にしか考えていないんでしょうね。
あと、自分の会社で何かのセミナーを開催するときもその程度で考えているのでしょうかね？
大丈夫か？って思ってしまいます。他人事ながら。

思い出すといろんなことをいう上司が居ました。

• 楽しく仕事をしていると遊んでいると思う人
  仕事はつまらなくて辛いものという考えなんでしょう。
• 趣味的なものだったら稟議は通さない（必要だから稟議書いてるんですが…）
  なんの稟議だったかはもう既に忘れてしまいましたが。
• 給料もらいながら勉強できていいなー。
  いやいや、それをただの作業にしてしまうか、覚えて次に活かそうとするとはその人次第なんだけど。
• 周りの人が技術的なことはあいつに聞けになっている人に対して答えられないとこを捕まえて勝ち誇る人
  技術的なことはなんでも分かると自分で言っているんだったらそうだけど周りがそう言ってるだけなんですけどね。
• セミナーの感想を聞かれて良くなかったというと、「まぁ、息抜きさせようと思って行かせた」とかいう人
  結局、セミナーを開くんだけど出席者居ませんかというのを会社の付き合いで行かされただけみたいでした。それもセミナーの体をなしてなかった。参加者は自分ひとりだけだったし…。

自分の面子とか、主観で組織を動かすとよくないよ。

話はズレズレでした…。

ノベルティの言い間違い

　あるイベントの出店者側の言い間違いが面白かった

ノベルティグッズを配っているので、そういうと思ったのでしょうが、大きい声で

「アメニティ」

と叫んでました。

ちょっと、寒くなりました。

データフォーマットって大事だよという話

　残念なことは続くよねー。
　移行データを作って送ってもらったのはいいのですが、フォーマットが違うため使うことができないです。
　初めて送ってきたんだったら何かの間違いと思って何も思わずに、直してくださいと言うんですが、それが何回も続くと大丈夫かこの人？ってなってしまいます。
　前回も違っていてそれを指摘すると、自分の責任ではなく業者の問題とかって言って、逆に叱られたんですよね。でも、そんなのには負けずに言い返しますけどね。

　本当の期限が迫っているので、それまで送られてくればいいんですが…。

もう、リリースを何回も伸ばしてるんだからこれが最後だろうな。

永久にリリースできないシステムのはなし

　去年の今頃から始まったプロジェクトを未だにやっています。
当初のリリースは、10月だったのですが、無駄にののびのびになってまだ、要望が上がってきています。

　そもそも、設計というものをせずに現行の機能をみてつくり始めたのでこうなるのは予想がつきましたが。
　（内心もっと、積んでおけばよかったと思っています。）

　テストと称してユーザに運用ができるように操作指導をしているようなのですが、その時にあがってるああしたい、こうしたいというを全て課題表に上げているようなのです。
　アホらしくて笑いが出てしまいます。

　まぁ、ユーザは言えばやってくれると思っているようですが、こっちはただではやりません。
終わるまでまたは、対応する要望をやった分の作業料は、間に入ってアホな動きをしている人に請求するつもりです。

　数が減らない限り運用なんて始めたくないし、させません。

アリバイ工作的な作業をする人はバイバイ

　アリバイ作り的な仕事の仕方をする人は、去ってほしい。

ここでいうアリバイとは、「ある作業をしたはいいが、正しくされていないこと」をいっています。

仕事(作業)したくない人は、「作業したフラグ」をオンにすることが仕事だと思っているようです。

　今回発生したことは、データコンバートの作業が必要なのですが、古いデータでデータコンバートをしたり、データの不備を指摘しているのにその改善をせずにそのまま使っているのです。

（そもそも、最新データを送ってきたのは、アリバイ工作的仕事をした人なのに…）

　10,000歩譲って、納期来てしまったから送ってしまっただったら、まだわかるような気もしますが(先に相談がない時点でNGですが)、既に納期なんてとうの昔に過ぎているのでぜんぜんダメです。

　なんか、嫌がらせをされているのでしょうか？

大抵、この状態で出てくる言い訳は、「ちゃんと納品したじゃないですか！！(怒)ただちょっと間違っていただけですよね！！(怒)」的な言葉になるんですよね。

　確かに間違うことはあると思います。人間ですし、ルーチンワークでもないので。

でも、限度ってものがあると思うんですよね。

　以前、ここにも書きましたが、間に合わないんだったら「早めに上司や、先方に相談すれば大抵のことは大きな問題にならない」んですよ。

仕事を遂行することで一番大切なことは？

　皆さんは、人と仕事をする上で大切なことは何だと思いますか？
納期？クオリティー？楽しいかどうか？ちゃんと支払がされるかどか？犯罪ではないか？

どれも大切だと思いますが、一番大切なのは

『トラブルが発生した時に直ぐに関係者に連絡する』

だと思っています。

自分で解決できると思っても

こんなのは当たり前だと思いますが、なかなか世の中そうでもなかったりします。

• 納期までにクオリティーの低すぎるものを納品してみたりとか
• 遅れまくっているのに誰もなにも言わないことをいいことに黙っていたりとか
• 更には、蕎麦屋の出前の今出ました的に、聞くと今やろうと思っていたとか
• 客の担当が居なくなったから進まないだとか

こんなもんやらない理由だからいくらでも出てきます。

　トラブルの予兆があったら、直ぐに動けるように準備するとかいろいろすることはあると思うんですけどね。
　ここには、悪循環の種というのも存在します。
そのトラブルを発生させようとしている担当の上司が「トラブル的な話を聞きたがらない」雰囲気を出しているとそのことが上に伝わらなくなってしまします。

　こんなスパイラルです。（こんな絵色んな本に載ってますよ）

1. 「トラブル」が発生しそうになる
   ↓
2. 解決できるかも(叱られるのが嫌)だから黙っておく
   ↓
3. トラブルが発生する
   ↓
4. 対応するために時間が足りなくなる
   ↓
5. 人を総動員して対応する
   ↓
6. 人が減った他のプロジェクトがトラブり始める
   ↓
7. 1.に最初に戻る

　さらに悪いことにその組織のトップがそれをやっていると、もうどうにもならない。
一人社長をするんだったら原因を他に転嫁するのではなく自分で先に動くようにしてほしいものです。

　直近のプロジェクトでそんなことが起きています。
「女性の社長で従業員がなし」そんなことはどーでもいいんです。
それを理由にできないんだったらさっさと会社を畳んで欲しいです。大きな問題にならないうちに。


さぁ、みなさんもトラブルの予兆を発表しまくりましょう！

　だって、発表して何もおきなかったら、おきなくてよかったねとなって終わりですもんね。
もし、やばそうだったとしても早めに対処できるし、手伝ってもらった人は他の人に手伝ってもらえるかもしれませんしね。

はてなが沢山浮かぶよ

　会議が終わった後には、議事録やまとめた結果を出すのがあたりまえだと思うのですが、それができないのは、とっても問題があると思いますよね。

　長時間会議した後に直ぐにまとめを出しなさいとは言いませんが、次の日くらいにはなにかアクションを起こしてほしいわけです。
　悪い意味での依存心を持っている人は悪でしかないと思います。

そういうまとめを出さない割には、SNSで記事を投稿したりしていてアホらしくなります。
さらに、その中で、この人はすごいとかという評価を受けていると、「はっ？実体はどんな人か判ってます？」とか言いたくなります。

　「まとめないと困るのは、自分でしょ？」くらいに思われているような気がしまして…。

腹立たしいのですよ。