時間管理なんてできません

時間は管理できません。管理できるのは自分の行動だけです。


（クリックで拡大）

前回ああいうマトリックスを描いたら、やっぱりこれも描きたくなりました。
「７つの習慣」という本で紹介されている概念です。
この本で「時間管理のマトリックス」とキャプション付きで紹介されているせいか、誤解して転載しているサイトもあるのですが、このマトリックスで気づき、管理し、変えていくことができるのは自分の行動です。

自分が持っている１週間 168 時間を上のマトリックスに分類した時に、どのブロックに時間を費やしているか、振り返ります。
右上の緊急ではないものの重要なことをもっと行いたい、と誰もが思うでしょう。

左上ばかりの人はストレスとプレッシャーにつぶれ、うつ病になるかも知れません。
左下ばかりの人は他人に振り回され、八方美人にしかなれません。
右下ばかりの人は論外です。

左半分の緊急なものは簡単には動かせません。
結局、右下の無駄な部分の行動を減らし、右上の重要な部分に割り当てるしかありません。
無為に過ごすこともいけませんが、もっといけないのは重要なことを疎かにすることです。
そして右上の重要な行動がうまく回りだせば、無用なトラブルが減り、左半分、特に左下の割り込み系が減っていき、より重要なことをより多くできるようになっていく、という好循環につながります。
ドラッカーの言葉を借りれば「トラブルへの集中からチャンスへの集中へ」です。

「四宮のクーパー」は正に右上の緊急ではないが重要なこと、ですね。
会社の視点でいえば、社員教育も右上です。
でもプロジェクトに入って仕事をこなしていた方が短期的には金になるからと、左側から動こうとしません（会社がそうしたくても部門長、上司が緊急度にばかり固執するケースもありますね）。

やりたいこと/できることマトリックス

やりたい事とできる事のマトリックスと、やりたい事ができるようになるまでの道のりをまとめてみました。


（クリックで拡大）

「「ゴッドハンド輝」に見たの日本一の下足番」に対し、「眠る開発屋blog」から頂いたトラックバック「スキルの育成について」を踏まえて、整理したものです。

ただ、またスキルが形成できるか否か･･･どこまで職業人としての自覚を持つか？っていうのは「本人の素質５割、環境５割」って気がします。
リンク先にならって、ゴッドハンド輝で話をすると、ヴァルハラいけば周囲に刺激されてがんばろー！って気になるけど、普通の病院へ行っても、クーパーの練習をする意識が芽生えるか否かはすごく微妙。

その通りだと思います。
環境の影響はものすごく大きい。

ですが、生まれ育った環境のせいで私はこうなった、というのはあまりに悲しいです。
自分はこういう会社に入ったから、こういう部署にいるからプロにはなりきれません、というのは悲しいです。

ゲンバの身の回りでそういう環境になければ、それこそマンガででも励みになるモノがあるといいんですが…

「ゴッドハンド輝」に見た日本一の下足番

「ゴッドハンド輝（テル）」というマンガがあります。
週刊少年マガジン連載の、医者のマンガです。

さて、そのマンガで妙に記憶に残っているのが、主人公のライバル役である四宮がクーパーという手術用のハサミを扱う練習を繰り返し、また自分用のクーパーを調達（ってもオーダーメイドではなく吟味した品番指定っぽい）して手術に臨んでいた、という回のハナシ。

目立ちにくい基礎技術を丹念に習得されることで、いつの間にか差がついてしまい、それを埋めるために主人公は…というストーリーだったと思います。
思います、というのは印象に残ったのが別のポイントにあったから。

それがクーパーを極めた四宮を見ての、院長と外科部長の会話。
「四宮はクーパーを極めることで、我々に無言のメッセージを送っているんですよ。
　もう俺は次の段階に進む準備はできているんだ、と」
実は肝心のここも、この通りの言葉を使ったかは記憶が曖昧なのですが、台詞の意味としてはそういう意味の事を言っていました。

「下足番を命じられたら日本一の下足番になってみろ。
そうすれば誰もお前を下足番にしておかぬ。」
日本で私鉄ビジネスの基礎を築いた小林一三氏の言葉です。

会社の中である程度上になってくれば、見えてくる言葉なんですけど、本来この言葉が向けられる下の方、新人なんかにとっては頭で理解できても、なかなか届きにくい言葉だと思います。
私も社会人になりたての頃はそうでした。
自分はもっとできる、なぜ自分がこんな仕事を、と考えていました。

