新社会人に伝えたい「インプットよりアウトプットが大切」の嘘

　新社会人向けに、おっさんがブログで講釈をたれるのが流行る季節になってきました。おっさんの一人として、私も偉そうなこと言ってみます。それは、

「インプットよりアウトプットが大切」

　なんて大嘘です。

そんな戯言を真に受けている暇があったら、さっさとインプットしましょう。確かにアウトプット大事です。私も定期的にブログやTwitterでアウトプット大事にしようと呟いています。でも、それには裏事情があります。

アウトプット大事と呟く人は、世の中には2種類います。

• インプットが好きで好きで、意識しないと延々にインプットし続けてしまう人
• そんな事情を知らずに、アウトプットが大事という事がを真に受けてしまう人

　知識や経験の裏付けがないアウトプットは薄っぺらいものです。１つ２つであれば、まぐれ当たりで凄い評価や反響を得ることもあるでしょう。でも、続きません。継続的に質の良いアウトプットを出し続けるには、まずはインプットを重視しましょう。インプットを続けて続けて、もう貯めきれないとなって自ずから吐き出されるようなアウトプット。まずはそれを目指すと良いのではないでしょうか。

　立花隆か誰かのインタビューか忘れましたが、1つのテーマについて書く時はそれに関する本を本棚1つ一杯になるまで読み込むそうです。1冊のアウトプットに対して、数百冊のインプットですね。すごく納得感がありますね。

　まぁ人が語る人生訓なんて、その背景となる経験とセットで考えないと全く身につかないものです。面白い読み物程度にとらえて、せっせとインプットに励んでください。そうしたら、自ずとアウトプットも出てきます。

See Also:

今まで読んで良かった本　100冊

ぼくはこんな本を読んできた―立花式読書論、読書術、書斎論 (文春文庫)

パソコンで作業する際は、ポモドーロ・テクニック（Pomodoro Techinique）を使うとよい

 


　最近、パソコンで執筆作業をしています。しかし、パソコンで作業すると調べ事のついでに、関係ないサイトとか閲覧して気が付くと全然進んでいないとということが多々あります。これでは駄目だと試してみたのが、ポモドーロテクニック（Pomodoro Technique）です。ポモドーロテクニックとは、時間を25分と5分に分けて作業することです。。25分のほうを1ポモドーロとしてタスクを割り振り、5分のほうを休憩時間とします。要は25分集中して仕事をし、5分休憩するの繰り返しです。そして4ポモドーロをこなすと30分程休憩するという方式です。ちなみに、ポモドーロはイタリア語でトマトです。考案者のFrancesco Cirillo氏が、トマト型のキッチンタイマーを使っていたのが始まりのようです。


　すごく単純なのですが、これが意外に作業効率がかなりアップします。パソコンで作業していると、前述の通りタスクと休憩の境目が曖昧になります。ちょっと休憩のつもりや調べごとのついでに、延々とTwitterやFacebook、ブログなど見続けることもあります。その時に画面の端っこにポモドーロ・タイマーを置いておくと、タスクの時間と休憩の時間をハッキリと意識できます。ブログとか見るのは、休憩時間の5分だけと決める、それだけで効率が数倍にアップします。（単純にサボり過ぎていたということに気がついただけですが。。。）


　さて、実践方法です。自宅の場合は、キッチンタイマーを用意するというのも1つです。しかし、公共の場だと音がなるものは、難しいでしょう。どこでも出来るお勧めの方法としては、パソコンにタイマーを常駐させる方法です。WindowsにしろMacにしろ、Pomodoroで検索すると幾らでも有料・無料を問わず出てきます。気に入ったのを1つ試すとよいでしょう。


　私は、PomodoroAppというのを使っています。恐ろしくシンプルで、25分と5分のタイマーがあって、画面に常駐するだけです。簡単に自分で作れそうですが、結構気に入っています。


　ついついサボっちゃうという人は、騙されたと思って試してみてはいかが？

PomodoroApp

• Chi Chiu Tang
• 仕事効率化
• ¥200
• 

仕事を分解する。

　昔上司が言った中で、印象に残っている言葉があります。部員に対するフィードバックで、全員に5分づつ個別に面談をする必要があったそうです。30人×5分で150分と3時間弱の時間が掛かると計算です。3時間とまとまった時間はなかなか取れないので、紙の束を見てやらないと思っていたそうです。
　しかし、暫くして気がついたそうです。毎日10〜15分であれば確実に時間は空いているし、その時間があれば2〜3人と面談が出来るということに。仕事を全体の総量で考えると大変で中々取り組めないが、分解すると１つ１つはたいしたことが無いということですね。新人の頃だったので、なる程と思っていました。

