« 2014年3月 | トップページ | 2014年5月 »

2014年4月の記事

考課の季節;チャンスとMBO

このブログには、比較的・技術的な話題を書くことが多いのですが、それはあくまで結果的なものです。
敢えて意図的に、そのようにしている訳ではありません。

という訳で、今回は時期も時期なので考課にも関係するお話を1つ。

アスペアでは、重要な考課要素の1つとして、MBO(Management by Objectives)の運用をしています。
俗に言う、「目標管理」ですね(←こう書いてしまうと、「やらされる」感が漂うのでイヤなんですが...)。

基本的には年度単位(より長期の課題は、年度をまたがっても構わない)で、
共有目標(全社、及びオプショナルで部単位のモノ)と、
個人目標(キャリアプラン&スキル体系定義に従ったものが基本)を立て、
その実現方法と、想定スケジュール(&マイルストーン)を目標として設定します。

各年度のMBOは、年度の始まる前(アスペアの場合は3月が年度の始めなので、2月末まで)に作成します。
共有目標の設定も必要ですから、必然的に、全社目標も年度の始まる前に役員から公開されます。
(まあ、全社目標は早々ころころと大きく変化するものではないのですが)

で、各人の進捗具合は、適宜でローカルにミーティングしたり、年度内に2回の考課のタイミングで確認します。

が、ここで大きな問題が!

「年単位の目標」ってのは、どうしても「目前にある・所属しているプロジェクト」の状況や抱えている日々の問題・課題に埋もれてしまい、忘れがちです!(←正直言って)

プロジェクトの開始時に行うキックオフミーティングに伴って、各人が立てたMBOの内容を見直してもらいたいのですが、なかなか運用が徹底できません...。
顧客先に常駐しているメンバーだと、なおさら難しくなります。

で、私の方からちょくちょく「MBO!」を話題にするのですが、それでも限界が...。

と言うか、そもそも目標を達成できるような状況・チャンスをつかめるとは限らない。
勿論、目標の内容・立て方にも拠るのですが。

業務的な前提条件を必要とするような目標は、状況が変わったらある程度柔軟に書き換えていかないといけません。
が、これを忘れるんだな.....大抵。

で、これをチェックする為にも週報を上げてもらって、必要そうな時に声を掛ける/メールを送るなどするのですが、業務が多忙だったり混迷している時はMBOがどうとか言っている余裕が無い!(こんなこと、私が言っちゃいけないんですが、事実ですから)。

そもそも、業務的な前提を要するような目標は、「チャンスを取りに行く」必要が有ります!
難易度の高い目標ほど、チャンスの獲得も難しいでしょう。

逆に、ひょんな事からチャンスが目の前にポッと現れたりもする。
(まあ、普段からチャンスを呼び込むような行動を取っている必要があるのですが)

いつチャンスが巡って来るかは「予定」など出来ない。
チャンスを呼び込む努力をしても、手中に出来るとは誰も約束してくれない。

言い換えると、1年を振返ってみたら、「計画」とは違っていたけれど重要なチャンスが巡って来ていて、そいつを逃さずにしっかりつかんで実績を残せたりしている場合も有るわけです。

これを、「事前の計画に載せていなかったから評価しない」のはオカシイ!

「目標の変更記載をしなかったから」と言って、ゼロ評価にされたのでは、やる気にならない!
嬉しくないし、楽しくない!
そんなMBOなんて、運用上で腐っていってしまう。

実際、年間を通して得点がゼロのメンバーが続出しました。
怠けていたわけではない。
ある案件(反復開発が続く)が、限りなくデスマに近かったんですね。
それでも、その現場のメンバーは、目前のタスクを消化するだけでなく、何とかして少しでも「改善」していこう!、という意思と行動が確かにありました。

それでも、MBOの結果は、「業務多忙につき達成度ゼロ」。

これは、違う!  何かが間違っている!!

