ホーム > 過去の日記 2011~2012

過去の日記 2011~2012

過去の日記

2012.2.2 Thu Google日本語入力

気がついたら、もう何ヶ月も更新してなかったね。
最近、やっと会社のPCがリプレースされて、OSがXPからWindows7になったんだけど、
これがなかなか使い辛い。

2011/10/28 Fri XxX機能 テスト終了

完了ではなく、残作業もあるのだが、正常系のテストは一通り行い、来週月曜に予定していた
他のグループへのテスト向けリリースは予定通りできる見通し。
スケジュール通り、直前に慌てて休日出勤で対応、とかなしに提供できるのは、このグループ
ではあまりなかったことなので、まずはよくやりました、と自分にご褒美(プレミアムモルツの缶ビール)。
今回、うまくいった要因はナンだろう?
まぁ、正直、スキルのある協力会社さんのメンバーの力によるところが大きい。
でも、その力をうまく活用できたのではないかと思う。
そして今回得られたこともたくさんある。

  • プログラムの構造、どこがキモか見えた
  • 誰がどの機能を得意とするか見えた
  • 設計を進める上で有効な資料はなにか見えた
    課題もたくさん見えたが、すぐに振り返り会をやって原因と対策を探り、次の開発チームに
    フィードバックしよう。
    今回のように要件ごとに短期の開発チームを作って小さな開発サイクルをまわし、課題と改善案を
    フィードバックしていく、というスタイルを定着させれば、プロジェクト全体のレベルアップが図れる
    のでは、と考えている。こうした小さい開発サイクルなら、メンバーを流動的に編成したり、
    チームリーダを持ち回りにして若い連中にリーダーの経験をさせたり、なんてことがやれる
    プロジェクトを目指そう。

2011/10/26 Wed ねた

仕事はサッカーなど、スポーツにたとえられる。
長谷部選手の本を読んでから
与えられたポジションで任務を果たすことが大事
オーバーラップしてしまったが、上司は理解してくれていた。
ただし、基本はポジションを守ること

2011/10/3 Mon 「ハイ、それ採用!」 (リーダーの心得)

どっちらかと言うと自分のフットワークはあまり早くない方である。
でも、手が早いメンバー、細かいことに気づくメンバーがいろいろ意見(クレーム?)を上げてくれる。
そしたら、すぐさまその意見に乗っからないと、と考えている。
なんでも言いなりではダメだが、Projectとして必要なことを指摘してくれているのならば、自分の
足りないところを補ってくれているのだし、意見を出した人ならば「その方向で進めてよ」で動いてくれる。
"水曜どうでしょう" の藤村ディレクターの「ハイ、それ採用!」 のノリである。
昔の自分はというと、リーダーたるもの、メンバーの意見を自分が納得できるまで推考して、とか、
その意見を自分で先頭に立って実行しなきゃ、とか思っていたが、今はメンバーに動いてもらうのが、
リーダーの仕事と理解している。メンバーからあがった意見、クレームには最優先で対応する
ことが、メンバーのモチベーションを上げ、やりがいをもって仕事に接してもらうコツだと思う。

2011/9/16 Fri UML、設計で使えてます?

いまいちちゃんと理解できてない UML。
いまの開発でも EA (Enterprise Architect けっこうメジャーなUMLモデリングツール)使って書いた
クラス図とかあるけど、本当に開発に役に立ってるのかな? なんかね、
おんなじようなクラス図ばかり。全部ソースに対応して書く必要ないよね? ソースと同じなら
ソースを見たほうが早いし。
必要なのはデータの流れや持ち方だと思うんだけど。
で、クラス図は静的モデルであって、プログラムの振る舞いを表すためのものじゃないので、
これから実装に落とすのは無理があるんだよな。きっとやり方間違ってんだろうな。
クラス図 + 動的な振る舞いを記述するノーテーションがないかな?

2011/9/15 Thu 

またまたご無沙汰です。
まだまだわからないことが多い GUI開発。ツールを使ってコードの自動生成とかやってるんだけど、
これがまた中途半端で使いづらい。コンパイルするまで誤記に気付かないし、コンパイルは時間
かかり過ぎるし。開発手順を見直したいんだけど、まだまだ謎が多い。
あと、グループをまたいでのリーダー会を実施。地方でソフト開発を続けるためには、なんらかの
技術的なアドバンテージが必要との意見で合意。でもなかなか新技術獲得の時間がとれない
のと、商売につながるような技術はなかなかなくて。。。

