エンジニアなんだから、この世界にまだないものを作って、この世界をちょっとよくするついでに稼ごうよーーー。汚いですけど、それでいくことに腹を決めました。いうわけで、2/1始動(の予定)です。部屋決めも早めにやりたいと思います。興味がある住民希望者はHPを見た上でぜひTwitterDMを。part2前回の続きから...4.言われたことを実装したらバグが生まれたこれこそ、害獣が駆逐したい対象のNo1💫に輝く素晴らしい人材。我々、エンジニアが心掛けなくてはいけないことは、常に自分が作るシステムにポリシーを持つことだと考える。出来るエンジニアと出来ないエンジニアを見極めるときによく質問することは、システムのポリシーについてだ。私は、PHP出来ます!Ruby出来ます。害獣にはどうでもいい。『現場の意見を取り入れたら、間違っていた!』とか顧客のせいにしているのを見ると、バカにしたくなる。システムのポリシーから外れたものを実装している時点でシステムとして既に破綻しており使えないものを生み出しているという認識を持ってほしい。システムのポリシーとは何か具体例を挙げるとしたら・一元入力(一度入力したら、再度同じ情報を入力させない)・確定後の数字は、変更されないなどである。請求書を出力するシステムにおいて【既に確定された数字を変更したい】という要望があったとする。何も考えず、その数字をアップデートする機能を実装したとして簡単に金額などを変動させ、不正を助長する機能を入れても良いのかということを検討・精査せずにただ機能が作れるからといって実装してしまう側に問題がある。【誰が】【何のために】【どのように】変更を行ったのかなどの情報を持たす必要があることは明確になるのだ。死んでいるも同義でただ言われた機能だけを作りバグを生み出し使えないシステムを生み出す奴隷。エンジニアは、サービス業ではなく職人であるべきだ。5.システムの項目を辞書化するシステム設計で、一番難しいのはDBの設計だと思っている。そこで、DBの設計や仕様を整理するのに使える資料の作り方の例を挙げる。辞書化を行うことをオススメする。【辞書化】このシステムにおいてどのような項目が存在するかということを整理し管理することを指す。Excelが一番扱いやすかった為、Excelで辞書化を行った例が下記の図である。【何の項目】が【どの画面】で利用されているのか一目で分かるので10万円の案件だろうと1億の案件だろうと必ずやっておくことをオススメする。管理したい項目をひたすらA列の2行目以降に記載していく次に、画面名(または機能)を1行目のB列以降に記載していく各列に表示(入力または出力)する内容に〇を付けていく後は、どの画面でINPUTされるかOUTPUTされるのかをこの資料に追記したりみんな大好き正規化を行えば、良いのである。数値に【意味】を持たせてしまっている設計が多いのではないだろうか。他システムと連携を行った際にお互いのシステム仕様書を突き合わせて整合性を合わせる作業になった際は、とんでもなくコストがかかる。(コンバージョン作業等)コード(id等)を持たせてしまうことで如何にシステムを動かしづらくなるか分かるので、フラグやステータスをなるべく減らす努力はするべきだ。本来、システムというのは時系列ごとにデータが作られていくので~フラグではなく、日付で管理されるのが正解であると考えている。フラグをどうしても持たないといけないときなどは、~フラグテーブルなど、1つのテーブルにまとめシステムを制御する仕組みにすればスッキリし作成者も管理する箇所が減りバグが減るのである。システムは、シンプルが一番難しく一番素晴らしいものだ。子となるデータを作成し紐づけるがidだけで紐づける設計以外も考えてみようというお話である。伝票を作るシステムがあったとする。通常は、1・2・3の順番を絶対に踏まないといけないことになる。...なんて構造が多いけれども、それを常識としないで欲しい。顧客から『他システムに格納されている伝票の情報を本システムに登録したい』という要望が出た場合、とてつもない労力になるのだ。伝票テーブルの構造が、~マスタのidや~サブマスタのidやらが必要だった場合それらを置き換えるプログラムの作成やら検証やらを行う必要が出てくる。伝票データの構造がidで紐づけるのではなく【名前】などの名称で紐づける仕組みになっていれば、コンバージョン作業など一瞬で終わるのではなかろうか。名称をキーとしている為、どちらからでもデータの取り込みが可能である。前から入れようが問題なく動作する仕組みを考えてみるのも大事な観点である。8.色んなところに意識が行き届いているか自分が作ったものに、意識がきちんと行き届いているかを確認をしましょう。目的を伝えたり、システムを作る上では重要になる。今回、例として挙げるときには統一出来なかったが青色は時系列を示す。選択ボックスは~色にするなど統一されていれば、ユーザーもシステムを理解するのに楽になります。たかが、色と思うかもしれませんが色に意味を持たせるなどの工夫はあるべきだと思う。9.最後に最後に、自分が作ったシステムに愛を注ぎましょう。害獣はシステムを作っている。システムは成長をするものであり、それらを直していくうちに自分自身も成長していくものだと考える。読んでもらいたいと思い今一度、自分は何をしたいのか?ということを振り返っていただけたら、この記事を書いた意味があるかと思う。part1害獣がトキワの森の記事をハックしたぞぉーーー!害獣についての解説は省く。これから記載していく内容には、人によって異なる見解があったりするので違うぞ!😠という考えを持っている人こそアウトプットをしていって欲しい。世の中に多く出回っているけれども顧客との関わり方やシステム設計の思想についての記事が思ったより少なかったので1匹の害獣の経験を元に、この記事を書いていく。1.システムは5W1Hで考えるまず初めに、システムの基本は5W1Hで考えるべきである。『今更なんじゃ、分かっているわ!』という方こそ原点に振り返って欲しい。全てこの言葉に通じるので、これ以降の内容についてもこの言葉を念頭に置いて読んで欲しい。何かしらの到達点となる目的がある訳で伝票を出力するという目的の為に、様々な情報を入力するのである。我々は最終目標である伝票という出力物の情報を整理しアウトプット→インプットを考えなくてはいけない。【データ構造】と【画面】を同一視してしまっている方が増えている。確認画面が作れる仕組みが拡充した為インプット→アウトプットの考え方でDBを設計し仕様バグを生み続けるエンジニアが増えてきているように思える。『顧客から機能はまだ確定していないのにシステムを作れと言われて出来る訳が無い!!』と嘆いてるエンジニアは、正解であるがもう一歩先に行く必要があると思う。顧客と一緒にシステムを思案していくことを大事にした方が良いと思う。職業や立場・環境を非難する内容ではないことを明示しておく。質問をしてこない出来ないと言えないこの2点である。これについては、実際に『出来ない』と言ったら評価が落ちてしまう環境が多いので、そうなってしまうのは仕方がないと思っている。報連相が出来ないのは論外である。『出来ない』と言うことを恥とし、出来たら報告し褒められようとする糞みたいなプライドが、チームだったり顧客だったりに迷惑をかけてしまっていることを再認識するべきである。顧客が納品を押し付けてくる敵として見ている時点で良い仕事や良い関係性が出来る訳が無い。下手に業界用語を用い、出来る風とかそんなくだらない事はどうでも良く顧客目線でシステムを作ることが大事なのである。『~機能について、マニュアルに書いたのに読んでないのが悪い!』とか言っている愚か者は断罪じゃ!読んでも理解出来なかった物を作ってしまったと反省するべき。顧客と同じ目線でシステムを語るとき文章で書いても共通認識と異なってしまう場合がある。そこで、フィッシュボーン(特性要因図)を参考に業務フローを描いて話すとお互い話が通じ合うぞ!(※気づいたけど学生の検索とか漏れまくりの図)書き方としては、1本でっかい線を引いて一番右には、ゴールとなる事柄を書き左から右へと時系列順に流れるように【機能】を書いていく。・このシステムの目的は何なのか・このシステムの登場人物は誰なのか・このシステムはどのタイミングで動くのかなどが一目で分かることになる。【機能の漏れ】を事前に防ぐことが出来る。これにより、お互いが納得し同じ方向を見て仕事がしやすくなるのだ。いつも要件定義の際には、ホワイトボードやメモ帳にこれを書いてお互いの認識をすり合わせているが機能の漏らしや、お互いの認識に齟齬が発生しにくくなった。best6!みなさんこんにちは。この記事はQiitaアドベントカレンダーの記事です。Qiitaプロフィールなどはこちらをどうぞ。言いたいところですが、雑然としているので整理するとこんな感じ。SIer9年目だよ上流から下流工程まで、アプリから運用まで色々やってるよ。社外でアクティブに活動しはじめたのは2018年5月頃からだよ。twitter.com職種的にはプログラマーではないので、どちらかというとビジネスより。この記事もプログラミングに要素は一切ありません!安心してお読みください。トキワの森プロジェクトとぼく自身の関係について、簡単にふれておきましょう。2018年5月頃にシマリスさんがITエンジニアで漫画家のトキワ荘みたいなシェアハウスをやろうとTweetしはじめる。シェアハウスに興味あるITエンジニアが集まり始める。ついでに運営にもJoin。企画・運営に色々と関わる。トキワの森公式Twitterの中の人、もくもく会の主催など。初台ハウスの入居可能時期が2ヶ月ずれたため、諸事情により入居は断念(運営には参加)。こんな感じになります。実は初期の頃のメンバーってあんまり現在アクティブじゃなかったりするので、長くを知っているという意味では希少かもしれません。Start!今回はトキワの森プロジェクト初のアドベントカレンダーです。ノリではじまってノリで書いてみようかって感じでJoinしたので、あまりテーマドリブンではなかったのです。ここ数年を振り返って「やって/やらなくて失敗したこと」をまとめていき、クリスマスの七面鳥の代わりにでもなればいいかと思います。はじめていきます!1.トレーニングしないぼく自身、2年前から筋トレをはじめたのですが、それ以前はまったく何もしていませんでした。当時は「筋トレなんかしなくても生きていける」と思っていたんです。これって実際にやってみないとわからないことでした。さんのようなことを言い始めるようになりました。筋トレエンジニアとか最近増加してる感じですが、まだまだマイノリティだと思います。人と差をつけるなら今!また、他業界(特に商社)はITの太めorガリガリとは逆で、ほとんどガタイのいい方ばかりです。ITエンジニアも追随して筋トレしはじめたら今までの5倍コードが書けることでしょう!ちなみにデメリットは昔の服が入らなくなることです。入らなくなった服はメルカリで売るしかありません。2.英語や語学に興味を持たない会社に入った後、5年くらいはずっと英語に興味がありませんでした。最近でこそTOEICがメジャーになり学生でも受験者がマジョリティな世間。一昔前は(というか自分の界隈だけ?)あまりそんな風潮もなく、興味もなかったのです。いえ現在はすでにグローバル化が激しく、ちょっと良くない言い方ですが日本人が下に見ていたアジア圏の方々は既にマルチリンガル。話しているのを都内だと良くみかけませんか?日本語のみで生きていける世界は、今後とても閉鎖的になってしまう気がしますよね。間違いなく今後マストスキルだと思います。勉強するデメリットは無しだと思います。言えば学習時間がかかることですが、費用対効果を考えると大体の場合がプラスになると思います。ぼくもTOEICスコア800超えまでアップしましたが、やっぱり最低でも数十時間は必要でした。3.イベントには参加だけするこの辺は結構多くITエンジニアのTwitter界隈では流行っているので、簡潔にしておきましょう。トキワの森エンジニアのブログ)を開催してみて意識が変わりました。Organizerとして関わることで、学びも大きいですし、なにより自分自身がどこまでパワーを発揮できるかを実感します。先日実施したものは少人数の単なるもくもく会ではあったのですが、やる前はすごく高かったハードルが、音を立ててガラガラと崩れ去った感じがあります。人を集めて何かする場を作るということは、会社員でもフリーランスでも生きていく上で必要なスキルなのは間違いないでしょう。4.趣味がIT関係しかないこれって結構あるあるだと思うのですが、ぼく自身も一時期プログラミングにハマった時に、一般人に趣味を聞かれて「ええっと・・・」となったことがあります。あ、ここでいう一般人はTwitterとかの外の世界の人のことです。プログラミングとかサービス開発に集中するのはいいのですが、その前にまずは人間であることを忘れてしまうと良くないと思いました。QOLを高めるためにも、仕事のためにも、リベラルアーツ的な知識や、仕事にまったく関係ない趣味を持っていた方が人間として魅力的です。著名なトップマネージャーなどもそうですね。そんな理由からやってるわけでは無いのですが、ぼくの場合は気になったら写真をとって、少し加工してはInstagramへアップしています。www.instagram.com世の中には絵が描けるとか、DIYができるとか、きき酒ができるとかのエッジが効いた趣味を持っている人がいます。そこまでじゃなくても良くて、キャンドル作りでもダーツでもカフェ巡りでも良いので何かあると厚みがでるはずです。(自分にも言い聞かせています。)5.本を読まない結構最近はインターネットだけで十分に無料で情報が集まることが多いですよね。ぼく自身も読書量が1年に数冊なんて年がざらにあったのですが、読んでない時は別に何も感じないものでした。読むようになって思ったのが、やっぱり情報が整理されていて信頼度も高い場合が多いなということです。参考文献がしっかりしていたり、推敲されている場合もある。中には変な本や偏った情報もありますが、有料な分、コンテンツが良いことが多いです。一方でインターネットはスピード感があるところがメリットだと思います。使い分ければいいと思うのですが、目的に応じて書籍も読むようにすると良いかもしれません。技術書だけじゃなくて、コミュニケーション、組織マネジメント、ビジネス書やMBA的な本も面白いのでオススメです。6.同じ人とだけ会う実はTwitterを2018年5月に始めるまでの間、知り合い以外の人とは年に数名も会っていませんでした。その後、Twitterを始めてから現在までで、Twitter、それ以外合わせてだいたい100名の方と新しく出会いました。「出会う」って結構難しくて勉強会で見かけたのはカウントしちゃダメだと思います。一言二言会話するのも微妙ですね、できれば次会った時に、軽く声がかけられるくらい会話できればいいと思います。去年までは結構おっくうな性格で、あまり知らない人と繋がることをしていなかったのですが、実際に出会いが加速するとインプットもアウトプットも加速していいことが多かったです。ヤフーロッジとかGridを知るインフラ勉強会を知るそこでLTするオフラインでもLTするトキワの森プロジェクトにJoinするもくもく会を開催する異なる業種・職種・会社の人と会話して視野が広がるデメリットは、合う人だけじゃなくて合わない人も出てくることが多いので、センシティブだとリスクも念頭に置いておく必要ありですね。(ぼくはあまり気にしないのですが。All!ここまでお読みいただきありがとうございました!さて、これを読んだあなたにもお願いがあります。ぼくと同じように「やって/やらなくて失敗したこと」をどんどんシェアして欲しいのです。成功ではなくて失敗なのか?例えば旅行のときに、「このコースを回ると全部の世界遺産を回れますよ」という話よりも、「このスポットは昼過ぎに行ったら激混みで失敗する!」のほうがためになりませんか?うまくやりたいという気持ちは、成功よりも失敗したくない方が強いのかもしれません。えー、なんだか自己啓発本みたいになってしまいましたが、気になることがあればライトに聞いてみてください。一言でもいいので感想をタイムラインにフィードバックしてもらえるとうれしいです!twitter.comそれでは!よい2019年にしましょう!最後に宣伝です。best6!Tweet広告を非表示にするもっと読むコメントを書く2018-11-18ゆるふわもくもく会でした|トキワの森シェアハウスお久しぶりです。