« 2008年7月 | トップページ | 2008年9月 »

2008年8月の記事

お仕事:権限って難しいデスよ...

形の点では社内的には職制、プロジェクトの中では公の役割設定とアナウンス、プロジェクトの中でのチーム、サブチームの中での決めとアナウンス、1対1での相対的な認識関係、ビューの制約を限らず非公式での権限認識、様々な体裁と実質的な運用・行使上の権限と公知認識がありますね。

意思決定権が、どんなサイズの集合に対してもたった1人にしか存在しないとしたら、大抵の組織は短命に終わるでしょう。  大抵の場合は段階的に決定権が付与されます。
特に巨大な組織の場合は、一度決めた権限ルールは容易に動かし得ません。  明らかに例外的なケースと思われるような場合でも、先ずは決められた権限通りに手順を踏みます。  例え、それが誰の目から見ても無駄・或いは非常識と分かるような場合でも、「決められた形」を守ることが第一義であるという側面はあるのでしょう。

しかし、少なくとも今現在、私自身が属しているかスペアと言う会社は、技術者・事務方全てを含めても40人に満たない小さな会社です。  例外的な措置ではあっても、合理的で道義的・必然的な判断と行動は必然視されるべきですね。  少なくとも、私はそう信じています。

バランスの難しい話なので、それこそコミュニケーションを密に取りながら認識合わせをしていくべき事柄です。  時には摩擦も生じるでしょうが、巨大企業を真似るような、今現在は身を置いてもいない非現実の前提を厳守しようとするような愚かな判断をしてはいけないと思います。
30~40人って規模は微妙なラインのようですね。
以前に、ベテランの保険屋さんに言われたことがあります。  このラインを超えられるかどうかが1つの壁なんですよね、と。  ここ数年、なるほどなあと感じる時もありますね。
良い意味での経験値として活かせればと思います。

Banner_02_2ブログランキング!

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

|

お仕事:リソース管理範囲のシフト...

全くもって社内的なお話なんですが...
ある有力な顧客から、アスペアでチーム体制を組んで、客先常駐の形態で開発の支援を行って欲しいという要望を戴きました。  有り難いことです。  有り難いのですが、タイミング的に丁度「頭」をまとめる人材に空きがありません。
  でも、とても重要な依頼なので何としても応えたい。
仕方なく(と言うと何ですが)、マネージャ(元々はアーキテクト的な技術者)がリーダーとして参画することになりました。

元々が幾つかの特定顧客との窓口を努めていましたが、特定案件に入り込んでしまうと、窓口の継続は不可能です。  必然的に、その彼とチーム体制的に動いていた私の方に担当窓口のシフトが発生します。

実は今、そのシフト顧客への挨拶回りの途中で、駅の喫茶店でNotePCでモバイルしています。  最近はモバイラーが増えましたねえ!?
結構なオジサンでもNotePC開いてパコパコやってたりしますね。
電車の中なんかでも、若い女性がNote開いてたりもします。

Banner_02_2ブログランキング!

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

|

お仕事:準備勉強会

新規のプロジェクトで必要となる技術要素が多いため、5名のチームメンバーが分担して調査・評価用プログラムなどを作成し、各々が交代で勉強会を開いていました。
執務室の壁がほとんど真っ白に近い色で反射率もほどほど、プロジェクターのスクリーン代わりとして丁度良いので、そのまま投影してます。  それにしても、超軽量のプロジェクターが1つあると便利ですねえ!

調査内容の内の1つは、殆ど日本語情報が無いものでした。  このグループの中には、ある程度英語が出来る人物が2人いますが、その内の1人は中国籍の社員です。  中国語が出来て日本語も結構できて、英語まで読み書きできるとのこと(日本語と同じ程度のレベルで出来るらしい!)。  すっごい!!、トリリンガルです!  折角なので、アスペアのサイトで日本語情報を公表したいですね。
Pict2133

Banner_02_2ブログランキング!

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

|

お仕事:IT業ってどんな人が向いてるか?①

そもそも「IT業」という括り自体が曖昧で広過ぎるんですが、一般的に言う「システムエンジニア、或いはプログラマー」として「中規模までのシステム開発に関わる人」ということにしましょう。  全然明確な定義じゃないですね、申し訳ない。

規模が大きなプロジェクトになればなるほど、相対的に役割分担が細かくなります。  仕事量が増えるんですから当然ですね。  小さなプロジェクトでは1人が複数の役割を兼任しますし、実質的に消滅するタスクもあるでしょう。  例えば大手のSI屋さんでは、細かくなった役割分担の中の幾つかで専門特化するような方もいるようです(部署や職制として定義されている場合も有るようですね。あまり詳しくは知りませんが...)。

ここでは「モノ作りに関わる人」という意味で、「内部構造的な設計や製造に関わる人」という意味で話を進めます。

IT業というと「理系の人向き」というイメージがありますが、少なくともアスペアでは文系出身者が約6割を占めてます。  ソフトウェアの特徴の1つとして「形が無い」という点が大きいのですが、形の無いものを複数の人間たち、場合によっては複数の会社で寄ってたかって作らないといけない訳です。
ここで重要なのはコミュニケーション。
コミュニケーションを支える要素は多くあるでしょうが、主たるものは「言語力(日本なら当然日本語力)」と「自律性」だと思います。

一概には言えないのですが、悪い側面だけを強調すると、理系の人は「提示された特定課題を深く掘り下げて解く」のが得意な人が少なくありません。  コミュニケーション、言語力という点では、必ずしも強くなかったりします。  また、「論理的な迷路に入り込んでしまい、なかなか帰って来ない」、「下手をすると、そのまま潰れてしまう」危険性をはらみます。

また、プロジェクトは大抵の場合複数人数で進めるものですが、個々の人間が「自律判断して行動する(無論、協調が前提ですが)」ことが必須です。  各々が指示を待つ状態になったら、出来るものも出来なくなってしまいます。
ちなみに、大規模プロジェクトでは役割分担が非常に細かくなりますから、横にも縦にも細かく分割されがちです。  コミュニケーションの重要度は変りませんが、伝達がボトルネックになって全体が停滞し易いという側面があります。

そこで重要なのは、「お互いの分担に少しづつ踏み入って話し・考え・判断する」ことです。  このクロスオーバーが無いと、コミュニケーションのズレが大きくなり、全体としては破綻してしまいます。
自分の境界に垣根を設けたがる人は、「指示を受けて動くのみのプログラマー」以外になるのは厳しいと思います。

Banner_02_2ブログランキング!

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

|

お仕事:テストドリブンは高い?、安い?

連続ネタです。
ITシステムを開発する場合に、テスト先行でプロセスを駆動させる場合、「テストドリブン」にすると「高く付く」のか「お安くなる」のか?
分かっている方にはまどろっこしい話なんですが、初期開発で前回に書いたような様々なリスクが存在し、表面化した場合には「相対的に安くて、しかも良いものが出来る」はずです。  「はず」と書いたのは、プロジェクト自体がデスマーチに至ったりした場合には比較もクソも無いからです。

「テストドリブン」以外のポリシーもしっかりしていて、プロジェクトが(楽だったかどうかは別として)リスクを望ましい形でコントロールできた場合は、コスト的には「やや高く」なると思います(←これは「初期開発」の場合の話ですよ)。

「品質が上がるったって、コスト高じゃしょうがねえじゃねえか!!」と、管理職の人や発注側は怒るかも知れませんが、前回ちゃんと書きました。  「システム寿命が長いこと」。  作り捨てのプログラムにテスト書いても勿体無いです。
拡張や変更を経て顧客と共に成長するシステムの場合は、テストコードが活きます!  寿命が長くなるほど、概ね累計コストは相対的に下がっていきます。  しかも、ここが肝心ですが、手を入れても混沌化の度合いを抑えられます。
まあ、「テストドリブン」と「オブジェクト指向的に良い作り」とは直接の関係は無いですから一概には言えませんが、テストドリブンで開発されていて、それを継承すれば極端なリスクを抱え込む事にはならないはずです。