　アジャイルの手法の1つに、スクラムがあります。スクラムではストーリというユーザの要求に優先順位をつけて、タスクに落としこんでいきます。タスクについては、実施段階ではもっと細分化してチケットなどで管理することが多いです。一つ一つのタスクを扱い易い粒度に分解しチケットで管理することは、よくよく考えると冒頭の考え方と同じですね。

　もちろん全ての仕事が分解出来る訳ではありません。じっくり考える必要がある仕事は、細切りの時間よりまとまった時間で集中してやる方が効率が良いです。しかし、分解することで効率よく出来る仕事もあります。その辺りを見極めて、取り組めると良いですね。

See Also:
自分を首に出来るように働く
技術を伝えても、技術者の価値はなくならないという話
5分くらいで出来るやる気の出し方

自分を首に出来るように働く

　年末ということで、自分がどのような働き方を目指しているのかを改めて考えてみました。結論的には、自分がいなくても仕事が回るような仕組みやチームを作り、いつでも抜けられる状態にするということです。つまり、いつ首になっても問題が無いポジションに落としこむということです。この働き方は、圧倒的に楽です。自分にしか出来ないことがないので負荷が集中しないし、代わりの人間がいるので心理的にもプレッシャーは少ないです。そもそもルーチンの仕事は、自動化などでシステムが出来るようになります。そうすると、面白い仕事が出てきた時に取り組み易くなります。
　反対に自分にしか出来ない仕事を抱え込んでしまうとどうでしょう？自分自身がボトルネックになるので、休めないし心理的なプレッシャーもあります。そして、延々と同じ仕事を続ける必要があります。10数年働いてそれなりの数の人を見てきましたが、自分のポジションを保つために仕事を抱え込む人は一定割合います。その人が伸びるかどうかというと、かなり疑問です。第一、横から見ていても面白そうに見えません。

　何故突然こんなことを書きだしたのかというと、先日Chikirinさんの「誰に評価されたい？　上司？　会社？　それとも市場？」というエントリーとそれに対する反論を読んでいて思い出したのです。今年の前半くらいに「技術を伝えても、技術者の価値はなくならないという話」というエントリーを書いて、Chikirinさんのブログに対する反論と似たような反応を貰っていました。当時は中々自分が考えていることは伝わらないなぁと思っていたものの、そもそも何を目指して働いているのかを折りにつけて考えていると冒頭の結論に達しました。

　当時の論旨を一行でまとめると、ITエンジニアが技術を他人に伝えても本人の価値は減らないよということです。これに対して、否定的な意見は次の3つに集約出来ます。

• 技術に対する評価と、社内の評価は別の問題
• そもそも技術を正当に評価出来る人は少ない。
• 技術者の価値と対価は別問題

　上記の意見については、実際問題その通りでしょう。しかしまぁ、どうでも良い話だと思っています。社内の評価を勝ち取るのも、また自身の価値に対して対価を得るのも、価値の論点とは別の次元の話だからです。評価を高める為や対価を得る為の活動は、それはそれで考えればよいだけです。
　ただ、そもそもの価値がなければ話は始まりませんよということです。そして価値をつけていくには、自分が出来ることを増やすか深くするのが近道と考えています。その為には新しいことに取り組む機会を確保する為に、必然的に今までやっていた仕事を他人に出来るようにしていく必要があります。それを突き詰めると、自分を首に出来るようにするということです。オチも何もない話ですが、頭の中のモヤモヤ整理です。

See Also:
技術を伝えても、技術者の価値はなくならないという話
伝えたかったのは、伝えるのが難しいということ。或いはバカの壁の話

参照：
誰に評価されたい？　上司？　会社？　それとも市場？ - Chikirinの日記

超高速開発と聞いて思うところ。或いは、アジャイル開発が目指すところ

　先日はじめて、超高速開発という概念を聞きました。正直何のことかよく解らなくて、ネットで幾つか調べてみると、元々は日経コンピュータの特集から生まれた言葉で、その名を冠するコミュニティが立ち上がって話題になっていた模様です。コミュニティの発起人をみてみると、開発ツールベンダーが一同に会しているようです。なんだかなぁと思っている所で、主催者の中の一人の方が書いたブログを読んで趣旨が解りました。

（本日の会で）改めて感じたのは、まだまだツールの認知度が低いということです。今は狭い市場を競合製品で奪い合うのではなく、ツールベンダーが一緒になって市場を拡大する時ではないでしょうか。

