カテゴリー「Mファイル」の35件の記事

Mファイル:持病

なんだか凄いタイトルですね~~.....
「元も子もない」って感じです。
でも、別に特殊な施設の話題じゃありません。

「健康」の定義ってのも難しいとは思いますが、特に不自由なく日常を暮らしている人間でも、持病の1つや2つは持っているんじゃないでしょうか?
まあ、確かに「何にも無いよっ!」という人もいるでしょうが。

アトピーや花粉症も含みます。
風邪にしても、「異様に引き易い」場合は持病に近いです。
血中の鉄分が凄く少ない(貧血気味)なんてのも、立派な(?)持病と言えるでしょう!

季節に相関して症状が出やすいものの代表が「花粉症」でしょうね。
私もそうですが、「今年は軽い目」との予測が出ているので、ちょっと嬉しかったりします。

人によって症状の出方も違うので一概には判断できませんが、プロジェクトのピークが「症状の酷くなる時期」に重なりそうな場合は要注意です!

特に、要求・要件定義~外部設計のようなリスクの高い工程と重なる場合、全体が短納期な上に反復を繰り返すようなプロセスの場合はドキドキです。

更に、季節に相関する持病を持ったメンバーが、同じ季節にリスクを抱えている場合は本当に心配ですね。

逆に言えば、可能な限りは、そのようなメンバーリングにならないように気を付けます(でも、「気を付けようが無い」って場合の方が圧倒的に多いんですけどね)。

喘息、メニエールなどはストレスにも相関します。
これはもう、可能な限り「楽しく(充実して)仕事をしてもらう」しかありません。

ご支援、宜しくお願いします!ブログランキング!

にほんブログ村 ベンチャーブログへこちらも宜しく!

| | コメント (0) | トラックバック (0)

Mファイル:山を越えました

某月某日、某所のWebシステムの開発の山を越えました。
ありがちな話ですが、開発に参画した段階で、既にうまく行かなかった成果物が山のようになっているという...。

既にかなりの時間を消化しているので、リリースまでの間にリファクタリングは無理ですね。
予算的にも、普通に考えれば次回以降のフェーズになるんでしょう。

厳しいスケジュールでした。
顧客の社内で開発してましたから、別にご紹介している「定例会」に「帰社できない常連」になってしまってました。

ですが、チーム内はとにかく仲が良く、雰囲気・連携は良かったとのこと。
厳しい状態の中でも、お互いのリソースをやり繰りしながら補完し合ってマイルストーンに間に合わせました。
品質的にも、最初にお話したような前提からは想像できないほどに(?!)改善できました!(「利用する側から見て」のお話ですが...)。

メンバーとも適宜で会って話もして来ましたが、体は疲れていても気力は失せず、の状態を保ってましたね。

厳しくなったプロジェクトを立て直すために残った企業、メンバーばかりでしたので、半端な技術者はいなかったようです。
なので、仲が良かったと言ってもただの仲良しグループとは訳が違います!

次期フェーズに向けて、小さなところ、可能な範囲からでも改善していく!
プロジェクトの運び的にも安泰なものにしていく!、という意思が、具体的な対策案と共に本人の口から出続けます。
リーダーやプロマネとして参画したわけではないのですが、ファシリテーション的な見地から言えば素晴らしい姿勢と行動だと思います。

これだけ厳しかったプロジェクトでも、モチベーションと全体改善の意思を失わない!
ファシリテーションを意識したわけではないようですが、個々人が自律的に判断しながらお互いを活かし、支援する。
「仲が良い」状態になった、その相性の良さと、共通した性質の部分が、結果としてプロジェクト・ファシリテーションと同様の効果を発揮した事例なんじゃないか?、と思わされました。

Banner_02_2ブログランキング!

にほんブログ村 ベンチャーブログへランキング挑戦中!

| | コメント (2) | トラックバック (0)

Mファイル:明日の晩は導入面談だあ

今月一杯で常駐先での対応を終えるメンバーがいます。
ビジネスのスピードが非常に速く、並行して走るビジネス数もかなり多い。  伴って開発の効率性と速度、ひいては判断の迅速性と正確さが要求さされる。  とっても「ビジネスオリエンテッドのアジャイル」なので、じっくりモノ作りをしたい人には必ずしも水が合わないか...。
というところで、「タイプミスマッチ」というケースもありますね。  短期間ならともかく、長期では無理が利きません。

