ふー

システム開発に際し、処理方式の検討は大変で、大事です。
処理方式が決まらないとプログラム設計や実装方針は決まらないので、コーディングが出来ない。
コーディングが出来ないと単体テストも出来ないので、スケジュールが遅延する。芋づる式に遅れて行くんですよね。
プロジェクトの計画や、開始当初の方針決めって大事だなぁと、最近つくづく思います。勢いで開発はできません。

最近、人の意見取りまとめて、説明して、説得して、資料に起こして、認識合わせて‥ってことばかりしてるので‥

疲れが溜まるの当然ですな

ふー

誰かが決めないと…

【誰かが決めないと…】

突然ですが…
システムを開発する上で、方針というのは大事だと思います。
方式決めるのも方針ありきですから。

プロジェクトの立ち上げに参画するといつも思うのですが…
「こうやればできますよ」
「こうしてもできますよ」
案は出すのに、方針として結論を出せない、決めきれない人が多いと感じます。
結局どうするかいろいろ提案した挙句、「どうしますか？」と…
結論を誰かに委ねてきます。

しかし、誰かが決めないと決まらない。
なんか当たり前のことなんですけどね。

決めるというのは責任重大ですし、失敗したら大変ですけど、
こうしましょうって決める人は重要です。

決断力のあるリーダーがいればいいんですけど、
なかなか決まらなくて長い打ち合わせの時なんかは
失敗したらその時考えればいい、とりあえずその時ベストだと思ったことを
決定事項としてやってみましょうと提案するようにしています。

失敗したらその時考えればいいなんて…
失敗すること怖がってた働きたての頃から比べると
自分も年とってきたなぁと思います。

まあ、経験則からくる「まあ、大丈夫だろう」という
予想があるからかもしれませんが。。。

経験て大事ですねぇ
つらいことも過ぎてしまえば糧になりますからねぇ

あまりまとまりのない終わりとなってしまいましたm(__)m

共通化とい名の下に複雑化するプログラム

【共通化とい名の下に複雑化するプログラム】
同じような機能を共通化して工数削減を目指すのは至極当然のことですが。。。
あまり共通化を進めすぎると逆にプログラムが複雑になり、逆効果になることが、たまにあります。

かくいう私も、途中参画のプロジェクトにおいて共通化しすぎて複雑になったプログラムを担当させられ苦労した経験があります。
少しの修正で色んなところに波及する恐れがあり、慎重にプログラムを修正したのを覚えています。また、複雑すぎて処理を理解するのに苦労しました。
ある時、そのプログラムの作成者に「難しい！！」って嘆いた事があるのですが、その時、「共通化を追及し過ぎて逆に複雑になり、わかりにくくなって失敗した。割り切って、別々のプログラムにしても良かったよ。」と作成者が悔やんでいたのを覚えています。

上記の経験を経て、私は時にはシンプルにするためにあえて同じようなプログラムを２つ作成しても良いという考えに至っております。

しかし…

たまに技術のある人で。。。
共通とい名の下にどんどん処理が複雑化させ、
さらに、ロジックに直接書くのを嫌がり、パラメータで処理制御を行うために、あちこちに制御用のデータを作りたがる人が居ます。
パラメータを増やすということは、そのパラメータを設定する運用が発生するということを判っているのかと説得したのですが、その人は運用のことは知ったこっちゃ無いという感じでした…


自分で痛い目にあわないと判らないという事もあるので…
あまりうるさく言っても嫌われるので。。。
というか、既に嫌われていたかも…

相手の意見を尊重して大人にならないとなぁと思う今日この頃です。

雛形テーブル

【雛形テーブル】
最近、テーブル定義を主な仕事にしています。
あまりに忙しかったので、テーブル定義書に記載済みのテーブルをＤＢに作成するのは、最近配属された新人にお願いしました。
お願いした時に話した内容は「テーブル定義書というエクセルファイルにあるシート内容をテーブルとして作成して」。
結構デキル新人なので何の質問もせず、黙々と作業し、完了の報告を受けました。そして、作成されたテーブルを見て、見知らぬ「雛形テーブル」を発見。
なんでこんなテーブル出来てるんだ？？？
少し考えて、原因が判明しました。
テーブル定義書にテーブル追加する際にコピーするために「雛形」というシート作っておいたのですが、それを律儀に定義してくれたのでした。