　確かに開発の現場におけるツールの認知度・導入率を考えると、業界が一致団結して取り組むというのは納得です。しかし、それ以前にそもそも開発って何だというのを考える必要があるのではないでしょうか？解りやすいのでウォータフォールモデルで考えてみると、IPAのソフトウェア開発データ白書の活用に詳しい調査結果が出ています。平均値でみると次のようになっています。
　設計が43%でテストが27.5%、そして制作部分が28.5%です。今回の超高速開発の開発がどこを指しているのか解りませんが、発言の文脈を見る限り制作の部分に焦点を当てているように思えます。となると、対象となるのが全体工程の3割以下です。3割の部分を生産性を10倍にしても100の工数が73になるだけなので、工数としては3割弱という所です。また基本設計から総合テストまでのフェーズが85%に対し、要件定義は15%くらいが一般的のようです。それを考えると圧縮効果はもう少し少なくなりますね。

基本設計	詳細設計	制作	結合テスト	総合テスト
23%	20%	28.5%	14.5%	13%

大切なのはムダを作らないこと

---

　もちろん開発ツールを導入することにより劇的に生産性があがるシステムや会社もあると思います。しかし、一般的には鳴り物入りで導入したものの、あまり効果が出ないなぁというところが多いのではないでしょうか。それでは、どうしたら良いのでしょうか？
　米国Standishグループによるシステムの調査の結果レポートによると、平均するとシステムの中で実際に使われているのは36%に過ぎないそうです。残りの64%は殆ど使われていないか、全く使われていないそうです。

　またアジャイル開発が理論化される中で、大きな影響を与えたトヨタの大野耐一さんもムダとは価値をうまない各種現象や結果と定義しています。
大野耐一　「７つのムダ」

• 「つくりすぎのムダ」
• 「手待ちのムダ」
• 「運搬のムダ」
• 「加工そのもののムダ」
• 「在庫のムダ」
• 「動作のムダ」
• 「不良をつくるムダ」

　生産性が低いということが問題になっているのであれば、直接的なアプリケーションの制作工程ではなくて、まずムダなモノを作っていないかを改めて考えてみるのが良いのではないでしょうか？SIの現場などにいると次にいつ予算がおりるか解らないので、初期開発の段階でいるか解らないけど取り敢えずありったけの機能を作りましょうという話はよく聞きます。
　本当にそれで良いのでしょうか？機能が増えれば増える程、システムの複雑さは増します。当然、テスト工程も大変でしょう。そして、複雑なシステムは保守性も悪く運用コストがかさみます。また、機能を追加する際にも余分な開発費が掛かることでしょう。ムダなモノを作らないというだけで、6割近い工数の圧縮を出来る可能性もあります。いかがでしょうか？
　実は、アジャイル開発が目指しているところは、ここにあるのだと思っています。アジャイル開発というと、名前だけ聞くと素早い開発ということで製作の高速化を目指しているように思われることもあります。しかし、実際のところはムダなことを無くして、本質的な所にリソースを集中出来るようにしようという手法だと私は理解しています。

プロフェッショナルの役割

---

　今回、超高速開発という新しい概念がうちだされて、世の中に（広まるか解りませんが、）広まろうとしています。エンジニアの反応は、またバズワードが出てきたと否定的な意見も多いです。私としては、別にバズワードが広がっても何でも良いのではと思います。キッカケはなんであれ、開発というモノに関心を持つ人が出てくれば、それを契機にちゃんとチームなりお客さんと話していけば良いのです。そして、本当は何を必要としているのか、しっかりと考えていくことだと思います。

See Also:
ソースの自動生成に関する本質的な違和感

参照：
開発ツールベンダー13社が集結し、「超高速開発コミュニティ」を設立
超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立 − Publickey
「超高速開発コミュニティ」は何を目指すのか - ジャスミンソフト日記
ソフトウェア開発データ白書の活用 - IPA 独立行政法人

5分くらいで出来るやる気の出し方

　人類の永遠のテーマ、というか受験生の永遠のテーマの1つが「やる気の出し方」です。やる気が出なくて、やる気を出す為に運動をしたり部屋を片づけたり、そんなことをしている間に時間がなくなったことありませんか？私は、いつもそうでした。

　そんな学生時代でしたが、社会にでて10数年。やる気の出し方が少し解ったような気がします。ずばりやる気が出てくるのを待つのではなく、やる気がなくてもとりあえず始めることです。対象は勉強でも、プログラミングでも、運動でも何でも同じだと思います。やる気が出なくて嫌でも、始めて5分もすれば意外に調子が出てくることないですか？

　これには、それなりの根拠があるようです。脳の海馬を研究している池谷裕二さんと糸井重里の対談本に次のような一節があります。

「やる気」を生み出す脳の場所があるんですよ。側座核(そくざかく)と言いまして、脳のほぼ真ん中に左右ひとつずつある。

〜中略〜

ところが、側座核の神経細胞はやっかいなことに、なかなか活動してくれないのです。どうすれば活動をはじめるかというと、ある程度の刺激が来た時だけです。つまり、「刺激が与えられるとさらに活動してくれる」ということでして。