スキルは実績を以って示す必要があり、プロにはその説明責任がある。
大きなハナシのようにも聞こえますが、ごく日常的な小さなタスクの中にも、アウトプットを積み上げていくことの大切さがある事に気づいたエピソードでした。

SQL の書き方によってインデックスが利用されない

インデックスを張ってあるカラムを where 句で指定すれば、無条件でインデックスが利用できるわけではありません。

その例を挙げていきます。
続きを読む

グロービスのキャリアデザインセミナー行きました

グロービスのキャリアデザインセミナーに行きました。

価値観について、問いに答え、周りの席の人に説明し、フィードバックをもらい…というのを繰り返しました。
回答をまとめたり、話し合ったりする時間が極端に短かったのが残念です。

やはり私の中ではある程度フィックスした内容でしたが、他人への説明がうまくいかなかったり、設問への回答で角度が変わって答えの形にできなかったり、といったコトはありました。

やはり、たまにこういうのに出て、キャリア観のストレッチをしないと気づかぬうちに凝り固まってしまうかも知れませんね。
時期の偏りはあるものの、社会人になってからほぼ年に１回のペースは守れています。
（大抵無料か安価なのだけれど）

他業種の方と名刺交換できたのも収穫でした。グロービスのキャリアセミナに来るような方ですからね、意識も高いですし。
また機会を作って語らいの場を設けたいです。

上流工程、下流工程って止めませんか。

情報システム業界では上流工程、下流工程という言葉があります。
これが無駄に確執や偏見を生んでいるように思えてなりません。
特にゲンバを知らない就職活動中の学生や（戦略コンサルにしろオペレータにしろ）狭い範囲でしか仕事をしない業界人にとっては、変な勘違いの元になります。

そこで上流工程、下流工程の代わりに前工程、後工程ってのはどうでしょうか。

「前工程は神様、後工程はお客様」
トヨタで使われている言葉だそうです。

前工程は神様なのだから、信頼して組み立て部品の受け入れ検査はしない。
後工程はお客様なのだから、完璧な出荷検査をして不良品を出さない。

高い品質を保ちつつ、余計な検査や無駄な手戻りを減らすための知恵です。

このスローガンを見たとき、情報システム業界でも使えるな、と感じました。

後工程はお客様。
使ってもらうことになる自分のアウトプットは完璧にすべきだし、不備や漏れがあるなんて失礼なことがあってはいけない。

前工程は神様。
彼らからのインプットは完璧なので、信じて自らの仕事に集中するべし。
何かあったも、それは天災だと思って自分のベストをつくす。

もちろん、不備があっても手戻りをしてはいけない、などと言いたいわけではありませんよ。
必要なケンカは大いにすべきです。

１つ強調したいのは（なんか同じことを何度も書いている気がしますが）、上下という言葉が内向きの言葉だということです。作り手の中だけで考えるからそうなってしまうのです。

前後という言葉は、それぞれの工程がお客様に向かって一連の流れとなった時の言葉です。

するとそれぞれの工程の責任の意味あいが大きく変わってきませんか？

地道にですが、この言葉を流行らせようと画策中です。
経済産業省のお墨付きをもらって情報処理技術者試験なんかで使われる用語になったら最高だなぁ。

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

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

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

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

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

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

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

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

グロービスのキャリアデザインセミナー行きます

グロービスのキャリアデザインセミナーに行きます。

日時：2005年3月15日（火）　19：00〜21：30（懇親会含む）
場所：グロービス・マネジメント・スクール東京校（有楽町線麹町駅徒歩１分）
参加料：2,000円

グロービスは以前説明会とお試し講座を受けましたが、なかなか充実した時間を過ごせました。
私の中ではある程度フィックスした内容っぽいですが、グロービスならきっと楽しめると思います。
仕事を早めに切り上げて参加しようと思います。

頼まれ仕事の納期

今暇？ちょっこコレ調べてくれる？

と、こまごまとした依頼はどこの職場でもよくあると思います。
作業の中断というのは、どんな仕事をやっていても効率を落とすもの。
今の作業との兼ね合いで、この飛び込み用件をどうスケジューリングするか？
いわゆる仕事術と呼ばれる Tips のうちの１つです。