2011/8/3 Wed GUIのフレームワーク、勉強中

ご無沙汰しちゃいました。
今週から GUI関連の開発に本格的に着手し始めました。今回は、サブリーダーとして
開発の方をメインにやってます。
エンハンス開発なんだけど、けっこう開発環境めちゃくちゃ。。。 フレームワークを
使ってたんだけど、いろいろ拡張して使い回してきたので、もはやフレームワークの
機能を果たしてない。かえって手間がかかってる。ここ立て直さないと、また大変な
だけのプロジェクトになるので、なんとか改善できるところを探しているところ。

2011/7/18 Mon BD始めました

次版開発では Redmineを使い始めてみることにしました。チケットとかは使うつもりは
なくて、Wikiで情報共有をするのが主目的。先日の、パス名に空白を含むとリンクでき
ない件は、メンバーの了承をもらってパス名の方を空白を含まない形に直すことで回避。
軌道に乗って来たらチケットも使ってみようか。

2011/7/5 Tue Redmineお試し

Trackの Wikiはイマイチだったけど、Redmineの Wikiはそれなりに使えるぞ。

"リンク名":file://XXX/yyy

でファイルサーバー上のフォルダやファイルにリンクできるのが素敵。
(IEでないと開けないが。。。)
でも 、パス名に空白文字が入ると正しくリンクが作れなくなる。
うまい解決法はないかな? 下のやつはインストールしたけど使えなかったぞ。
http://bearmini.com/lang/ja/redmine-plugins/macros-for-wiki/unc-link/

2011/7/4 Mon 続・Redmineの導入

MySQLのインストールや Apacheの設定で少し悩んだけど、ネットで調べればたいていの
ことは解決できた。基本的にRedmineのウェブサイトにあるセットアップ手順にしたがって
インストールしていったのだけど、意味は解らずともとりあえず手順に従ってコマンドを
叩いていけばインストールできた。
かなり前に XOOPSのインストールを試みたことがあったけど、さんざん悩んで結局挫折した
のに比べると、適当にやってもちゃんとインストールできるのがすばらしい。よく作られ
ているんだな。インストール後、Redmineにユーザを追加したり少し使い始めてみたけど、
特に問題なし。
でも、Redmineをいじり始めたのを見た課長の反応はいま一つ。ツールの導入がプロジェ
クトの問題の解決にはならない、と考えているからだろう。別のグループが Trackを導入
したけど、結局チケットとかの機能は使わずに終わってしまったし、また余計な手間が
増えるだけで結局使わなくなるんじゃねーの? と言いたい言葉を飲み込んでいるのを
感じる。そんなことより、目の前の仕事を片付けろよ! と言わんばかり。
 
オイラもツールを導入しただけで問題が解決するとは思っていない。ただ、現在は
グループの情報共有に Pukiwikiを使っているんだけど、自由度が高すぎていろいろと
手順を決めないといけないとか使いづらさも感じていて、Redmineなどのプロジェクト管理
ツールがうまい解決法にならないかと模索しているのだ。
でも Redmineがうまく適用できない懸念も。障害管理などにチケットの機能は有効だと
思うし、それが大きな目的で導入するのだろうけど、うちのプロジェクトの場合、
検査部門が開発した障害データベースがあって、そこですべてのグループの問題を管理
している。だから、障害管理の用途には必要ない。また、SVNとの連携についても、
このプロジェクトは専用の開発サーバーが用意されていて、その上で商用のソース管理
ツールが動いている。Redmineとは連携できそうにない。
一番の目的としては、業務手順を Redmine上の Wikiに載せて、それをメンバー全員が
常に参照できるようにすることと、その業務手順と連携して必要な情報にアクセスでき
る仕組みがほしいだけなんだけどね。
ま、まずはいろいろ試して、成果があれば公開してみます。

2011/7/1 Fri

