こんにちは、しょごたんです。
ニーアオートマタ、くっそ面白いですね。
前作のニーアレプリカントも最高でしたけど、今回も最高です。
2B が可愛すぎてしかたがない、尊い。
さて、大学を卒業して地元の IT 企業に転がり込んでから 10 年近く経っちまいました。エンジニア 10 周年記念ですよ、10 周年。
振り返りも兼ねてウチが開発する上で心がけてるポイントを並べて見ようかと思います。
クライアントの身になって自分の意思も据える
設計を行う際にどのような機能が必要かを考えるわけですが、 その際に実際扱うクライアントがどのようにしたら扱いやすいかを一番に考慮します。当たり前なことではあるんですけど、その辺を加味せずに作るとクライアントからしたら扱いづらいものになってしまい、クライアントで扱いきれず費用をかけてもそのまま放置、そして他でリニューアル……となってしまい、もったいないです。
そのために、必要とあればディレクターやクライアントに直接ヒアリング・提案を行って納得がいく形を模索します。お互い納得したものをカタチにして、それを利用してもらったときのお客様から満足の声は最高です。
想定される可能性を広く多く考える
要件定義からシステムの基本設計、詳細設計などを経て いざ開発するわけですけど、 入力データを使った処理に関しては必ずあらゆるケースを考慮する必要はあるかと思ってます。必須、形式、業務チェックなどのバリデートは当たり前なんですけど、想定できるユーザエラーも考慮して見ると お堅いプログラムになると思います。
例えば、データ取得ファンクションにおいては仕様・運用上データありきなものだったとしても、 後々運用にのせた後に予期せぬ形でデータ欠損によるエラーがでてしまう可能性も加味してあげたり。クライアントを疑うわけではありませんけど、開発者としては「もしかしたら」「万が一」っていう意識でいるべきかと思います。必ずしも想定される結果が返ってくるって絶対神話を持ってしまわないように。
「世の中 バグや不具合が起こらないプログラムなんてない」って絶対神話をぶち壊しに行くためにも、いい意味で疑ってかかりましょう。
ソースコードは読みやすく可読性重視
企業に努める身として、自分で構築したものは基本的には自分で更新・改修などを行いますが、 ときには当時の担当者が退社していたり、当人はいても他の人が担当となって扱うときがあります。その際に、設計書や仕様書など的確なドキュメントがあればこともなしですが、基本的にソースを解析してどういう仕様で組まれてるかは 読み込んで把握していくしかありません。
そんなときにもスムーズに仕様を把握できるように可読性を重視したコーディングをしていくようにしています。
条件分岐にもいろいろな書き方がありますし、書き方の好みなど宗教戦争が勃発しそうな話ではありますが、扱う人のレベルにかかわらず読みやすく、扱いやすく、ひいてはメンテナンス性も重視して共通化するように構築しましょう。それだけで後々随分違ってきます。
ただ、時折 頭沸いたときはついカッとなって、こっそりイースターエッグとか仕込むかもしれませんけど。
担当外の箇所にも首をつっこむ
構築にあたっては各担当者がそれぞれの作業を行います。バックエンドとしては主に下流にて組み込む形でしょうが、ディレクター・デザイナー・フロントエンドのアウトプットを都度確認します。要件定義や仕様策定以降の下流で急に仕様が変わるなんてのはザラですが、それぞれのアウトプットが機能的に想定仕様にのっとっているのか、追加されたのならどのような想定で作られているのかを細かく確認します。
そういうコミュニケーションロスによる想定仕様の差異などを防ぐためにも積極的に首を突っ込んでいきます。その際に確認したものはサイト仕様書などでまとめて共有しておくとあとで迷わず作業ができますよね。
まとめ
いかがでしたか。
なんやかんやでいっぱしになってからの構築思想は基本変わらないものですね。RPG でいったら攻撃力より防御力を重視した姿勢な的な、FF14 でもメインタンクだし（関係ないけど）。
それでは。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