但し、テストドリブンも「ポリシーがしっかりしていて、メンバーに理解され、徹底されている」場合に限られます。  アスペアで参画させて頂いて、既存システムへの機能追加・改修を行うケースも有りますが、「テストケースが有ったり、殆ど無かったり、まるで動かなかったり」といったケースも少なくありません。
このようなケースでは「コスト高になった」でしょうね。  このプロジェクトの前のフェーズを経験した技術者や管理者は、「テストドリブンなんて高く付いてダメ!」と吐き捨てるのかも知れません。
その点では、「誰がどうやっても旨く行く魔法の手法」でないことだけは確かです。

Banner_02_2ブログランキング!

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

|

お仕事:テストドリブンは常にお得?

「テストドリブン開発」(TDD)ってやつですね。
前に、アスペアの中途採用の応募を戴いた方と面談をした際に、「TDDのプロジェクトなんて見たこと無い」とおっしゃってました。  アスペア社内で見る限りでは、TDDを全く経験していない人間がいたかどうか?  まあ、確かに「厳密な意味でのTDDって何だ?」とまで問われると答えに困ります。  JUnitでテストコードを書いたことが有れば、TDD経験ありって言えるのか?、と問われれば、それは違うでしょうし...

そもそも、何故「テストドリブン」なんでしょう?
「やった事が無いから」、「やってみたいから」ってケースも、未だにゼロではないのかも知れませんが。

適用して「吉」のケースは、
システム(或いは開発対象のコンポーネント、論理層など)の寿命が長い、性能改善の必要がある(要求が高い)、品質重視(金融系など)、リファクタリングを予定している(他の項目とリンク?)、技術面でのリスクが見込まれる(部分的な性能低下やリソースの異常消費など)、細部の仕様変動が見込まれる、などで、要は【機能の改変無しで内部構造を複数回変えることが見込みまれる場合】になると思います。

適用して「凶」のケースは、
短命なシステム、とにかくリリースを急ぐ、性能目標が低い、技術面では枯れていてリスクが少ない、割と大きな仕様変動が見込まれる、テストケース数が少ない(単純で難度が低いケースばかり)。
要は、手間(=コスト)をかけたけど、自動テストが動く頻度が限りなく少ないケースでは「無駄」ですね。  多少以上の時を経て、複数回テストコードが動く・意義を発揮するケースでなければ「無駄なコスト」になり兼ねません。

ちなみに、テストドリブンを基本ポリシーにしているプロジェクト(大抵の場合に、その判断が正しいケース)でも、対象とするコンポーネント、層、サブシステム等によっては「適用の意義が乏しい」場合も有ります。
「ポリシーだからテストドリブンする!」で画一的に動いてしまうと、時間とコストの無駄で自分たちの首を絞める場合があるので注意が必要ですね。  慣れてしまうと、無意識と惰性で行動してしまいがちなので、複数のメンバーで振返りを行うことも重要です。

様々なリスクや高い要求を満たさなければならないプロジェクトでこそ、テストドリブンは効果を発揮するはずです。  部分的な性能改善や、製造が進んでからのリファクタリング(後の寿命が長いので混沌化を抑える必要あり)をする必要が生じたときに、「迷わずに手を付けられる」、「自動再テストを流せば安心!」というのは非常に心強いです!

Banner_02_2ブログランキング!

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

|

定例会(2008/08/22)

8/22は2週間に1回開催している定例会の日でした。

・16:05 ~ 16:05 (00) 業務連絡等 [業務推進部、他]
・16:05 ~ 17:45 (100) 社長からの話(クレドについて)
・17:45 ~ 17:55 (10) (休憩)
・17:55 ~ 18:05 (10) 5分間スピーチ [Sat]
・18:05 ~ 18:15 (10) IT-Tips [Ooh]
・18:15 ~ 18:20 (05) 振り返り

この日は、殆どを「クレド」の話題が占めました。
この辺に関しては、まさに社長が出してくる話題なので、社長ブログの方で書かれるだろうとは思うんですが...。
先ずは社内お披露目、という事で、出席した社員に全般を説明。  マネージメント層だけは、事前に公開・議論を重ねて来ました。
今までは「経営方針」としては文言が存在していましたが、クレドという「社員一人一人が自分の言葉として持つ」ような形態は有りませんでした。  ので、作る方も受け取る方も、なかなか準備が追いつかない面は有りますが、時間が解決してくれる部分もあるのでしょう。

5分間スピーチでは、外国人技術者とのコミュニケーションの話題が取り上げられました。  中国出身の技術者の方と業務上での話題を話し合っているときに、「キサマ、....デス」と繰り返し言われる。
え?、何か怒らせちゃった??、何で?
でも、語尾は丁寧だし、表情は柔らかだし、何だろう?
答えは、「貴様」(キサマ)でした。  相手は丁寧に、会話相手を尊重した表現をしていたつもりだったのですが、ちょっと使い方が違ってましたね。  ヒヤヒヤ、ドキドキしたひと時だったそうで。

IT-Tipsでは「ランダム関数」のお話でした。
ただのRandomクラスと、物理乱数を返すSecureRandomeクラスってのが有るんですね。  私自身はJavaに深く入る前に現場から離れてしまったので知りませんでした。  このSecureRandomeクラスの方が、特にLinux系OSにおいては /dev/random デバイスにアクセスしており、物理イベントを利用して乱数を発生させているとか。
なので、余りに頻繁に乱数を発生させようとすると、物理イベントの発生の方が追い付かなくなってリターンが遅くなる(物理イベント発生を待つようになる) → システム的なボトルネックになる!、というお話でした。
へえ~~~~~~。

Banner_02_2ブログランキング!

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

|

お仕事:アジャイルの妄想

「アジャイル」と記載してしまいましたが、「アジャイル系開発プロセス」と読み取ってくださいね、と、念の為。  要は、「ウォーターフォールじゃ現実的にリスク対処が先送りになるので、リスクコストが肥大化しちゃう」。  「こまめに作りを進めて実証しながら、リスクコストをトータルで抑えましょ」ってことです。
リスク管理視点からのみ、もの凄く乱暴な表現をしましたがご容赦下さい。  これから書くことの前振りが目的なので...。

オブジェクト指向開発バリバリ(技術水準も生産性も高い(←実はこれは大変難しい!))で、アジャイル系プロセスオンリーで活躍している企業さんがありました。  そこにたまたま、アスペアから1名のみが開発参画させて貰う機会がありました(2名で提案したんですが、残念ながら1名しか入れませんでしたね...)。

全体概要を少し聞いただけでも数十名体制、1年以上は必要としそうなプロジェクトです。
通常一般的には「アジャイルは少人数向き」(せいぜい1桁の人数体制向き)と言われます。  実際、その時の顧客でも、アジャイルで実績があるのは数名体制のプロジェクトばかりとの事でした。

失礼ながら、開発プロセスに関して幾分かでも机上で勉強していれば(或いは経験の幅によっては)、開発規模に応じて適した開発プロセスの選択、或いはカスタマイズ、或いは【複数プロセスの組み合わせ】が必須になることは知っているはずです。
ですが、その時は残念ながら「アジャイル最高!、今まで通りで出来ないプロジェクトは有り得ない!!」といった認識が、少なくとも表面上を占めていたようです(良識のある一部の方は、自ら抱え込もうとしている危機に気が付いていたのかも知れませんが...)。

アスペアとして参画させて頂いてから2ヶ月と経たず、プロジェクトは明らかに暗礁に乗り上げました。  反復計画(と呼んで良い物かどうかは別として)を大幅に遅延し、成果物は品質も低く(そもそも動かない)、今後どうやって回復させるかも目処が立たない状態です。
明らかにデスマーチに向かっているので、非常に残念ですが、アスペアとしては早期に撤退させて頂くことにしました。  契約上も間に1社入っており、提案し辛い・通り難い。  体制も整っていない(自社からの投入が1名のみで、リーダー格設定でもない)ということでは、こちらからの改善は厳しいと判断しました。

どんな場合にでも万能な開発プロセスなんて有り得ません。
理論的に完璧なプロセスがあったとしても、そんなことに大した意味は有りません。  大切なのは、そのプロジェクトの現場のメンバー達が「実行して、成果を残せるか」です。
「開発規模」もそうですが、プロジェクトには「開発メンバー」を含めて様々な【属性】が有ります。  【時間経過】も非常に大きな属性ですね。  それらに応じて、必要なプロセスを常に考える必要があるはずです。
その企業なりの「得意なベースプロセス」を持つのは、現実的で良いことだとは思いますが、それだけで「必要十分」と思ってしまった時点で危険です!  「ウォーターフォール一色」に染まるのに近いほどに、時としてリスクが高まります。