やる気がない場合でもやりはじめるしかない、ということなんですね。そのかわり、一度はじめると、やっているうちに側座核が自己興奮してきて、集中力が高まって気分が乗ってくる。だから「やる気がないなあと思っても、実際にやりはじめてみるしかない」のです。

やりはじめる前に、やる気がないのは当然なのですか？はい。やっていないから、やる気が出なくて当たり前です。

　やる気が出るのを待つのではなく、やる気を生み出せということですね。従来から考えていた主従が逆ですね。ちょっとプログラミングしようかと思ってたのですが、やる気が出てこないのでウダウダと書いてみました。とりあえずXcodeを立ち上げることから始めます。

See Also:
最初の一歩は、GTDでやると良いですよ。　続やる気の出し方

技術を伝えても、技術者の価値はなくならないという話

増田で、この記事が話題になっていました。
正社員に仕事を教えたくない

私は今年で契約が切れるパート。同じ部署に昨年、数歳年下の新入社員が配属された。

彼女は私が少ない仕事から数年かけて学び、また効率的に処理できるように試行錯誤して会得したノウハウを、たくさんの仕事の中でどんどん吸収している。これまで私しか使えなかったソフトも、ほぼ同じくらい使えるようになった。

　この記事書いた人の仕事の内容はよく解らないので元ネタに対するコメントは差し控えます。一方で、これを見ていたIT系エンジニアのクラスタっぽい人々が、技術職にとっては技術を伝えると自分の価値が無くなるよなぁ的な発言をしているのを幾つか見たののが興味深かったです。なので、ITエンジニアにとっての技術と、それを伝えるということを考えてみました。前提として、ITエンジニアの技術についてです。製造業の技術流出は別の問題だと思うので、対象にしていません。

IT系エンジニアにとっての技術とは？

---

　まずIT系エンジニアにとっての技術とは何でしょうか？書いたコードなのでしょうか？それとも、コードを書くための能力なのでしょうか？これは後者だと思います。次にコードを生み出す為の技術ですが、実はこれも２種類あるのではと思っています。１つ目は、いわゆるテクニックとかノウハウとか言われるものです。もう１つは、もっと本質的な知識であったり考え方・思想だと思います。
　あまり適切な例えではないですが、遅いSQLに対して高速化の手段（インデックスを貼る等）を知っている／行えるのが、テクニックです。これに対して本質的な知識とは、DBの内部構造を理解していてどういう理由で遅いのかを理解していることだと思います。これが解れば、どういった対策を行えば良いのか、自ずと解るようになります。

技術を伝えるということ

---

　技術を伝えることを恐れる人は、前者のノウハウ／テクニックだけを技術と思い込んでいるのではと思います。ノウハウ／テクニックについては、比較的伝えるのも簡単で知っていれば誰にでも出来る類のモノは多いです。これに対して、後者の技術（本質的な知識）については伝えようと思っても、生半可なことでは伝えられません。何故なら、技術とはバックボーンとなる膨大な知識・考え方の上に、築かれるものだからです。ピラミッド構造でいうと、下の図のように考え方という土台の上に知識があって、最後に乗っているのがノウハウとなると思います。要は、ノウハウというのは氷山の一角ということです。バックボーンがあってこそのノウハウなのです。

　一応補足しておくと、ノウハウが悪いと言っている訳ではありません。ノウハウとしてまとめられるようになるには、とてつもない知識や経験が必要になるということです。だから、ノウハウを作れる知識を持っていれば、ノウハウ／テクニックの流出に対しては何も心配する必要はないということです。またノウハウではなく知識を伝授するには、これまた深い理解が必要です。今持っている知識を人に伝えるようになれば、恐らく伝えようとする前より１段階上のレベルに達していると思います。

まとめ

---

　上記のことから、私はIT系の技術者は積極的に技術を伝えるべきだと考えています。伝えれば伝える程、自分のレベルアップになります。またちゃんと技術を伝えられるという人は、組織にとって得がたい人です。それでも低評価というのであれば、組織としての将来性は無いでしょう。身の振り方を考えれば良いと思います。自分の価値を高める為に技術は秘密にするという考え方では、長期で考えるとジリ貧になると思います。
　自分が出来ることを他人が出来るようになれば、喜んでその先のことに挑戦していけば良いのではないでしょうかね？また、技術をちゃんと伝えられる人には、その過程で自然と新たな技術が習得出来ると思います。セコい事考えずに有能な後進をどんどん育てていけば、みんな幸せになれると思います。 Enjoy!!

2013/05/30追記：
補足を書きました。
伝えたかったのは、伝えるのが難しいということ。或いはバカの壁の話
自分を首に出来るように働く

See Also:
伝えたかったのは、伝えるのが難しいということ。或いはバカの壁の話
自分を首に出来るように働く

参照：
正社員に仕事を教えたくない