丁度11月の頭に連休があるので、よい気分転換になるでしょう。  本人も特別には休暇は望まないという事だったので、11月の第一営業日(4日)から参画すべく、次期案件の調整をしてます。

明日の月曜日、夜に顧客先にて導入可否を含めた面談を行うことになりました。  リリース直前の結合テスト・システムテストの最中なので、当日いきなり「済みません、障害が出ちゃったので今晩は動けないっす!」とか連絡が入るかも知れませんが、私には無事を祈っているしか手がありません。

ウチのプロパーが1人、パートナーさんから3名入って頂いている顧客先ですが、今回は別プロジェクトになっちゃいます。  フロアは同じなんですがね。
なるべくならプロパーでチームを構成したいのですが、この景気の悪い状況で条件を重ね過ぎると、いつまで経っても稼動できなくなっちゃいます。

元より、各人のチャレンジシート(自分の進みたい方向の中・長期の仮計画)を考慮して、出来る限りの営業上・マネージメント上の考慮をしているので、稼働率が下がりやすいんですから(案件を選ぶので)。

明日は涼しいといいな。  雨の予報は無いけど、温度や湿気が高いとスラックスにネクタイは辛いものがあるから。

Banner_02_2ブログランキング!

にほんブログ村 ベンチャーブログへランキング挑戦中!。クリック応援、お願いします!

Ok_s[ どんな会社だ?、ん? ]

| | コメント (0) | トラックバック (0)

Mファイル:一旦終了(一部まだホット)

久々の持帰り案件、エンドユーザー先にウチから1名が入っていて上流工程をこなしつつ、自社内にて下流工程を消化してました。
ユーザー先にいるメンバーは、顧客と、開発の面で同列のメンバー達と連携して多忙な作業をつつ、自社からは速射砲のような質問・確認連絡の嵐にもまれてました。  いや、そう表現すると「過去形」になってしまうな。  今日(10/22)までもまれ続けてます。
本当にご苦労様です、合掌...。  いや、そうじゃなく!

でも、本当によく動いてくれます。
社内のメンバーも決してノホホンとしているワケではなく、ユーザー先のメンバーと密に連携しつつ、気も使い、社内でも自律分散・協調の動きがとても良いと思いました。  あまり手前味噌で褒めるのも嫌らしいですが。

もうすぐ産休間近いリーダーと、今年の新卒新人1名、元アスペアの主任職だったアルバイトの1名(別の道を目指してプロ予備軍だが、学費稼ぎのため)の3名で作業してますが、新人も含めて上流資料の読込みが深い。
もちろん、経験での差は歴然と出ますが、新人の彼までが仕様書をよく読み込んでいるのには少し感心しました(ちょっとクシャミの声がでかいのがたまにキズですが(?!))。
バリバリ論議して、今後のアクションを決めていきます。  現実的に可能な範囲で、ポジティブに。  現実制約の面は、リスク管理的な視点で論議・方針決定していってます。
プロジェクト状況的には非常に心配の多いものですが、メンバーのアクションを見ていると、(こう言っては拙いかも知れませんが)妙に安心できます。

これを支えているのは基本的な指向と姿勢、モチベーションでしょうね。  言い換えれば、モチベーションを失わせるような状況で長期に放置してしまえば、大きく生産性や品質が落ちる危険性が高まります。

バイトの彼も含めて、良い仲間を持てたことは本当に幸せです。  みんな、アリガトー!
とりあえずの納品日(直前に書いた定例会の日)の夜に納品物が仕上がり、私がハンドキャリーしました。
CD-R格納ファイルの一覧を用意しておらず、私が移動中に携帯メールで指示し、客先にメールで送ってもらうようにしました。
ぎりぎりセーフ!  私の到着前に、客先のリーダーの方が受信されてました。  ホッと一息。  会社の連中は、その頃は歓送迎会・兼・プロジェクト打上げ(全員じゃないけど)で飲んでたでしょう。
私も自宅で乾杯しました。
客先で多忙にしているメンバーにはゴメンナサイですが。

