読書、未納が増えると年金が破綻するって誰が言った？、細野真宏、扶桑社

　国民年金、払ったけどちゃんともらえるのかな、という思いがある。もらえるだろうけれど、受給開始が延びるという話も聞いているし、本当にその時の物価水準に合ったものなのか・・・、等不安は尽きない。

　しかし、今はこんな先のことを気にしていても仕方がない。１年後に自分が生きているかなんてことすら分からないのだから何十年も先のことを不安に思ってみてもどうする事も出来やしない。自分には今日できることを精一杯やっていくことしかない、そう考えている。

　そうした考えの中で、私は年金という具体的な事例を通じて経済のことを考えるための２つのポイントを探すため、本書を読了した。

　１つ目は、「どうすれば思考力が身につくのか？」というものだ。

　本書ではこの点についてはごくごく簡単に説明されている。その方法とは「なぜそのようになるのか？ということを段階的に整理していく習慣を身につけること」であるという。つまり、何か事象Ａが生じたときに、「Ａが生じたのはなぜか？」と考え、事象Ｂを探す。そして、その事象Ｂが生じたのはなぜか、と考え、事象Ｃを・・・、というように１つずつ事象を繰り返し考えていくようにする必要があると提唱している。

　２つ目は、「先読みの能力について」というものだ。

　先を読む力、ビジネスの世界でも先読みする力というものが時折注目されることがある。こういう能力は何か特別なもののように見え、いわゆる外資系コンサルタント、ファンドマネージャー、のような正直よく分からない、個人的には如何わしい人間が偉そうに述べてるな、という印象を受けるものだが、本書では、この先読み力について、その極意？をこれもごく簡単に説明している。要は、「常に「なんで？」と、その根拠を考えていく」ことである、とする。

　つまり、これも結局１つめのものと内容的には同じである。

　本書では、約２００ページ弱にわたり、経済についての解説を行っているが、その根底にあるものは何かというと、「それが行ったのはなぜか？」ということを考え、一つずつ突き詰めていくことであった。一見ややこしそうに見えるものも、それには一つ一つ理由があり、それを解いていけば意外とやさしいものである場合がある、ということを知った。

　また、本書以外の経済の本においても、経済の本質については、なぜか？と考えることと解説されているものもあり、経済と言うといかにも学説や数式というイメージがあるが実はロジックで解決がされるものであるということを実感できたものであった。

「未納が増えると年金が破綻する」って誰が言った? ~世界一わかりやすい経済の本~ (扶桑社新書)/細野 真宏
￥735
Amazon.co.jp

読書、ラクに勝ち続ける働き方、小室淑恵、幻冬舎

　最近の仕事をめぐる環境は非常に厳しいと言われている。事実、自分自身でもそれを感じている。自分自身、国内向けと言われてきた産業に従事しているが、それでも近年は国外に出ていくビジネスが増えてきた。

　今までであれば、国内だけを相手に考えていればよかったものが少しずつ国外を相手にしていかないと生き残れなくなる時代になってきたのだと思うと、正直焦りを感じる。

　そんな中で、少しでも効率良く、かつ成果の上がる働き方をしていかないと自分自身が行き詰ってしまうであろうと考えている。

　そこで、私が決して無理をすることなくかつ成果を挙げていけるように働くための４つのポイントを探すため、本書を読了した。

　１つ目は、「内的要因の発見に「簡単ロジックツリー」」というものだ。

　課題を発見するために、フレームワークやロジックなどを活用する。これはもはや一般的なものとなりつつある。しかし、これらはしっかりやろうとすると、とてつもなく苦労をすることとなる。そこで、本書で提唱されているのはロジックツリーを作る際には、大きく「外的要因」と「内的要因」に区別して考えていくというものだ。

　何か問題がある場合には、その問題を引き起こす原因を「他人や周囲の環境に原因のある」外的環境、「自分自身に原因のある」内的環境、それぞれに分けてその本当の原因を探していくというものだ。

　２つ目は、「仕事はなるべく「分解ルール」」というものだ。

　１つの仕事をするにあたっても、それはいくつかの工程に分かれている。そして、各工程ごとに必ず行わなければならない作業があるはずである。普段はそれを意識することなく行っていたのかもしれないが、それを分解し、一つの作業にどれだけ時間をかけるか予定を立て、その上で仕事全体のスケジュールを立てていくことが必要である、とする。

　３つ目は、「気軽にスタートできる「とりあえず８割ルール」」というものだ。

　完璧主義者がよく陥ることとして、何かやるからには必ず完璧にやらなければならない、というものがある。なにしろ、自分自身が完璧主義者だったからよく分かるのだが、やるからには完璧に、中途半端はあり得ない、という考えが根付いている人がいる。

　そのため、そういう人は仕事においても、何か１回で完璧なものを作ろうとして、その準備や作業に時間をかけ、どんどん追われていくということがある。

