Digital Heroes: Guide to IT World

設計書とマニュアルに向き合って初めて気づいた「伝える仕事」の正体 うわっ!? ドキュメントって、誰が読むの？ 画面を前に、思わずそんな独り言が漏れた。プログラムを書いているときには感じなかった種類の、じわじわとした難しさがそこにあった。     ■ プラットフォームを「作る側」に回った瞬間 プラットフォームを理解し、サーバを理解し、構築業務に携わる。 私の役割は、設計からプラットフォームを作っていく仕事だった。設計書を起点に、プログラムを自動生成する。だからこそ、設計書の出来が、そのままシステムの質になる。 フォーマットを決め、何をどう書いてもらうかを定義する。 プログラムが得意な先輩に何度もレビューしてもらいながら、少しずつ形にしていった。 ■ 「全部プログラムに落ちるの？」という葛藤 設計書は、どこまで書けばいいのか。 全部が全部、プログラムに落ちるのか。結構、時間をかけて考えた。 経験が豊富とは言えない自分が、設計者の修正を想定し、設計すべきことを考える。よくある問題は「設計漏れ」だ。だからこそ、漏れがないように設計書の項目を一つひとつ決めていった。 ■ 本当の難関は、その先にあった 一番てこずったのは、そこからのマニュアル作りだった。 考えたことを文章にすればいい、という話ではない。読む人が分かりやすいように、丁寧に、でも読みやすく。 そもそも、どうやってマニュアルを開くのかすら分からない人もいる。 そして正直に言えば――自分は、あまりマニュアルを読まないタイプだ。 ■ 「自分でも読むか？」を問い続ける そんな自分でも読むには、どうしたらいいのか。 意味のある情報は何か。知りたい情報は、きちんと読み取れるのか。 気づけば、「プログラムを書いている方が楽かもしれない」と思っていた。 こんなにもドキュメントを書くのが下手だったなんて。日本語の奥深さを、思い知らされた。 ■ 消せるから、書ける それでも、パソコンで良かったと思う。 すぐ消せる。何度でも書き直せる。難しさに苦しみながら、少しずつ仕上げていく。 ドキュメントは、単なる説明書ではない。 未来の誰かと仕事をつなぐ、静かなコミュニケーションなのだと、今なら分かる。 設計も、プログラムも、ドキュメントも。 全部つながって、...

完璧を目指した先で出会った、想定外を暴く知恵 うわっ、テストってこんなに奥が深いのか!?――それが、私が社会人になって最初のシステム構築プロジェクトで感じた率直な驚きでした。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ 最初のシステム構築プロジェクトの洗礼 配属されて間もなく参加した、人生初の本格的なシステム構築プロジェクト。そこで教え込まれたのが、「テストは気合と根性ではなく、構造でやるものだ」という考え方でした。 ■ マトリックステスト表との出会い 当時のテストは、マトリックステスト表が中心。 縦軸と横軸に条件やデータを並べ、あらゆる組み合わせを一つひとつ確認していきます。 ロジックはすでに分かっている。だからこそ、そのロジックに合わせてテストケースを作る。 組合せ網羅――これがマトリックステスト表の最大の強みでした。 ■ 「これをやっていれば漏れはない」はずだった 正直、ここまで細かくやれば、バグなんて残るはずがない。 当時は本気でそう思っていました。 実際、このテストはかなり優秀で、論理的な抜け漏れはほぼ防げます。 ■ あれ？これ、普通じゃない？ ところが後になって気づきます。 このマトリックステスト表、日立では当たり前のように使っていたのに、他社ではあまり見かけない。 テスト関連の書籍を読んでも、あまり詳しく出てこない。 「これ、もしかして企業内の知恵なのかな？」 そう感じた瞬間でした。 ■ それでも、最後にバグは残る どれだけ組合せを網羅しても、なぜか最後にバグは残ってしまう。 なぜなのか。 ■ バグは“意識の外”に潜んでいる 後で分かったのは、バグは意識しているところにはいない、という事実でした。 設計によるバグ、仕様によるバグ、コーディングバグ、テスト漏れ…。 いくつもの関門をすり抜けて、しぶとく残るバグがいるのです。 ■ そこで登場、モンキーテスト この残党バグを見つけるために使われたのが、モンキーテスト。 サルのように、バンバンとキーボードを叩く。 意味不明な文字を入力する。 順序もルールも無視する。 ■ 想定外をあぶり出す力 一見ふざけているようですが、これが結構優秀。 設計者もテスターも想定していなかった操作によって、サーバの...

 驚きの呼び出し 「えっ!? 上司にKISS!?」 思わず耳を疑うようなフレーズですが、これは恋愛話でも武勇伝でもありません。私がキャリアのある一日、スペイン人の上司に呼び出されて学んだ、人生を変えるほどの一言の話です。 その日も私は、グローバルのCRMを日本市場に適用するという難しいプロジェクトに没頭していました。インドのベンダー、日本のベンダー、そして社内の各部署をつなぐ“Technical Project Lead”として、日々フル回転。プロジェクトが遅れないよう気を張り、夜遅くまでメールとコードと会議に追われる毎日でした。正直、難しいプロジェクトには慣れていたはずなのに、今回はどこかうまく回らない。じわじわと低迷の影が差していました。 スペイン人上司からの問いかけ そんなある日、リードであるスペイン人上司に呼び出されました。 「いろいろ問題はあるが、どう思う？」と聞かれた私は、必死に前向きさをアピールしました。 「難しいですが、頑張っています。挽回できると思います」 すると彼はじっと私を見つめ、こう言いました。 「お前はKISSを知っているか？」 頭の中に「？？？」が並びました。KISS？ キス？ いやいや、そういう関係じゃない。何を言っているんだろうと困惑する私に、彼はニヤリと笑って答えました。 KISSの意味とは 「Keep It Simple, Stupid」 彼は続けました。 「複雑なものを複雑にしすぎるな。シンプルに考えろ。ごちゃごちゃしているものは一度静観して、後ろから全体を見て整理しろ」 その瞬間、頭の中で何かが“カチッ”と音を立てた気がしました。夜遅くまで必死に細部を追いかけ、問題を抱え込んでいた自分。複雑な糸をほどこうとするほど絡まっていく毎日。そんな時に浴びせられた「KISS」というシンプルな一言。頭がポカポカするような感覚に包まれました。 視点が変わる瞬間 それから私は、複雑に絡まった課題を前にすると「KISS」を思い出すようになりました。冷静に後ろから眺めてみると、本当に重要な部分は実は限られている。そこを解決すれば、他は自然とついてくる。無理に全部を抱え込む必要はない。 あの一言がなければ、私は今も「複雑さの迷路」の中でもがき続けていたかもしれません。シンプルにする勇気。それは技術者...