少し考えれば判るのに…

いくら仕事が出来ても新人らしい所あるなと…

少しホッとし、少しげんなりしました。

早いもので…

【早いもので…】
早いもので…
今のプロジェクトに参画して２年半が経ってしまいました。
新規のプロジェクトに投入されて、システムをリリースしたら、また次の新規の案件という感じで、１年以下の期間のプロジェクトを転々として来た私にとって、なんだか不思議な感じがしております。

２０代の頃は、いろんな経験をしたくて、１年ぐらい経ったら次の案件に行きたいと思っておりました。
でも、最近は安定志向で…
自分の自由がきくプロジェクトにいたいと思ってます。
まあ、年をとるに従って考え方も変わってきました。
だからといって、新規案件が嫌だというわけではないのですが…。
とりあえず、今は楽で居たい…

しかし、世の中不況なので、プロジェクトの縮小が頻繁に発生し、一つのプロジェクトが継続していくのは厳しい状況ですね。
メンバーが続々と去っていきます。
今月も一人メンバーが減るのですが…
そのメンバーの送別会の副題が「プロジェクトを卒業するＡ君の壮行会」となっておりました。
Ａ君は参画した当初は新人同然だったのですが、今は別人のように成長したので。
卒業って良い表現だなぁと…、感心してしまいました。

いろんなプロジェクトを渡り歩いて様々な人たちに育てもらって今の自分が居るので、１つのプロジェクトでじっくり育てるのも良いのですが、一定期間が過ぎたら他のプロジェクトへ移っていくのが良いと私は思います。
一定期間とは１、２年ぐらいですかね…私の場合。

プロジェクトを転々とするとそれぞれ顧客やチームのメンバーが変わるので…
プロジェクト毎に色があり、一から始めるのが新鮮で、大変でいしたが、自分の経験の幅が広がり、結構良い勉強になりました。

でも、１プロジェクトに腰を据えてある程度仕事をすれば、それはそれでそのプロジェクトのスキルと業務に精通してきて、それはそれで良い経験となると思います。

それぞれに良い面と悪い面がありますね。

私は、自分が転々として来たので、自分の配下のメンバーも無理に抱えようとしないのですが、それが最後まで面倒を見ない無責任のように上司に思われることが稀にあります。
責任をもって育てない訳ではなくて、いろんな人を知って欲しいだけなんですけどね…。

Ａ君の話に戻りますが…

Ａ君とは１年半の付き合いでしたが、今回のプロジェクトで何かを得られたかなぁと…ちょっと不安になります。
正直なところ…
もうちょっと一緒に居て面倒みたかったんですが…
それも叶わないので…

せめて
「このプロジェクトに参画して良かった」
と言ってくれるといいんですけどね。

その言葉が一番嬉しいので。

Ａ君の今後のプロジェクトでの健闘を祈ります。

任せると押し付けるは紙一重だと思う

【任せると押し付けるは紙一重だと思う】

最近思うのですが・・・
任せると押し付けるは紙一重だと思いました。

プロジェクトメンバーの中でも、最近年寄りの方に分類されることも増えてきました。
その為、仕事での立場も否応なしに責任が重くなり、面倒な事が増えてきます。

顧客との折衝だとか、問題点のフォローとか…

いろいろな事を対応しているうちに…

任せると言われると聞こえは良いのですが、なんだか押し付けられてる事も多くなったような…

まあ、任せると言われている以上、なんとか頑張ってます。

そんなこんなで忙しい日々が続いております。

なので...

今回の連休はのんびりするチャンス！！

仕事のこと忘れてのんびりしたいと思います。

今日乗ったタクシーの運転手さんに感謝！！