Banner_02_2ブログランキング!

にほんブログ村 ベンチャーブログへランキング挑戦中!。クリック応援、お願いします!

| | コメント (0) | トラックバック (1)

Mファイル:プロジェクト終了ミーティング

山手線内、真ん中辺りでのプロジェクトを9月末日で終わったメンバー(9/1のブログに記載)が、リフレッシュを兼ねた休暇を終えて町田の事務所に出勤しています。  前日のブログでも触れた「開発終了報告」を作成し終わり、「プロジェクト終了ミーティング」を行いました。

「経験したこと」が「単なる過去」になってしまわないよう、得られたナレッジはナレッジ、今後の課題は課題として可能な限り切り分けます。  ナレッジで共有可能なものは、共有可能な形で記録します。  記録不可能なものは、定例会などで「シーンシミュレーション」のネタにしたりします(実は、既にこプロジェクトでは1回シミュレーションを実施済みです)。

今回のプロジェクトでは、俗に言う「基本設計からの参画」という事前の話で、実際に入ってみたら実質的に「要件定義から」という、特に大きなプロジェクトではよくあるパターンでした。
報告書では「事前・事後のリスク」視点からの記載が標準化してあるのですが、全般から得られたナレッジ、チェック項目などの記載を促す具体的な項目がありません。
今回はこの視点での様々な「気付き」が非常に多く、また提案もして来たので(残念ながら聞き入れられて運用にまで乗った件数は多くは無かったようですが)是非とも記載しようという事になりました。
本人自身にとってもナレッジを自覚・明確化する効果があり、共有可能な形に表現することも有用です。  限定されたシーンでのシミュレーション問題集のような形で活かせるかも知れません。

決して楽なプロジェクトではありませんでしたが、制御不十分なケースほど反面教師として得られるナレッジが多いというのは皮肉な現実ですね。  逆に言うと、どうにか旨く運用できたプロジェクトばかりに属していると、「旨く運ばせる」感覚やナレッジが身に付きにくい、という側面もありますね。

にほんブログ村 ベンチャーブログへランキング挑戦中!。クリック応援、お願いします!

Ok_s[ Webサイトも覗いてあげる ]

| | コメント (0) | トラックバック (0)

Mファイル:お疲れ様でした!

山手線内、真ん中辺りで、結果的にアスペアから1人で常駐作業をしていた社員が、9月末で作業を終えて帰って(撤収して)来ました。  当初の計画では増員参画してチーム対応しようと考えていた案件だったのですが、明らかに立派なデスマーチと化してしまいました。

増員を見送った上、上流工程から参画させて頂いてきたメンバーを、切りの良いタイミングで撤収させて戴きました。

今日1日は事務所に出社してもらい、開発報告(要は得られたナレッジなどを、振り返って文書に吐き出す作業)を作成してもらいます。  作成した開発報告は、社内サーバー上で共有します(さすがにインターネット上には置けませんが...)。

律儀な人間なので、ギリギリまで最大限の努力をして僅かでもプロジェクトを真っ当な方向に、少しでもタスクを消化しておこうと結構な稼動をして来ました。  本当にお疲れ様でした。
撤収することは心に決めていましたが、出来るならなるべく事を荒げたくない。  関係各社と睨み合うようなことは避けたいと思っていましたが、契約元が誠実に対応して戴けたので泥沼にはならずに済みました。
有難う御座いました。

社内的な打合せ時間も惜しいので、現場近くのお食事処などでランチミーティングを繰り返したことも、今となっては過去の思い出です。
明日からは1週間、しっかり休んでリフレッシュして欲しいと思います。

Banner_02_2ブログランキング!

にほんブログ村 ベンチャーブログへランキング挑戦中!。クリック応援、お願いします!

| | コメント (0) | トラックバック (0)

Mファイル:開発プロセス/プラクティス

久し振りに自社内持帰りのプロジェクトが動いています。
成果物要求が旧式形態ですし、ウォーターフォール的な流れを強制されるポイントも有るので制約が少なくありません。  それと、最も困るのが「スケジュールを動的に管理できないこと」。

