成功する女性の教科書

久々にビジネス書を読みました。

成功する女性の教科書 ―世界最大の雑誌社社長が「妹たち」に教える仕事術

成功する女性の教科書 ―世界最大の雑誌社社長が「妹たち」に教える仕事術

邦題がひどい

こういう系の本によくあるのが、「成功」とか引きの強い言葉を並べるライフハック的なタイトル。
原作のタイトルは「BASIC BLACK」。
作者(姓がBLACKらしい)が今の状態を手にしたのは、こつこつと自分らしく生きた積み重ねの結果だということを伝えたかったそうです。

内容

作者が経験した内容をもとに、主に仕事関係で充実するためのTipsをまとめたものです。
トピックと解説だけではなく、ケーススタディやすぐに実践できる行動指針もあります。
私はカタカナ苦手なので、読み進めるのが結構大変でした＞＜

気になったトピックを以下に記しておきます。

360°の人生

「360°の人生」　それは、仕事、人間関係、家庭生活、家族といった日々の生活のあらゆる面に意識を向ける人生のことである。

この本が他のビジネス書と違うのは、言うまでもなく女性に特化して書かれていることです。
この一文がそれを象徴しています。

女性には結婚とか出産とか子育てがあったりする。これは逃れられない事実で、それを受け入れる。
家族や友人や趣味や他のいろんなものを充実して、しかも仕事も欲しい。欲張りでもいいじゃない。
全部を手に入れるのは難しいかもしれないけれど、自分が幸せだと思えるバランスですべてを両立すればいい。
そんな風に思いました。

権力

権力についての記述が独特だったので紹介したいです。
ここでいう「権力」とは、肩書きではなく、責任感とかリーダーシップとかそういうものなのかなと思います。

  • 権力＝常に全体像を見渡せること
    • わかるわかる
  • 権力＝コントロールできること、できないことが何かを理解すること
    • 自分にできるのは、自分には変えられないと認めた上で対応する、それだけだ。ふむふむ。
  • 権力＝闘うべき場面を慎重に選ぶこと
    • 最近痛切に感じる。行動を起こす前に十分考えること
  • 権力＝情報の流れを管理すること
    • これは必須ですね。必要な情報が行き渡っているようにすべきだし、不必要に不安にさせる情報は流れてこないようにする。
  • 権力＝己の強みと弱みを知ること
    • 自分の不得意な分野で能力があるふりをしない
  • 権力という概念に過剰にとらわれない
    • サーバント・リーダーシップなら当たり前？バランスのとれたものの見方を保つ。
  • 権力＝爆弾を投げる必要がないと知ること
    • 真の権力とは、鞭をふるわずしてチームの意欲をかきたて、目標を達成すること。
  • 権力＝手放すことを知ること
    • ミスをしても自分を責めない。何をどう変えればよかったかを考え、二度と同じミスを繰り返さないように学ぶ。


「爆弾を投げる必要がないと知ること」は、個人的にかなりグッときました。
まさにここ1年くらい作り上げてき(てもらった|た)のは、脅しではなく楽しみでプロダクトを作り上げていくことでした。
今も権力とかぜんっっっぜんないけど、チームとしてやっていく中で自然と身に付いたものが整理された感触がありました。

Casual-Talk #1でおはなししました！

2009/11/20に開催された、Casual-Talk #1にてお時間を頂き、初トークしてきました！


今技術調査をしている、ベイジアンフィルタについてお話させて頂きました。
本当はモジュールの内容についても触れたかったのですが、今回は使い方のお話です。

資料を公開しておりますので、よろしければご覧ください。
http://www.slideshare.net/aomushi510/casualtalk-1


perl-casualの方々はみなさん素敵な方ばかりでした！
かっこいいPerl-Mongersさんにもあこがれますが、
Perlが好きで、楽しく使っているユーザ同士の集まりというのも大切な場だと思います。


