元記者がエンジニアの仕事を新聞流に考えてみた
この記事はマネーフォワードアドベントカレンダー2019🎄の11日目の記事です。色んな職種のメンバーでお届けしています！
こんにちは！マネーフォワードでサーバーサイドエンジニアをしている藤井です。
私は日本経済新聞社の記者職から転じ、2019年4月にマネーフォワードにエンジニアとして入社しました。その経緯はnoteやマネーフォワード エンジニアブログで書いています。
今回は、そんな少し変わり種な私が今年1年エンジニアとして働いて考えた事を、新聞社時代の言葉に置き換えて書いてみます！新聞記者とエンジニア。全く違う職種のようで、仕事で気をつけるべき点は似たところもあるかな、と感じています。
刺さる人には刺さるコンテンツになるかな、と思います！どうぞお付き合い下さい。
1. 「絵」の無い紙面(PR)は読まれない
新聞社時代、私は紙面のレイアウトを作る「整理記者」という仕事をしていた時期がありました。新聞のレイアウトは記者の書いた原稿と写真やイラスト、そして整理記者が付ける見出しから構成されています。
新聞の社会面のレイアウトをしていた時にデスク(編集者)から言われたのが「絵」の無い紙面は読まれないという言葉です。「絵」とは写真やイラストの事です。
新聞は基本的には文字で情報を伝えていますが、新聞をパッと開いた時に目に飛び込んでくる写真やイラストの力はやはり大きいです。読者を惹きつけるためには文章だけではなく「絵」がないといけないという事ですね。
これはエンジニアが作るPull Request(PR)にも似たことが言えるのでは無いか、と思っています。
PRをレビュワーが読む時、基本的にはコードの差分を見ますね。ただその前に、このPRが何を目的として作られたか理解するためにdescriptionを読むと思います。このdescriptionにも「絵」が必要だな、と考えています。この場合の「絵」は、画面のスクリーンショットですね。
(イメージ：修正前と修正後の比較などがあると分かりやすいですね)
画面に変更が入るPRはもちろんスクショを付けた方が良いと思います。変更が視覚的に分かり、レビュワーに優しいですね。画面に変更が入らなくても、コンソールでの検証結果などもスクショすると良い場面もあるかと思っています。実際に手元で検証を実施したことが分かるからです。もちろん場合によってはスクショなどが必要ないPRもありますが。
これは開発のエンジニアだけでなく、QAなどでも言えるかと思います。弊社のあるQAエンジニアは、どんな些細な事象でも、バグ・インシデントのチケットを起票する時はスクショで分かりやすい証跡を残した方が良いと言っていました。「開発者は忙しいので、目に見える証跡が無くて理解に無駄に時間を使わせたくない」との配慮からだそうです。
これも弊社のエンジニアで「PRはエンジニアにとっての作品」ということを言っている人がいて、良い言葉だと思いました。自分の作品をレビュワーに理解してもらいたいからこそ、「絵」を付けたいですね。
2. まず見出し（目的）とスケルトン（全体像）
記者として企画記事を書く時、まず言われるのが見出しを決め、スケルトンを書けということでした。スケルトンとは記事の企画書のようなものです。
経験が浅い記者は集めた材料を元になんとなく記事を先に書いて、後から見出しを付ける、という事をやりがちです。しかしそれでは伝えたい事に焦点が定まらない記事になってしまいます。
まず見出しを決めて伝えたい事をはっきり定義し、さらにスケルトンを書いて記事全体の構成を固める。その上で追加の取材をして出稿する記事を書き上げる、というのが基本なのですね。
このように仕事の全体像を先に固めて着手する、というのはどの業種でもある程度共通すると思いますが、やはりエンジニアの仕事にも通ずると思います。
機能追加であれ既存機能の修正であれ、まず自分がどのような目的で作業をするか(これが見出しに相当すると思います)を決め、更に工数の見積もりや調査、設計、実装、QAへのテスト依頼、リリースなど全体の計画(これがスケルトンに相当しますね)を立てる。この一連の流れの基本は変わらないと感じています。
見出し、というのは個々のPR単位で考えるとより分かりやすいですね。PRのタイトルはコードを修正する目的を表していますが、これが記事における見出しにそのまま当てはまると思います。
良いPRを作るには、見出し(=目的)を最初に定めて作らなければいけないという事ですね。
3. 初行（変数）ズバリ
またまた紙面のレイアウトを作る「整理記者」時代のお話です。整理記者の一番の仕事は、記者の書いた原稿を見て見出しを付ける事です。
ここでデスクから教えられたのが初行ズバリという言葉です。何の事だか分かりませんね。解説します。
よく見る新聞記事の見出しというのは大きい文字の行とその左の小さい文字の行の2行で構成されていることが多いですね。大きい文字の行は見出しで一番伝えたいこと、小さい文字の行はその補足情報が書かれています。
初行ズバリというのは、この2行のうち大きい文字の行(=初行)を読んだだけで記事全体の大まかな内容が分かるようにする、ということなのです。言い換えれば、小さい文字の行や、記事の本文を読んでようやく意味が分かる初行だとダメだということですね。
この考え方は、エンジニアの仕事でいうメソッドや変数の命名に通ずるのではないか、と思います。メソッドや変数の名前も、処理を追うことでようやく理解できるのでは良くないですね。名前を見てある程度メソッドの処理や変数の中身が分かるのが良い命名だと思います。
名著『リーダブルコード』にも「名前に情報を詰め込む」という章がありますが、やはりメソッドや変数の名前(=新聞の見出し)を見ただけで情報を読み取れるようにすることが大切だと思います。
さいごに
長々と書いてきましたが、要は新聞記者もある意味情報媒体という物を作る仕事なので、仕事をする上で気をつけることがエンジニアと通ずる、という話でした。
上に書いたことで、私自身気をつけてもできていなかったりすることもあるので、頑張って良い物作りができるようにしたいと思っています。
読んで頂いてありがとうございました！
この記事が気に入ったらサポートをしてみませんか？