【今日乗ったタクシーの運転手さんに感謝！！】
今日は、終電に間に合うかどうかでヒヤヒヤしました。

顧客が報告書を明日提出するということで、その作成を手伝ったのですが…
終電の１５分前まで付き合わされてしまいました。

その為、家に帰るのを半ば諦めて、近くの親戚に連絡をし、寝る場所を事前に確保したのですが…
まだ少し時間があったので、駄目もとでタクシー乗りました。

半ば終電に乗るのを諦めてはいたのですが…
タクシーの中で後輩と「間に合うかなぁ」とか「奇跡が起きないかなぁ」なんて会話していたら…
何気にタクシーのスピードがUP！！

タクシーの運転手さんが何も言わずに終電に間に合わせようとして、飛ばして駅に向ってくれていたのでした。

奇跡的に終電の１分前に駅に着き、何とか終電に乗れました。

今日乗ったタクシーの運転手さんに感謝です。

ありがとうございました。

無事に家に着きましたよー！！

ちょっと嬉しい出来事

【ちょっと嬉しい出来事】
６月でプロジェクトから退場する社員に一緒に仕事できて良かったというようなことを言われ、少し自分のやってきたことがとりあえず間違っていなかったんだなと…ちょっと嬉しく思いました。

その社員は出来ない量の仕事を押し付けられても自分で抱え込むタイプでした。

抱え込んだままだと精神的に良くないので…
（現に私がそのプロジェクトに関わった時にその社員は精神的に病んでいたのですが…）

とりあえず、私はその社員に「出来る事と出来ない事を早めに切り分けて、問題がある場合や懸念事項がある場合は然るべき人にすぐ相談するようにし、どうしても出来ないことは誰かに代わりにやってもらうようにお願いしなさい」と言いました。
「それで文句言われたら責任は持つ」と背中を押して。

期限が迫ってから出来ないと言っても手が打てませんから傷が浅いうちに問題を認識してもらうようにすることが大事だということを言いたかったのですが…
そのことを理解したようで、「出来る事と出来ない事の切り分けが必要なんですね。」と感謝されました。

何でもすぐ諦めろということではありませんので誤解しないで下さい。

ケースによってはスケジュールと自分のスキルを基に出来るかどうか判断することは必要だということです。
（出来ない事を根性でやれという場面もあるにはあるのですが…
　それは置いておいて…）

自分の出来ない事にチャレンジしてスキルを向上させることも必要なんですけど…。
やっぱり仕事ですから、期限内に終らせる方が優先されると思います。

とりあえず、感謝されて良かった。

その社員の次の職場での活躍を祈るばかりです。

課題がなかなか解決しない時

【課題がなかなか解決しない時】
システム開発をしていて、課題がなかなか解決しない時って
結構ありますよね。
課題が解決しなくて何も着手できずに、ずるずる行って…
挙句の果てにスケジュールが遅延して、リリース間際に残業の日々。

まあ、よくある話ですよね！！
私も結構経験してきましたし…。
で、何度も痛い目にあってきたので、最近課題を記載してお客さんに
提出するとき、以下のようなことを心がけてます。

１．期限と担当を明記する
　　⇒まあ、当たり前のことですけど。ずるずる行かないように…
２．可能であれば、YES／NOで答えられるように課題に自分の対策案を記載する。
　　⇒YES／NOじゃなければ、いくつか案記載して選択にする。
　　　選ぶだけなら意外と早く回答が来る。
　　　どうしますか？って聞くとほっとかれる事がしばしば…
３．定期的にフォロー
　　⇒定期的に催促することで、課題の存在を忘れさせない。
　　　回答があまりにも遅いと打合せを実施して無理やり認識させる。

４．１～３までやって駄目なら、自分の案で進める旨伝えて了承を得た上で
　　とりあえず、回答を待つのを諦めて進める。

しかし、これだけやっても解決しない時はしないんですけどね。
後輩が課題が解決しないと悩んでいたので…
後輩に話した内容を書いてみました。