【10年進歩なし】10年近く前にまとめたIT業界の名言集を久々に読み返したところ、今見ても新鮮味があるというか、IT業界の変わらなさを実感し、ちょっと残念な気持ちになりました。この10年間でIT業界は果たして進歩してきたのでしょうか。2017年版の要素も追加して、IT業界迷言集を紹介します。何をやってもバグが解消せず、終電がなくなってもまだ直らない。なったら「仕様」と言い切るしか術は無い・・・そんな悲しい状況が目に浮かびます。私はDBコネクションプールで同じ憂き目を味わいかけました。この迷言、10年経ってもまったく色褪せません。2019年頃と目される民法改正でシステム開発契約における「瑕疵担保責任」の考え方がさらに厳しくなります。仕様と言い張ることもできなくなりそうです。【その2】-------------------------------------「1年に1回起こる可能性が1%の問題なんて無視していい。総稼働時間で考えれば、100台同時に動かすと1年で問題発生ですね。ハードディスクの耐久性能で”100万時間稼動”(MTTF)という製品の考え方と同じ理屈です。この論理で押し切れるクライアントがいたら、逆にヤバいです。2017年現在では、クラウド運用業者は同時に数千台のサーバーを動かしますし、GoogleやFacebook規模だと毎日数台のサーバーが不良で止まります。1万分の1の確率さえ「起こり得る事象」と捉えなければなりません。ユーザーにフェイルオーバーを感じさせない技術も発展したため、フロント側からすると「止まらないシステム」に見えるものも増えました。【その3】-------------------------------------「営業が出した要件が全てだと思うな」おいおい、身内を欺いてどうするんですか。孔明の罠なんて誰も求めてませんから、さっさと仕様を聞き出してきてください。この迷言、10年経っても変わりません。営業と現場は敵同士のところはまだまだ多いです。DevOpsで開発vs運用の戦いが収まりつつあるなら、「SalesDevOps」まで踏み込んでしまえばいいのに。【その4】-------------------------------------「所詮ボクらは農耕民族。運用チームにこんなことを言われると本気で泣けてしまいます。そんなに卑屈にならないで下さい。どこの業務ユーザに苛められたんですか?あなたのチームがいるからみんな仕事ができるんですから、どうか自信を持ってください。2017年、DevOpsが徐々に世に広まり、DevがOpsの仕事を巻き取る(奪う)ようになってきました。運用チームに狩猟民族の血を入れる必要はありませんが、好奇心旺盛で開発に首を突っ込んでくるプロモーターの血は必要でしょうね。畑を守るだけの運用チームに居場所はなくなりつつあります。」ああ・・・哀れ、ブルースクリーンを見てしまいましたか。ダンプ情報が書かれているのに、一瞬で消えてしまうから内容を確認する間もないという冗談みたいな画面。なんのためにエラー情報吐いているんだぁ!!2017年、ブルースクリーンを見ることはかなり減りました。オフィス製品がフリーズして作成中のファイルが失われてしまうことも、オートバックアップのおかげで減ってきたと思えます。Luke)!」コード至上主義の方と仕事をすると似たような話を聞きます。確かに一理ありますし、生産性も高いのですけど、官公庁の仕事でそんな無茶を言わないで下さい。手動で仕様書は作らないとダメですね。【その7】-------------------------------------「我がコードは我流。論よりコードに似ているようで全然違います、コチラの方はコードの可読性が限りなく低い!一体誰に保守させるつもりでしょうか。我流で書けるのは分かりましたから、次はコメントの書き方やデザインパターンを学んで、可読性の高いコードをお願いします。2017年、今でもこうしたコードを見かけます。開発費をケチられたといっても、保守できないレベルのコメントしか残していないというのは開発者の矜持に欠けますよ。「いつまでもあると思うな保守のカネ」2人月×12か月で積んでもらった保守費用なのに、わずか6か月で使い切るとはなんということでしょう。バグだらけのシステムを無理やりリリースしたばっかりに。この後半年間、どうやって過ごすつもりでしょう。「嘘から出た受注」IT業界は慢性的な人不足。それは昔から変わっていません。受注金額はなぜこんなにも低いのでしょう。裏を返せば、単価を高くしたら仕事をもらえないということ。お断りする前提で高値入札しちゃいますよ、と勇んで出した提案書が通ってしまったとき、営業は青ざめるのです。やばい、空売りだ!その結果、頭数は10人しかいないのに20人分の働きをしなければならなくなることも。2017年は働き方改革の影響で残業規制がすさまじいです。月残業が45時間を超えると指導が入りますから、130%以上働く月が続くとアウト。IT業界特有の働き方がこの機に改まることを願います。一説によれば、15以上の言語を操れるレベルで一人前のプログラマーらしいです。Java、JavaScript、C、C++、C#、PHP、Python、Ruby、Objective-C、HTML5、CSS、Perl、Haskell、Go、COBOL、R、VBA...これだけできれば一人前か。「電話いそげ」メールでコミュニケーションしたい気持ちはわからんでもないんですけど、そのメールを1通書くより先に電話を一本したほうがいいんじゃないでしょうか。「転ばぬ先のテスト」それな。テストドリブンでもテストファーストでもどっちでもいいですから、テストしてないものを本番環境で動かすのはやめましょう。やってないテストコンディションを「やった」と言い張るのも、1回目のテストエラーは全部ノーカウントで、2回目からトラッキングするとかいうのも怖いからやめてあげてください。運用保守チームが死にます。「風が吹けばコンサルが儲かる」ちょっとしたことを大事にして案件に仕立て上げる。そんな悪いことをする人は最近のコンサルにはいません。そんなことをせずとも、クライアント企業の企画部門は人員不足に苦しんでいます。予算さえ確保できれば、すぐにコンサルに声をかけるのです。日本のIT部門の生産性は指折りの低さ。やることはどんどん増えるのに残業規制で働きたくとも働けない。そんな状況では、外部のコンサルに仕事を切り出すしかないんです。案件の絶対量と納期がもっと緩くなればいいのに。「納品良ければすべて良し」いくらたくさんのテストエラーが出ようとも、課題検討会で相手にボコボコにされようとも、サービスインがうまくいって、納品完了すればよいのです。雨降って地固まるよろしく、苦労を共にするとベンダーとクライアントの一体感は激増します。yourself」(ITは各自で取り組むように)です。ITを情報システム部門に頼る時代は終わりました。クラウド活用が叫ばれる昨今、ユーザーは自分でクラウドサービスを申し込んで、自分でサービスを利用開始してしまいます。Salesforceのように。いう勝手ITはユーザー自身の手で後始末してくださいね、と言えたらどんなに楽でしょう。最後はまともな名言で締めましょう。一を聞いて十を知る人も確かにいますが、多くの人は一を聞いて一を理解する程度です。いや、確実にその一を達成できる人はやっぱりそんなに多くないでしょう。書籍や伝え聞いた話で理解した気になるのではなく、実際にソースコードがどんなものかを感じ取ってからITを語ってほしいです。いう点で、最強のIT戦士になるためのスタート地点はプログラマーなのだと思っています。ITコンサルもSEも、原点はプログラマーにあり。読みやすい資料を作るための6つのルールビジネスシーンで用いられる実践的でわかりやすい資料は、一定のルールを満たしています。ドキュメントの読みやすさは、ロジック(ストラクチャー)/書式(スタイル)/図表(スキーマ)によるところが大きいですが、何よりも「文章術(センテンス)」の出来の良し悪しは目につきやすく、資料作成の力量が問われます。あなたにそのつもりがなくても、相手の誤解や認識不足を招いてしまいかねない言葉は用いません。難しい表現、あいまいで抽象的な表現はできるだけ避けます。文法が正しくとも、言葉と言葉のつながりがわかりにくくなるほど長い文章は、適度なボリュームに切り分けることも必要です。センテンスがわかりやすい文書は、「言葉を簡単にする」ための6つのルールを実践しています。1.一般的な表現を使うカタカナ語句の多用は、あなたの表現力の弱さを読み手に感じさせ、文章の質を損ないます。社内ではカタカナ語句が飛び交う外資系企業でも、対外的に提出する文書では乱用しません。海外とのやりとりが多い部門や、業界標準の多くが海外で決まる世界(IT業界など)では、避けようもなくカタカナ語句が溢れています。した言葉を組織の人々で共有するためのやり方として、用語集を作ることを推奨します。「〜性/〜的/〜化」の接尾辞を持った熟語を減らし、文として説明するように書き換えると、漢字の比率が下がり、読みやすくなります。ビジネス文書に書きなれると、文字数を節約するために熟語を多用しがちです。本文中にこうした熟語を用いる際は、「熟語化を避けた方が読みやすくなるか」を自問し、もしYesなら、熟語の使用はやめましょう。形式名詞/副詞/接続詞/補助用言/複合動詞は読みやすさの点から漢字にひらきます。ビジネスの現場でよく登場する「ひらく」漢字はだいたい決まっています。副詞なら以下の通りです。一般的には30%、ビジネス文書なら40%以下の漢字率を目指します。トンカツは食べないまた、「似て非なる漢字を使った言葉」での誤用は目立ちます。以下に示す言葉の使い分けを厳密に行えていれば、それだけでも文章の質は高まります。2.明確な表現を使うあいまいな表現を用いると、相手の勘違いを招きます。勘違いは混乱や手戻りにつながり、悪くすればビジネスを頓挫させてしまいます。人によって捉え方が異なる表現は避けて、数字や具体的な表現を用います。誰かに聞いた話(伝聞)、あなたが想像した話(推量)は事実とは言えません。ビジネス文書では、事実ではない情報を極力排除します。あなたの意見が求められる場合に限り、推測にもとづく内容も伝えます。・自分の意見が強い場合は能動的、一般的な考えである場合は受動的に表現する。・推量表現を英訳する場合は以下の確率を目安にする。:10%期限と度合を表す言葉で認識違いが起きると、致命的なミスになりかねません。具体的な数字を使って記述します。コストとボリュームに関する情報は具体的な数値を使って説明すると説得力が大きく増します。「このシステムを導入すると業務効率が向上して新規事業に取り組む余裕がでます」と言われるより、「今まで10人でやっていた事務作業が5人で済むようになり、残りの5人分で新規事業に取り組むことができるようになります」と言われた方が、具体的な効果をイメージすることができます。3.文体を統一する日本語で書かれるビジネス文書は、敬体/常体のいずれかで記述します。敬体とは「です/ます」調の文章です。この文章も敬体で書かれています。常体は「である/だ」調の文章です。常体表記の方が短い文字数で表現できるため、特に決まっていないのであれば、ビジネス文書の本文レベルは常体で表現します。何かを相手に依頼したり、自分側の落ち度を謝るときには、本文を敬体にすべきです。敬体は柔和な印象を漂わせ、指示や依頼が持つプレッシャーを和らげる効果があります。「一方的に押しつけられた」と相手に思わせないための工夫です。社外向け文書についても同様で、相手に一方的なプレッシャーを与えないために敬体で書きます。4.トートロジーを削るトートロジー(Tautology)とは、文章の知的レベルを損ない、文書の内容自体に疑いを持たせかねない、誤った重複表現です。見つけたらすぐに書き改めます。単純なものとして、「白い白馬」や「頭痛が痛い」のように、言葉同士で同じ意味を持つものを組み合わせてしまう「同語反復」があります。同語反復に気づいてしまった人はそれが頭の中に引っかかり、几帳面な性格の相手なら議論が脱線してしまうこともあるでしょう。話に集中してもらうために、同語反復は文書の中から排除しましょう。同語反復よりも見つけにくく内容面で致命的なのが、理由と結論が繰り返されている「同義循環」です。「右とは左の反対である」と「左とは右の反対である」はいずれも正しい定義ですが、両者を同時に扱うと同義循環になります。5.「〜を行う」を多用しない検討を行う、調整を行う、設定を行う......気づけばつい使っている「〜を行う」という表現は、名詞にくっつけるだけで動詞に早変わりします。便利ですが、使い過ぎると文章を稚拙でわかりにくくする原因になります。「処理を行う」という文は「処理する」と1語で表すとシンプルになります。「Aする」と書ける部分を「Aを行う」と表すことで、助詞の「を」が増えます。した表現が増えるほど、文中に登場する「を」の数が増し、文のリズムを狂わせます。目安として、1つの文で許容する「行う」は2語までとし、それを超えるものは動詞1語で書き表すことにします。前提や仮説を含めて書くビジネス文書は多く、文中には名詞との組み合わせで「可能だ」という表現が頻出します。この表現が文中に何度も出てくると漢字比率が高くなり、格式ばった文章に見えがちです。そこで「可能だ」→「できる」と書き改め、文を読みやすくします。「来週までに提出可能だ」は「提出できる」と書き換えます。「可能だ」と並んでビジネス文書頻出の表現が「必要だ」です。これも「すべきだ」と書き換えることで文を読みやすくできます。「修正が必要だ」→「修正すべきだ」と改めることができます。6.受け身を多用しない受け身とは「れる」「られる」といった受動態で表現するさまを意味します。「会議を開く」を受動態で表現すると「会議が開かれる」になります。受け身表現で文章を書くと、主語にすべき言葉がぼかされ、主体者不在のような印象を読み手に与えます。受け身が多く使われている文書を読むと、「他人事のように書いている」と思わせてしまうリスクがあります。捉えられやすい表現に「せる」「させる」があります。この言葉は、相手に何かをさせる場合に用いる使役表現です。両者を比べると、�@よりも�Aの方が積極性を感じられます。自分が代表して意見を述べる場面では、�Aの表現を用いて主体性を示します。わかりやすい文章を作る方法はこれだけではありません。相手へ誤解なく情報が伝わる文章は、例外なく構造が単純です。これについても次の6つのセンテンスルールが存在します。→主語と述語のずれを防ぐ→主語と述語だけをつなげてみる11.主語と述語を近づける→主語と述語が離れると複数の解釈ができてしまう→主語と述語を近づけて解釈を迷わせない12.校正機能を利用する→オートコレクトを絞りこむ→言葉のゆらぎ/文法の謝りを修正する→スペルミスを修正する→読みやすさを自動的に定量評価する→文章の修正経緯を変更履歴で辿る先に取り上げた1〜6についても、もっと踏み込んで具体的に説明できますが、いずれもコンテンツのボリュームが大きいため、詳細な解説は『外資系コンサルのビジネス文書作成術』(東洋経済新報社)をご覧ください。センテンスのルールだけではなく、ロジカルシンキングにもとづくコンテンツ構造を作るルール(ストラクチャー)、使いやすくて見やすい書式設定のルール(スタイル)、チャートとグラフをわかりやすく表現するルール(スキーマ)についても図解しています。サルが扱う書類」と聞くと、PowerPointで華麗にお絵かきされたチャートやExcelで緻密に関数処理されたワークシートを思い浮かべる読者も多いでしょう。日々のビジネスを支えているのはWordで作成した文書です。何か新しいことを提案するのにPowerPointは有効ですし、複雑なデータをわかりやすくまとめるのにExcelは役立ちますが、文書管理の視点から、「フォーマルな業務文書はWordだ」と考える組織はとても多いです。それほど重要なWord文書の作成法を体系的に学んだ人はほとんどいません。見よう見まねで作成する、過去に誰かが作成したテンプレートを上書きすることが繰り返され、Word文書はどんどん見にくく、読みづらい存在になっています。その結果、「Word文書は扱いにくい」という認識を多くの人が持つようになりました。Word文書にはPowerPointにもExcelにもない、それ自体で相手の納得を引き出す力があります。そのことをあなたの周囲も、あなた自身も真に理解していると断言できるでしょうか。累計数十万部を数える「外資系〜シリーズ」には、パワーポイント向けの「スライド作成術」、エクセル向けの「Excel作成術」があります。ワード向けの本は存在しませんでした。ルールさえ知ってしまえば、Word文書を自在に操ることは、実は難しくありません。本書では私がコンサルタントに指導しているWord文書作成メソッド、「伝わる文書を書くロジック」と「効率よく作成するWord機能の使い方」を解説しています。優れたWord文書を効率よく作成する方法を知り、適材適所でビジネス文書を作り分ける術を自分のものにしましょう。※書籍で「ビジネス文書作成レベル診断」を行うことができます。・Wordで議事録を書く・議事録作成をシミュレーションする紹介用のPDFはこちらからどうぞ。→ダウンロードリンク以上。プロフェッショナル仕事術2017年03月13日ITエンジニアのコミュ力IT業界に長く生きていると、様々なタイプの人に出会います。コンピューターに向かい合う業界なので、技術に詳しい人が多いと思いきや、「技術的なことは大してわかりません」という人も数多くいました。した人はコミュニケーションスキルに長けた方が多く、ユーザーとの接点も多いため、クライアント側からは頼りにされます。一方で、コミュニケーションベタが理由で、優れた能力を持っているのに「この人は頼りにならない」とネガティブなレッテルを貼られることもあります。「自分の理解できない説明ばかり」「知りたいことにピンポイントで答えてくれない」などの不満から、クライアント側で評価は低く、これが相手との信頼関係を損なって、本来は不要なコミュニケーションをどんどん求められるという構図に陥ります。スキル本位のギークな世界であるはずが、「コミュニケーション」というスーツの世界に浸食されている状況を憂うITエンジニアは多いかもしれません。スーツの世界の武器を1つ手に入れてみればよいだけの話です。人と人とのコミュニケーションも、アプリ間のインターフェースと本質は変わりません。許可されているコマンドとオプションの数が多いだけです。コミュニケーションのコマンド&オプションのバリエーションを覚える近道は、具体的なやりとりをたくさん見聞きして経験値というか熟練度を増やすことです。日々の仕事の中で経験してもよいですが、典型的なパターンを本から学ぶのも効率的でしょう。私の手元にある『ITエンジニアとして生き残るための「対人力」の高め方』(日経BP社)では、次のケースが列挙されています。バッドケースとグッドケースが両方示されているので、理解しやすいです。等この本に謳われている『「他人ごと」を「自分ごと」にする』という姿勢は、ギーク・スーツ問わずに共通する必須のコミュニケーションスキルです。相手の状況を察して「自分があなたの立場にあったらこうします」という意見を持っている相手だからこそ、信頼を獲得することができるのです。した事例を手元に置いてイメージトレーニングすることは、スーツの上を行くギークになる近道になるでしょう。マスターヨーダもクリエイター:クリエイティブになる31の方法(05/31)主要ツール120個を網羅するDevOpsツール周期表、作り方(05/26)ロジカル・ラテラル・クリティカルシンキングで発想力を鍛える(05/26)ユンケル黄帝液とユンケルスーパー黄帝液の違い(08/24)文章をわかりやすくする【18個】のルール(05/31)誠意を見せつつ相手に納得してもらう「謝罪報告書」の書き方(04/11)10年前に予測したITの将来が2017年どれだけ実現できているか?(03/30)【IT業界名言集】我がコードは我流。