Banner_02_2ブログランキング!

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

|

雑記:オープン1年で御座います!

このブログも、生まれ変わってから10ヶ月を過ぎました(事務所を移転したときに、うっかり手続きミスで全消去してしまった!、しかもバックアップなし!!)。
特に「組織票」を構成しているわけでも無いんですが、どうにか2万アクセスを超えました。  これも皆さんのナマ暖かい眼差しのおかげです!  本当に有難う御座います。
時には、「もう書くのやめよう!」と思ったことが何度あったことか...。  つい最近も平日に2日間ほど穴を開けました(書き込みをサボりました)が、「もうやめた!!」と思ってたんですよ、まあ、個人的な事情でですがね。

リピーターの方がどの程度いるのか?(全くいないのか?)分かりませんが、まあボチボチと続けることにします.....。  でも、そもそも何でこんなもの書いてるんだ??、と問われれば、「こんなに素敵なアスペアを自慢しまくって、仲間を増やしたいんだよ~~~っ!」という事なんですね、実は。
こんなこと書いてるのも就業時間中です。
対投資効果はあると評価できるんでしょうか?

「人気ブログランキング」(転職・キャリア)カテゴリーで、最高17位まで行きました(そこで息が切れちゃったんですが...)。
単純に嬉しいです。  ネタは社員や業界のものですが。
もし関心を持った方がいたら、http://www.aspire.co.jp/ にもアクセスして下さい。  定例会とかも、応募者には適宜で公開してますんで。

Banner_02_2ブログランキング!

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

|

お仕事:でっかいプロジェクトは難しいよ~

以前は常時1つ以上は関わりが有ったように思いますが、ここ数年はアスペアとしては全くやってないですね。  大きくても30~40人体制の中の一部を占める程度です。

業界経験者なら痛いほど、まさに痛いほど感じると思いますが、巨大なプロジェクトは健全に進めるのが非常に難しいです。
巨大なプロジェクトを受注するのは必然的に(大抵の場合は)超大手企業です。  超大手起業が採用している開発手順は「ウォーターフォール」です!  断言してしまって良いのか?、と、業界関係者以外なら思うのかも知れませんが、関係者なら声も無く頷くでしょうね。  しかも、ちょっと憂いを含んだ表情で、横を向きながら頷くんじゃないでしょうか?

巨大なプロジェクトは、大手や中堅企業が下請けに入ります。  そして更に孫請けが入ります。  ひ孫や玄孫(やしゃご)、何だか分からないものも入ります。  間に入った会社からは、誰も現場に入っていないなんてことも珍しくありません。
指揮体系は「見かけ上」は決まりますが、これだけの商流階層を重ねて、現実的に効率的に機能する指揮体系が構成できる例は稀なんじゃないでしょうか?

プロジェクトに参画した企業・技術者たちがバラバラに考え・動くことが無いように、様々なガイドライン・決め事が山のように存在します。  参画すると、真っ先にその導入資料を読まされます。  1ヶ月経って、どれだけの人が記憶しているかは怪しいですが。
前述のように実質的な管理体制も希薄になるので、結局は各々の塊で動き易いように動き出します。  具体的な「書式」などは残るでしょうが、実際上の運用は、各人・或いは各固まりが「慣れている」やりかたで進んでいきます。

で、結局は成果物がどんどんバラバラになっていきます。
勿論、様々なチェック機構でこれらの混沌化を防ごうとはします。  正に凄い時間とエネルギー(コスト)を使って。

要求や仕様は、特に比較的初期は必然的にどんどん変化します。  時間が経ち、具体的な成果物(紙だとしても)が少しでも出てくると、またまた要件が変化し出します。  これらが、より良く会話されコントロールされ、指示・伝達されれば良いのですが、巨大なプロジェクトではそれ自体がまともに進みません。  実際に手を動かす人に届くまでに、時間が掛かったり内容が変化してしまったり、勘違いして受け取られたままで補正できなかったり。

プロジェクトによる差異は勿論大きいのですが、「良い形でコントロールされている!」と思えた巨大プロジェクトを見た・聞いたことはありません。  これらに巻き込まれると、メンバーが疲弊してしまい、良い結果・経験値にはなり難いです。
1回くらいは経験するのも勉強になりますが、何度も味わわなくても良さそうです。

Banner_02_2ブログランキング!

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

|

お仕事:中途採用面談時の質問

具体的なことは書きませんが、重要な点として、「こちらの尺度で、どういった要素でどの程度の力があるか?」と、「自己認識のスキルと、こちらが認識できるものの差がどの程度か?」があります。

本人が「俺はこれが凄く出来る!」と思っていれば、本人基準で高額の年収を希望してくるでしょう。  採用側の基準で「大したことはないな...」となれば、当然、出せる給与水準は下がります。  会話をすることでこのギャップを埋めたとしても、応募者側の妥協を要した場合、どうしても不満感が燻ります。

不満感が年単位で持ち越されてしまうと、例え採用・入社に至ったとしても退職の可能性が高くなります。  或いは、「このスキルならこの年収」という水準感覚が、アスペアの給与テーブル・職能給体系とかけ離れている場合も同様ですね。
応募者がどのようなキャリアプランを描いているのか?、と合わせて、当面の設定年収・年収の変化度合いなどを仮にでもシミュレーションしてみて、応募者のイメージ・基準と大きくかけ離れている場合は、残念ながら採用自体を控えることになります。
高い給与を支払うというのは一種の「賭け」であり「期待」「投資」ですから、パフォーマンスを発揮できないまま短期で退職されてしまったら痛手です。

それから、先に書いた項目「こちらの尺度で聞き取る」も非常に重要です。  前回に書いた内容とかぶるのですが、本人自身から申告される経験・スキルは、あくまでも本人の基準感・経験によるものです。  プロジェクト内で進捗報告を聞き取る場合と同じで、本人申告の言葉をそのまま鵜呑みにしてしまっては面談になりません。
周辺状況、組織の特徴、体制、役割、実際の判断とアクション例の幾つか、などを聞き取りながら、「こちらの尺度」に補正して聞き取りを行います。
これを怠ると、当然のことながら「アスペア基準で一緒に仕事をしたい人材」ではない人を採用してしまうことになります。  残念ながら、過去にそんな実例も有りました...。  苦い思い出ですが、着実に今後に活かすという点では実践しているつもりです。

Banner_02_2ブログランキング!

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

|

お仕事:自分で認識したスキルって

「真実」って、何でしょう?

また、いきなり変な出だしだぞ~と思われるでしょうが、「真実」を現実世界をベースに(言語的・論理的にではなくて)表現しようとすると、結構難しいと思いませんか?
特に人間の行動(+前提になる判断)が関わる事象。  複数の人間が関わり合ってたりすれば、なおさらのこと「どんな真実が存在するか」を言い尽くすのはとても難しい気がします。

例えば、面接などで自分自身の「スキル」を相手に説明する場面を考えてみましょう(ここではIT業界の面接を想定します)。  「どんなプロジェクトで、どんな役割で、どんな経験をした。何を考えて、どう行動した。結果はどうなった。何を習得した。(云々)」  お互いが共通の事実を記憶・認識しており、使われる言葉の前提認識・レベル感などを高いレベルで共有できていれば話は別ですが、それだったら、そもそも面接は必要無いですよね...。

相手が知らない自分のスキルを説明する(高い評価を得る)のが目的ですが、自分のスキル認識を支えている、或いは表現するための言葉は、それまでのプロジェクトで自分が関わった人達が、組織がよく使っていた言葉・認識・基準感がベースになります。

既に複数の顧客のプロジェクトでの開発経験のある方なら分かるでしょうが、会社・部署、プロジェクト単位により、標準として使われる言葉や前提認識は結構バラバラです。  いくつものプロジェクトを経験していく内に、この言葉・表現なら「だいたいこの辺りの意味・レベル感」といったアナログ感覚が身に付いていきます。
言うまでも無く、これは「その人が経験してきた世界」で「その人が感じ取り、認識した結果」です。

