語源に見るプロフェッショナルの条件

　ランチで仕入れたネタです。

　サラリーマン（いきなりですが、政治的にはサラリーパーソンってのが正しいんでしょうが、この語自体が最近聞かないので言い換えも目にしませんね）は和製英語で、salaried man に由来し、salary は、ローマ時代の兵士に対価として与えられた「塩」を意味するラテン語の salarium
が元。当時は塩が貴重で給料として支給されていたそうです。
　すなわち、サラリーマンとは給料をもらって働く人のこと。

　一方、プロフェッショナルの語源は「告白、宣言」の過去分詞であるラテン語の professus 。宗教用語。
　つまり神に対して告白、宣誓した人や神の託宣を受けた人を指し、最初は聖職者のみを指したそうです。
　それがまず裁判官や医師に広がったそうです。今でも彼らはプロフェッショナルのイメージに近いですが、善悪の Judge や治療は確かに神の領域により近いですね。
　語源からして、プロフェッショナルは誓いのために働く人であり、また自ら高い（神に準ずるような！）規範や倫理を課し続けている人のこと。

　その後、会計士やコンサルタントにも間口が広がったそうです。効率化のアドバイザに過ぎなかったコンサルタントをプロフェッショナルへと引き上げたマービンバウアーが高潔さと職業倫理にこだわったのは有名な話です。
　そして現在は漠然とハイパフォーマーを指したり、アマチュアとの対義語として対価を受け取る職業人（本質的にサラリーマンと一緒ですね）にも使われたりします。

　私は以前何も知らない時、「プロの心得：外を見つめる。まっすぐに。」で、

自分の中ではこの、組織の外を見つめて自分がいかに貢献できるかを追求するか、それとも組織の中で得られる権限を追求するかがプロとサラリーマンとの分かれ目だと思っています。

　と書きましたが、語源を遡るとその違いが際立ちます。

障害のある職場への暫定対応と恒久対応

　はてなの匿名ダイアリより、「とある医者漫画」

医者Ａは、自分の勤務時間が終わるとさっさと変える。休日返上で出勤はしない。救急患者がきて手が足りない時でも自分の管轄は救急科じゃないしもう勤務時間は終了したといって帰る人。それを非難されると、「スタッフが足りないなら医師に無理をさせるのではなく病院側になんとかしろと言うべき」と言う人。

で、自分は医者じゃないけど、医者Ａの考えの方が普通にまともだと思って読んでたわけよ。そしたら、まあ主人公が「休日出勤で頑張る側」にいるから当たり前っちゃ当たり前なんだけど、医者Ａを説教？かなんかして、結局Ａは改心、休日でも急患がきてもバリバリ働く人になりました、みたいなオチだったんすわ。いや、それはどうなのよと。Ａの言ってる事は正しいじゃんと。その説教シーンで、主人公が「自分が死んでも患者の命を救えるならそれが本望。それが自分の生き方」みたいなことをいって、Ａが改心するんだけどさ。それはどうなのよと。

　違う違う違う！
　どっちもおかしい！
続きを読む

学ぶなら、楽しんで。

　あー、すごい当たり前だけどなんとなく忘れていた感覚。
　Think! という季刊ビジネス誌の今春号の特集が「キャリアアップ勉強法」で、読者へ向けたメッセージとしてボストンコンサルティンググループ（BCG）日本代表の御立尚資さんの寄稿から。

　「これを知らないと世の中の動きから取り残されてしまう」という強迫観念から勉強を始めていないか。（中略）それよりも「よくわからないけど何か面白いことが起きているみたいだ」と思う方がよっぽどいい。基本書でおおまかな知識を得たら、たとえば、ネットで「セカンドライフ」（3Dの仮想ゲーム）をやってみる。これは実際の話だが、BCGの社内で Web2.0 について議論したところ、2回目のミーティングでは、50代半ばのシニアコンサルタントが「セカンドライフ」で自分自身のアバター（キャラクター）をつくっていて、それをプロジェクタで見せながら Web2.0 の実体験についてコメントしていた。

　机の上で、あるいは通勤電車の中で本を読んでも楽しくない。楽しくないから身が入らない、効率が上がらない。なら実体験の中で楽しさやすごさを「体感」した方がよっぽど身につく。
　子供の頃はサッカーをやるにしてもすぐに試合形式で遊ぼうとしたのに、なぜか最近は走り込みやパス練習だけを黙々と続けるような勉強方法ばっかり取っていました。