仕事の合間に、いぜん使っていたサーバーに Redmineのインストールを試みる。
Redmineを動かすために必要なアプリがけっこう多い。Ruby関連は gem ってツール
があるのわりと楽にインストール。
MySQLのインストールにちょっと手こずる。最近は yumってツールでなんでもかんでも
インストールできるみたいなんだけど、サーバーに入ってるのはCentOS4 ってちょっと
古めのバージョンなので、yumが入ってない。まずそこからセットアップ。yumも単純に
はインストールできなくて、yumに必要なパッケージでCentOS4に必要なバージョンを
探しまくってやっとこさインストール完了。でも Redmineはようやくこれから。

2011/6/30 Thu

今後のスケジュール説明。でも、まだ細かい要件までは見えてないぞ。
お尻はテスト完了まで含めて5週間。
1週: 作業手順の確認と環境構築
2週: SD開始
3週: DD/PG
4週: LT/UT
5週: CT
ざっくりだけどこのぐらいのペースってことだよ。
今回もまたきつそうやね。。。

2011/6/29 Wed

出荷判定 「可」 となりました。おめでとう!!

2011/6/23 Thu

やっとファームFix. でもいくつか障害が。。。 今頃言うなよ。
回避手段はありそうなので、出荷はいけそう。
さて、そろそろ次の仕事に着手するか。
次のバージョンもすでに工数が足りないらしいぞ。
課長はまだ体制のこと、何も言ってくれないので、まずは2次チームのサポートに回ろう。
Project管理に Redmine 使ってみようと思う。

2011/6/15 Wed

ファームFix前日だというのに、駆け込みの修正依頼や障害が。。。
今日、徹夜です。

2011/6/8 Wed

障害対応はほぼ完了。明日からメンバーに何やってもらおう。。。
相変わらず先の読みが甘いオイラなのでした。。。

2011/6/7 Tue

昨日はけっこう寝たので、今日は頭すっきり。仕事をさばくことができました。
やっぱり睡眠って非常に大事。
長いこと調べていた問題がようやく解ったと思ったら、修正確認のテストで別の問題が
発生することが判明。これまで調べていた問題の裏に隠れていたようだ。
 
テストが不十分だったところは、必ず何か起こる。ソースを流用した開発だと、
すでに動作実績があるからとテストの手を抜きがちになってしまうが、少しでも手を
入れたところはテストの対象にしないとダメだね。
 
誰だ? リリースを優先だ、なんて言ったのは。テストを省くことが工数の削減には
ならないことを改めて実感。別のアプローチがなければ、工数の削減なんて普通は無理
ってことだ。
次は反省を生かしてくれよ、2次開発に着手したメンバーたち。

2011/6/6 Mon

なんかね、もうそんなにやることないはずなのに何からやっていいのかわからない。
なんだか頭が回ってない。あれをやろう、これをやろうとタスクを積み上げるんだけど
結局ほとんど手がついてない。で、結果を出せてないからなんだかイライラしてしまう。
なんか、計画を立ててそれを遂行するという習慣が抜けてしまったようだ。
 
まず自分のリズムを取り戻そう。なにかやらねばとあせって夜更かししても何の成果も
あげられない。まずしっかり寝よう。そのためにストレッチとマッサージ。ぐっすり寝て
早起きしよう。
 
お知らせ: 「出張の友」に「便利アイテム」載せてみました。

2011/6/2 Thu

マニュアルも上がったし、100件以上あった改善要求もほとんど片付けた。でもまだ
細かい問題が上がってくる。。。
っていうか、もうコードFixだってのにいつまでもテストしてないでくれよ。
今日この頃は、次版に先送りする事項やマニュアルの誤記修正のリストを作り始めてる。
 
あとは引継ぎ先のグループからの質問への回答。我々がコードを流用したとき、元の
ソースにはなるべく手を加えないで差分の出たところだけ直そう、という方針をとった。
それが短期間で品質を確保するのに有利と考えたからだ。しかし実際には全体を解って
いないで表面的な所だけ修正するので、要求仕様通りになっていない、そもそも装置
仕様が解ってない、動作原理を理解していない、結果 工程遅れ、問題多発となった。
引継ぎ先のグループは、かなり細かいところまでソースの解析し、自分達のやりやすい
ようにコードを作り変えるようだ。
流用開発といってもコードをそのまま利用できないのであれば新規開発と同じだけの
開発工数が必要になる、ってことを痛感したプロジェクトだった。
 