あと、ステキPerl女子のid:acotieさんとお友達になれて、とても嬉しかったです！！！

技術者からの事業へのアプローチ

はじめに

若気の至りで書いてますので暖かく見守ってください＞＜

エンジニアが月100万円稼ぐために

エンジニアが、例えば月100万円稼げるようにするためには何をしたらいいのでしょうか？

  • 技術を磨いてブログ＋講演料で稼ぐ？
  • 新人研修を引き受ける？

いろいろな方法があると思いますが、
まず、月100万円出してもらえるような事業に育てること、
それだけ出してもいいって思ってもらえるような技術側からのアプローチが必要だと考えています。


能力が高いエンジニアの方は本当にたくさんいらっしゃいます。
他の人や他の職種に比べて高くもらうべきだ、という主張はよく伺いますが、
お金がもらえる源泉である事業自体が収益が出るものでないと、気持ちよく払ってもらえません。
ブロガーにしても講師にしてもパイが限られているような気がするので
それよりも、事業がもっと儲かるように働きかけるべきだと思います。

理想の状態

今は以下の2つを理想の状態だと思っています。

構築にかかる投資を上回る効果を数値で出すことができる

構築には費用がかかりますが、それ以上の効果があれば投資を続けることができます。
逆に効果がないものは(会社なので当たり前ですが)投資を続けることができません。

その効果を数値で出すことができるようになると、
システム化する意義がわかってもらえるようになります。

例えば、業務システムの高速化であれば、

構築費用 ＜ 高速化された時間 x 一人あたりの人件費 x 業務を行う人数 x 効果が持続する日数

という見積もりが出ればシステム化することができるようになります。

事業の意思決定プロセスに技術者が入ることができる

構築内容が固まった状態でエンジニアに頼まれているようではだめだと思っています。
もっと事業にコミットして、意思決定プロセスに入るぐらいしないと、
エンジニアがメンバーとして認識してもらえません。
もっと安い会社に外注されてしまいます。


とはいえ、エンジニアのバリューを発揮できる箇所はあると思います。

構築するのに必要な要件が固まっているか、
将来の改修を見据えた柔軟性をどこまで保つか、

そういったエンジニアでないとなかなかわからない勘は
エンジニア以外のメンバーからすると意思決定に大きく影響する情報となります。


経験上、事業の立ち上げ時期は小さく始め、
拡大期に入るころに、量をこなすためにシステム化することが多かったです。
この時期に、事業側の状況を理解した上で投資できる金額に応じたシステムを提案できると
その後の意思決定プロセスにも入ることができます。

  • 構築にかかる投資を上回る効果を数値で出すことができる
  • 事業の意思決定プロセスに技術者が入ることができる

この2点を、エンジニア以外の事業メンバーからみてわかりやすい状態になっていると、
事業の中でのエンジニアの貢献が見える化され、
成果が出たときに評価してもらえる台に載ることができます。

じゃぁどうすればいいのさ

エンジニア以外の事業メンバーに、
エンジニアの存在をわかってもらうこと、必要性を理解してもらうこと。
そこから始まり、それに収束するような気がしています。

私もまだその域に達していないしわからないことが多いのですが、
今に至るまでのプロセスをまとめてみました。

事業部側が企画立案し、エンジニアに依頼する
(この段階では安く作ってくれるなら誰でも良い)

　↓　(技術者からの機能提案がある、事業部側の意図を汲み取る)

事業部側に、このエンジニアは柔軟に作ってくれる、
やりたいことをわかってくれると思ってもらう

　｜　　←イマココ
　↓　(技術者側から投資対効果が含まれた提案がある)

意思決定プロセスに技術者が載ってくる

　↓

事業拡大、もやもや
もやもや

　↓

事業が儲かる

　↓

エンジニアも100万円もらえるようになる☆★

途中からもやもやしてて夢がありますね。

書いていて気づきましたが