自分のスキルをどう説明するか?  それをどう聞き取るのか?  これは、実は非常に難しいはずの事なんですが、それを望ましいレベルで意識して自分のスキルを説明できる人ってのは滅多にいません。
いや、会ったことが無かったかも知れません。
当然のことですが、聞く側も大変難しいです。  聞き取り間違えれば、採用すべき人を落としてしまったり、その逆になったり。  後々にも様々なマイナスの影響が出ます。

Banner_02_2ブログランキング!

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

|

お仕事:素敵なタイミング?!

人生、何でもそうですね...タイミング。
いや、いきなり失礼しました。
「ここに進みたい!」という次のステップが必要とするタイミングと、今関わっているステップから踏み出せるタイミング。  これがうまい具合に合わないと、掴めるはずのチャンスも手中にできなかったりしますね。  自分の、或いは会社としての能力に関わらず(会社の場合は「営業力」や「政治力」だったりするんでしょうが)。

ある技術方向を指向する技術者が数名いて、その技術方向の経験者を数名必要とする顧客・案件が有って、営業的な調整を行って来たんですが、結局プロパー社員が1人しか参画できないことになりました。
先行案件の終了時期が微妙に遅いのが響きました。
次期案件の方が、どうしても一気に人を集めたがっていたんです。
先行案件から一気に人を剥がしたら、プロジェクトが収束しません。  契約違反です、ビジネスとして成り立ちません。  人をすげ替えるなんてアクロバットも不可能です。

この中に、パートナーさんの技術者も含んでいました。  経験年数は長くは有りませんが、センスが良く、現場対応力が高い、モチベーションの高い方です。  誤解を恐れずに言えば、やたら経験が豊富であるよりも「より良い方向に対応していける人」「良くしようという意思の働いている人」は貴重です!
今回のパートナーさんは正にそういった方だったので、アスペアとの契約を中断しなければならないのは本当に残念です。
2ヶ月以上も前から調整を続けて来たのですが、次期案件側の都合や顧客意思ってのは制御しきれるものでもありませんね。  悔しいです。

Banner_02_2ブログランキング!

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

|

お仕事:退職しちゃいましたが...

もう3~4年前になりますが、当時のアスペアのトップを競う主任技術者でした。  個人としてのパフォーマンスは当然の如くに高く、リーダーとしての素養も実力も非常に高い、ポジティブ思考でいながら肩肘張らず、場の雰囲気をリラックスさせつつモチベーションを上げる人物でした。
「この業界に入る時点から、どちらにしようか迷っていた業種がある」、「そちらの可能性を捨てられない、年齢的に方向修正をするならそろそろ限界」との理由から、退職希望を申し出て来ました。
元々が自律判断・行動力、モチベーションの高い人材を採用するようにしていますので、起業を目指す、より高い水準の動きを直ぐにでも実現したい、技術方針に同意できないなどの、比較的先鋭な理由で退職する人間が少なくありません。
相性が合えば、会社と個人が相互に益の多い、仲間同士でも刺激し合える居心地の良い会社として認識して貰えるのですが、指向が鋭く狭い傾向の人だとなかなか安定はしてくれませんね。
この主任さんの場合は相性がとても合っていると思っていたので、退職意向自体がとても意外でした。  しかし、理由が理由です。  本人にとっては別の可能性に挑む為の退職ですから、人として、仲間としては応援して送り出すべきだと考えました(「管理職」の立場としては、正直、苦しい心持ではありましたが)。
元々がスポーツマンで、何気に結構高い水準の人だったようです。  で、自分が何かしらのスポーツをするのではなく、スポーツをする人の体を守る・直す・整える仕事をしたいとの事。  実は専門の学校があり、大変な倍率&卒業が大変に難しいらしい...。
時は過ぎ、既に通常のカリキュラムは修了し、現在は「教える側」の学校に通っているとの事です。  で、最近はアスペアの事務所に頻繁に顔を出し、ITのお仕事をしています。

あれ?、何それ???

いや、学校は継続しているんですが、実は学費が非常に高いらしいです。  で、季節によって自由になる時間が大目のときは、アスペアで開発系のアルバイトをして貰っています。
かなり厳しい授業で、覚えることも山のようにある&実習も容赦ないらしいんですが、開発のバイトも続けています。  さすがに最新のWeb系技術をフォローアップしているという訳には行きませんが、判断・行動力、生産性は今でもかなり高い水準です!   う~ん、失礼ながら、化け物ですね。

でも、本人が言うには、「IT系の知識や考え方、アプローチは今の職業でも絶対に必要!」とのこと。  なので、意識的にある程度のフォローはしているそうです。

Banner_02_2ブログランキング

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

|

お仕事:生産性が低いんですけど...

ある顧客先で、アスペアのメンバーも上流工程の作業中です。
今後の工程分の見積作業を並行して行っているのですが、ここの顧客はバリバリのウォーターフォールでの開発。  規約関連の書類が、めまいがするほど多いです。  作成必須のドキュメントも、種類も量もまさに山のよう。  こんなに書いて、誰がどうやって、幾らかけてメンテナンスをするのだろう?

成果物がとにかく細かく規定されているので、工数積上げ式をベースにして見積もってみました...。  ビューが細かいので、業務に入っている者に作成して貰いました。
う~~~~ん、総工数でかい。  担当者から聞いた範囲の機能からして、「何でこんなにでかいの?」という工数です。
試しに、FP法(ファンクションポイント法(SPR法))でも試算してみましたが、概ね社内で開発プロセスを主導できる場合と比較してみると、生産性が1/3近くまで下がってます!
生産性係数が、これまでに実績のある案件でのかなり悪い方、「同じくウォーターフォールを大前提とされた場合」、「失敗プロジェクトで手戻りが頻発したケース」、「意味の理解が難しい「基準数値」の厳守を求められてテストケースを無理やり増やしたケース」、「やたら大量のドキュメントを要求されて開発自体が迷走したケース」に匹敵してます。

開発する側にとっても辛いですが、何よりも「高い見積」を各ベンダーから受け取る顧客側が困るはず。  果たしてこの見積は通るんでしょうか?  予算のプールが枯渇するんではないか?  或いは開発の中断??
規約を建設的に見直して頂くのが最も良い選択肢だと思うのですが。

Banner_02_2ブログランキング

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

|

お仕事:ウォーターフォールの幻想

「開発プロセス」という括りから、大昔から適用されている「ウォーターフォール型」。  その名の通り、水が流れる如くに上流の工程からカッチリ決めて次の工程に進めていく。  基本的に逆に流れることは無いはずだし、逆流は許さない。
理論的には正しそうな印象を受けます。  しかし、あくまでも「理論的には」です。  「成果物が形を持たない」という特殊性を持つシステム開発においては、「水の流れ」という単純な物理的イメージに沿ったアプローチでは無理が有ります。
「絶対に逆流を許さない」となると、一部でも要求や仕様が未決の部分があれば先に進めない。  結果的に要求・要件定義工程が異常~~に長くなり、最終納期は変わらないので後工程が逼迫する。  上流工程でつまづくプロジェクトは大抵その根本原因があるはずで、それは多くの場合に改善されないまま先の工程に「流れていく」。  次の工程でも計画よりはるかに長い時間がかかり、さらに後工程が逼迫していく...。
かくしてデスマーチプロジェクトの完成です。

とまあ、典型的なパターンを書きましたが、極まれな例外もあるでしょう。  しかし、「どんな課題とリスクがあり、どんなアプローチが効果的なのか?」も考えず、「巨大で超重量のローラーで何でも均一にペッタンコに仕上げて、完璧な状態で先に進む」なんてのは、現実的には殆どの場合で叶いません。

とてつもないコストをかけて、でも完成度には現実的な限度がある。  一部でも先に進めてみないと分からない事も少なくない。  それでも、「各ステップを完璧に済ませ続ければ、ウォーターフォールの方が良い」というのは、明らかに現実を直視していない理想主義者か夢想家の見解です。

こういったプロジェクトを受注する企業は、当然ながら生産性が低いので、対象となる機能数や難易度に相対して高い見積を出さざるを得ません。  そこで、発注側の企業はどう出るか?  「予算が無いからもっと安くしろ!」
いや~~、コストの掛かる方法を自ら選択し、それを厳密に守ることを要求して高コストの必然を招いておきながら、「安くしろ」ですからねえ。
このようなパターンに遭遇してしまうと困ります。  と、困ってもいられないので、何とかお得意さんの声に応じられるよう「工夫」して対処するわけです。  このような流れの中にドップリ漬かって適応する技術者と、別の道を探しに外に出る技術者がいますね。
どちらが良いとか悪いとか、言うつもりは全く有りません。  それぞれ支えているものは、相応に難しく重要なものでもありますから。