　よくないなぁ。

　エンジニアなので、ものを作り、動かすシンプルな喜びを忘れちゃいけないし、定期的に自分の心に陽の光を当てないと。

Think! 2007年春号 No.21

posted with amazlet on 07.05.07

東洋経済新報社
東洋経済新報社 (2007/04/20)
売り上げランキング: 277

おすすめ度の平均:

まっとうなことが書かれています。お勧めです。

Amazon.co.jp で詳細を見る

目的と成果を問う。賢く働く。

　生産性の向上は、より賢く働くことでしか達成できない。ところが経済学者や技術者は、生産性向上の鍵として、より賢く働くことに主役の座を与えようとしない。経済学者は資本を主役とし、技術者は技術を主役とする。

　知識労働の生産性の向上を図る場合にまず問うべきは、「何が目的か。何を実現しようとしているか。なぜそれを行うか」である。手っ取り早く、しかも、おそらくもっとも効果的に知識労働の生産性を向上させる方法は、仕事を定義し直すことである。特に、行う必要のない仕事をやめることである。

　ピータードラッカーの「プロフェッショナルの条件」からの引用です。

　作業と仕事の間に距離があるように、仕事と成果の間にも距離があります。
　「本当にこれって役立つの？誰に？いつ？どのくらい？」という問いは常に意識しておきたいものです。

　会議が槍玉にあがることが多いですが、日々目にするすべてのアクティビティに関して改めて問いかけてみると新たな発見が得られることがあります。さすがに丸ごと無駄ということは滅多にありませんが、でも「この人がやる必要はない」「毎日やる必要はない。週次で十分」「自動アラートスクリプト書いて任せよう」といったことはボロボロ出てきます。またプロジェクトが進行するにつれ、状況が変わったりスキルが定着することで見直すべきアクティビティも出てくるでしょう。
　SE の成果と貢献は設計書とソースコードに集約されるはずです。
　ならば、極論ではありますが、設計書とソースコードの量と質のいずれにも貢献しないすべての作業は一度は「止めたとして困るのか？」との議論の遡上に上げるべきです。

　また必要な作業でも、その目的に照らして、本当に付加価値を生んでいるか、付帯作業はないかと問うことができます。
　コーディングは必要な作業です。でも例えば関連する資料の印刷は？何か疑問が浮かんだ時の解決は？設計書の入手、最新であることの確認は？標準やルールの参照や従っていることの保証は？と探してみれば色々と気づける点が出てくるはずです（Eclipse をはじめ IDE がかなりの部分をカバーしてくれるようになりましたねー）。

　技術力が私たちの依って立つべき場所であることは間違いありませんが、仕事上の課題の解決の手段として「賢く働く」というのも常に検討すべきですね。

肩書きを疑う。成果を信じる。

あなたの会社ではどんな肩書きがあるでしょうか。あるいはどんな肩書きであなたは仕事をしているでしょうか。

ここでいう肩書きとはクラスとか職位のことです。

一般的な会社では部長や課長という肩書きがあるでしょう。
またこの業界ではプログラマ、システムエンジニア、アプリケーションエンジニア、リーダー SE、テクニカルプロフェッショナル、アナリスト、システムアナリスト、プロジェクトマネージャー、IT コンサルタント、ソリューションエンジニア、テクニカルアーキテクト、……とまぁ、いろいろな肩書きが存在します。

この手の肩書きには注意が必要です。
これらは会社の考えるキャリアパスにマッピングされた用語であり、個人の責任と役割を必ずしも表明しないからです。かつて５級社員、４級社員と呼んでいたものにプログラマやシステムエンジニアなんて言葉をマッピングしていたがために、なぜか基盤系のプロがアプリケーションエンジニアと呼ばれていたり、「経理の同期はシニアアカウンタントになる頃だから、君もそろそろ職位表上同列のシステムアナリストだね」なんてことが実際にあったりします。
大きな会社だと議事録と提案書を書き続け、コードは自分用のツールのために Excel/VBA しか書いたことのない人間がプログラマを卒業して SE に、なんて事もあります。入社 n 年経って n 千ステップ以上のコードを書いたので要件をクリアしているためです。（メインフレーマ系では日常的な風景のように思えますがどうでしょうか）

この手の肩書きには注意が必要です。疑いましょう。