今のところエンジニアが出せるのは投資対効果までで、
やっぱり儲かり戦略、拡大戦略については事業部側に考えてもらうほうが良いですね。
でも、一気に事業拡大するにあたっては自動化は必須なので
ひとつのアプローチとしてはアリなのかなと思います。

YAPC::Asia 2009 特別研修に参加しました

YAPC::Asia 2009の特別研修「Moose入門」に参加してきました。少人数で、9時〜17時までみっちり勉強できました。

復習用資料

資料はgitで落とせます。exerciseがとても充実していて、exerciseができれば一通り講義の内容がわかるようになっています。Mooseの使い方を一通り知りたいかたはぜひやってみるといいと思います。

git clone git://git.moose.perl.org/moose-presentations.git
cd moose-presentations
git -b checkout origin/japanese

講義はMooseのマニュアルに沿ったものでした。Moose日本語マニュアルがすごくいいので、英語の400ページの資料にげんなりしちゃうときはこっちを読むとしあわせです！
http://perldoc.perlassociation.org/pod/Moose-Doc-JA/index.html

わからなかったこと

アトリビュートにdoesつけたときがよくわからなかったです。

  1 package Fly;
  2 use Moose::Role;
  3 sub fly {
  4     my $self = shift;
  5     print 'fly';
  6 }
  7 no Moose::Role;
  8 1;
  9
 10 package Wing;
 11 use Moose;
 12 with 'Fly';
 13 no Moose;
 14 1;
 15
 16 package Bird;
 17 use Moose;
 18 has 'wing' => (
 19     is => 'rw',
 20     does => 'Fly',
 21 );
 22 no Moose;
 23 1;
 24
 25 package main;
 26 my $eagle = Bird->new(wing => Wing->new);
 27 $eagle->wing->fly;

wingというアトリビュートにdoes 'Fly'したときって、wingには「Flyができるオブジェクト」をいれなきゃだめなんですね。(10〜14行目の部分)
こうして全体をみると当たり前のことかもしれないんですけど、アトリビュートの部分だけしか見えてなかったのでちょっとつまづきました。
でもオブジェクト入れないとってことは、isa 'Wing'でもいいんじゃ！？？doesで制限するときのシチュエーションがわからない！

同じメソッドを持っているいくつかのオブジェクトのうちどれでもいいっていうときに使うのでしょうか＞＜

若手IT勉強会に参加しました

第11回若手IT勉強会に参加させていただきました。初参加だったのですがみなさん暖かく迎えてくださって嬉しかったです。

内容

技術的な部分については、 d:id:seiunsky:20090913 で書いてくださっているのでいきなり割愛させてください><ちゃんと予習してから行くべきでした。とほほ。。
文殊堂さんのJUIの時のプレゼンももう一度聞くことができて良かったです！

懇親会

場所は神楽坂の「しゃぶ屋」でした。大根のしゃぶしゃぶがめちゃうまでした。
文殊堂さんのお話がはんぱなかったのでぜひそっちメインで残しておきたいと思います。

id:monjudoh さんが語る転職のやりかた

まずは勉強会に行け。
勉強会に行っているような人は普通に1人月以上の仕事ができる人たちばかりだから、その中で自分の強みを考えろ。
勉強会に行っているうちに縁がつながってくる。それから、まわりの人たちにどんな良い会社があるのかを聞け。そうするとつながった縁からおのずと見つかってくる。

かっこいい。
社外での活動も大事だなっと思いましたが、
(あたりまえなんですけど)そこに行くだけじゃなくって、自省して磨いていかなきゃだめですね。

インターンシップを終えて

8月17日〜28日まで、会社で技術系インターンシップが開催されました。
6名の学生さんと一緒に、2週間の濃ゆーーーいプログラムが始まりました。

プログラム

