「ITエンジニアとして生き残るための指南書」 売れ行き絶好調特別記念イベント！ITエンジニア3作品一部を無料公開！！

こちらの3作品の一部を公開中です。
↓画像クリックで読みたい書籍の記事までスクロールします。

まえがき

ITエンジニアはかっこいい、という憧れを持ってIT業界に入ったものの、なんだかイメージがずいぶん違うなぁと感じていませんか？
本書ではイメージと現実のギャップを解明することで、日頃のモヤモヤを吹き飛ばします。

筆者はITエンジニアとしてIT業界で、20年という長い年月をかけて仕事をしてきましたが、モヤモヤが長らく晴れず、このままITエンジニアを続けるかどうか悩んでいました。こうした悩みを打ち明けることもできず、一人で考えても解は出てきませんでした。

20年間、筆者が試行錯誤して身につけたノウハウや気づきを本書に書き下ろしました。

ITエンジニアとしての日頃の業務に辟易し、新人の頃にあったはずの憧れもどこかへ消え、ただ生活をしていくために毎日頑張っている人がほとんどでしょう。それはそれで立派なことですが、ITエンジニアとして長く続けられない人もいます。どんなに酷い状況でも楽しんで仕事ができるなれば、忘れたはずの気持ちが復活し、人生が楽しくなります。

本書で紹介する18のテクニックを明日からでも実践していきましょう。

【1章公開】ITエンジニアってどんな仕事なの？

本書はITエンジニアの働き方をテーマとしたものですが、ITエンジニアの業種には、実に多くの種類が存在します。そこで本書ではプログラマとも呼ばれる開発職を前提においてお話をしていくことにします。筆者は国内のIT企業に、プログラマとして20年間勤務していたことから、その経験を踏まえて話を進めていきます。
当然のことながら、同じ業種でも会社や会社内の組織ごとにそれぞれの文化が異なるので、筆者がITエンジニアとして体験したことがそのまま通用しない場合もありますのでご了承願います。

さて、プログラマというと読者の皆様はどのようなイメージを持っているでしょうか？
毎日、パソコンに向かって何やら文字をタイピングすることで、スマホのアプリやパソコンのソフトウェアを作っている、と思われているかもしれませんが、あながち間違いではないです。映画に出てくるハッカーもそのような感じで、かなり脚色はありますが、概ね合っています。ただ、映画では暗がりの中で怪しげに作業している風景になっていますが、現実のプログラマは明るい部屋の中でコーヒーを飲みながら、快適に作業しています。
プログラマが、パソコンに向かってキーボードをカタカタする行為をプログラミングやコーディングといいます。プログラミングにより作り出されているのはソースコードと呼ばれるもので、建築でいうところの設計図に近いものと考えておけばよいです。

ソースコードは、ある決められた言語を使って記述された文字の羅列であり、基本的にプログラマが一文字ずつ手で入力をしていきます。ソースコードに含まれる文字数は、開発案件によりまちまちなのですが、例として、とあるネットワークカードの制御ソフトウェア(デバイスドライバと呼ぶ)のソースコードは9万文字ほどです。
学生時代に読書感想文で使った400字詰め原稿用紙で換算すると、225枚にもなります。宿題で出される読書感想文はせいぜい5～10枚使う程度でしたので、225枚というと途方もない枚数であるといえます。10万文字で250枚相当なので、100万文字だと2500枚相当にもなり、気が遠くなるようなボリュームです。なお、実際にはテキストエディタのコピー＆ペースト、開発環境のコードスニペット(定型的なソースコードの断片を挿入すること)、ソースコードの半自動生成といった機能を活用することで、ソースコードを作る手間を効率化する(人手のタイピング量を減らすこと)のが一般的です。
なお、ソースコードのボリュームに関しては文字数ではなく、行数で表現することが一般的です。前述の9万文字のソースコードは、行数では3000行ほどとなります。
開発にかかる工数(プログラマの労働時間)を算出するために、ソースコードの行数が使われることがあります。昔は、行数の多さで単価が決められていた時代があったため、確信犯的に行数が増えるようにソースコードを記述するというバッドテクニックがありましたが、昨今ではそのような算出で単価が決まることはありません。

ここで大切なことですが、プログラマはプログラミングすることだけが仕事ではないということです。学校の課題や趣味で行う開発では、プログラミングという作業のみを行うことがほとんどです。確かにプログラミングという行為のみでソフトウェアは作れます。しかし、それだけではソフトウェアの品質が保証できないため、一般的に業務開発(プロとしてのプログラマが開発すること)ではプログラミングだけの作業を行うことはなく、もし開発の現場でプログラミングしか行っていないのだとすると、それは一般的な常識から外れていると考えたほうがよいです。
開発手法として一般的なウォーターフォールモデル開発を例に挙げると、要件定義→設計→プログラミング→テスト→リリース→保守という流れで開発が進むので(途中で工程が戻ることもある)、純粋にプログラミングを行っている期間はむしろ少ないのです。

