こんにちは。
SIerで仕事している2年目の若手SEになります。
ソースコードとコチャコチャ遊んでいる時間が殆どなので
職業柄、英語に触れ合う期間は長いです。
グローバルなこの社会で世界的公用語である英語という言語の
能力を磨くことは最早、必須ともいえるでしょう。
しかし、web界隈ではどうなのか知りませんが
SIerではそれと同じくらい、
設計者や仕様書に向き合う時間も長く、
膨大な日本語にも触れ合って来ました。
現場によっては文言まで統一された
ガチガチフォーマットもあるのでしょうが、
私が経験して来た現場は割と
フリーフォーマットの緩いところが多かったです。
そうなってくると千差万別、人の数だけ設計書があり、
そこには多種多様な日本語が見受けられて来ました。
個人的に気になることを少しだけ書きたいと思います。
日本語は文面という手段において有利#
私は日本語というのは文体という世界で
非常に優秀な言語だと思っています。
それは漢字がもたらす恩恵です。
世界に色々な言語はありますが、
「文字」自体に意味を持たせることが可能な
日本語、中国語は文章によるコミュニケーションを
とる際に非常に強力なツールだとおもっています。
しかし本来の日本語のアドバンテージを
履き違えているような日本人の方が散見されます。
日本語の正しい使い方#
ビジネスにおける熟語の正しい使い方を知っていますか？
何が正しくて、何が正しくないとかあるのか
と思われるかもしれません。
まず、間違った熟語の使い方はこうです。
「ログインを行ったアカウントが初めてのログインである場合に、
画面Aから画面Bへの画面の遷移処理を実行する事が可能」
やや大げさには書いてますが、これに近いような
冗長性を塊にしたような設計書をよく見かけます。
個人的にはベテランレガシープログラマーに
多いような気も。
こんな文章は以下のようにかけます。
「初回ログインのアカウントの場合、
AからBへ画面遷移できる」
スッキリしましたよね？
ポイントをピックアップして行きます。
①熟語の使い方##
まず、初めての〜が「初回」の2文字で表現できてますよね？
これが正しい熟語の使い方です。
英単語では略語を使わない限り
どうしても文字数は減らせません。
②DRY原則##
また、画面、画面、画面とうるさかったのが
画面遷移と書くことで前後のAとBが画面であることを
暗黙に示唆しています。
DRY原則(don't repeat yourself)は
何もメソッドなどに限りません。
同じことを何度も書かない工夫をしましょう。
引用などを使うのもベターです。
③無駄な単語##
次に個人的に一番嫌いな単語、
処理、実行など。
ほんとに、その言葉必要ですか？
削除処理→削除
変換処理→変換
処理という言葉の
8割くらいは省略できるんじゃないかと思います。
「学校へ行く」ことを「登校」と２文字で
短く簡潔に表せるのが本来の熟語の利点です。
無駄に文字数を増やしていては本末転倒です。
④ひらがなの効果##
また、敢えて「出来る」を平仮名で書いています。
なんでもかんでも漢字ばっか使うと
お経のようになってしまいますが、
区切りに平仮名を用いる事で
メリハリが生まれて読みやすくなります。
「従業員情報削除処理実行」
よりも
「従業員情報を削除する」
の方が読みやすいですよね。
日本語は難しい言葉を振りかざして
賢ぶる為にあるわけではありません。
「負ける」を表現するだけでも
惜敗、惨敗、完敗…
などたったの2文字で表現豊かに「負け方」を表すことができます。
短い単語の中に情報量を多く詰める事こそが
本当の美しい日本語の使い方だと思います。
見やすい図の描き方#
単体テスト項目書などで使われる
マトリクス図やディシジョンテーブル。
こんな描き方していませんか？
傘の条件
| 晴れ | 雨 |
|---|---|
| 傘を持っていかない | 傘を持っていく |
これでは図を使っている意味がありません。
以下のように描けば見やすくなります。
傘の条件
| 晴れ | 雨 |
|---|---|
| × | ○ |
○: 傘を持っていく
最後に#
少しの工夫をするだけで
あなたの設計書は途端に見やすくなります。
設計書は書くものではなく読まれる為にあるので
再度自分で読み返してみて
無駄のない美しい文章を心がけましょう。
まだまだ私の文章も精査が必要だと思いますが
ここまで読んでいただきありがとうございました。