2週間を通して、既存の監視ツールの新機能開発がミッションとして課せられており、
前半はプログラミングのレクチャー&新機能の企画、後半は企画した機能のプログラミングをやっていただきました。
最終日に成果報告会を行い、それぞれの企画を役員陣から監視担当部署メンバーまで見て頂きました。

インターン生

理系の学生を対象に募集を行ったのですが、いざ面接を通って来る学生さんを見るとほとんどプログラミング経験がないっっ！！コンソールを立ち上げたこともlsコマンドを使ったこともない方ばかりで焦りました。
でも、人一倍好奇心をもった、向上心のあるインターン生の方々にきて頂きました。

1日目〜3日目

1日目のレクチャーでは、lsコマンドも知らないインターン生が多く愕然としました。これからやっていけるのかと不安に。。
(次からUNIX講座入れた方がいいっ＞＜)
2日目、3日目になってくると、面接の時には気付かなかった彼らの良い面が見えてきました。チャラいと思っていたのに熱心な子。自分中心なところがあるかと思っていたのにメンバーと共有をする子。全然タイプが違う6人がまとまり出したのもこの頃でした。

4日目〜5日目

2週間という短いなかでもひと山かならずあるもので、この頃はまさに葛藤期でした。
まずはタイピングが遅いという問題。そもそも事前課題で言っておけばよかったーーーー！
プログラミングは書かないと理解できないので、タイピングの遅さは死活問題でした。既に課されているたくさんの課題に加えてタイピングをやることになったので、彼らの負担はとても大きかったと思います。

もう一つは企画が小さくまとまり過ぎてる問題。
自分的には筋が通った企画でも、使い手が必要ないものであれば作っても使ってもらえない。その根拠作りに苦労していました。
これは一般のインターンシップのレベルを超えているという議論もあったのですが、
もともと自分の殻を破りに来ているのに、
今の実力でできることをやっても意味がないということであえて高いハードルを設定することになりました。

6日目〜9日目

5日目の壁を越えたら、ひたすらプログラミングするしかない！！！
実装＞＞＞＞＞＞＞＞＞＞飯 って子がいてうけたwww
そんなに好きになってもらえるととてもうれしいですね。
実装し始めはつまづきながらだった子も、
画面ができてくると一気に楽しくなっているようでした。

10日目

社員の前で成果プレゼン。みんなとても緊張していました。
プレゼンの仕方によると思いますが、やはり開発系でない社員も多いのでどうしても企画のほうにプレゼンの焦点が集まりがちなのが難点でした。
最初は、カラム追加とかは一部の人に限ってやって、集計系のシステムを作ってもらえれば、、と軽い気持ちでいたのですが、全員それを軽く超えてくる企画内容・実装内容だったので本当にびっくりしました。

まとめ

良かった点
  • 開発を楽しそうにやってもらえた
  • みんなアツくて個性的なメンバーだった
  • 実際に仕事で使っているシステムを見せるとやる気を出してもらえる
  • 他部署含めて、たくさん社員に登場してもらった方が良い
  • 山と谷を作ってあげると達成感につながる
  • 発表は豪快に！
改善点
  • 事前課題にタイピングを入れるw
  • UNIXレクチャーが必要
  • 社員コミットしすぎwww
  • これからの縁をつないでいくことが大切☆

いちばん嬉しかったこと

「やっぱプログラミング好きです！！この道に進むって決めました！」と言ってもらえた！
やばい＞＜泣ける。。

感謝

初めての投稿は、ずっと思っていたことを描いてみたかったのです。



まわりにいる人のことを幸せにしたいです。


大きなビジネスはできないし
今も昔もいっぱいいっぱいだし
少しずつ歩むことしかできないけれど

まわりにいる人が、楽しんで仕事ができるように
お手伝いをしたいです。


プロジェクトがうまくいくことも大事だけど
みんながやりがいをもって楽しそうにしているのがとてもうれしいです。


いつも苦しい思いをさせてごめんなさい
頼りにしています。みんな
いつもありがとう

感謝しています