筆者もそうですが、プログラミングをする姿に憧れて、プロのプログラマになりたくてIT業界に入ったわけですが、思っていたのと違ってソースコードを作成する作業が少なく、ガッカリしたものです。これは理想と現実のギャップですが、このギャップに慣れないとストレスが溜まっていきます。プロとして仕事をする以上、ギャップをなくすことはできないので、こういうものだと理解してしまうのがよいです。
どうしてもプログラミングという作業をたくさんしたい場合は、余暇を使ってプライベートで行うのがおすすめです。業務が多忙で、貴重な余暇を消費したくないという気持ちもあるかもしれませんが、GitHubなどのソースコード共有サイトにプライベートで作った成果物を登録しておくことで、転職の際のアピールポイントになることもあるので、決して無駄にはなりません。

チェックリスト：
1. 仕事にプログラミングだけを求めるのはやめること。気持ちの切り替えが重要。
2. 余暇を活用してプログラミングを楽しみ、アウトプットすると転職にも有利。

購入はこちらから（Amazon）

本書の目次

ITエンジニアってどんな仕事なの？
ITエンジニアの勤務体系ってどんな感じ？
業務遂行に必要なQCDってなに？
IT業界の人手不足とチームの体制
論理的思考が通じない時にどうすればよい？
社内交流、工数削減、バグ曲線
なぜなぜ分析、PDCA
学ぶ楽しさを忘れないこと
会社を辞めても、人生は続く。
ITエンジニア幸せチェックリスト

まえがき

ITエンジニアになる前はプロのITエンジニアとしてバリバリ仕事して、職場で活躍し、経験を積み上げ、凄腕技術者になろう！という意気込みがあったはずですが、実際にITエンジニアとして働いてみて、初志貫徹どころか初志すらもどこかに行ってしまったという方も多いのではないでしょうか？

筆者も新人の頃は社会のしくみをまったく知らなかったので、上から言われたことを真面目にこなし、コツコツ頑張っていれば、組織の中で末永く技術者として生きていける、と思っていました。しかし、現実は理想とギャップがあり、このままでよいのだろうかという疑問が常にありました。

筆者がITエンジニアとして20年間の経験から、いつまでも現役であり続けるためのノウハウや気づきを本書に書き下ろしました。

生活をしていくためには仕事をしてお金を得なければなりませんが、ITエンジニアとして携わっている業務に満足できていないのであれば、今もこの先もしんどい思いをし続けることになるでしょう。やりがいがないと人は仕事上で死んでしまうからです。

本書を読み、行動に移すことで明るく技術者として生きていけたら幸いです。

【4章抜粋】障害対応でスキルが向上するチャンス

障害対応のことをトラブルシューティング(TS=TroubleShooting)とも言いますが、ITエンジニアは障害対応の場数を踏むことで、飛躍的にスキルが上がります。障害対応というのは、例えば作ったプログラムに不具合があり、期待外の動作をするが、その不具合の原因が作った本人や他の誰にも分からないといった迷宮入りになる問題のことです。お客様に出荷する前の開発中での出来事でも、その問題を解決しないと出荷できないと判断される場合は障害対応といいます。
反対に、出荷後にお客様のサービスに影響がある障害が発生した場合、サービスを復旧させるために障害対応を行うこともあり、どちらかというと、障害対応というと、このケースを指し示すこともあります。

障害対応は、単なるデバッグ(プログラムのバグを取り除くこと)とは区別されます。どちらかというと、誰が調べても原因がすぐに分からなくて、本来予定されていた業務にはない計画外の作業で、一度関与すると無限に工数が取られ続けて、つまるところ誰もやりたくない仕事という意味合いを含んでいます。

障害対応はプログラマに限った話ではないですが、プロのITエンジニアの方でも経験がない人もいらっしゃいます。そもそも、障害対応は誰にでもできる仕事ではなく、できる人が限られるので、お上の判断で障害対応の業務が落ちてこないことがあるからです。もっとも、前述したように障害対応は過酷な仕事なので、むしろ知らない方が幸せという話もあります。
しかし、障害対応を経験できることは実は大変貴重なことで、大幅なスキルアップができるからです。……抜粋ここまで

【11章抜粋】オープンソース開発

