はじめに（改訂版）
ＩＴエンジニアの労働環境は、その過酷さから３Ｋ、さらには７Ｋなどと揶揄されています。
また、自身を自嘲的にＩＴ土方などと呼ぶＩＴエンジニアすらいます。
さらに、就職・転職先としてＩＴ業界を避ける「ＩＴ業界離れ」という現象も広く知られるようになってきました。
なぜＩＴエンジニアの仕事はこれほど厳しいのでしょうか？
細かい分析は本書の趣旨から外れますので割愛しますが、安定した成果を残すために必要な３要素である、プロセス、スキル、マインドを職務で活用できるレベルで備えていないＩＴエンジニアが多いことが要因のひとつであることがわかってきました。
もちろん業界の慣習など、ＩＴエンジニアにとっての外部要因による影響もありますが、まだそれ以前の問題が多く残されています。そういった慣習もいずれは改善していく必要がありますが、まずはＩＴエンジニア自身が仕事のやり方を変えていく必要があります。
プロジェクト進行に関してはプロセスが整備されつつありますが、業務上の意志決定（問題解決）や人材育成に関しては各人のセンスに大きく委ねられているのが現状です。
特に人材育成に関してのプロセスやスキルが欠けているために、職務遂行に必要なスキルやマインドを持った人材が不足し、トラブルが頻発しています。
そこで、この問題に長く取り組んできた経験をもとに、この問題を解決し得るひとつの方法論を提示したいと思います。
もちろんこれが唯一絶対の解ではありませんが、少なくとも机上の空論ではなく、実際の現場で適用し、試行錯誤を重ねてブラッシュアップされてきたものだということは大きなアドバンテージであると考えています。
この方法論の適用により、ＩＴ業界の労働環境が少しでも改善されることを願っています。
他の先進国と比較して、日本の知識労働の生産性が低いことは有名です。
しかし、多くのＩＴエンジニアが新しい働き方を身につけることによってＩＴ業界から生産性革命が起こり、日本全体の知識労働の生産性向上に貢献できるようになることを夢見ています。
そして、ＩＴエンジニアが生産性向上の恩恵を受け、成果と成長と休息のバランスの取れた、幸福なエンジニアライフを送ることができるようになれたら、これ以上の喜びはありません。
ITエンジニアの新しい働き方
小冊子を作成する目的
先日日記に書いた小冊子（ITエンジニアの賢い働き方）の執筆は順調に進んでいます。
小冊子の目的を理解してもらうために前書きを転載しておきます。
小冊子で評判になれば出版できるかもしれないという思惑があったりもしますが、そもそもなぜ出版したいかというと、結局目的は小冊子作成と一緒です。
出版した方がより多くの人の目に触れるチャンスがあると思うので、できれば出版にこぎつけたいと思っているだけです。
はじめに
ＩＴエンジニアの労働環境が非常に過酷なものだという認識が世間で広まってからだいぶ経ちました。
「ＩＴ業界離れ」という言葉も一般的なものになってきています。なぜＩＴエンジニアの仕事はこれほど厳しいのでしょうか？
細かい分析は本書の趣旨から外れますので避けますが、結論として安定した成果を残すために必要な３要素である、プロセス、スキル、マインドの全てに大きな問題があることがわかってきました。
もちろん、外部環境による影響も大きいのですが、個人レベルで解決不可能なところに原因を求めても意味が無いので、コントロール可能な内部環境に絞って話を進めます。プロジェクト進行に関してはプロセスが整備されつつありますが、業務上の意志決定（問題解決）や人材育成に関しては各人のセンスに大きく委ねられているのが現状です。
特に人材育成に関してのプロセスやスキルが欠けているために、職務遂行に必要なスキルやマインドを持った人材が不足し、トラブルが頻発しています。そこで、この問題に長く取り組んできた経験をもとに、この問題を解決し得るひとつの方法論を提示したいと思います。
もちろんこれが唯一絶対の解ではありませんが、少なくとも机上の空論ではなく、実際の現場で適用し、試行錯誤を重ねて磨きあげられてきたものだということは大きなアドバンテージになると考えています。この方法論を多くのＩＴエンジニアが取り入れることにより、ＩＴ業界の労働環境が改善されることを願っています。
日本の知識労働の生産性が低いことは有名ですが、ＩＴ業界から生産性革命が起こり、日本の労働生産性向上に貢献する日が来ることを夢見ています。
そして、ＩＴエンジニアが生産性向上の恩恵を受け、成果と成長と休息のバランスの取れた、幸福なエンジニアライフを送ることが出来るようになれたら、これ以上の喜びはありません。
ＩＴエンジニアの賢い働き方
自分は、成果を出すことと人材育成をどうしたら効率的に行えるかの試行錯誤を重ねてきました。
その結果、気づくと人とはだいぶ違ったアプローチをとっていることが判明しました。
せっかくなので、これまでの成果を小冊子にまとめて興味を持った人に使ってもらおうと思っています。
ゆくゆくは加筆して出版できたらと考えていますが、とりあえずは必要最低限の部分だけでも早急に買いてしまおうと思っています。
参考までに構成を記載しますので、興味のある方はご連絡ください。
タイトル：ＩＴエンジニアの賢い働き方（仮）
はじめに
ＩＴエンジニアの抱える問題
本書の目的第１章 プロフェッショナルマインド
第２章 職務遂行スキル
ＧＰＤＣＡフレームワークの活用
問題解決スキル
コミュニケーションスキル
伝達力
質問力
合意形成力
ＩＴスキル、業務スキル（本冊子の対象外）第３章 人材育成スキル
報連相の活用
タスクの依頼と確認
目標管理
学習プロセスに対する理解
行動科学マネジメント第４章 チームマネジメントスキル（今回は対象外）
第５章 プロジェクトマネジメントスキル（今回は対象外）
第６章 クリエイティブスキル（今回は対象外）
プロフェッショナルとは ~成果をあげるために~
お金をもらって仕事をするということはプロフェッショナルであるということです。
プロフェッショナルである以上、報酬に見合った成果をあげることが求められます。
それではどうすれば成果をあげられるのでしょうか？
ただ闇雲にがんばるだけでは成果はあげられません。
成果とは何であるかを知って、成果をあげるための正しい努力をしなければ成果はあがらないのです。
プロフェッショナルにとっての成果が何かと言うと、顧客に対する貢献です。
顧客に対して、顧客の期待に応える価値を提供してはじめて成果をあげたといえるのです。
大事なのは顧客にとっての価値です。
自分にとっての価値ではありません。
したがって、成果をあげるためには顧客が何を求めているのかを知る必要があります。
それは顕在化している場合もあれば、潜在的なものである場合もあります。
一見顕在化しているように見えても、実はそれは表面的なもので、真に求めるものは顧客ですら気づいていないかもしれません。
ちなみに、ここでいう顧客とは直接お金を払ってくれる狭い意味での顧客ではありません。
自分の成果を利用する人すべてが自分にとっての顧客になるのです。
新人だとすると、初めての顧客は先輩や上司であることがほとんどでしょう。
私はSIerでインフラ系のSE（プロマネ）をしていたことがありますが、そのときに自分が顧客と考えていた人は多岐にわたります。
まず社内でいえば、チームメンバー、自部門の上司、業務アプリ開発チーム、担当営業、技術調査部門などを顧客と考えていました。
社外だと、実際の顧客（ユーザー部門、システム部門）、ベンダー（ハードウェア、ソフトウェア）、協力会社などを顧客と考えていました。
一般的には、ベンダーや協力会社は顧客ではなく、逆にこちら側が顧客なのではないかと考えるかもしれません。
もちろんそれも正しいのですが、ベンダーや協力会社にきちんと成果を出してもらうために、その前提となる価値をこちらから提供するという意味で顧客と考えていました。
具体的に言うと、ベンダーの持っている能力を引き出して、こちらが求めるレベルの成果を導き出すことのできる「指示（情報提供を含む）」が、顧客としてのベンダーに対する成果になります。
ここで挙げたそれぞれの顧客が求めるものを考え、価値を提供すべく行動していたのです。
簡単に「顧客の求めるもの」と書いていますが、表面的な要求だけを捉えるのでなく、システムとしての全体最適の視点を持って、顧客が真に求めているものを考え抜きました。
「顧客が求めるもの」は簡単にわかるわけではありませんが、「顧客が求めるもの」を考え、そのために自分がどのような価値を提供することが出来るのかを考える習慣を付けることが成果を出す第一歩となります。
「顧客が求めるもの」を導き出すためには、情報を収集/整理/分析する力はもちろん、想像力も必要になります。
ステークホルダーが多岐にわたる場合は、全体最適の視点も欠かせません。
これらは一朝一夕に身につくものではありませんが、努力することで誰でも身につけられる能力だと考えています。
いまさら「もしドラ」
NHKで「もしドラ」のアニメが放送されるということもあり、いまさらですが「もしドラ」を読みました。
自分は社会人数年目で「プロフェッショナルの条件」に出会って以来のドラッカリアンなのですが、正直ちょっとなめてました。
ストーリーもよかったのですが、著者のドラッカーの言葉に対する理解度の高さやドラッカーを敬愛する気持ちが伝わってきて、一気に読んでしまいました。
主人公みなみの一番の成功要因は、「マネジメント」で書いているマネージャーが野球部のマネージャーとは別だと気づいたあとに、それでもこの理論を野球部のマネージャーに適用してみようと思ったことだと考えています。
簡単そうなことなのですが、これがなかなかできないことなのです。
以前「ザ・ゴール」という企業小説が流行りましたが、「自分は製造業でないから関係ない」と言う人が多いことにとても驚いたことを覚えています。
ある事例を抽象化し、それを自らの事例に適用するという「コンセプチュアルスキル」をみなみが高いレベルで持ち合わせていたというのが大きいですね。
著者がどこまで意識していたかはわかりませんが、みなみの行動には普通は軽く読み飛ばしてしまうようなことだけど、ビジネス上での成否を分けるような行動が多く含まれています。
このような行動は、仕事が出来る人にとっては当たり前すぎる常識であるため、あまり教えられることもありません。
おそらく著者も優秀な人であると思うので、無意識で書いている可能性もあるのではないかと思っています。
もちろん、意識的にせよ、無意識にせよ、みなみがこのような能力を持っていなかったら話は進まないのですが（笑）
これまでは若手に対して、一番読みやすいと思われる「プロフェッショナルの条件」を薦めていたのですが、これからは自信を持って「もしドラ」を薦めることが出来ます。
やはり読みやすいと言っても「プロフェッショナルの条件」だと初心者にはちょっと敷居が高いところがあったので。
もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら
- 作者: 岩崎夏海
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2009/12/04
- メディア: 単行本
- 購入: 265人 クリック: 12,967回
- この商品を含むブログ (1008件) を見る
iComptaの使い方（基本機能編）
準備ができたところで、基本的な使い方の説明です。
主に使う機能は transfer（資金の移動）と transaction（資金の収支）の２つだと思います。
「資金の移動」とは、銀行からお金を引き出したり（銀行から現金への移動）することです。
「資金の収支」とは、給料をもらったり、買い物をしてお金を支払ったりすることです。
なお今回説明する使い方は、自分が使いやすいと思った方法なので、本来の使い方とは違っている可能性もあります。
資金の移動
まずは、資金の移動の入力方法です。
ここでは、銀行からお金を引き出すときのことを考えます。
上部メニューバーの「Make a transfer」をクリックします。
「資金の移動」の詳細を入力します。
Debited account: で引き出す銀行口座を選択
Credited account: で「現金」を選択
Date: に引き出した日時を入力（デフォルトで当日の日付が表示されます）
Amount: に引き出した金額を入力
最後に「OK」をクリックします。
これだけではまだ Pending（未確定）なので、Reconciled（照合済み、確定）にします。
ACCOUNTS の「現金」（銀行口座でもよい）を選択して、該当の取引を表示します。
一番右にある両方向矢印をクリックして、資金移動のセットを表示します。
内容に問題がなければ、一番左をクリックしてチェック（Reconciled）に変更します。
リコンサイルについては、もっとうまいやり方があると思うので、使いながら調べていきたいと思います。
資金の収支
次に、資金の収支の入力方法です。
ここでは、給料が振り込まれた場合とカードで買い物をした場合を考えます。
・給料が振り込まれた場合
ACCOUNTS の銀行口座を選択してから、下部のアイコン群一番左にある四角いアイコン（画像では青くなっている）を押し、transaction入力用ペインを表示させます。
transaction入力用ペインの右上の「＋」をクリックして、必要な情報を入力します。
Transaction に名称、日付、金額（矢印を緑にするのを忘れずに）を入力し、
Bank で「Reconciled」を選択する
・カードで買い物をした場合
ACCOUNTS のクレジットカードを選択してから、下部のアイコン群一番左にある四角いアイコンを押し、transaction入力用ペインを表示させます。
transaction入力用ペインの右上の「＋」をクリックして、必要な情報を入力します。
Transaction に名称、日付、金額を入力し、
Mean of payment で「Card」を選択し、
Categories の「＋」をクリックして、適当なカテゴリを選択し、
Bank で「Pending」を選択し、カードの引き落し日付を入力する
あとは、クレジットカード引き落としの金額が確定したら、銀行口座からクレジットカードに資金移動すれば完了です。