アスペアには後者の人間が集まって来ます。
どう進めるべきなのかを顧客と話し合い、提案します。  そして、より納得できる方法で先に進めていきます。

Banner_02_2ブログランキング

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

|

雑記:ひああああ!、24位だああ!

いや、失礼しました!
「人気ブログランキング」【転職・キャリア】のカテゴリーで24位に入りました!  初めてです!  嬉しい~~~~~っ!!

25位以内に入れると、表示枠(テーブル)が違って、銀のカップが表示されるんですよね。  クリック応援を戴いた方々、有難う御座います!

順位が目的と言う訳ではないはずなんですが、やっぱり単純に嬉しいです。  それに、何と言っても、やはり上の方にいると見てもらい易いですからね。

Banner_02_2ブログランキング!

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

|

新卒採用:ガイドラインと会社のカラー

アスペアの2008年の新卒新人は3名です。
(本当は4名だったんですが、1名が単位をこぼしまして...)
「残念でした」の1名を含めても、全員が「逆求人フェスティバル」というイベントを介して採用した人材です。  ネットで手繰れば出るでしょうが、学生側がブースを構えて、企業側の人間がブースに訪問するという、見た目上、逆の形を採ったイベントです。
学生側は自分のブースを運営しなければならない。  宣伝材料、デモ素材を用意し、自身を売り込みます(中には、準備の自覚のない学生さんも散見されますが)。  つまり、「このイベントに参加している」という時点で、「自ら動く」という自律性・能動性・【覚悟】などのフィルターが効いてるんですね。
企業説明会などで、基本的に誰でも入れますよー、採ってくれないかなー、どんな会社か見るだけ見よーという、ある意味ぬるい意識の学生さんは殆どいません。
企業側と学生さんの話は、基本30分の枠の中で行われるので、真剣勝負です。  それに、かなり疲れます。  1日フルにいると10人以上と会話することになりますから。
そんな、結構な負担のイベントに複数回足を運んで、自分にあった企業・仕事を探そうという真剣な学生さん達。  そのような人達の中から、アスペアは4名を選ばせて貰いました。

全員に概ね共通している面があります。
先ずは個性的ですね。  まあ、個性の無い人ってのはいない訳ですが、訴求力が強いです。  黙ってませんし、個性を隠そうともしてません。  自分らしい自分にポリシーを感じます。
それと、基本的にポジティブです。  必要な「反省」はしても、うだうだと「後悔」を続ける人はいないようです。
それに話し好きですね。  結果的に話し慣れています。  定例会などで前に立ってもらいスピーチをさせても、事前準備で大騒ぎしません。  さくさくと、しかも元気にこなしてしまいます。
あ!、全員が文系ですね、確か。  少なくとも残っている3名は文系です。  「いかにもな理系の人」だとコミュニケーション力、日本語力に問題があったりしますが、幸いにして3名にはそのような傾向は見られません。
あと、「IT系の知識や経験はほぼゼロ」の人ばかりでした。  「既にサーバーサイドJavaをボリボリ経験している」人でもいれば確かに欲しいですが、そんな人は殆どゼロです。  それよりは、「伸びしろ」の豊かな人に入ってもらった方が余程良いです!

上記の結果は、偶然になった訳ではありません。  ガイドライン、というほど大層な物ではないのですが、やはり採用上の基準があります。  或いは、必ずしも明文化されていない「アスペアの空気・カラー」が、どうしても反映されますね。
「類は友を呼ぶ」。  こんな所でも当てはまる言葉です。

Banner_02_2ブログランキング!

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

|

お仕事:異業種への転職...

つい最近、ある客先に先行して入っているアスペアの技術者と一緒に、増員参画してもらう人を1名、パートナー会社さんから募りました。  たまたま依頼されたスキルセット&レベルが比較的低めだったので、1年生(とは言え、異業種への転職者でしたが)の技術者2名との打合せを行いました。
同じ所属会社の方だった(しかも、同時に異業種転職した同僚同士だった)ので、1名だけを選択するというのは申し訳ない気もしますが、仕方がありません。
ほぼ同年齢のお2人でしたが、結局は以前に営業職を2年ほど経験していた方を顧客側に提案することにさせて戴きました。

「既に何が出来るのか?」も確かに必要な要素ではあるのですが、正直のところ1年生にはそれほど多くを期待出来ません。  より重視していたのは「伸びしろと効率」です。
「伸びしろ」とは、今後(先ずは1~2年の範囲で)どの位成長しそうか?という見込み感を意味してます。  ありていに言えば「やる気」「興味・関心」「自分なりのマイルストーンが有るか?」「率直な【喜び】にリンクしているか?」などのメンタル面、判断と行動に論理性や一貫性があるか?と言った基本的な能力面が前提になると思います。

一方の「効率」。  やはり自力だけで仕事は出来ませんし、多くの情報を人から引き出さなければなりません。  これも、ありていに言えば「コミュニケーション能力」となりますが、「質問のタイミングと頻度の判断」「質問のポイント」「得た情報の反芻・理解と応用」「話し易さ(相手に与える印象)」その他に分解されると思います。

「営業職の経験があるからコミュニケーション力が高い」という論法は成り立たないとは思いますが、今回会った方に関しては当てはまってました。  見かけが丸顔でにこやか、少しだけ訛りが顔を出す、それでいて発言はポジティブで論理だっているという、ある意味アクセント&インパクトのあるキャラクターでもありましたね。

学習という面から、特に異業種からの転職後1~2年は学習・習得すべき点だらけです。  混乱しないように時折復習・整理しながらも、新たな項目についてどんどん学習を続けるべきです。
この方の場合は、「1日の中で不明点・気になる点が有れば、その日の内に帰宅後でも調べて、場合によってはサンプルを動かすなどして理解する」とのこと。  それじゃあ土日などの休みは何をしているのか?と聞けば、「休みの日はしっかり休みます」とのこと。  メリハリを付けるのは良いことです!  トータルで学習効率も上がるでしょうし、ストレスも貯めずに済むでしょう。

未だ結果は分かりませんが、出来ればこの方と一緒にお仕事が出来れば良いなあと思っています。  ウチの社員の方も、ある意味で刺激を受けられるだろうとも思いますし。

Banner_02_2ブログランキング!

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

|

定例会から(2008/8/1)

社長ブログの方に書かれるかな?、と思って遠慮してたんですが、未だに書かれないので書いちゃいましょう。  まあ、両方に同じ題材で掲載されたら、それはそれで面白いだろうとは思うんですが。

先の定例会で、「付加価値を高めて契約単価を引き上げるには?」を課題として、出席した全社員でKJ法をツールとして話し合ってみよう!、というコンテンツがありました。
プロジェクトの状況が厳しくて暫く顔を見せていなかったメンバーも数名が出席していたりで、意外と参加人数が多い印象を受けました。  実際上は、1年近く前までの状況的には「普通の出席状況」だったんですがね...。
で、10名ほどを単位として2グループを構成し、KJ法で案出しと処理を行います。  具体的には、カード作り、グループ構成、空中配置、A型図解、B型図解、発表(1チーム10分)の順番・要領です。

カードとセロテープなどの「道具を使う」ってのも、日常とは違う新鮮味が有るんでしょうね。  結構わいわいと、冗談も飛び交いながらバリバリとカードが書き足されていきます。  あ、ちなみに、チームにはマネージメント層の人間は加わってません。  現場ベースの稼動が前提となる「主任技術者」までが加わってます。

●チームY
 カードの木のタイトルのみ書き連ねますが、
まず主張!、ヒューマンスキル、OutPutの質・量改善、プロジェクトの安定化、というサブタイトルで詳細が展開されてます。
●チームK
会社としてできること、営業としてできること、マネジメントとしてできる事、チームとしてできること、個人としてできること、といったサブタイトルの下に詳細が展開されてます。

う~ん、やっぱりリーダーと言うか、まとめ役の人のカラーが出ますね。  各チームの発表者(=パネルを纏めた人)は主任技術者でした。