筆者はITエンジニアに末永く使ってもらえるソフトウェアを作りたいとを考えました。しかしながら、フリーソフトにしろシェアウェアにしろ、ゼロから作り上げることは、本を書くこと以上に大変な労力が必要です。
本業も忙しいので、余暇で開発に回せる時間も限られているので、最初のリリースまでに年単位の時間がかかってしまうことが容易に想像できました。プログラムの規模にもよりますが、プログラミングはとにかく手間がかかるので、少なくない時間と根気がないと続きません。

次に、ゼロからフルスクラッチで作るのではなく、何かベースとなるソフトウェアを改修するのはどうだろうかと考えました。ソフトウェアのバージョンやリリース日に着目して調べてみると分かることなのですが、世の中には多数のソフトウェアが公開されているのですが、長らく更新が止まっているソフトウェアが存在することに気付きます。
特に個人開発されたソフトウェアは、開発者が忙しくなった、興味がなくなった、ユーザからの辛辣な要望でやる気がなくなった、など理由は様々です。誰かが引き継いでくれればよいのですが、そもそもソースコードが公開されていない、作者に連絡が付かない、やってもお金にならない、といった理由で引き継いでくれる人を探すのも大変です。

その中でもフリーソフトは開発者にはお金が入らず、ボランティアベースとなるため、貴重な余暇を潰してまでやろうという人はまずいません。ITエンジニアとしてプロとして働き続けていると、対価(お金)を求めるようになるのが普通だからです。これは本業の収入が多いとか少ないとか関係なく、ITの仕事をしてお金を稼いでいるのだから、ITに関する作業はなんであれ対価が必要、という発想です。それだけプロ意識が高いということでもあります。それに、仕事では大変な苦労をかけてプログラミングしているのに、なぜ似たようなことをプライベートで、かつ無償でやらないといけないのか、という心の葛藤もあることでしょう。

閑話休題。筆者は開発のベースとなるソフトウェアを探していたのですが、ちょうど業務でも使っていたTera Term(テラターム)というターミナルエミュレータ(装置を遠隔操作するツール)が長らく放置されていることに着目しました。Tera Termは寺西高さんという大学の先生が開発したフリーソフトです。……抜粋ここまで

購入はこちらから（Amazon）

本書の目次

生涯現役でありたい姿、会社は運、終身雇用の崩壊
プログラマ35歳定年説、技術職か管理職か
技術とマネジメントの両方を習得する
障害対応でスキルが向上するチャンス
開発環境の構築やサーバ管理は実はおいしい
人の上に立つには強くあれ
ITエンジニアの横のつながりを作ろう
ITエンジニアの勉強会に参加しよう
ITエンジニアの交流会に参加しよう
生涯に残る自分の作品を創ろう
オープンソース開発
チェックリスト

まえがき

「キミはいったい何が言いたいのか分からない」と上司に怒られたことはあるでしょうか？
もしくは、部下に向かって同様のセリフを言ったことがあるでしょうか？

おそらく、ほとんどの方がYESでしょう。筆者はITエンジニア(プログラマ)として、IT企業で20年間勤務しましたが、若い頃、よく怒られたものです。怒られる原因は論理的思考ができていなかったからです。

本書はプログラミングするために必要な論理的な考え方を発展させ、ITエンジニアだからこそできる論理的思考のノウハウについて書き下ろしました。論理的思考は数値と辻褄合わせからできているといっても過言ではありません。

論理的思考スキルは仕事を円滑に進めるためには必要であり、論理的な考え方ができないと周りから信用を失います。信頼関係をなくすと、誰からも相手にされなくなります。

論理的思考スキルを身につけ、「キミは仕事ができる人だね」と言われるようになったら成長した証です。そうなれば、どこにいっても通用する人材となれることでしょう。本書が読者の皆様に少しでも気づきになれば幸いです。

【1章公開】論理的思考がなぜ必要なのか？

論理的思考のことをロジカルシンキングとも言いますが、物事を論理的に捉え、筋が通っている考え方のことです。日本ではここ20年近くに渡って、枯れることなく、常に話題となるキーワードです。論理的思考およびロジカルシンキングというタイトルの書籍は山のように発売され、インターネット上にも多数の記事が公開されています。

なぜ、論理的思考が取り上げられるかというと、仕事をする上で必要とされるからです。筆者はIT業界にいますが、IT業界以外の業界でも必要とされます。そして、論理的思考は一朝一夕で習得できるスキルではないため、組織ごとに課題を抱えています。すべての社員が論理的思考を習得できているという会社なんて、どこにも存在しないでしょう。だからこそ、20年経過した今でも論理的思考が話題になり、常に現場で必要とされるのです。

論理的思考というと、なんとなく堅苦しいイメージがありますが、考え方としてはいたってシンプルです。ここで3つの文章をご覧ください。