状況に流されて、ただ担当タスクの消化や、スキル相当の割り当てロールの役割を遂行するだけだと「MBOとしての目標達成」としての評価は難しいのですが、
・厳しい状況でも改善を意識し続けて働きかけた、
・偶発的にでもチャンスが得られた(自身の種まきの成果ならなおさら)、
・当初の見込みとは違ったが、チャンジ的なロールを任されて何とか遂行できた、
...等々、
当初は「目標」として挙げていなかったとしても、成長・成果、或いはプロセスも評価されるべきです。

MBOにはメタな定義(全社Value;全社として目指す価値・方向性)が有ります。
これも全社共通のモノです。
個人の成長と、会社の成長がリンクする要素です。

これに合致するものであるなら、当初の「目標」として挙げられていなかったものも、「成果」から逆順に見て目標を逆おこしする(意義の振返り定義=自覚)、難易度を当時を振返って設定するのもOKです!

そこから、MBOの評価として項目追加・或いは変更して、加点することにしました。

.....長文になっちゃいましたね、御免なさい。

色々な要素を含んだ問題なので、読まれた方に意味が通じない部分が多いかも知れません。
ここまで読んで頂けた方がいらっしゃいましたら、有難う御座います。

とりあえず、現場で一生懸命に働いてくれているメンバー達を、公正に評価する為に&成長して貰うために、MBOという切り口を設けて工夫し続けてるんだよ(なかなか上手く運用し切れて無い面もあるけど)、
...というお話でした。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

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

新卒新人がやって来た!

常時・開発の人材募集してますっ!!

...と言っても、中心は実務経験者・即戦力の採用なのですが、同じ業界の(特に採用担当者の)方ならばご存知でしょうが、「なかなか人が採れないっ!!!」。

特にWeb系の実務経験のある(厚い)技術者は「超」引っ張りだこですね!

とは言え、「来ない、来ない」と言っていても仕方が無いので、第二新卒・新卒者も対象に含めて、コストと時間はかかっても自社で育成していくしか無いんじゃないか?!...と話していた矢先のこと...。

やって来ました新卒新人さん!

正直のところ、今年の新卒採用は計画していなかった(新卒募集の告知もしていなかった)のですが、アスペアの公開サイト&ブログを見て、専門学校卒業の方から直接のアプローチが有りました。

社長の直感で(応募内容や文面などを見て)、「面白そうだから会ってみよう!」という事になり、トントン拍子で「採用っ!」ということに。

それが決まったのが3月の半ば過ぎ。

急いで教育専任者を決め、以前の社内教育カリキュラムをベースに最新版としてアップデートを掛けてもらい、入社に備えました。
う~~ん、泥縄...。

いや、散々の試行錯誤の末に練られた教育カリキュラムをベースにしてますし、教育担当者は若手のエースですから、問題なし!!
アジャイルな対応はお手のものですよっ!(...冷や汗)

で、入社直後の辺り(4/11)に定例会が有りますから、その後に歓迎会を開くのが、最も迎える側の面々としては参加し易い(調整が容易)だろうということで、急遽・幹事さんも決めて歓迎会の準備も並行して進めました。

Pict2641Pict2643たまたま定例会コンテンツの1つを担当予定していたメンバーが体調不良でお休みになったので、定例会自体を30分短縮して早めに終了。
歓迎会へとなだれ込むこととなりましたー!

事務所から近いイタ飯屋さんで、個室っぽい空間を1つ確保で来たので、騒がし過ぎることなく楽しく飲み食いして騒いで...、じゃなくて、心のこもった歓迎会が出来たんじゃないかと思います!

Pict2639Pict2640急遽幹事をお願いしてしまった2人にも感謝・感謝です。

新人の速形君、これから宜しくお願いしまっす!!
(先ずは覚えることが一杯で大変だろうけど、頑張ってねー!)

あ、そうそう!

新卒新入社員向けに、業種に依存しない初期教育(社会人としての意識、マナー、その他)は、例年アウトソースさせて頂いてます。
(今年は株式会社エールライフさんにお願いしました)

Pict2645Pict2648その会場が「中央大学駿河台記念館」だったので、最寄り駅は御茶ノ水駅。
すぐ隣は秋葉原、ということで、ちょっと足を伸ばして「カリーどら焼き」をお土産に買ってきてくれましたーっ!(パチパチパチパチパチ)