実際、何をマネジメントすべきかを考えていない「マネージャー」や、基礎的な論理思考能力がなかったり知識を右から左へ伝えるだけで付加価値への情熱がない「 IT コンサルタント」や、ビジネスレイヤーでしか議論のできない「システムエンジニア」は多くいます。


我々の仕事を定義づけるのは、まず何よりも成果であり、次に付随する責任と、さらにその次にこれらを果たすための権限です。

これら、特に成果について、自分がどれだけのモノを引き受けられるかが、自分の仕事を測るほぼ唯一の尺度のはずです。

環境をも打ち倒すウェルチの「志」

今、文庫版の「わが経営」を読んでいます。

ウォールストリートのアナリスト向けに、ウェルチが初めて語った時の言葉がえらく気に入りました。そのスピーチ自体は失敗として振り返っていますが、ウェルチの強さがビリビリと伝わってきます。曰く、

我々は単に GNP に見合った成長を目指していたのではない。それは他の大企業の目標だ。GE が目指すのは GNP を牽引する機関車であって、それに引っ張られる貨車ではない。

んー、アツいですね。

業績発表の場で市場の冷え込みを言い訳に使う IT 企業経営者も多いですが…なんて語るのは楽だし卑怯なんで、自分を振り返ってみます。

私は技術面での成長のヘッドルームが見えたせいで、転職しました。
ホント、30代半ばを過ぎて「マルチユーザー OS」がわからないような SE がいる職場に辟易していたんですね。

でも外に出るのはある意味簡単だし誰でもできることですが、中に留まって技術面でのリーダーシップをとる事を通じ、部内のプロジェクトのリスク低減に貢献するという働き方もあったのかも知れません。（いやまー、技術がワカランというのが致命傷でなくリスクにしかならない SI はやっぱり壮絶っちゃ壮絶ですが）

何年後かに自分が身につけているテクニカルスキルを尺度にすれば、転職は間違いなく成功です。
でも自身のテクニカルスキルを使って組織の生産性に貢献したりアーキテクチャを部内に浸透させるなんて経験と比べたなら、多少のスキルの差なんて霞んで見えるかも知れません。

当時の私は自身の成長のため、環境の中でいかに選択するかを考えたわけですが、ウェルチはいかに環境と戦うかを考えている。
うーん、スケールの違いを思い知りました。

他にも有名な「 No.1 か No.2 になれない事業は再建か売却か閉鎖」に漏れた事業部の反論にはこう答えています。

「利益は出ている。一体何が問題なんだ」
場合によっては大いに問題だ。長期的な競争戦略がなければ、その事業が破綻するのは単に時間の問題に過ぎない。（強調は市井）

強い男ってのはこういうのを言うんでしょうね。
「生活はできている。一体何が問題なんだ」どこかで誰かが言ってそうです。

まだ上巻の途中ですが、久々に読むのが楽しみな自伝です。

Am I a Knowledge Worker ?

私はナレッジワーカーだろうか？

ナレッジワーカーのはずだ。
本当に？その根拠はいったい何だ？

続きを読む

オーナーシップを取り戻せ

「キャリアコンサルタントのひとりごと。」より「私はほかのだれでもなく、私である。」のトラックバックです。
この Blog では初の、単なる紹介だけになってしまうトラックバックです。

うん、うん、とうなづきながら読んでしまいました。

へたをすると、いかにその組織のなかで自分が優位に立つかということに腐心したりしますし、それで一喜一憂したりもします。

仕事をしている以上、意識すべきは仕事で関係のある人、とくにお客様に対して誠意をもって接しているか、ということでありますし、お客様から評価されているか、ということこそが大事なことなのです。

私が「プロの心得：外を見つめる。まっすぐに。」で言いたかったコトをズバリ、です。
私の記事では社内調整のハナシでしたが、外を見つめるのに邪魔になるのはむしろ、こういう社内で得られる権限や地位に対する傾倒ですね。

「私はほかのだれでもなく、私である。」
仕事（とそれを通じた生き方）に対してオーナーシップや主体性を取り戻すために唱え続けたい言葉です。

人生をドライブに例えたとして、果たして私は運転席に座っているだろうか？それとも助手席だろうか？
気づくと組織にハンドルを握られていた、なんて嫌ですよね。

自主的サービス残業の是非

この業界では作業にかけた時間、工数というものでコストを計算するのはご存知の通りです。

その計算は大抵は自己申告制で、個人にとってはほぼ「残業代請求（申請）」です。

