うまくいかない時に気にしてみたい四箇条（精神論です）
こんにちは。BTI部のタケヒロです！
これまで、要素技術的な個別の分野に関する内容をご紹介することが多かったので、今回はもうすこし精神論ぽいことを書きたいと思います。
私は以前SEとして働いており、そこでシステム開発における大切なことをたくさん学んできました。
プログラム言語やアーキテクチャ、製品等、その時々で必要とされる重要な技術です。
ただ、学びとして多くを得たのはSEとして過ごした期間の終盤になってからで、個々の技術と言うよりはもっと基本的な考え方の部分です。もっと早く気づいていれば...と思うこともあります。
ちょっと説教くさい内容になってしまうかもしれませんが、特に、これからいろいろな経験を積まれる若い方たちに読んでいただければ幸いです！
急がば回れ
突然ですが、以下のようなコードをご覧になってどう感じますか？
見方によっては、コード量も少なくコンパクトにまとまっているようにも見えますが、ロジックを追ってみると何がしたいのかよく分からないコードですよね。
以下のように書くとどうでしょうか？
大分長くなりましたね。
これらふたつのプログラムは、全く同じ結果を返します。
コード全体は長くなりましたが、後者の方が直感的に分かりやすいコードになったと思います。
ちなみにこのコードは、「18時以前はハッピーアワーでビール1杯300円だが、それ以降は600円。ただし、3杯以上注文したお客さんは1杯あたり500円」ということを意味します。
（私がよく行く、近所のバーの料金ですね。）
なお、ふたつめのコードでは、
一つ一つの定数や計算結果を変数に格納する
コメントをちゃんと記載する
三項演算子を使用しない
という観点から、多少長くなっても分かりやすさや保守性を意識した書き方をしています。
例をもうひとつ。少し大きなプログラムの構造（アプリケーション・アーキテクチャ）も見てみましょう。
以前、こちらの記事で、以下のような処理フローをご紹介しました。
ご興味のある方は、是非お読みいただければと思います。
処理フロー例①
処理フロー例②
処理フロー①より、②の方が良いのでは、という内容です。
せっかく例①の様に1つのフローで実装できているものをふたつのフローに分割し、さらにファイル入出力でつなげてまで疎結合にしたひとつの理由は、個々の処理がシンプルになり「分かりやすく」なるからです。
「分かりやすい」というのはとても大切な事で、個人的には「難しい関数を使っている」とか、「コード量（ステップ数）が少ない」などの要素よりも価値のあるものだと思います。
先のバーの料金体系の例に戻りますが、ひとつひとつの処理要素が明確になっているためぐっと可読性が高まりますし、その結果コードの誤りも各段に減ります。
「コードや処理を実装してバグを作り込んでしまった場合、どこに誤りがあるか分からなくなりがち」「自分が作ったコードは他の人にさくっと引き継ぎたい」…などという場合は特に、上記のようなことを気にして実装してみてください。
急いでトリッキーなコードを書いたらうまく動かず、自分でも何が悪いのかわからない…まして、それを別の人に引き継ぐことなんてできない（誰も引き継いでくれない）ということもなくなり、結果的に無駄な努力を削減できると思います！
逆転の発想（思考の切り替え）
業務要件・システム要件をもらい、その要件通りに素直に実装しようとしたところ、うまくいかなかったという経験はありませんか？
そんな時はちょっと頭を切り替え見方を変えてみると、ずっと簡単な方法が発見できる、ということは結構あります。
弊社での「現場の担当者が作成する日次レポートを、統括部に報告する」という業務においての実際の事例をご紹介します。
もともとは、共有ドライブに保存されたエクセルフォームを現場担当者が更新する、というワークフローで回していました。
（この時点で非効率臭がプンプンしますが、その点は一旦置いておくとして...）
毎日ファイルを開くのが面倒なので、まず現場担当者側の入力フォームをSlackに移行しました。
Slackのスラッシュコマンドを使ってダイアログから入力する、というUIです。裏側では、GAS（Google Apps Script）をつかって、Googleスプレッドシートにデータを蓄積します。
今回は変更（効率化）するのは入力側だけにして、統括部側はまた改めて、ということにしました。
統括部の担当者がGoogleスプレッドシートを直接確認できればそれで済む話ではあるのですが、社内の諸々の事情により、既存のエクセルを見る必要があります。
ここで、Googleスプレッドシートからエクセルにどうやってデータを反映させるかが課題になってきました。
素直に考えたら、例えばRPAを使ってGoogleスプレッドシートからエクセル管理表にセルの値をコピペする、といった処理がすぐに思いつくと思います。
ただ、統括部の担当者がいつエクセルを開くか分からないので、いつ開いても良いようにリアルタイムでエクセルにデータを反映させる必要があり、ちょっと面倒です。
逆に、いつ見に来るか分からない一日一度の確認の為に、リアルタイムで更新する労力をかけるのも勿体無いですよね。
そんなときには、逆転の発想です。
Googleスプレッドシートからエクセル管理表の方向にデータをコピーするのではなく、逆にエクセル表からGoogleスプレッドシートにデータを取りに行くようにしてやれば良いのです。
詳細は割愛しますが、エクセルのパワークエリという機能を使用します。
エクセル側からGoogleスプレッドシート内のデータを参照しに行くので、統括部の任意のタイミングでデータを見に行くことが可能です。
要は、「エクセルを見た時に最新のデータが見られれば良いわけで、わざわざエクセルを常に最新化しておく必要はないよね。だったら、エクセルの方からデータを取りに来てもらった方がシンプルじゃない？」ということ。このように「目的はぶれずに持ったまま、そこに至る過程においていかに発想を変えられるか」がスマートな実装かどうかの分かれ目になってくることがあります。
このような思考法は、BPR（Business Process Re-engineering：業務改革、業務効率化）に取り組む際にも必要な発想です。
ビジネスとして同じ目的を達成するにしても、現行のプロセスは正しいんだろうか？他にやり方があるんではないだろうか？逆に考えたらどうなんだろう？と、頭を切り替えてみると、新しい発見があるかもしれません。
灯台下暗しになっていないか？
これは、自分が作ったコードや処理の結果がなぜか想定と異なる時とか、エセクル計算結果がなぜか合わない時などに良くあることです。
いくら見返しても書いた内容は正しいはのずなに、なぜか思っいてた結果と違う。明らかに「何かがおしかい」のに、何が原因か分かならいことってたまにありまんせか？
挙句の果ては、「自分は間違っていないずはかだら、製品の不具合だ！」とか、「エクセルの結果がおしかいのは、そのデータを作ったXXさんのせいだ！」と言う様に、原因を転嫁しまてしうこともあるかもしれません。（私はよくあまりす…）
しかし、このうよな場合、大抵（ほぼすてべと言っても良いぐらい）は、自分が気づかなかったコードの一部にタイプミスがあるとか、もっと根本的なとろこでそもそも間違っていることが多いのです。
私の最近の灯台下暗しは、時間をかけて作ったパワーポンイトの資料がなぜか先祖返りしてしまい、クラドウスレトージの同期の問題を疑って何時間も格闘していたのに、実際には何気なくコピーしたバックプッアファイルの方を一生懸命更新していた、と言うものでした。
プロラグンミグで良くあるのは、タプイミス（タイポ）です。
どんな条件でプログラムを実行してみても結果が同じになってましう、ロジックをいくら見直してみても結果が合わない、と言う場合、変数名に誤りがあったり、テーブルの間違った列名を指定してる場合は結構あります。
タイポグリセミア現象って聞いたことあるでしょうか？
次の文章を見てみてください。
これは、弊社ホーペムージの冒頭に記載されている文章です。
どこか、おかしとなころにお気づきでしょうか？
本物は、以下の通りです。
よく見ると、いくつかの単語で、最初と最後の文字以外の順番が入れ替わっているところがありすまよね。
こうのよに、文章の中の単語に誤りがあっても、気づかずに文章として正しく読めてしまう現象をタイポグリセミア現象と言います。
変数のタイポが見つけらなれいのも、この現象に起因するところです。
このような基本的なミスを起こなさいために、例えばVBAであればExplicit記述を使い変数の宣言を必須化するとか、エディタのコード・アシスト機能を使って変数名を自動補完することで大分ミスを減らすこがとできます。
最初の「急がば回れ」の例にも通じるものがあります。
もうすでにお気づきの方もいらっしゃるかもしれませんが、今お読みいたいだているこの章にも、いくつか、文字をひっくり返している箇所があります。
よく見ると間違っているのに、全体としては何となく正しく思えてしまうことがあるんだ、ということを意識してみると、なぜうまく行かないか分からない！と言う時の原因の発見に役立つと思いますよ。
基本に忠実に
最後に、私が一番大切だと思うことをお伝えして締めたいと思います。
それは、「基本に忠実に」ということ。
特に、システム設計の前半であるコンセプト設計やアーキテクチャ策定のフェーズで、難解な業務仕様の実装検討や、システム的に高度な処理の実装を考えるときに、難しく考えすぎてついつい無駄に複雑なアーキテクチャにしてしまいがちです。かくいう私も何度も失敗したことがあります。
しかし、どんなに複雑と思える事象も、分解してしまえばシンプルなロジックの積み重ねで成り立っています。
そのひとつひとつのロジックを紐解き、着実に実装して行くことで全体を完成させることができるものです。
先にご紹介した３つの内容も「高いスキルを身につけましょう」ということではなく、「まずは基本的なことをしっかりと押さえましょうね」という内容になっています。
これまで何度も名のある技術者や、難しいプロジェクトを渡り歩いている百戦錬磨のアーキテクトの方たちの仕事ぶりを見せていただくことがありましたが、共通することは「物事をシンプルに捉え、地味とも思える作業を面倒くさがらずに着実にこなしている」という点でした。
基礎研修受講中の若手の方だけでなく、長年経験を積み多くのスキルを身に着けてきた中堅～ベテランの皆さんこそ、その技に頼るばかりだけでなく、基本に忠実にいることを忘れないでいたいですね。
私も改めて襟を正し、基本に忠実に精進して行きたいと思います！
三ッ輪ホールディングス株式会社 BTI部 部長 タケヒロ
2002年からSIerにて官公庁や大手銀行、海外系電子決済等、主に大規模系B2Bサービス開発に従事。その後、コンサルティングファームを経て2020年に三ッ輪産業株式会社に入社。現在は、三ッ輪グループ全体のデジタル化や業務効率化、社外向け新規サービスの企画・構築を担当。
得意領域（≒趣味）はスクラッチ開発だが、最近は釣りの分野にも活動領域を広げ、仕掛けづくりの研究開発や新たな釣りものの調査にも日夜努力を重ねている。
この記事が気に入ったらサポートをしてみませんか？