(a) 資料を読んでおきます。
(b) 今週中に資料を読んでおきます。
(c) 今週金曜日の午前中までに資料を読んでおきます。

上記の文章でどれが論理的だと思いますか？
正解は(c)です。
ビジネスの世界では納期は重要です。どんな仕事にも期限があります。

(a)の文章は「いつまでに読み終える」のかが分からないので、これではダメです。納期を意識していない、つまり筋が通っていないからです。
ただし、納期が特になく、いつでもいい場合は、これでも問題はないですが、そもそも「いつでもいい」作業はやらなくもいいのと同じで、やったところで工数(時間)の無駄となります。

(b)の文章は一見して納期が意識されているので問題ないように見えます。ただし、それは資料を読んだ結果報告が来週だった場合です。もし、今週金曜日の午後に報告をしなければならない作業だとすると、そのことを認識できているのかが不明です。もしかすると、担当者は急ぎだと考えておらず、来週にずれ込んでもよいと思っているかもしれません。厳しいように感じるかもしれませんが、これではダメなのです。
実は担当者と上司の間で、納期に関して認識のズレがあると、計画通りに作業が完了しない可能性が出てきます。金曜日の午前中までが納期であるのに、担当者は金曜日終日だと勘違いしていたとして、仮に金曜日の朝に上司から「午後から資料読みの結果報告をよろしく」と言われたら、担当者はびっくりするでしょう。

さて、(c)が正解となりましたが、ビジネスの世界における論理的思考というのは、ひとつの手法として「曖昧な言い方をしない」ということに尽きます。「今週中」、「今月まで」、「来月まで」、どの言い方も曖昧です。厳密すぎるぐらいでちょうどよいのです。逆に、普段の日常生活では厳密な言い方をすると「この人は細かいなぁ、神経質な人だなぁ」と思われるかもしれませんが、仕事では「この人は論理的だなぁ」と思ってもらえます。
特に、納期に関しては曖昧な言い方をしていると、「この人はいい加減だなぁ」と見られることになります。

さらに、ここで話は終わりません。実をいうと、(c)の文章には問題があります。
どこに問題があると思いますか？
それは「ゴールが分からない」ということです。ゴールという言葉は目的に置き換えることもできますが、つまりは資料を読んだ結果どうするのかが分からないのです。学校の宿題に出される読書感想文ではないので、仕事として取り組むわけですから、資料を読んだ結果、何らかのアウトプットがあるわけです。ただ、資料を読むだけでお給料がもらえるなら、なんと楽なことでしょう。現実はそんなことはありえないのですけれど。
ということで、本当の正解を以下に示します。

(d) 今週金曜日の午前中までに資料を読み、開発に必要な要件について、金曜日の午後に報告します。

これぐらいの報告ができれば完璧です。「この人は仕事ができる」と思ってもらえます。
論理的思考というと、MECE(Mutually Exclusive and Collectively Exhaustive)や3C分析(Company, Customer, Competitor)、SWOT分析(Strength, Weakness, Opportuniy, Threat)、PEST分析(Political, Economic, Social, Technological)、PDCAサイクル(Plan, Do, Check, Action)、What/Why/Howロジックツリーなどといった様々な手法があります。名前だけ聞くとなんだか難しそうですが、論理的思考は、仕事ができる人になるための手法です。特に、ITエンジニアはその仕事柄、論理的思考のスキルが強く要求されます。物事を筋道立てて理解し、説明できる必要があるからです。

論理的思考は義務教育では教わらないので、自分で学ぶ必要があります。会社によっては社員教育で学ぶ機会があるかもしれないですが、そうでない場合、やはり自分で学ばないといけません。
会社で仕事をこなしていれば、自然とスキルが身につくかどうかは本人の努力次第なので、自分で意識して学んでいかないと、経歴は長いのに、「あの人は論理的じゃない」などという評価がなされてしまいます。そうならないためにも、自己学習は必要です。

チェックリスト：
1．日頃の業務で論理的思考ができているか？
2．仕事をする中で曖昧な言い方をしていないか？
3．仕事をする上でゴール(目的)を意識できているか？

2019年1月4日発売予約受付中

本書の目次

論理的思考がなぜ必要なのか？
論理的思考はシンプルな考え方の組み合わせ
伝え方のコツは結論から
定性的よりも定量的で
あるべき姿と現状を常に考えよう
愚痴と提案を使い分けるのがオトナ
モレなくダブリなく
問題は系統立てて考える[前編]
問題は系統立てて考える[後編]
仮説思考とPDCA
論理的思考の例題集(1)
論理的思考の例題集(2)
論理的思考の例題集(3)
チェックリスト

平田豊（ひらたゆたか）

1976年兵庫県生まれ。石川県在住。