SE歴16ヶ月で培った具体的で多角的な考え方とは
わたしは現在システムエンジニアとしてユーザがいるサービスの開発を行っています。新卒未経験でSE歴16ヶ月のわたしが、開発をするに当たって、特に念入りに！念入りに！意識していることを紹介します。
SEに限らず誰かのお仕事や何かに取り掛かる人の参考になればすっごくうれしいです。
はじめに。多角的に物事を考えましょう
就活する時、仕事をする時、いろんなときに聞いたことがある人は多いのではないでしょうか。多角的に物事を考えるというフレーズ。
これを聞くたびにわたしがよく思ってたのが「多」って具体的になに？？ということ。多角のジャンルや種類はその物事によって異なるし、まず「多」を知らないから、結果として多角的に考えられてないんじゃないか。
こんな風によく思っていたので、お仕事を通して発見した「多 ×７つ」を列挙してみます。わたしがやってきたシステム開発では、これほんとに重要なんですが、実際に現場を見てみるとおざなりにされていることが多い。
（まじで大丈夫か...？って思う）
逆にいうとおざなりにしてもある程度成り立ってしまう、ということ。では、なぜ「おざなり」に対して念入りに意識する姿勢をとっているかというと、それは自分の特性を知っているから。
どんな作業が好きですか？？
わたしは
・散りばめられた情報を集めること
・その情報を元に分析すること
・情報を共有するために文字や画像に落とし込むこと
が得意だし結構すきです。これがわたしの特性。逆に苦手なことは
・壊れたものを直すこと
です。バグ修正なんかそうですね、本当に苦手です。とくに嫌なのが実装当時の考慮漏れが数ヶ月経ってから発覚したパターン。ほんとに嫌です。
なので、そもそも追々壊れそうなものを作らないようにするため、作る前の準備段階にフルコミットしています。こうすることで未来の誰かの時間も奪わずに済みますしね！！
そこで多角的に開発を考慮できるように意識しています。具体的な「多」を軸にしました。全部で7つ。
多角的になるための7つの軸
1.実現手段軸
「〇〇が大変だからシステムで△△△できたらいいなと思うんだよね」
悩みや要望がある人たちがシステム開発を依頼して解消しよう！ということでいろんなご要望をいただきます。ただ、言われた通りに開発するだけでは100点満点とは言えません。この場合だと、ただ△△△するように開発をするのでは根本的な解決にならない可能性があるからです。
そもそもお金がかかる開発をする価値が本当にあるのか。
もっと少ない予算で・別の方法で解決することはできないのか。
これらを念頭に、要望やそれが生まれた原因を細かく聞いて、解消するための最善策を探ることが大事です。
2.時間軸
では、システム開発を着手することになりました！ということで次に意識するのが時間です。過去と未来を考えます。
例えば、
過去・・・過去のデータを参照したときに不整合が起こらないか・10年前のデータと開発後のデータを比べて違和感のある違いがないかを考えます。
未来・・・開発後ユーザの方々に使ってもらうことになったとき、要望が叶えられつつみんなが幸せかどうかを考えます。
誰かに不利益になってしまったら本末転倒ですね、予期せぬタイミングや場所で不利益が生まれたりする場面をみてきたので、気をつけています。
3.運用軸
時間軸の未来と少し被りますが、開発したあとの1ヶ月後・3ヶ月後・1年後、起こりうる出来事を想定しておきます。
というのも、現在OKだったものが1年後には法律改正やルール改定によってNGになった → だから追加開発が必要になるということもありえます。その時に修正がしやすい設計にしておくことも未来のためには必要です。
4.予算軸
ここはわたしが一番すきで超大切にしている費用対効果です。
例えばこんな場面を想像してみてください↓
「この業務に毎月5時間かかって大変だから自動化したいんです！」と言われ、開発に必要な予算を見積もったら3000,000円くらい（高...）かかってしまうということがわかったとき。5時間って時給換算すると7,500円しかかかってないよね。（1,500円/時としたとき）
この開発、しますか？しませんか？考えてみてください！！
でもちょっと待って。このシステムを100人が使っていたとしたら毎月500時間の短縮、時給換算すると750,000円削減できることになる。それプラス、その部署の直近1年の入れ替わりが激しい & 新人さんへの教育コストもかかっているとの情報を知れたとき。
3000,000円の開発をしたあと、半年もあればお釣りが出るんじゃないか？？って思えませんか？
開発をすることで何ヶ月でお釣りが発生するのか（開発に投資した金額をペイできるのか）、その期間は長期的 or 短期的にみた時に妥当な期間であると言えるのかは十分すぎるぐらい検討します。
※番外編
わたしは営業職じゃないので自分の実績を数値化しにくい＝評価されにくい傾向にあります。だから数値化できる部分はなるべく具体的にして評価や実績につなげられるように工夫しています
5.技術軸
技術的に可能なのかどうかは、技術職のわたしが考えるべき内容です。
この開発をすることでどのくらいサーバに負荷がかかって、その結果画面遷移にかかる時間が＋5秒だったら考え直したほうがいいな
この処理の順番の場所を見極めないと他の処理と拮抗しちゃうな、拮抗すると1個のデータしか入らない場所に2個のデータを入れようとするリクエストが発生しかねないな、エラーになるな、となるとAPIが実行されないな、それはまずいな
というような、運用のされ方に配慮しつつ、今後を考慮した開発になるように考えています。技術的な面、ここが一番難しいですね。。
6.現場軸
対ユーザにどんな影響があるのかを考慮します。
Aの開発をしたらBができなくなっちゃった！とかも発生しうるので現場影響は混乱を招かないためにも予測しておくことが重要です。
また、要望を発案した側の方々は「開発によってよくなった未来」だけを考えている傾向があります。「よくなくなっちゃいそうな未来」わたしは異常系と呼んでるんですが、正常でない or 予期しない挙動を想定しておきます。
7.関連軸
開発内容が何とどのくらい関連しているのかを考慮します。
例えばデータの内容を変更するということを行ったとき。
そのデータが別のツールや違う部署の方々が使用しているかもしれません。そのデータを使ってマクロに入れて活用してたのに開発後にマクロが動かなくなっちゃった！ということも過去に起きたことがあります。現場軸と少し被りますが、
・現場で
・今から開発しようとしていることが
・どう活用されてて
・開発しようとしているところとどう関連しているのか
を事前に把握しておきます。これはヒアリングを続けると意外とでてきたりするのでちゃんと聞く。打ち合わせで話を聞いて「お？」と思ったところをリストアップ → あとでテキストでヒアリングの流れで聞いていきます。
テキストにすることでヒアリングや同意を得られた痕跡が残るので後々良くないことが起こったとき、自分自身の責任を分散させるために役立ちます。保険ですね。話すのか文字にするのか両方使うのか、先を見越して動きます。
さらに意識すること〜新卒編〜
これらの軸は先輩から教えてもらったわけではありません。先輩は「見て学べ！」「とりあえずやってみろ！」というスタンスだったので、まずは打ち合わせに同席して先輩方がつっこむ観点・考えていそうなことを観察していました。
そして、この全部の軸に関わる準備をなるべく最短で終わらせること。チャットで送って返信が来たら即レスでさばく。ステップが長いぶん、一歩でも先へ進ませたいので遅延が起きないようにする。相手から返事が来ない...なんてことが起こらないように回答が欲しい期日も一緒に伝える！とかも意識します。
さらに...！大前提だけど、技術職でない方々に対しては相手に言葉を合わせて、わかりやすく伝える。自分がよくわからない現場用語がでてきたとしても、その用語のほうが伝わりやすいなら、意味を理解した上でそっちを使う。
やりとりするときに発生する障壁は低いに越したことはないです◎
とにかく情報収集を。
こんなながーーーい道のりを経て開発を行っていきます。
とにかく変なシステムは作りたくない。考慮漏れだらけ・後々修正が発生しまくるシステムを開発したって誰も幸せにならない。
過去に考慮漏れだらけの開発の修正を担当したことがありましたが会社に行くのが本当に嫌になりました。。。
だから事前に打てる手は全部打つ！！！！っていう勢い。
ここにかける時間は未来の技術職の方や要望を発案した方々の時間を奪わないためにも必要です。これが要件定義ってやつだと思う、そんな風に思えるようになったのは本当に最近でした。
そしてこのながーーーい道のりは汎用性が高いものもあって、他の領域でも役立ったりする。システム開発で培ったこの多角的な考え方を、今度は別の領域で生かしていこうと思ってます。たのしみ☺️