若手のエンジニアチームのゼロからのサービス作成
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、モデリングしていますか?へのお便りその2、です。 前回もお便り回答会というのをやりましたけれども、また別の方からもいただいておりまして、
今回それについて、またちょっと違った観点になって面白いと思うんですけれども、それをお話ししていきます。
エンジニアリングマネージャーの問題集。
はい、では今日もお便り回答会ということでお話ししていきます。
前回もそうだったんですが、こちらもまた、私がしばらく前に開催された PHP カンファレンス福岡というのに参加した時に、
現地で、本当に前回と同じパターンなんですけれども、このポッドキャストを聞いてくださっている方から、こういう質問があるというか、
ぜひポッドキャストで取り上げてほしいということでしたので、取り上げさせていただきます。
ちなみにテーマが、エピソード45のモデリングしていますか?についてということで、ここしばらくモデリングとか設計とか、そういう話が続いているんですけれども、
このポッドキャストってエンジニアリングマネージャー向けということでやってはいるんですが、
なんでしょうね、ピュアに 101 とか、マネージメントにすごくダイレクトに近いお話もしていますけれども、私としてはエンジニアリングマネージャーであれば、
マネージメント、ピープルマネージメントっていうのかな、そちらよりも当然必要なんだけれども、やっぱり軸足として、どっちかが欠けちゃいけないんだというような感じで、
エンジニアリング側についても一定程度、知識を深めておくというか、なんならエンジニアのときよりもより広い視点というか、いろいろな視点でシステムというものに対して語ることができるっていうんですかね。
という意味で、こういう話もしたほうがいいかなと思っているので、割と僕の好みということもあるんですけれども、設計だったりモデリングだったり、そういったところも取り扱っているというところです。
聞いてくださっている方も、今今マネージャーじゃなくて、ICっていうんですかね、普通にエンジニアとしてやられていらっしゃる方も結構いらっしゃるのかなと思ってまして、
普通にそういう方にもそのパートだけ、マネジメント以外の話っていうところで楽しんでいただけたらいいなと思っているところでもあったりします。
今回いただいたそのご質問というかお便りですね、Kさんという方からいただいております。
これ質問を説明すると、そこそこ大きなIT系の会社でいくつかのサービスをやってらっしゃるところに所属されていて、
チームとしてKさん以外にもう少し若手の方というんですかね、もう何名かいらっしゃって、これまでは主に既存の既にある一定程度の運営を続けてきたような大きさはいろいろあるんでしょうけれども、
そういったものに対する回収というか機能追加というか、そういった感じでチームとしてはやってきたんだけれども、この度新たにゼロから新規のサービスを作るということになったそうで、
なんだけれども、このチームの若手のメンバーの方々がゼロからサービスを実装していくというか設計していくというか、そういうところをエンジニアの経験の中でされたことがないということで、
そういった方々に、例えばモデリングというのもゼロからやったことがない方々なんだけれど、そういう方々にどういうふうに、例えばモデリングをインストールしていったらいいのかというか、そもそもどういうふうに新しい物事に取り組ませるのがちょうどいいのかなというような、
モデリングそのものも含むんだけれども、結構大きな難しそうなテーマのお話をいただきました。
こちらもなかなかいろんな観点が含まれていて、私としても非常に面白いトピックだなと思って、これはPHP Conference福岡の非公式二次会のところでそういったお話いただいて、
その場でももちろん結構盛り上がってお話した内容でもあるんですけれども、リクエストということで改めてこのポッドキャストの方で取り上げさせていただきます。
まずこのようなお話いただいて本当にありがとうございます。
とはいえこれ結構答えるの難しいなと思っているんですけれども、なんていうんですかね、そもそもテーマでかいですよね。
この若手のチームにいる若手のメンバーの方々も含めて、会社が新しいビジネスというかサービスというかを始めるということで、
どういう期待値があるのかっていうところが少なくとも僕の目線ではまず最初にすごく気になったところでして、
チームのステークホルダーの期待
サービスによってはもう絶対に失敗できないようなものかもしれませんし、そうじゃなくて結構探索的に新しいところも会社全体としては伸ばして発見して拡大していかなきゃいけないという文脈もあるだろうから、
失敗は一定程度許容されてるんだけれども、やっぱりとはいえ何らかちゃんとリリースして、どういう反応だったのかっていう学びを得るみたいなことがゴールというか求められてるかもしれないし、
はたまたその辺の結果、ビジネス的な結果っていうものも当然考えなきゃいけないんだけれども、会社として探索を増やしていきたいみたいなことを考えたときに、それを数多くできるようなカタカナで言うとケイパビリティっていうんですかね、そういう能力を備えた組織である必要があるっていうところがあって、
そういう人を増やしたいってなると、経験のある人だけでやってくるには限界があるので、若手の方々とかいうところにもどんどんそういった場を与えて、やらせてみてというかチャレンジしてもらって、そこでそういう新しいものをどうそこそこクイックに形にして出して検証していくのか、
そういうちょっと人の方にフォーカスして、その人たちがどういう経験をして何を学んで、それを組織として生かしていけるのかというような、そういう学びというか、人の能力というんですかね、そちらにフォーカスした期待というのもあるかもしれませんよね。
なので、僕的にはまずそこのあたりは、なんていうのかな、ステークホルダーの方と握った方がいいだろうなっていうのは、すごいマネージャー的な視点になっちゃうんですけれども、話の大前提の大前提ぐらいのところで、まず気になったところでした。
そういうのもあるし、新しいシステムを、システムというかサービスを始めていくっていうのって、本当にモデリングが一旦トピックではあるんだけれども、それ以外のあらゆることっていうのが出てくるわけじゃないですか。何かを始めるときって。
まあ何だろう、そのものにもよるんですけれども、スケジュールとか機能はどこまで作るのかだとか、そういうものの中でどういった価値が提供できるのかみたいな、そういう3つのものを比べたときにどういうバランスでやりきるのかっていうところをあれこれ議論して決めて進んでいかなきゃいけないみたいなところもあるので、
モデリングの外側にまずそういう、主者選択というかいうところをチームとして、もしくはステークホルダーと話しながらやっていくっていうようなことも必要だったりしますし、そういったことを決めたとしても、この辺りは一定既存の開発でもあるかもしれませんが、何かやったことないものをゼロから作っていくっていうところで、結構不確実性が高いプロジェクト的なものになると思うんですよね。
それを、おそらくそんなにいつまでかかってもいいから、気長に待ってるよみたいな感じなことってそんなにないと思うので、一定のスケジュール感みたいなのを出しながら見積もって、それに対して進めていくっていうことがあると思うので、見積もりと振興の管理と、そういうレポーティングというか、今どれくらい進んでて、こういうリスクが新たに出てきたとか、
そういうことをちゃんと説明しなきゃいけないと思うんですよね。そういうのを、これは新規の場合には限らないんだけれども、新規の場合にはよりちょっと難易度が高くなるのかなという気もしてるので、その辺をやらなきゃいけないみたいなこともあるし、
さっきの話でも触れたんですけれども、新規のものをやっていくっていう時に、よりステークホルダーが何を求めてるのかっていうところは、ちゃんとコミュニケーションしとかないと、間違ったところに力を入れちゃったりすることもあるのかなと思うので、
その辺もやらなきゃいけないですし、一方でサービスとして出していきますっていう時に、どうなんですかね、既存ユーザーに新たに提供するにしろ、新規のユーザーにアプローチするにせよ、そういったユーザー、どんな方々がいらっしゃって、どんなペインを抱えてるんですかみたいな、そういうリサーチというか、これアンケートだったり、そういうものも含むと思うんですけれども、そういうこともやっていかなきゃいけないし、
そういうのが分かった上で、サービスの形っていうのが見えてきたら、それをどういうふうにユーザーに届けていくのかっていうところでも、ユーザーコミュニケーションみたいなことを考えなきゃいけないですよね。そういうのも必要だし、どうなんですかね、ちょっとものによっては、例えば、
従わなければいけないレギュレーション、法的なところは何なのかとか、そういったところをクリアにしたりだとか、もしくはわかんないです。会社から予算が決められてますみたいな話があって、予算をどううまく何ですかね、マーケに配分するのか、システムの何かに配分するのかとか、その辺を考えなきゃいけないっていうことも出てくるかもしれませんよね。
だったりだとか、作るものによっては、ただサービス作れば終わりじゃなくて、なんやかんや後ろのオペレーションみたいなものがあって、そっちの業務フローっていうかオペレーションはどうなるのみたいなことを、システムの外側で設計して、何ならここは人を動かしていくみたいなことも必要だったりするので、その辺を調整していったりだとか、似てますけれども、サービスとしてリリースすると、
そのユーザーからの問い合わせみたいなのが出てくるので、そこのサポート体制どうするんですかとか、こんな感じで結構いろんなことを考えなきゃいけないので、それを小さなチームで全部やるっていうのは、そこにいる人ってたぶんものすごくいろんな経験値を短期間にギュッと得られるっていうような感じだと思うんですよ。
なので、全然モデリングだけじゃないよなっていうのが僕的にはすごく気になるというか、そういうもんだよねっていうふうにまずイメージしてしまうので、チームがもしかするとそういったサービスを立ち上げるっていう中の開発のとこだけっていうふうにスコープが絞られているのであれば、もうちょっと話はシンプルになるんだけれども、どうなんですかね。
そういう立ち上げっていうのってそんなふうにあまり区切って動くイメージがあまりなかったので、割と小さいチームで全てをやっていくみたいな話なのかなと思って今話してますけれども、とはいえちょっとモデリングじゃないところ結構あるよなというふうに思っています。
なので結構すいません、おそらく聞きたい答えじゃないだろうけれども、何を会社だったり組織だったり事業責任者だったりが期待してこれをやろうとしてるのかっていうところは、もう本当に大前提としてチームが全員が理解しておく必要があることかなと思っているので、
モデリングの重要性と悩み
ここはもうちょっと厚めにお話ししたというところだったりします。
で、とはいえじゃあ一旦何やかんやあるにせよ、そういうチームでモデリングっていうのをちょっとトライさせたいんだという話に絞るとしましょうか。
先ほどいただいた質問のサマリーのところでもお話ししたんだけれども、このチームの若手の方々っていうのは既存のシステムの機能追加だったり回収だったりっていうことをお仕事とされてきたということで、
おそらくその既存のシステムにはモデルというかそういうものはもう結構当然出来上がっていて、モデル以外の開発の作法とかそういうのも出来上がっていて、
基本そういったものを踏襲するというか、今あるものを理解してそれに沿った方向性で新しい機能をつけたりだとか、既存のものを理解して必要な修正というのを施すということをされてきたということなので、
モデルというものの理解とかが全然ないっていうことではないと思うんですよね。モデルっていうのはこういうもんだっていうのは一定知った上でお仕事されてきた方々だと思うんだけれど、とはいえそれはゼロから新しく何かを作るっていうのとはやっぱりかなり違った種類の仕事になるんですよね。
ここがそのKさんの悩みポイントというか、ゼロから作るのってやっぱり全く異質のことで、その最初のゼロから何をきっかけにというか何をフックに物事を決めて作り始めるのか、これはモデルにしよう、ソースコードにしよう、何もないところに最初の何か構造というかね。
何かこう作り始めるっていうことが必要なので。ここはやっぱり確かに経験してない人は全然経験してないかもしれないし、そういう方々がそこそこの規模のものをゼロから作りなさいって言われたときにどうやってスタートしたらいいかっていうのは、なかなか何ていうのかな、何か本読んでできるとかそういうことでもない気がするんですよね。
これ、懇親会のところでKさんとも話してたんですけれども、例えば私とか、Kさんもそういうふうにおっしゃってたんですけれども、結構インターネットみたいなのだったり、そもそもソフトウェアで仕事をしていくみたいなのが一定出来上がりつつある時期にソフトウェアエンジニアになって、
そもそも既存のソフトウェアのシステムっていうのがまだそんなにない時期も、もちろん一定メインフレームのシステムとかそういうのはあったんだけど、まだまだそれは限定的なもので、インターネットみたいなものがようやく出てきたとかなので、そこに今から作っていくっていう時代だったんですよね。
なので、ゼロから作っていくっていう機会が圧倒的に多かった時代だし、それを経験してるっていうところがあって、それはある種のラッキーっていうんですかね。そこを経験できたっていうのはすごく良かったことだと思っています。
今の人たちがそれを経験してないことが不幸なのかというと、必ずしもそうではないというか、逆にいろんなものが整ってきていて、しなくてもいい苦労みたいなところは省かれているっていう意味のラッキーな状態にはなっていると思うけれども、やっぱりでもゼロから作るっていうところの経験っていうのはしづらくなってる可能性は一定あるのかなというのは理解します。
で、その中で、じゃあでもゼロからやっていかなくちゃいけない。このモデリングっていうものをゼロからやっていかなくちゃいけないという話ですよね。でも何ですかね、そのモデリングで何をするのかっていうところも、ここも多少前提とかを揃えてあげた方がいいのかなと思っています。
で、何でしょう、新しくサービスを立ち上げるっていうことは、おそらくこれは完全に推測になるんですけれども、その新規サービスで扱う対象というんですか、ドメインっていうんですかね、そこに対して少なくともその会社では、何かそのドメインの知識っていうんですかね、そこが何かちゃんと育ってはいない。
もしくはゼロっていうような状態からスタートするっていうことだと思います。で、だからわからないことが多いんですよね。なので、なんというか、そのわからないことを何かものを作る前にすべてわかった状態にするっていうことって、おそらく不可能なのかなと思うんですよ。
これはものにもよるんですけれども、やっぱり何ていうのかな、作ってみてやってみて初めてわかってくる物事っていうのが一定程度はあると思うんですよね。
何か開発してる途中だっていうのをするし、実際運用に乗せてみて初めてわかる業務的な事態というかいうことがあるので、モデリングっていうものも何て言うんだろうな、一定程度には事前にやった方が当然いいんだけれど、何かそれが100%何か完璧っていう状態にはならなくて、
一定リリースした後でも、よりわかってきた段階でモデルをアップデートしていくみたいな、何かその辺のモデルっていうものだったり、ソフトウェアっていうものだったりに対する構えというか考え方というか、いうところは前提として持っておいた方がいいのかなというふうに思ったりもします。
あと、そうだな、なかなかモデルの話に入っていかないんですけれども、何でしょう、モデリングっていうのはゼロからやったことがないチームの若手の方々が、何かどういう状態になったらモデリングっていうのをできるようになったと言えるのかっていうところも、もしモデリングをテーマにするのであれば、何かわかっといた方がいいなと思いますよね。
何だろうな、そういうゴールもあまり明らかにせず、とにかくモデリングをやれと言っても、やっぱりできたのかできてないのかっていうのが検証の仕様がないというか、どこに向かっていけばいいんだみたいな話になっちゃうので、一定こういう状態になれてるといいよねというのは、少なくとも任せる側の立場の人は自覚的であったほうがいいのかなと思っています。
ここはもちろん、僕はこう考えるというものでしかお話できないんですけれども、モデリングが身についた状態とは何かって言われたら、僕としてはモデリング技法みたいなものがいろんな種類のものがあるので、当然基本的なところ、100パーものすごい細かいところまで知り尽くしたっていう必要まではないと思うんだけれど、
言って基本的に技法っていうものがどんなものかっていうのは、知ってるっていう状態は必要なんだけど、知ってるだけでは当然ダメで、その技法を使って対象の扱ってる、実際に作りたいシステムに対して、
何て言うんだろうな、このモデリング技法って、これ渡辺さんとか杉本さんがよく使う言葉だと僕は思ってるんだけど、技法の射程っていうものがあるんですよね。どういうものなら捉えられるのか、この技法はっていうようなものを射程とよくおっしゃってて、射程っていうのは何だろう、ピストルとかで何メートル届くっていう長さみたいな話ですよね。
それはモデリング技法の場合の技法がどこからどこまでを捉えられるのかっていうのを技法の射程って言って、これは別の言葉で言うと技法の視点みたいなことかもしれません。
その技法がどういう射程、視点を捉えられるのかっていうことと、それを使って一定程度のシステムの詳細なことを描いたり語ったりすることができる、この辺が使えるっていうことに近いんですけれども、
さらにもう一歩進んで、何か描いてる途中に、この技法だとこういう制約があるから、こういう描き方はダメなんだというか、モデルとしてダメなんですみたいな。
そういうフィードバックがかかるっていうのが、結構モデリング技法を身につけたっていうときの一つの指針になるのかなと思っているので、単に絵を描くだけじゃなくて、一定程度のルールみたいなものも理解して使っている状態っていうんですかね。
複数のモデリング技法の活用
相手と話しているときに、いや、ちょっとこのモデリングのルールだとそういうふうには描けないので、きっとこっちの構造になるはずなんですよみたいな。そういう話ができるというのがモデリング技法が身についた状態なのかなと思っています。
あと、当然この辺って、練習しないと身につかないというか、実践地なんですよね。実践地が多いですよね、ソフトウェアの世界って。
これもその人が考えて何か絵を描いて、それをその人自身の言葉でもって説明してみて、その説明が他の人に対して通じなかったり論理がわからんと言われたり、ここは違うと言われたりっていうような外からのフィードバックを受けて、
じゃあこの技法ではこういうふうに直さなきゃいけないなっていうのが自分で回している状態みたいなのが必要かなと思うので、とにかくこの自分でできている状態ですよね。自分で考えて使えているということも大事ですよね。
なので身につくっていうのはそういう状態であるっていうことを、自覚的に明確に理解しとくっていうのが大事だと思っています。
でも、モデリングってなかなか難しいですよね。モデリングとは何ぞやみたいな話でもあって、なかなかそのシステムを作ることと切り離してモデリングだけを
取り上げることって少なくなっているようにも思ったりするんですけれど、やっぱりこれエピソード45のモデリングしていますか?のところでも話したんですけれども、
このモデリングっていうソフトウェアのコードを書くっていうのとはちょっと別の軸のスキルっていうんですかね、技法を持っておくと、
そのシステム対象物をちょっと違う観点だったり違う言葉で表現したり、細かく見ていくということができるので、やっぱり知っておくとすごく便利なんですよね。
なのでそのモデリングって、ある種特定の視点、物の見方ですね。射程という言葉もありますけれど、なんか視点と制約のセットみたいなところがあるじゃないですか。
データモデリングだったら、システムのデータというものに着目して、そのデータっていうのをあるルールに従って整理していく技法ですよね、データモデリングっていうのは。
なんかそんなように視点と制約っていうのがセットになって、それでもってシステムをどう見ていくのかっていう話じゃないですか。
なので、視点と制約、すごく限られた道具っていうのかな、ブロックっていうんですかね。
それでもって対象物を表現するっていうのは、もちろん自由度はないんだけれども、その分、その道具で表現できることだけにすごく意識を集中することができるんですよね。
なので、その側面に関しては結構鋭く対象物を見るということにもつながるのかなと思っています。
なので、不要なものが削ぎ落とされる感じなんですよね。データモデリングならデータのところだけだし、
UMLのクラス図ってのはちょっと幅が広いかなって感じがするんだけど、状態遷移図だったら本当に状態遷移のことだけ考えるとかあるじゃないですか。
そういうふうに結構ポイントが絞られてるモデリング技法っていうのがいくつかあって、
それで物事を見ると、そこに関してはすごくクリアなビューで捉えることができるみたいになったりしますよね。
モデリングの完璧さとリリース後のフィードバック
みたいな感じで、モデリングっていうのを道具として使えますし、もちろんこれって一つのモデリング技法だけでシステムのすべてを捉えられるっていうことでは、
やっぱり必ずしもないわけですよね。多くの場合、データモデリングからスタートする場合が多いのかなと僕は思ってるんですけれど、
データモデリングだけでは、場合によってやっぱり捉えられないものの方が多かったりもするんですよ。
状態遷移の方が大事なシステムっていうのもあるので、そういう場合は当然データモデリングでは捉えきれないので、
システムのあるスコープに関しては、状態遷移みたいなものがメインでたくさん書かれていたりだとか、
あと、これは渡辺幸三さんの3要素分析法だったら、データモデル図以外にも機能モデルと業務モデルっていうのを書きますから、
もう渡辺さん的には、やっぱり3つの視点でもって業務を捉えるっていうのがいいんだっていうふうにおっしゃってますからね。
1つだけでは捉えきれないということでもあるので、そこは複数のモデリング技法というか、
違う観点のモデリング技法でシステムを見るというようなことも交えたほうがいいかなと思うので、
視点と制約がセットになってるものだよというような意識を持って練習してもらえると、
その若手の方々にも効率よく学んでいただけるのかなと思ってます。
あと、繰り返しみたいになっちゃいますけれども、やっぱり自分で考えることが大事だし、
あと考えるだけで終わってたら、当然やっぱりフィードバックが足りないので、
システムのためのモデリングなのであれば、ドミンクロ説教の中に書いてあるプラクティスとも通じますけれども、
やっぱり実装してみて、何なら実装するだけじゃなくって、さらにリリースして動かしてみて、
それでやっと得られるフィードバックだったり、気づきというか、間違いだったりだとか、そういうものが多分にあるわけですよね。
なので、モデリングっていうのもそういうシステムを作り育てていくというか、
そういう活動の中の、やっぱり一つの要素というか、ぐらいでしかないんですよ。
そういうふうにシステム開発、ソフトウェア開発で捉えたときに、リリースした後から出てくる仕様変更っていうのって、
まあね、皆さん結構嫌いだと思うんだけれども、やっぱりそういうものってモデリングに足りてなかった観点を学べるチャンスっていうんですかね。
実際の業務ではそういうことをやってるんだっていうのが、やっぱり最初のモデリングの中では気づけていないみたいな。
かつ実装の中でも当然気づけていないみたいなことがあって、
それはリリースして運用してみてやっと知ることができるみたいなものって結構あるんですよね。
なので、それを何かこう仕様変更みたいに、デッドラインとかあったらやっぱり避けたいはわかるんだけれども、
でも学びなんだみたいな感じでポジティブに受け取るような、
なんかそんなような開発のマインドセットというか、そういうもんなんだというふうに捉えておくといいのかなと思いますし、
それってイコール、本当繰り返しばっかりになっちゃうんですけれども、
モデリングでできるものって常に完璧ではないというか、
100%の状態、もうそこまで作りきったら後は絶対もうそれ以上の変更しなくていいような、
そういった完璧な状態にはやっぱり永遠にならないものだというふうに捉えておくほうがいいかなと思います。
もちろんリリースした後にもう絶対変更ができないような類のシステムであり、
かつその動作がものすごく影響がシビアというか、
多くの人の生活インフラに影響するだとか、人の命に関わるだとか、
本当にそういったシビアなものであれば限りなくリリース前に100%にしておくっていうのは必要ですよね。
そういう種類のものであればそこにコストをかける必要は当然あると思うんですけれども、
多くの昨今のビジネスの現場では、そこまで高い精度で作る前だったりリリースする前に、
モデルというものの、機能的な正しさは保証するけれども、モデルとしての完璧さっていうのは、
それよりも少しぎこちなさが残ってるっていう状態っていうのは普通なのかなというふうに思うんですよね。
モデリングの重要性
なのでそれを動かしながらアップデートしていくっていうのが、何ならあるべきソフトウェア開発の姿なのかなと僕自身は思ってますので、
そういうふうに捉えておくと、モデル一旦ここまでで作れるよねみたいなところまでやったらもう実装してリリースしていくと、
いうような形でチームが捉えるといいのかなというふうにも思ったりしてます。
そうですね、ちょっとそういう心構え的な部分を結構多く話したんですけれども、
具体のモデリングっていったときに、でもゼロから全部自分で考えろってやれなくはないんですけれども、
やっぱりそれって結構物によっては大変というか、どこに行くかわからないって感じにもなってしまって、
責任者側も供養できる範囲にリスクが収まるのかどうかわからなくなってしまうので、
ここは悩みポイントでリスクの大きさにもよるんだけれども、場合によっては大構造っていうんですかね。
詳細の部分はチームに任せるとしても、大きく分けたらこういう要素になるよねぐらいのところは、
任せる側というか経験のある方のほうが行ってガイドしたり出してあげたりすることで、
チームの若手の方々はその引かれた線の中で、じゃあ細かい話どうなんだっていうふうに集中していけるので、
そういった最初の大きな線を引くぐらいは、僕だったらやるかもしれないなという感じですね。
これは作るサービスがどんなものか全然わからずに話してますけれども、どうなんでしょう。
AmazonみたいなECを新しく短期間で作ってねみたいに言われて、そこがもし全然知見がないところでどうしようってなるんだとしたら、
どうでしょうね。例えば、会員制にするのであれば会員管理みたいなものが、会員登録とかその会員に関する
機能群みたいなのが言ってあるので、会員管理っていうエリアがありますよねとか、
あと商品っていうものがあってそれを売るみたいな感じなので、その売るものというかアイテムっていうんですかね、そういうものを管理し、
販売も含めた管理システムっていうんですかね。そこらが言ってあるだろうし、買われたものをどうでしょうね。
さっきの販売管理にかなり密に関わりそうだけど、現実のものとして管理して、それを出荷するようなものだったら、やっぱり出荷は出荷でちょっと分かれそうな
感じがするので、例えばじゃあこの3つのエリアがありますよねみたいに線を引いてあげるとか、
なんかそれぐらいをしてあげると、じゃあ一旦ちょっと出荷は置いといて、会員管理とアイテムのところだけ考えようかというか、
一旦最初アイテムのところだけ作ってみて、後から会員のところを付け足していこうかとかね、なんかそういうことがチームの方で
頭の切り替えみたいなのをしやすくなると思うんですよね。 こういった線を引かなくても、サイズによってはシステムって作れちゃうんですよね。
お便りへの回答
私自身も過去、本当にそんな線引かずにもうARで全部の図を書いて作ってきた経験もあるんですけれども、
なんというかやっぱり大構造みたいなのが見出されていないと、役割の境界っていうんですかね、なんかそういうものが曖昧になって、
この機能ってどの辺に置いとくべきだろうとか、そういうのは毎回なんかちょっと曖昧になっちゃったりだとか、
する傾向があるかなと思うので、ちょっとモデリングの話から若干ずれるんだけれども、やっぱり大構造みたいなのは最初に
引けてた方がシステムとしても、何かこう一定、 完璧ではないんだけれども、何らかのルールに基づいて
整理された状態っていうのができやすくなるかなと思うので、 そういった大構造だけを与えて、その中でじゃあアイテムの販売管理のところのデータモデルはどうなるのかなっていうふうに考えてもらったりだとか、
会員管理のところの、会員もたぶん状態とかありそうだから、ちょっとじゃあ状態遷移考えてみようかとか、フローチャート考えてみようかとか、
そういうふうにやりやすくなると思うんですよね。 なので、何か最初のそういう問題を小さくしてあげるというのか、
いうところだけは一定経験値が必要な感じもするので、 そこだけやってあげて、じゃああとはその範囲の中でちょっと君たちで頑張ってみてねというような感じはどうかなと思ったりもしています。
というわけで、今日はモデリングしていますか?についてのお便りへの回答会ということで、 ケイさんへの回答をお話しいたしました。
本当に皆さんからネタをいただくというか、お便りいただくことって、 こういったポッドキャストで話している身としてはものすごくありがたいことだと感じてまして、
それによって私自身も新たな側面というか、 いただいた状況でどう考えるのかということを考えるきっかけにもなったりするので、
本当にありがたいと思いますし、皆さんからいろんなこういったお便りというか、 質問というかテーマをいただけると本当に助かるなと思っております。
さて、この番組では感想や質問、お悩み相談をお待ちしております。
エンジニアリングの現場で遭遇するあらゆるトピックについて、番組詳細欄にあるお便りフォームよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。 EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのポッドキャストではレビューもできますので、 こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイル、COO兼CTOの後藤秀典でした。