　そのようなことに対してここでは、まずは８割程度の出来を目指してパッと作ってしまえばいい、というものだ。そうすることで骨組みとなる所はできているだろうから、後はその後に少しずつ微調整などをすればよく、その方が時間短縮につながるといえる、とのことだ。

　４つ目は「社内でのやり取りには「指さし確認法」」というものだ。

　仕事をしていると、時折お互いの認識がずれていることに後で気が付き、ちょっとしたトラブルになることがある。たとえば「なる早」と、なるべく早く、という言葉を使う時には認識のずれが生じる可能性が極めて高い。当然、それを頼まれた方は自分にとって都合のいいように見るだろうし、頼んだ方は頼んだ側の都合を出すことが多いだろう。

　そのようにならないため、電車の車掌が指さしで確認をしているように、仕事においても、納期やその作業の完成水準を具体的に聞いておくべき、というものだ。

　本書では、様々な仕事効率化に関する方法がコンパクトにまとめられている。また、なぜ、そのように働く必要があるのかについても丁寧に語られている。自分自身の働き方を見直したい人、組織として何か考えている人はぜひ一読しておくと良いであろう。

ラクに勝ち続ける働き方/小室 淑恵
￥1,000
Amazon.co.jp

読書、要求定義の基本とポイントが分かる本、佐川博樹

　仕事上、時折システム開発に絡む仕事をすることが多い。そこでいつも悩むのは要件定義、外部設計・・・等の工程についてである。このあたりについては人によって話すニュアンスが微妙に異なっていたりするため、その都度話を聞きながらこれはどこまでを意図しているのかを判断せねばならず、正直大変である。

　そこで、私は私が要件定義とは何かということについて少しでも理解するための３つのポイントを探すため、本書を読了した。

　１つ目は「本来、要求定義は誰がするものか」ということだ。

　いわゆる一般的な書籍では、これはユーザー側がベンダー側に提示するものである、という説明されているが、実務ではこれをユーザーが提示した例を聞いたことがない。まず、ほとんどがベンダー側で行っている。ひどいと全て丸投げでベンダーが提示したのをそのまま受け入れて開発がスタート、ということまである。そして、完成後にその機能等をめぐりトラブルに・・、等ということがよくある。

その点について、本書では実務の実態に合わせてお互いで不足しているところを相互に補完しつつ要件定義を作り上げていくことが望ましい姿であるとしている。

２つ目は、「ＲＦＰとは何か」というものだ。

ＲＦＰと聞いてもピンとこない人がいると思うが、これは「Request　for　Proposal」の略で、提案依頼書と訳される。一見すると要件定義書と似ているようにも感じるが、要件定義とは性質は明らかに異なり、これはユーザー側がベンダーを決定する際に、依頼候補に提示する書面のことを言う。そして、これを元に各候補者は具体的な機能提案等を行う。そのため、この書面自体は漠然とした大まかな内容となっており、抽象度自体は低いものとなっている。

　３つ目は、「現状を調査する」というものだ。

　要件定義を作成するため、ユーザーからそのシステムにおける要求を獲得した後に行うヒアリングにおいて何をすべきかということだが、ここでは主に「業務調査」と「既存システムの調査」との２つの観点から行う必要があるとする。

　業務調査では「人から業務を追う」という方法で調査することが求められるとする。つまり、当該担当者から具体的に何をしているかについてヒアリングを通じて確認していくことが求められる。

　そして、既存システムの調査では、まずは大きく調べていき、その後は徐々に絞り込む中で調査を進めていくとされている。

　本書では、システム開発における要件定義について、要件定義とは何か、どのようなものが求められるかということろから、実際にはどのように進めると良いか、という点についてまで詳しく説明されている。本書を一読することでなんとなく分かっていたような要件定義についての知識は一通り得ることができると思う。今までは「要件定義」というもの自体も正直あやふやにしか理解できていなかったが、要件定義とは両者で作り上げていくもの、ということを再確認することができ、今後システム開発の仕事が来たときにも今までのように不安を抱えるということもなくなってくるのだろうとは思う。

　ただ、これは本書そのものの問題ではないが、ここで解説されていることのうちいったいどれだけが実際になされているのだろうかという疑問はある。今でも要件定義は全てベンダー側にお任せという事例は耳にするし、ＲＦＰという書式など見たことがない、あったとしても本当にごくごく簡単な書類１枚くらいということもよく聞く。ユーザーにはユーザーの都合があるのは仕方ないのだろうが、少しでも本書にあるようにベンダーに寄り添ってもらい、ユーザー無くしてシステムは作れないという認識を持ってもらうよう働き掛けていくことこそがベンダーには求められているのではないだろうかと感じた。

ポケット図解 要求定義の基本とポイントがわかる本 (Shuwasystem Business .../佐川 博樹
￥840
Amazon.co.jp