私は国内のメーカー系 SI から外資コンサル系 SI に移りました。
外資だといっても働いているのは日本人ばかり、お客様も基本的に日本人ばかり。
（例外的にグローバル案件だと互いに海外オフィスの人間も交えますけど）
基本的に文化の違いはそうはないなぁ、と感じていたのですが、この小さな依頼ばっかりは前職場ではあり得ないだろう、という会話が成り立ちます。

以下、実際にあった会話。

「市井くん、君 Excel 詳しかったよね？こういうのって VBA 組まずにできそう？」
「んー、いつまでに回答したらいいですか？」
「できれば今すぐ。でも考えて思いつきそうだったら言って。作業着手を明日に先延ばすから」
「考えるって、何分くらい考える価値あります？」
「そうだな、さしあたり 10 分。そこで今日中かかるか仮回答もらえる？」
「10分ならいいですよ。今やってるのは、さほど緊急の仕事でもないので。
　普通の Excel 関数の組み合わせでどうにかなりそうですね…」

スケジューリングをどうするか、を考えるには、そもそも重要度と緊急度を天秤にかけ、スキルと時間という資源を配分する必要があります。
そのためには、依頼する側、される側でそれら判断材料を共有しなければならない。
考えれば当たり前なんですけど、普通なかなかできないですよね。

私の前職場でも一方的に指示が来るだけでした。
先輩に対して「考える価値あります？」なんて絶対に言えなかったです。
でもせめて納期確認ぐらいはしてもよかったかな、と思います。

…なんて書いてて、自分で書いた「プロの心得：外を見つめる。まっすぐに。」と被るのに気がつきました。
私も先輩も、チームとしてのアウトプットという「外」を見ず、互いの上下関係だけを意識して仕事をしていたのかも知れません。

こりゃぁ、気づいていないところで色々やっちゃってるかも知れませんね、私。


ドラクエトークで盛り上がる「すーぱーSEへの道」より「調べ物を頼まれたら」のトラックバックでした。

業務の視える化ツール、ノリとハサミの MagiCa

情報システムは業務を改善/改革するためにあり、その前提として業務を分析しなければなりません。
誰がいつどこで何のために誰と何をどうやってするか、その量は質は、というのが「パッと見てわかる」状態にないと改善のしようがありません。

これを支援する楽しいツールを知りました。
「わたしが知らないスゴ本は、きっとあなたが読んでいる」より「続マジカのひみつ」で紹介されている、StarLogicの Magica です。

改変しなければ再配布自由とのことなので、PDF(875KB)を置いておきます。

効果については上記トラックバック先の記事を参照して下さい。
お客様のゲンバで気軽に作業を開始できるのがいいです。
例え UML であっても、システム屋の言葉が出てくるとゲンバの方は身構えます。
そこにノリとハサミで、ってのがイイですね。
すごく楽しそうだしイタズラっぽい感じがして好きです。

自分の仕事としてはお客様の業務分析はしていないので、とりあえず自分の仕事をこれで視える化してみようと思います。
非定型作業で効率化が難しいと思って改善に着手できずにいますが、何か新たな課題が視えるようになるかも知れません。

日本人財銀行の市場価値判定を受けてみた

（クリックで拡大）

スコア 697 で、全体での偏差値 55.5、年齢別だと 56.8、職位別（一般職）だと 57.6。
続きを読む

ある小学生の作文に学ぶ履歴書の書き方

知っている方はタイトルを見ただけで、あぁ、アレかとわかってしまうでしょう。

皆さんご存知の @IT 主催のキャリアに関するあるセミナーで突然、
「社名を含む、一切の“所属”を使わずに隣の人と互いに 3 分で自己紹介して下さい」
「はい、この中で、1 分間でいいので皆に隣の人を紹介できる方はいますか？」
というオープニングオリエンテーションがありました。

誰も手を挙げられませんでしたねぇ。
キャリアの土台になるのは「語れる自分」であると、そして意識しなければ「語れる自分」は作れない、というのを実感させるためのもので、狙い通りの効果をもらっちゃいました。

転職のためには相手に自分を買ってもらう必要がある。
キャリアアップのためには相手に自分を認めてもらう必要がある。
いずれにしても、まず相手に自分をわかってもらう必要がある。

自分の夢、目標が語れる。
今の実績を示せて、目標との差分を自覚している。
そしてその差分を環境のせいにせず、克服するためにどんな行動を自分から起こしているか説明できる。

ここまで語れなければ、自分が進みたいステップを理解し、認めてもらうことはできないでしょう。
私の転職も、旧職場への不満を愚痴るだけの状態だった頃にしていたら失敗していたと思います。