「カリーちゃん」キャラが、いかにも「世界に知れわたる秋葉原」してますっ!

お味の方は、「甘いんだけどカレー味のどら焼き」(そのまんま)。
驚いたことに、なんと福神漬けまで中に入ってましたー!

絶妙な味のバランス感ですが、妙に忘れられない、クセになる味でした。

う~~~ん、やるな、今年の新人は.....。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

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

脆弱性検証ツールを使い倒す!

4/11の定例会で、ベテランの紀さんから脆弱性検証ツールの紹介と活用のススメのコンテンツがありました。
Pict2636
紀さんは、リリースする成果物の品質担保、開発プロセス上の設計・製造・テスト上のガイドラインなどの作成・運用で実績の厚い人でもあります。

で、紹介戴くツールの名は「Paros」(パロス)。

基本的な検証項目は一通りチェックしてくれて便利なのですが、2006年以降に更新されていない、という事が残念なツール(←この点に関しては、後でも触れます!)。

具体例を元に、実際の操作方法・ツールの動きなどをデモしてくれました。
実際のPC上での操作を、プロジェクターで写しながらリアルタイムで動きを見られます。

Parosをプロキシとして設定しておき、
実際にアプリケーションの操作(検証したい部分の操作の流れ)を一通り実行させます。
すると、Parosが対象アプリの実行パスを記憶し、各種の攻撃パターンを自動試行してくれて、脆弱性の検証を行ってくれる、という流れです。

Pict2637Pict2638
結果は、先ず簡単に検証結果の一覧表示がされ、
更に詳細を参照すると、脆弱性が発見された部分の詳細説明、及び、具体的な改修方法を提示してくれます(全て英語ベースで、ですが)!

写真の例では、デモ実行のPC上にローカル環境を構築し、事前に意図的に脆弱性を仕込んでおきました。

結果、見事に引っかかりましたね!!

ただ、実は1回目の実行時には脆弱性の発見ができませんでした。
これは推測になりますが、脆弱性のパターンデータが多少ランダムに適用されるのではないかと。
テスト手順自体を、うっかり間違えたのかも分かりませんが.....。

しかし、上記の仮定が正しいとすると、同じ操作パスに対して最低でも2回以上はテストを実行した方が良いのかも知れませんね。
ツールの特性をよく理解した上で適用しなければ、とんでもない落とし穴になりますから。

で、先に述べた「2006年から更新されていない」点ですが、
「Paros」の後釜に相当するツールが開発・リリースされている旨、定例会に参加していたメンバーから指摘が有りました!

OWASP ZAP(ゼッドアタックプロキシ)
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project#tab=Main

他国語対応が成されており、有り難いことに日本語もサポートされています。
最新のリリースバージョン(2.3.0)が、2014/04/10 にリリースされています。

2013年中にも、バージョン番号の 2桁目・3桁目の変更を伴う、(恐らく)マイナー・バージョンアップが4回も行われており、機能拡張や安定性の向上が続いているようです。

こいつを使えば、「検証したい操作パスを手動実行する」必要も無く、対象アプリをパースして(?)自動的に操作ケースを抽出し、脆弱性検証をしてくれるらしい!!

制限もあるかも知れませんが、素晴らしいです!!

↓:IPAによるウェブサイトにおける脆弱性検査手法の紹介サイト
https://www.ipa.go.jp/about/technicalwatch/20131212.html

人手でテストケースの設計・作成・テスト実行をするのは極めて大変でコストも膨大です。
ケース漏れのリスクもあるし、ソース変更/機能追加/変更毎に、影響範囲を厳密&正確に判断してからテスト実行するというのも、正直言って現実的じゃありません。

担保できる品質の限界レベルが下がってしまいます。

こういったツールの存在を知らない、或いは知っていても敢えて「オープンソースのツールの利用は禁止!」なんて時代を履き違えた(?)プロジェクトも有ったりもしますが、
やはり積極的に導入して、その可能性と制限をしっかり把握した上で、効率的に活用したいですね!