最後に、定例会の振返り時の意見を書き並べて見ます。
概ねディスカッションに絡んだ意見が多くなってます。
・プロジェクターのスクリーンにマーカーで赤い線を引いてしまった。反省しています。【Osa】
・KJ法という基本的なアプローチを経験できた点が良かった。
・ディスカッション形式で他の人の意見が聞けて良かった(視点・発想が違う)。
・参加人数が多くてよかった(参加頻度の低いメンバーが出席していた)。

今回は(&今までも)技術者だけでディスカッションをしてしまったのですが、今回のような題材なら業務推進部にも加わってもらっても良いと思いました。  ちなみに、今のウチには営業部など他の部は存在してません。  対外的な名義を別とすれば、システム開発部と業務推進部のみです。

Banner_02_2ブログランキング!

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

|

雑記:皆さん、飲んでますか!?

なんだかフザケた題名が続いて申し訳ないです。

暑いです。  仕事中でもビール飲みたくなりますね。
中には炭酸やホップが駄目って人もいるでしょうが、殆どの人はビール(或いはビールもどきも含めて)が恋しい季節だと思います。

最近は低カロリー、健康志向(酒飲んで「健康志向」ってのはどうよ?、と思うんですが)のアルコール飲料が増えてますね。  でも、少なくとも3.0%以上はアルコールが入ってます。
一方、一時期話題になりました(最近はあまり見かけませんが)低アルコールビールと呼ばれる、アルコール1.0%未満のビール様飲料があります。  そんな中の1つで、以前から近所のスーパーで見かけていた、オーストラリア産の「ウエストエンドエキストラ」(0.9%)を、最近、生協で頼んで飲んでみました。

むお!?、意外と旨い!  国産ビールでは味わい難い、野太い麦の香りを感じます。  数kmのジョギングの後で、シャワーを浴びた後に一気に飲むのに最高です!  軽い脱水状態のときにアルコールの強いビールを一気飲みすると、結構酔います。  俗説によると、このような飲み方をすると通風になり易くなるとか。
最初に低アルコールビールから始めると、何だか悪酔いしにくいです。  結果的に摂取するアルコール量に変わりは無くても、水分の摂取量が違うからなんでしょうか?  立ち上がりのアルコール吸収が少なくなるからでしょうか?
元々が結構安く手に入るので、その点も含めてお気に入りのビール(?)になりました。

Banner_02_2ブログランキング

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

|

雑記:皆さん、眠ってますか?

勿論、今は眠ってないでしょうけど。
夏の盛りで、かと言ってクーラーは苦手という人もいるようなので、睡眠時間の確保、1日分の疲労を確実に解消していくってのが意外と難しかったりしますね。  プロジェクトでの稼動が高かったりすると、常態的な睡眠不足になる事も避けられなくなってきます。

営業職の人や、複数プロジェクトを横断的に見るマネージャなどは表を歩き回るでしょうが、特定プロジェクト専属で動く人は、1日にそうそう長い距離は歩かないでしょう。  運動量が乏しくて神経を多く使う人は、体は疲れないけど「疲労感」は積もるという、ある意味で不健康な状態になります。

このアンバランス状態を是正する為に、頭を優先してリラックスさせるか、バランスを取るために体の方の疲労感を上げる(運動をする)か。  と言っても、時間が無いときだと、ひたすら寝ることに時間を割り当てるしか無いとも言えますが。
リラックス系では、音楽、読書、パチンコ、お酒、カラオケ、その他。  1人でもカラオケに行って、大きな声を出すとスッキリするって人もいますね。  うん、とっても分かります。
運動系だと、手軽なジョギング、ジムで筋トレなど、夜は厳しいですがサイクリング、サッカー、野球、バスケット、中には剣道って人もいるでしょう(ウチにもいますが)。  私自身も21時辺りまでに帰宅できれば、体調と気分次第で5km程度走ってます。
疲労感のバランスを取っておくと、眠り易いような気がします。

やはり頭を使うお仕事。  睡眠もコンディション上の大切な前提条件の一つです。  「睡眠も重要な義務」とまで言うと嫌になっちゃいますが、まあなるべく快適に気持ち良く寝たいもんですね。

Banner_02_2ブログランキング

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

|

Mファイル:産休秒読み!?

アスペアチームとして(パートナーさんを1名含んでますが)ピーク時で4名で開発していたプロジェクト(請負契約だけどセキュリティ・ポリシーに基づいて客先敷地内で開発)があり、その中に産休間近の女性エンジニアが1名含まれてます。
通勤的にはちょっと遠めなんですが、SES契約ではないので出勤・退勤時刻はアスペア内である程度柔軟に調整可能です。  基準は10:00出勤なのですが、交通機関の混み具合を考慮して、更に30分シフトして10:30の出社としています。

ちょっと残業稼動を含んでいて、40時間位でしょうか。  トータルで月間稼動が200時間までには達しませんが、体の状態を考えるとちょっと心配です。
本人自身は「安定期だし、特に辛くはない。無理もしていない」とのこと。  このまま順調に経過してくれればと思います(初産ですから慎重にね)。  もうすぐ終了する案件ですが、稼動が落着いて来ているのでホッとしています。

10月末くらいまで働きたい(働けそうかな)との本人意向なので、許容できる案件と時期・顧客との認識合意の下に次期案件の調整も進めています。

Banner_02_2ブログランキング!

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

|

お仕事:妻の出産とお仕事

大分前の話になりますが、ある巨大なプロジェクト(全体で数百人が開発に関わっていた)に数名で参画させて頂いていた時がありました。  (ちなみに、最近はこういうケースは避けています。外側からの調整依頼が届かないケースが多いので...)
請け元企業の(ベンダー内)リーダーさんの奥さんが、もうじき出産との事。  ですが、殆ど連日、深夜帰宅の状態でした。  あれじゃあ立会い出産なんてとても無理だろうなあ。
たまたま現場訪問したある日、前日に奥さんが出産されたとの事。  一夜明けましたが、未だリーダーさんは現場にいます。  「これから2~3時間現場を空けて、産院に行って来るみたいですよ」とマネージャーさんから聞きました。  いくら生むのは奥さんだと言っても、これはさすがに可愛そうだなあ、と思いましたが、プロジェクトの状況と立場からすれば仕方が無いということになるんでしょうか。

現状でも男性の育児休暇取得が2%に満たないそうですが、10年近く前ですので比較にもならないでしょう。
今のアスペアならば、そもそも過負荷に至るリスクの高い(制御不能なリスクが多い)案件への参画は控えますし、出産や結婚などの大きなイベントは分かっている時点で(可能なら参画前でも)顧客側に話し、休暇取得のネゴを取っておきます。  事前に話せないほどの長期プロジェクトへの参画も控えていますが、もし途中段階でも分かれば営業的な訪問をして相談・ネゴを取ります。
そういった判断がマネージメント担当者の個人依存にならないよう、毎週のマネージメント会議で状況や判断・アクションの共有も行っています。
まあ、だからと言って「完璧にやってます!」とまでは言えませんが。

家族や生活があってこその仕事です。
誰かが犠牲や不幸になることは、何としても避けたいですね。

Banner_02_2ブログランキング!

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

|

Mファイル:客先で表彰された!

山手線の東側、この数ヶ月間、やたら負荷が高く厳しいプロジェクトが有りました。  アスペアはWebアプリ開発者集団ですが、時には要件実現のためにバッチ処理が含まれることもあります。  アスペアから参画したうちの1名がバッチチームに配属され、その客先でも類を見ないほどの高稼働プロジェクトになってしまいました...。
ママさん主任技術者の【Mur】さんです。

既にカットオーバーを終えて落着いていますが、つい昨日、今後に関しての本人希望を聞き取るべく打合せを行ってきました。  たまたま本人の休暇日だったので、自宅最寄り駅まで出向いて喫茶店で打合せを行いました(ちなみに、打合せに要した時間数は、社内月報にはちゃんと計上して貰いますよ)。

その際に出た話題だったのですが、「私、お客さんの所で表彰されちゃいました!」と。
いきなり何のこっちゃ???、と思いましたが、期毎にリーダーの推薦を元にエントリー&決選投票し、受賞者を決めるとの事。  数多くのプロジェクトが同時並行して動いている客先なので、表彰者として選出されるってのは大いに光栄な話です!
無論のこと、ただ単純に稼動が高かったからと言って戴ける賞ではない。  その実績、業務姿勢や周囲との関係、現場の雰囲気に与えたプラスの影響など、様々な要素をプラス評価戴けたようです!  嬉しいですねえ、うん、本当に。