さて、タイトルにある「ある小学生の作文」です。
（作文を読む）

（雑文）リンク稼ぎに乱用されるトラックバック

気分が悪いので愚痴です。

読みたくない方は飛ばして下さい。

愚痴につきあってもよい（続きを読む）

2億4000万円が730万円。システム運用コストの話。

読売新聞の記事より。

会計検査院のシステム運用委託費が、業務内容の見直しや一般競争入札の導入などにより、年間で 2 億 4000 万円かかっていたのが 730 万円になったとのこと。

官公庁系のシステムは入札でありえないくらいの赤字で案件を獲得し、開発は大赤字、その後の運用でふっかけて赤字を埋めてさらに利益を稼ぐ、というビジネスモデルがあります。
日立が東京都の文書管理システムを 750 円で入札して公正取引委員会に警告を受けた事件が有名ですね。（でもあの入札、IBM の 155 万円や富士通の 82 万円も同罪だと思う）
それでも運用で利益が出てしまう。それほどまでに運用はオイシイ、簡単に金が取れる仕事なんですね。

業界の人間としては（いわゆる甘い汁を吸っている側の企業に勤めているとはいえ）もちろん、税金を納めるイチ市民としても基本的には歓迎すべきニュースですね。

でも 730 万円だとオンサイトでスタンバイは無理のような気がする…
対象とするシステムの規模もわからないし、業務内容の見直しというのも、どの程度まで削ったのか心配になる面もあります。
逆にトラブルに発展しなければいいのですが。
詳細は IT Pro などの「こっち側の」メディア待ちですね。

いい方向ではあると思うので、変な失敗はしないで欲しいところです。

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

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

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

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

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

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

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

メインフレームについて話してみる

私はメインフレーマ系の SI 会社でパッケージ導入を経験し、外資コンサル系 SI に転職した身です。
そんな立場からなら一つの視点を提示できるかも、と「プログラマの思索」より「システム開発のボトルネックはメインフレームに有り」のトラックバックです。

前の会社では、自社製メインフレームからのリプレースもやりました。
メインフレームの頃からお付き合い頂いていたお客様で、ハード的な老朽化やビジネス上の要求の変化から、 Windows ベースのシステムに切り替える、なんて案件もありました。

実際にお客様のビジネスを支える、という視点に立つと、既に充分な稼動実績のある、エンジニアが使う言葉で言えば「枯れた」システムに手を入れるのは大きなリスクが伴います。

確かに「開発」という作業から見ればメインフレームやオフコンはオープン系の技術との親和性が低く、連携が絡むと足を引っ張られる、邪魔くさい存在ですが、ビジネスプロセスをどう設計するかという視点からすれば、大きな意義のある存在です。

だって今、ゲンバで実際に役立っているんですから。
システムはそれがすべてでしょう？

さらに会計や人事給与なんかは商法、証券取引法、税法などの法律や各種社会福祉制度などで業務自体がガチガチに固められているので、既にあるメインフレーム上の仕組みを置き換える理由がなかなか出てきません。
例え連携で開発コストが増えたとしても、会計の仕組み自体を作り変えるよりはずっと安上がりですし、安心です。

それに業務アプリを作るソフトウェアエンジニアは見逃しがちですが、メインフレームで使われている技術ってスゴいですよ。
トラブルがあっても基本的に一社がすべて取り仕切るので、OSのバグやミドルウェアの不具合まで含めてサポートされるというメリットもあります。「それは Sun に、これは Oracle に」なんてことは絶対ありません。
どこのメーカーもある種の威信をかけてサポートしますからね。


メインフレーム自体は技術者の減少と共に徐々に減っていくだろうとは思いますが、なかなか無くならないでしょう。

私としてはメインフレームの問題は、むしろ保守体制が生むベンダーとの関係にあると思います。
どうしてもメーカーに頼りきってしまう。
確かにサポートは厚いけれど、それに見合う金額は支払わなければならないし、徐々にベンダーをコントロールする能力を失ってしまい、お客様が自分のシステムに対して主体性を持てなくなってしまう。

レガシーマイグレーションなんて言葉も流行りですが、単純にオープン系に置き換えるだけでは「マイグレーション」は不完全で、ベンダー依存の体質からの脱却が伴わなければ、またベンダーからいいように甘い蜜を吸われてしまうんじゃないでしょうか。