ひとり言: まだ課長は今後の方針を教えてくれないな~

2011/5/31 Tue

昨日はわりとサクサク仕事が進んで、メンバーにも仕事が振れてたんだけど、今日は
割込みが多くて予定してた仕事が片付かず。
先の見通しをつけずに一日を終えるから、次の日、やるべきことにすぐ取り掛かれず、
メンバーの作業が止まったり、それを避けようとして自転車操業になる。
その日 予定した作業が終わらなかったとしても、見通しをつける時間は設けよう。

2011/5/28 Sat

各地の原子力発電所停止に伴う夏の電力不足に向けて、環境省が『スーパークールビズ』
を提唱。オフィスでポロシャツやアロハシャツ、はてはTシャツにジーンズの着用も
認めるというもの。
会社でTシャツっていうなら、僕はもう何年も前から『スーパークール・ビズ』ですよ。
下手したら冬でも(^_-)。毎日テンパってるんで。。。

2011/5/27 Fri

プロジェクトが火を噴いたため、一時期は部門をまたいでたくさんの人たちがプロジェ
クトの応援に来てくれていた。ようやく終わりが見えてきて、今日は最後の2人が元の
部署に戻ることに。本当なら応援に来てくれた人もみんな呼んで打上げでもやりたい
ところだが、まだそういう状態ではないので、グループ全員集まった前で一言 挨拶し
てもらい、全員の拍手で感謝を伝える。 
こんなでも、これが応援に来てくれた人達のモチベーションになってくれれば、と思う。
 
一時期は協力会社の人とか大勢いすぎて、当日になって「え?、明日で契約終わりな
んですか?」 という人も結構いたからね(当人じゃなくて僕がですよ。あと自分の
グループのじゃなくて隣のグループで契約していた人ね)。
サポートしてくれた大勢の人達に感謝。

2011/5/26 Thu

あいかわらず進捗報告が苦手で困る。。。
今日の課長からの指摘
・実績を書くのではなく、見通しを書くこと

2011/5/24 Tue

課長と今後の体制について少し話す。具体的にはまだ決まっていないが、主要メンバー
はエンハンス版の開発に着手、残りのメンバーは現在のバージョンの残作業。うちの
グループもそろそろやることがなくなってきたので、もう一方のグループの残作業を
手伝うらしい。おいらは現在の業務の後始末。
次版開発に向けて体制は見直した方がいいのでは? とか、うちのグループのメンバー
も加えないと、とかいくつか提案してみたが、「まぁまぁ キミの意見は、もう通ら
ないので」言った感じ。
今後について、ほんとは全部の業務を切りたかったが、もう一方のグループの実装は
大変複雑なので今後のメンテナンスを考えると切るに切れなかった、というのが発注
元の内情みたい。うちの実装は昔のコードの流用なのであっさり取り上げられた。
もはや信頼されていないのなら、また最初から実績を積み上げていくしかなさそう
だ。。。

  • 今日できたこと : 改善項目のたな卸し
  • できなかったこと: ドキュメントの修正量と修正箇所をピックアップしないと

2011/5/20 Thu

今の仕事の引継ぎのため出張。2本立てで受けたモジュールが両方とも遅れてしまった
ため、次期開発でうちの部署は片方のモジュールに専念することになり、うちの
グループの担当分は別のグループへ。くやしいが、結果を出せなかったのだから何も
言えない。
残りの時間でどこまで作業できるか見極め片付けに入ろう。
次期開発の体制はどうなるんだろう? おいらの行く末はいかに?!

  • 2011/5/19 Wed
    結局、ほったらかしになったままプロジェクトが終わりに近づいてる。
    リニューアルしてセカンドシーズンに入ろう(意味不明)。

コードフィックスが近いのに改善指摘がまだあがってくる。

Work Hacks! に 「特定のメールへのショートカットを作る」 を追加。

このページを共有:
  • このページをはてなブックマークに追加 このページを含むはてなブックマーク
  • このページをlivedoor クリップに追加 このページを含むlivedoor クリップ
  • このページをYahoo!ブックマークに追加
  • このページを@niftyクリップに追加
  • このページをdel.icio.usに追加
  • このページをGoogleブックマークに追加

このページのURL:

ページ新規作成

新しいページはこちらから投稿できます。

TOP