本人も、まさか自分が戴けるとは、本当に夢にも思っていなかったようで、最初に受賞の連絡を受けたときにはドキドキしちゃったとのこと。
落ち込むことも有ったようですが、踏ん張ってきた甲斐がありましたね。

Banner_02_2ブログランキング!

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

|

雑記:ハリーポッターとソフトウェアモデル

何やら時事ネタのようで全然違うのですが、申し訳ないです。
ハリーポッター・シリーズのおかげで、ファンタジー系の書籍が子供の為のものではなく、「大人が読んで楽しめる」物だと認識されるようになった、とか何とか盛んに言われてますが、実は私もこの本でファンタジー系に入り込んだ(と言うほどでは無いんですが...)クチです。
「ダレンシャン」も全巻買って読みました。
「ネシャン・サーガ」はウチのカミさんが買ってましたが、1~2ページ読んで挫折しましたね。

一方は貪り読める、一方は巻頭部分で挫折、この違いは何処なんだろう?
深く考える必要も無く、「鮮烈な画像を具体的に頭に描ける」、「イメージできるシーンがストーリーと共に展開できる」点が違います(勿論、個人差は多分にあるでしょうが)。
「ハリー」は映画化もされているので、やはりその俳優さんのイメージで想像が展開しますね。  明らかに想像し易いです。

ところで、改めて言うまでもないことですが、ソフトウェアって形が無いですよね。  何らかのアプローチで視覚化しないと扱い辛いので、オブジェクト指向やUML表記を利用したりします。
で、「よいモデル」(基準は多様ではありますが、ここではOO的に美しい事を指すことにします)って、頭の中にイメージし易いですよね。  モデルを読むのが楽しかったり、感動したりします。
そんなモデルを自分の頭の中から捻り出せるのがアーキテクトです。  「ITアーキテクト」と表現してしまうと範囲がえらく広がってしまい、敷居が高くなるのですが、ここではそこまでには意味を広げません。

人を感動させられるかどうかは別としても、「頭の中に自然なイメージが展開できない」モデルは、実現(実装)の工程でも無理が生じます。  「画像イメージにすがるのは知能が高くない証拠?」なのかも知れませんが、現実には大抵の人が「イメージから入ると理解が深まり、結果がぶれにくい」はずです。

がっちりとファンをつかんで離さない「ハリーポッター」と、優秀なアーキテクトが描くモデル、無関係のようで属性的には近いものを感じてしまいます。

Banner_02_2ブログランキング!

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

|

雑記:読書とプログラミング

私事になりますが、比較的最近まで本を読むということが苦痛でした。
いや、いつの間にか苦痛が増してきた、と言った方が正しいのかも。
ぶ厚い本でも薄い本でも、読み残しているページの量・比率が気になって仕方がありません。  一定時間読み終えるたびに、全体量の内の何割程度を読み終えたか?チェックしてました。  本の内容の如何に関わらずです。  楽しく読んでいる本でもそう。

でも、楽しい本は「読んでいるという時間そのものが悦び」なのであって、残りが少なくなるのは悲しいことです。  この当たり前の事実をやっとここ数年で自覚して、楽しむべき本はじっくり楽しく読めるようになりました。

今ではもう開発の現場からは遠ざかってしまいましたが、以前は主にC/C++でのコーディングもしてました。  巨大ではないシステムを自分一人で全工程・全機能を担当するというパターンが多かったので、コーディングはとても楽しみな作業でしたね。  自分で構築した汎用部品、アプリに依存したモデルと基本構造、ドメイン依存部分の作り込み、基盤部分の改修や拡張に手を付けたり。
今のJavaEEアプリに比べれば他愛のない代物でしたが、じっくりと楽しめたものでした。

しかし、その内に社員数が増えてきて、人の管理・他プロジェクトのフォローや営業支援、その他雑用が増えてくると、プログラミングをポチポチ楽しんでもいられなくなってきます。  生産性・コストを無視できませんし、「いつまでも自分で書いてんじゃねえ!」って話になるのも必然です。
段々と現場に入る時間比率が下がり、2000年の明けにはついに管理側100%になってしまいました...。

今の現役の技術者たちは、良くやっていると思いますね。  ビジネスの速度は速いし、イコール納期は概ね短いし、業務アプリなので仕様も複雑だったりするし(特に「金額」を扱うのは辛そうです。少なくとも私は苦手です)、仕様の変動も起き易い。
そんな中で、多くの技術要素を覚え・消化吸収し、リスクに対処しながらシステムに形と機能を与え、完成させるんですから、格好良いと思います!  いや、実際凄いと思ってます!!
にもかかわらず、結構楽しそうにプログラミングしてますね。  本当に切迫している時には、さすがに楽しんでもいられないんでしょうが。  テストファースト等のアジャイル系プロセスのプラクティスにも、結構「作り手」として「楽しめる時間」が必然的に設けられる部分が有りますね。
嬉しい、有用な武器だと思います。

Banner_02_2ブログランキング!

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

|

セキララ:劇団やってます

アスペアの社員で、劇団やってる人がいます。

人によって、トライアスロンだったり、トランペット(ジャズ公演)だったり、企画モノで外国ともやりとりしてたり、色々な人がいますが、劇団やってる人は初めてですね。  多分。
アンパンマンミュージアムでも活躍してたそうです。  エンターティナーですね。  私にゃ絶対マネ出来ません。
9月13日(土曜日)に公演します。  小学生以上は500円だそうで、「みんな来て下さい」とのこと。  私も、子供達のプールがある日ですが、たまにはカミさんに任せて行ってみようかと思ってます。
劇団員さん4人いますが、どの人がアスペア社員かは秘密にしておきます。
Pict2132

Banner_02_2ブログランキング!

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

|

Mファイル:個人希望は?

マネージメントの"M"ファイル、今日は山手線の東側から。
極めてキツイ開発スケジュールの中、女性リーダーとして(実質はかなり支援戴いたのでサブリーダー稼動だったと言った方が実情に合っているが)顧客や他社メンバー達と開発を終え、保守部隊への引継ぎ準備で概ねマッタリと過ごしている8月の【Mor】さん。
強行軍の末の打ち上げで、かなり盛り上がったらしい。  焼肉屋で朝の4時まで皆で騒いでいたとか...

開発工程の途中でも幾分か話題にはして来た事なのだが、本人に確認しておきたいことが有り、「個別ミーティング」を行いました(ランチミーティング等では、なるべく同じ現場の皆が集まるように調整して貰ってますが、今回は目的が違うので)。
直前回は非常に厳しい開発スケジュールとなってしまったが、今後、同じ顧客で業務をどこまで継続するか?

本人意向だけで決める訳ではありません。  言っている事、考えている事に「それは違う」と思われる部分があれば意見交換します。  しかし、ずっと現場にいた人間本人の視点と所感・意見・意思は無視できません。  と言うか、無視すべきではありません。
カットオーバーが済んで一段落した段階で、恐らく心も平常心にありそうなタイミングで改めて本人確認を行います。  「どう?、自分としてはいつまでやりたい?」
【Mor】さんの応えは、プロジェクト途中に聞いた答えと同じでした。  「今回はプロジェクトを上手く回せなかったので、未だ抜けたくない!」、「リーダーかサブリーダーとして、しっかりプロジェクトを回した実績を残してから抜けたい」とのこと。
彼女の性格からして答えは変わらないだろうとは予想していましたが、思った以上に明確な印象を受ける答えでした。
「高い負荷」に至ったのは、確かに彼女自身の判断ミスも効いている。  次回はリスクという荒馬の手綱をしっかりコントロールして、今回ほどの過負荷には至らないことでしょう。
さてと、他の2人のメンバーからも同じ話を聞き取らないと。

Banner_02_2ブログランキング!

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

|

雑記:[さん付け]で呼ぶこと/区別と差別?

職位名を付けて相手の名前を呼ぶべきなのか?
それは、組織内ローカルな事情・各位の目的に応じて必然的に変わるでしょう。  職位のイメージ・枠に捕らわれずに会話・発想することで、組織としての活性を高める、といったような事がよく言われます。  「組織としての形や習慣・意識を根付かせたい」ような目的が存在するような場合は、職位付きで呼ばれるでしょうね(直前に所属していた会社がそうだったと思います)。