無秩序にスケジュールを改変するのはNGですが、必要に応じてタスクの担当を変える(リソース配分の最適化)。  タスク内容が見えてくることにより、もっと効率的なタスク順と配分が見えてくる。  リスク吸収の為にコストが掛かり過ぎた場合に、取り戻しの為にプロセスの詳細を変える。
このような当たり前の手立てに対して、「スケジュールを変える時は逐一理由と対処内容、期待する結果などを事細かに報告しないとダメ!」という縛りを加えられると、プロセスはまともに回りません。

今年の新人が1名含まれているとは言え、その本人を含めてモチベーションは高く、「何をどうするのが最も良いのか?」を考えながら行動することが出来る、それを当然のことと考えられるメンバーが集まっています。
厳しい条件は各種集まっていますが、リスクを制御しつつ着実に前に進められることと信じています。
(もちろん、「妄信して見もしない」ということは有りませんが)

ちなみに、執務室の机の上にに築かれた「おやつ場」は、殆どが彼らの為に(彼ら自身の手によって)築かれたものです。
さすがに今日(土曜日)はお休みのはずです。

Banner_02_2ブログランキング!

にほんブログ村 ベンチャーブログへランキング挑戦中!。クリック応援、お願いします!

| | コメント (0) | トラックバック (0)

Mファイル:挨拶からスタート

タイトルを書いていて思いましたが、カテゴリーが何だか曖昧だなあ...と。  まあ、とりあえず結構書き溜めてしまったのでこのまま進めさせて貰います。
皆さん、ミーティングや会議を始める時にどんなスタートをしてますか?  何となく最初の議題が、人が集まったタイミングで突然に始まるって感じじゃないでしょうか?
気の利いたメンバー構成の場合は、「アイスブレイク」として軽い雑談から入ることも有るのでしょうが。  個人的には、どうもだらだら、ふうわりと始まるって感じが苦手です。  メリハリ無いです。  頭が切り替わりません。

特に技術者の場合は、個人のタスク処理に集中していた直後だったりすると、視点の置き方・頭の回転がミーティングのそれに切り替わらなかったりするんじゃないでしょうか?  そんなボンクラは私くらいのものでしょうかね?

声の大きさ1つ取ってもそうです。  静かな執務室で隣の人と話すのと、ミーティングルームで情報や意見を交換する時の声の大きさは全然違うはずです。

私は、社内的なミーティングや会議のスタートの時には必ず「宜しくお願いします」とか、「お疲れ様です」から入ります。  声の大きさは、当然、その空間と人数に十分通る大きさにします。
念の為に言っときますが、私は体育会系じゃありませんよ!?  決してバカみたいな大声は出しません。

この挨拶で締まる気がします。  皆の目的意識と集中力が、ほんの少しですが高まって、良い意味での緊張感が加わる気がします。  時には、ミーティングの基本ペースが遅々となるのを防いでくれるような気もします(思い込みが激しいだけか?)。
ファシリテーション的にも重要なポイントの1つだろうと思います。

今では、大体が「あいさつ」からスタートするようになっているようです。  私が習慣付けさせたという訳でもないのでしょうが、悪くは無い状態だと思います。

皆さんのミーティングのスタートは如何でしょう?
結構、その企業の文化を反映していたりすると思いますが。

Banner_02_2ブログランキング!

にほんブログ村 ベンチャーブログへランキング挑戦中!。クリック応援、お願いします!

| | コメント (0) | トラックバック (1)

Mファイル:せーのーはどうしますか?

「機能外要件」などとも表現されますが、性能、セキュリティ、システムの冗長化、システムのバックアップ&修復などが含まれます(ケースバイケースで集合要素は違ってくるでしょうが)。

IT関係でも比較的上流・初期工程を扱う書籍なら必ず取り上げられると思いますが、要求定義・要件定義工程と並ぶタイミングで、性能指標に関しても明文化して同意(同感)を得ておく必要がありますよね。
性能基準のレベルや適用範囲にも拠りますが、性能レベルを変えるというのは、プログラム製造が進んで(殆ど終わって)しまってからでは極めて難しくなります。  不可能ではないかも知れませんが、システム規模に相関してコストが跳ね上がります。