MavenやJenkinsでテストの実行自体も自動化すべきでしょう!

ともあれ、ナレッジの共有(埋もれている知の掘り起こしも含めて)に貢献してくれた紀さんに、感謝感謝です!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

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

「振返り」結果をプロジェクト間で横展開する

請負案件で、社内持帰りで開発しているプロジェクト群では、開発プロセスの選択肢の自由度は当然大きめになります。

リスクの制御に見込みが立たない場合には、開発フェーズを複数に区切ってリリースさせて戴くよう、契約的な提案・調整が通る場合も有ります!

逆に言えば、残念ながら通らない場合も有りますが、その場合は受注範囲に含まれるリスク見込みの要素を抑えるよう、アプローチを変えたり...。
まあ、開発プロセスと、現実的な「契約」を良い形でリンクさせるというのは、特に受発注実績の無いお客様との間では、なかなか難しい面もありますが...(この辺はお客様側のキーマンの方;顧客社内(部署内?)の文化にも強く依存しますね)。

ともあれ、旧来のウォーターフォールそのままでのリスク先送り的な開発は絶対に避けて様々なアプローチで(営業的にも開発サイドでも)回避していく
ひとかたまり分のリスクのサイズを極力小さくして、リスクコストを抑えながら、お客様にも・開発を行う我々自身も不幸にはならないように進めていきます

さて、こちらからの提案でフェーズを分けることに成功した場合、
フェーズの長さ(工期)は必然的に短くなります。

フェーズの開始前には、想定されるリスクを挙げてみて(勿論、初期段階で「挙げ尽くす」ことは出来ませんが)、調査なりプロト作成なりのリスク吸収タスクを組み込みます。
(実態上は Redmine で管理していますので、チケットを切る形になります)
(アジャイル的には「アナログツール」=「かんばんボード」を使いたいところですが、物理的に離れた場所にいる顧客とリアルタイムで情報共有をすることが前提条件だったので、デジタルツールを選択しました)

フェーズの終了時点では「振返り」(KPT;K=Keep、P=Problem、T=Try)を行います。

Keep:良かったこと、引き続き行うべきこと、
Problem:問題点、拙かったこと、失敗したこと、
Try:前述のProblemを踏まえて(特に重要な点を主として)次は何をすべきか、

...をまとめます。

で、これを印刷して、普段見える所・頻繁に通りかかる所などに張り出します。

同時に、IRC(オンラインでのリアルタイム・チャットツール)のタイトル部分にもメッセージ表示させます(最重要事項を1つだけ簡略に)。

この振返りを繰り返しながら改善をしていくわけですが、所詮は人間が行うこと。

他のプロジェクトでも、時を前後して概ね似たような点が挙がったりします。

特に、プロジェクト非依存の問題点(Problem)と、それに対する方策(Try)、或いはナレッジ(言語的なものとか、環境面、プロセスや対人的な点とか...)は、プロジェクト間でも共有した方が良いに決まってます

ということで、社内共有する分には問題の無い情報に関しては、この「振返り」議事録も社員専用Webサイトに掲載して共有することにしています。

「ただアスペアという会社に所属しているだけ」ではなく、各々のプロジェクトの中;日々の業務を行っていく上でのナレッジ/情報共有を行うようにしています。

また、「[振返り]くらいは習慣化しようよね」・「前に振返った結果は大事な資産なんだから、活用しようよね」という、社内相互でのメッセージのやりとりにもなっていると思います。

人間、直ぐに忘れますから。

どうしたって、怠けますから。

楽な方に流されやすいです。

でも、社内の仲間;他のプロジェクトのメンバーから或いは過去の自分自身からのメッセージを受け取ることで、プロジェクトや構成メンバーが変わっても、改善の流れを失わないで;忘れないで済むようになるんじゃないか?!

幾分かでも幸せに開発が、仕事ができるんじゃないか、.....などと考えつつ、振返りの実施と・結果の活用&成果物の共有に、日々努めておりますー。


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

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

« 2014年3月 | トップページ | 2014年5月 »