アスペアはどうだろう?
殆ど職位なんて付けてませんね。  社長に対しても「さん」付けです。  昔からの習慣がそのまま引き継がれて来ているんですが、ことさら変えようという意図や力は働いていないような気がします。
私自身の意識としては、「相手に応じて言葉使いを変えたくない」という原則が有るので、新卒新人でも社長相手でも、極端に言い換え・呼び換えをしてません。  これは、半分は「言い換えを行うと、その判断が相手にも伝わってしまう」し、「微妙な場合の判断・行動が面倒臭いから」でもあります。
残り半分は、「自分が職位付きで呼ばれるのが大嫌いだから」です。
型枠が有って、そこに「ポン」とはめ込まれるような気がします。  時には「らしく」振舞うべき時も有りますが、何だか何もしていなくても仕事をしているような気がしてきます(変?)。
自分が呼ばれたくないので、(少なくとも口頭では)人に対しても職位を付けないようにしています。

みなさんの会社では如何でしょう?

Banner_02_2ブログランキング!

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

|

雑記:グリナを飲んでみました

味の○のグリナ、あちこちで宣伝してますね。
Web上からお試しセットが購入できます。  980円で6袋入り。
実は齢50に近い私としては、「しっかり疲れが取れる!」って謳い文句は、ちょっと惹きつけられるものがあります。  で、試しに買ってみました。

080804_190123 080804_190159
爽やかな青、と言うか水色のパッケージに入ったサラサラの顆粒。  グレープフルーツ味にしてあります。  3gという量も無理が無く、アミノバイ○ル(顆粒)よりは格段に飲み易い味です。
で、肝心の効き目は??  う~~ん、「よく分からない」と言うのが正直なところ。  朝、幾分か早めに目が覚めるような気がします。  心なしか、スッキリしているような気がします。  自己暗示のレベルかな?、という印象です。
これは、言い換えれば「普段から必要十分には眠っている(回復している)はず」って事ですかね?  だからグリシン摂取しても変化を自覚できない、と。  確かに、モニターの人達で「もう手放せません」的な発言をしているのは60代以上の人が多いかな?って感じです。
良かった!  いかにも「効いたよ~っ!」って結果にならなくて!  「ジイサマ」の証拠を自ら打ち立てるところでした、ああ、危ない。
いや待てよ?  しっかり働いてないことの証明になってしまったのか?  芯から疲れるほど働いていないのか?、オレ?!

ちなみに、アミノバイ○ルは効きます。
運動後、60分以内だかに飲むと、筋肉疲労が残りにくくなります。  これは、ジムに通っているときに試しました。

Banner_02_2ブログランキング!

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

|

定例会(2008/08/01)

8/1(金)は定例会でした。

・16:00 ~ 16:45 (45) 社長からの話
・16:45 ~ 16:50 (05) 業務連絡等 [業務推進部、他]
・16:50 ~ 17:05 (15) 5分間スピーチ [Toka]
・17:05 ~ 17:15 (10) (休憩)
・17:15 ~ 17:25 (10) IT-Tips [Osa]
・17:25 ~ 19:10 (105) 単価アップを目指す上での必要事項について (KJ法)[全員]
・19:10 ~ 19:20 (10) 振り返り

最初のコンテンツ「社長の話」が長いのは、上期の決算報告を行ったからですね。  冬のボーナス想定も早くも発表され、通常通りの2.5か月分支給となる計画です。

5分間スピーチは、このブログに別記事として前回書きました「インドの人の英語」ネタでした。  IT-Tipsは「NetBeans」ネタ。  Javaの世界でのEclipseに相当するようなモノが有って「ウレシイ~」というお話。  .NETの世界の人達から見ると、VisualStudioの高機能・完成度から見ればEclipseも大分貧弱で不便だという意見もあるようですけれど...。
講師が興奮して、プロジェクターのスクリーンにマーカーで赤線を引いてしまうというアクシデント付きでした。  うう~~ん、アツイ漢だ!!

Pict2128 Pict2131 
最後のネタは、技術者を案件単位に見て契約を行う場合、付加価値を高めて契約単価を上げるのはどうすれば良いか?、を、全員にKJ法を使って考えてもらう、というものでした。  10名程度を1単位のグループとして、2グループを構成。  各々でディスカッションし、結果を発表するというもの。  この辺は、恐らく社長ブログ(http://blog.goo.ne.jp/y-kato-aspire)に書かれると思いますので省略します。
やはり、少人数のグループに分かれてディスカッションするってのは盛り上がりますね。

Banner_02_2ブログランキング!

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

|

定例会より(2008/08/01)

女性DBAの【Toka】さんの5分間スピーチ(実際は8分くらいありましたけど)からネタを戴きます...。

DBAメンバーとして顧客先に常駐していますが、インド人のエンジニアが多数働いているそうです。  【Toka】さんは英語・フランス語が出来るということで、インド人エンジニア達とは英語で直接コミュニケーションすることもあるそうです(通常は通訳の方がいるそうですが、夏休みで長期休暇中らしいです)。
各国の発音の特徴・クセ傾向から、同じ英語といえども「なまり」が有るんだそうですね。  例えば...

雑談の中で、インドという国に興味を示した際に聴いた言葉、「サマル」。
果たして何でしょう?  単語1つ分だそうです。
答えは、「Summer」、夏です。  「夏は暑いから来ない方が良いよ」と助言してくれたのだそうで。

次は業務中のお話。  用向きのお話が終わった後で、「あ、ついでに」という感じで話しかけられた際の言葉。  「ドコモン」。
ディスプレイ上にOracleの各種資料を幾つも開きながら、何かを話しかけて来ている、というシチュエーションです。
答えは、「Document」、ドキュメントでした。
「情報が集約された、読みやすいドキュメントは無いのか?」との質問だったそうです。
でも、どうして「ドコモン」なんだ?、と思いますが、日本人の発音も客観的には怪しいものなんでしょうねえ。

他には、「オパン」。  業務上の技術的なやりとりをしていた時だそうですが、複数のインド人技術者に囲まれて、口々に「オパン」、「オパン」と繰り返されたそうで(私だったらパニックになっちゃいますね)。
一体、何??
答えは「Open」。  「そのファイルを開け」だったそうです。

いつも常駐されている通訳の方も、最初はその発音のクセにかなり苦労されたそうで。  やっぱり、アジア系の人種がヨーロッパやアメリカの言葉を発音するってのは無理が有るんでしょうかね。

Banner_02_2ブログランキング!

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

|

お仕事:新卒新人の実務配置

2008年のアスペアの新卒新人採用は3名(1名が事情があって脱落、元々は4名だった)。  6月末に集中研修が終わってから、継続的な案件に入った者が1名、ヘルプ参画したものが1名(対応が終わって、8/1に戻ってきました)、1名が待機しながら追加学習中です。
何処でもそうでしょうが、ロースキルのメンバーを最初に配置するのはかなりの難関です。  ですが、どうにかチーム構成の中に全員が組み込めそうな雰囲気。  未だ確定はしていませんが、嬉しいですね(ぬか喜びにならなければ良いのですが)。  もうそろそろ、「新人」と呼ぶのもおしまいにした方が良さそうです。

さて、営業活動は複数のメンバーが並行して活動しますが、ある顧客から「アスペアさんの新人を参画させて育てて欲しい」との要望を戴きました!  うわあ~嬉しい!  これも、先行して参画している技術者の実績と信頼のおかげです!  アリガトウ!、【Kin】さん!
と.....あれ?、もう新人いません。  一通り(未だ見込み状態ですが)はけちゃいました。  昨年の新人(2年生)は、既に幾つもの現場・案件を経験してバリバリ働いてます。  うを~~~~~~っ、こういう時に限って該当者がいないっ!  贅沢な叫びですな...。

仕方が無いので、特に懇意なパートナー会社さんから、年単位で長期対応して戴けるロースキルメンバーを受け入れる方向で調整中です。  短期じゃ困ります!  立ち上げて、他所に行っちゃった!、だと何にもならないですから(得られるものが少な過ぎます)。

Banner_02_2ブロ

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

|

« 2008年7月 | トップページ | 2008年9月 »