そしておそらくは誰もがやったことがあるであろう、「今日はパフォーマンス悪かったから時間分満額請求しにくいなぁ」という自主的サービス残業。

自主的サービス残業は、制度の不完全さを補う正しい行為と言えます。
そもそも我々の賃金は勤務時間の長短によって決めるべきではなく、成果の多寡で決められるべきです。ところが個人の成果の多寡を客観的に測定することができないので、会社は観測可能な時間という単位で賃金を計算します。また労働基準法上も、時間外勤務があれば相応の賃金を支払うことを義務付けています。
この歪みを正す行為なので、正しい行為と言えます。

私もよくやっていましたし、今でもたまにやります。

でも最近、必ずしもそれが正しいとは言えないかな、とも思うようになりました。
それは…（続きを読む）

プロの心得：外を見つめる。まっすぐに。

プロとして提供すべき価値は、常に組織の外に向けられたものです。
組織の中にはコストしかないし、プロならば社内調整や権限獲得に奔走すべきではないです。

えー、以上、建前論というか「こうありたい」論です。

自分の中ではこの、組織の外を見つめて自分がいかに貢献できるかを追求するか、それとも組織の中で得られる権限を追求するかがプロとサラリーマンとの分かれ目だと思っています。
できる限り社内調整や組織内の利害整理なんてしたくないです。
そんな事をしている間に、お客様に割ける貴重な時間が費やされてしまうのが耐え難いです。

でも、じゃぁ貢献するためにはプロジェクトチームがなければならず、２人以上の人間がいるならそこには必ず政治が生まれてしまい…

前の会社、今の会社、社外の同業、ネット上。
仕事上の愚痴のほとんどが…下手したらすべてが、社内の話。
ゲンバの現実問題として避けては通れないんですよね。

でもせめて、これらの問題への対処が「自分が果たすべき貢献」ではなく「貢献を妨げる制約条件の除去に過ぎない、付加価値は生んでいない」ことは忘れないようにしたいところです。


一個下のエントリの件も含め、プロフェッショナルと組織。深いです。

SE は組織を超越する

SE は組織を超越した存在です。ボランティアが NPO を超越した存在であるように。
高度のスキルはそれ自体が生産手段であり、組織が集約的に持つ資本や物的資源から独立して価値を創出しうるからです。
SE に話題を限れば、組織にとっていかに働いてもらうかは、もはや労働の問題ではなく人的資源の問題です。

大きなコトを言っていますが、ドラッカーの受け売りです。
（もちろん、ドラッカーが論じていたのは SE だけでなく Knowledge worker 全般でしたけど）
ご存知の方はひと目見てわかったと思います。良いですよね、ドラッカー。

さて、「未来のいつか」より「人材のプール」のトラックバックです。
続きを読む

やりがいを感じる瞬間

SE がやりがいを感じる瞬間は大体

1) システムの稼動時
2) お客様が喜ばれた時（感謝された時）

という意見が多いですね。
多少、表現のブレがあるにしても前者は物を作り上げた喜びで、後者はそれを「誰かに喜んでもらう」喜び。
エンジニアとしてはモノヅクリが嬉しいのは当たり前だし、それに人として産まれた以上、人を喜ばせる以上の喜びはないでしょう。

でも第３のパターンとして、私の先輩のケースが強く印象に残っています。
曰く、「本稼動から１年後、お客様の財務諸表を PDF でダウンロードして経費が XX 億減ったのを見たとき」。
自分が作った物が、ビジネス上の価値を生んだことに感じる喜び。
ん〜、プロですね、プロ。

少なくとも情報システムはお客様が楽しみたくて発注するわけではなくて、ビジネス上の目的があって「投資」しているわけです。
投資は回収されなければ意味がない。

仮にシステム導入で業務改善ができても、現場の人が「仕事がスムーズになりました、ありがとう」と言ってくれたとしても、トップが「よく頑張ってくれた」とねぎらってくれたとしても、ビジネス上の価値を生まなければ意味がない。
ビジネス上の価値が生まれなければ、利用はされても「動かないコンピュータ」に等しい。

まぁ、人は人間なので（トートロジー）喜びを感じるツボはそれぞれですが、自分の仕事の定義を再認識させられた一言でした。


あ、私ですか？
私は日々の業務をきちっと終わらせて帰る瞬間ですね(笑)。
凡人なので平凡な幸せの積み重ねがいいんです。

「SWITCH BACK」より「やりがい」のトラックバックでした。