つい先日、アスペアが既に数年間に渡ってお世話になっているエンドユーザーで問題が起きました。  「本番環境にシステムをインストールしてみたら、性能が悪くて実質的に使い物にならない!」とのこと。
では、性能基準があったのか?と言うと、有りません。  要求仕様にも記載なし。  電子メールなどにも記録なし。  顧客側担当者から口頭で伝えたような?とのことですが、開発側担当者の記憶には残っていない...。

では、本番機にインストールする前にどうやってテストしたのか?  顧客側に受け入れテストを実施して戴いたのですが、本番環境と全く同一のレコード数までは用意していなかったとの事。  その時点では性能面でも全く問題が出ませんでした。

誰がどう悪いの云々は言えますが、少なくともアスペア側に落ち度があった事は事実です。  数年に渡って開発反復を繰り返して来たのですが、なんと、その中で性能指標が記載されたことが1度もありませんでした。  顧客側も我々も、それで当然になってしまっていたんですね。

しかし、データベースを含むシステムを開発しようというケースで、想定レコード数が不明のまま開発を行うというのは、ちょっと恥ずかしいです。  「顧客側から指定が無かった、記載が無かった」と言って逃げてしまうのは拙いです。  それでお客様が納得することを期待するようでは、アスペアは下請け案件しか対応できないといった事にもなり兼ねません。

言われないことまでしっかりやる!  それはビジネスとは違うでしょう。  しかし、言われないことでも「隠された要求の存在が無いかを確認する」ことは必要です。  それを当然のこととして出来るのがアスペア品質のはずですから。

Banner_02_2ブログランキング!

にほんブログ村 ベンチャーブログへランキング挑戦中!。クリック応援、お願いします!

| | コメント (0) | トラックバック (0)

Mファイル:パートナーさんを知りたい!

アスペアでもパートナー会社の技術者の方にお手伝いを戴いています。  ほんの数ヶ月前までは極端にパートナーさんが少なかった(と言うよりゼロだった)ので、今は特に積極的に増やしている最中です。

ですが、やっぱりトラブル率が高い目なのが気になります...
勤怠面とか、業務上での成果面(事前に期待された能力とのギャップ)での問題が殆どです。  難しいですね。
要求されているスキルセットとのギャップ、人物的な確認精度を高める為にいろいろと工夫もしますが、これと言った決定打はなかなか有りません。

私自身は、無理が無い限りはなるべく相手の所属会社に出向くようにしてます。  間に仲介的な会社が入ってしまう場合には余り意味を成さなくなってしまうのですが、「所属会社の空気」「他の人の対応・雰囲気」や「会社としての対応」を見ることで、ある程度の補完的な判断ができると思ってます。

訪問したときに、たまたま会った社員の方が挨拶してくれたり(しかもしっかりとした声で(小さな声で言われる場合が多いんですが))、基本的なビジネスマナーを比較的しっかり実践されていたり(人のことは言えませんけど...)、そういった会社さんは、採用・育成の時点からこだわりが有る。  或いは、暗黙でも必須のスキル/マナー水準が有って、そのレベルに達していないと恥ずかしくってその会社にいられない。  そんな印象を受けたら大当たりです!

逆に、たまたま行き違って顔を合わせても何も言わず、会釈もしない。  全体に汚い、どんよりした空気が漂っている。  衣服がだらしない。  何かとちょっとした事なんだけどマナー違反が気になる。  そんなパターンだと、残念ながら、所属している社員さんなら同じような傾向属性を持つ場合が多い気がします。

しかし、少しでもリスクを制御しようとして訪問を繰り返す訳ですが、真夏は辛いですね...。  私は特に暑さが苦手なので。
数日間、涼しい日が続きましたが、蒸し暑さのぶり返しに続いて猛暑が戻って来ました。  たった1つ嬉しいのは、夜がどうにか晴れる日が増えて来たこと。
19時辺りに南の空を見ると、それほど高くない空にひときわ明るい星が光ってます。  10倍位の双眼鏡で見ると、小さ~な衛星を幾つも伴った木星であることが分かります。  惑星萌え~~です。

Banner_02_2ブログランキング!

にほんブログ村 ベンチャーブログへランキング挑戦中!。クリック応援、お願いします!

|

より以前の記事一覧