GoTheDistance

ユーザ系SIerから全く別業種の会社で「ひとり情シス」として内製してる変わったエンジニアのブログです

BPStudy#92で「エンジニアの経営学」の話をします

おはDで有名なビープラウド佐藤治夫 (@haru860) | Twitter様よりご依頼を頂きまして、お話をさせて頂きます。BPStudy91,BPStudy92と連投でございます。

bpstudy.connpass.com

注意事項

  • イケてるWebサービスのビジネスモデルみたいな話は一切しません。
  • 自社サービスを成長させる為にみたいな話は一切しません。
  • エンジニアは経営者になれ(ドヤァ みたいな話は一切しません。
  • 会計(簿記の基礎や決算書の読み方的な)話も一切しません。
  • 社内政治や人間関係がどうこうみたいな話も一切しません。
  • 僕のマイブームはWelcome | Flask (A Python Microframework)ですが、flaskの話も一切しません。
  • テンション上がると野球の話に切り替わる恐れがあります。

お話したいこと

皆さんに「会社を見る目」を養って欲しいと思っていますので、その為の視座やヒントをご提供したいと思っています。

残念なことに、僕を含めて多くの方は何らかのお仕事をして対価を得て社会生活を営んでいかねばなりません。つまり、何かしらの貢献をして「会社に自分の居場所をつくる」ことが求められます。その場所にいる理由がないなら、お互い不幸です。

この視点がすっぽり抜けてしまうと、色々不幸なことがあります。スキルアップ(自分磨き)にご執心な方ほど、会社での居場所を失いがちです。スキルを身につけたら万事OKではありません。Javaが好きでJavaの勉強をしてJavaOSSツール出してる所に入社したら、終始PHPのレガシーコードをメンテナンスするような話も枚挙に暇がありません。

会社を見る目を身に付ければ、初めて立体的に自分の仕事を見直すことが出来るようになります。そして、不幸なすれ違いが減り、自分がやっていきたいことと会社がお願いしたいことが高密度でリンクするようになると思っています。そうすれば、自社の先も読めるようになりますし、お客様のお困り事も一歩進んだ観点から見えてくるようになるんです。

そーゆー話を中心に、自分の身を守る視点と自分の能力を活かす視点から、「エンジニアは目の前のものさえ作ればよい」という幻想をぶち壊していきたいと考えています。

「べき論」は人を縛るだけで良いことがないから辞めよう

べき論というのは「義務を果たすこと、理想を実現しなければならないこと」などを強く主張することだけど、何も生産的な要素がないなぁとつくづく感じました。

べき論で自分の考えが無駄に縛られて精神的な自由さが奪われてしまう。べき論はしないことも同時に規定するので、自ら望んで板挟みになるようなもんだ。「すべき」と「しないべき」の板挟みの果てにできるのは「かくあらねばならない」という強烈な固定観念。強烈なリーダーシップを発揮することもあるが、思考の引き出しが1つしかないので、切羽詰まると正論(**であるべきだ)としか言えなくなってしまう。

べき論は終わりがない。言われたら言われるほど、自分に課されている義務や理想が膨らんで負担が大きくなってしまう。本当はミニトマトぐらいの大きさでしかないのにね。そして、その精神的負担は常に付きまとう。終わりが無いから。何を言ってもべき論で返されたら、これほどめんどくさいものもない。すべきと言っているのは自分がそうして欲しいから言っていることが多い。他人が共感できない自分だけの正しさというのは、非常にヒステリックに映る。

べき論では地に足の着いた議論にならない。置かれている立場が考慮されないので、「もう大丈夫」とも言えないし「こうしよう」とも言えない。よくわからないゴールだけが語られ、話の腰を強烈に折ってしまう。「できてたらやってんだよ」「それがダメだってわかってるよ」という憂鬱な気持ちが出てしまう。色々と「○○すべき」って言われたのに全然出来なくて結果が出なくて自分は...って自分を追い詰めてしまう。心の新陳代謝が出来なくなる。最もアカンやつ。あなたに否があるわけじゃないのに。

べき論では捨てていいものが捨てられなくなる。べき論は万能すぎて、森羅万象に対して○○すべきと言えてしまう。勉強はすべきだし、結婚はすべきだし、風邪は引くべきではないし、ミスはすべきではないし、太るべきではないし、仕事は頑張るべきだし。捨てていいものはいくらでもあるはずなのに、べき論が作り出すステレオタイプな理想に潰されてしまう。

僕は中小にいるので会社全体が見えるから特に感じますが、「こうすべき」「やめるべき」では間違いを正そうとしなくなります。べきだったよね〜よね〜ですよね〜で風化して同じ問題が再燃する。責任の追求をしなくても良いから丸く収まるけど、トップのミスとして認めればすぐに改善できるのに。やっちゃダメなことを決めて、やらないことを決めて、やれることにフォーカスする。そうしないと、異なる立場の人間をまとめて組織力をUPすることが出来ない。

人生は「やる」「やらん」「好き」「嫌い」の4つだけで充分です。今日も一日、適当にやってればよろしいと思います。

スクー(schoo)でエンジニアの経営学という講義をさせて頂きます。

スクー様からご依頼を頂きまして、先日の下記エントリで作成した資料について、講義をさせて戴くことになりました。


エンジニアのための経営学という資料を公開しました - GoTheDistance

エンジニアの経営学

4/15 19:00〜22:00で、3回に分けてお話をさせて頂きます。

あの資料は読み物として仕上げたため、講義となるとかなり行間が空いておりました。それを埋めるためにステップ by ステップでじっくりと話ができたらいいなと思っています。

生放送です。リーチ一発生放送でございます。

どうぞよろしくお願い致します。

【書評】はじめよう!要件定義 -ビギナーからベテランまで

著者の羽生章洋さんより献本御礼。

はじめよう!  要件定義 ~ビギナーからベテランまで

はじめよう! 要件定義 ~ビギナーからベテランまで

本書の特徴を一言で言うなら、「これ以上に必要なことはないが、足りていないことは何もない」という絶妙なバランス感です。サラッと読める分量にしているのに、各章を良く読み込んでいくと気付かされることが多く、豊かな行間があります。

要件定義というテーマはとても扱いが難しくバランスをとるのが難しいのに、本書は170p弱でまとめあげている。しかも、イラストも結構多い。この分量で大丈夫なのかと勝手に思ったが、最後のほうではDB設計の話も出てくる。データ設計も要件定義の範囲として捉えているのも、実装を重んじる羽生さんらしいアプローチだし、そこまで考えないと要件として不十分だよねっていう。

以下、僕自身の要件定義のアプローチと照らしあわせてながら、重要だと感じたポイントを書いていきます。

要望と要求と要件を分けて考える

11pに書いてあるのですが、皆さんこれちゃんと意識されてます? これすげー重要な絵ですからね。羽生さんのOK出たので、キャプチャ画像貼ります。

f:id:gothedistance:20150312100309j:plain

まとめると、こんな感じになります。

要望 システムによって叶えたい思い・未来像
要求 要望を叶えるために必要な能力や成果物
要件 要求を満たすために必要な条件

要件定義が出来ているというのは、この「要望⇔要求⇔要件」が分割統治されていることが大切です。つまり、要件に落としこむまでに然るべき理由がそこに存在しているか、その要件でなければならない理由は語られているか、そういうことをチェックするには分割統治するしかないからです。やりたいことと、やらねばならない理由と、要求を満たすためにやらなあかんことが分けて考えられていないと、要求自体の間違いに気が付かないことになります。

最悪なのは、間違った要望に対する正しい要件や仕様です。間違った前提ほど怖いものはありません。

全てのステークホルダーを明確に

要件定義はそのシステムに関わる「全ての」ステークホルダーの要求を可能な限り実現する必要がありますが、その全体像をこうまとめると簡単だよって絵がありました。これはわかりやすい。

f:id:gothedistance:20150312100340j:plain

システムを中心とし、ステークホルダーでレベル1を作り、その要望をレベル2として書いているマインドマップ、と言いますか。要求一覧表なんかよりもわかりやすい。そのシステムを使うことで別のステークホルダーの負担が増えたり、何かが犠牲になったりするということが、要件定義の過程で結構あります。大抵それが地雷になりますので、早めに地雷を摘むためにも全てのステークホルダーの要求をキチンと整理しましょう。

システム化対象業務の設計ポイント

全体図だけでは設計に移れませんので、ドリルダウンして実際の作業とシステムの関係を明確にしていく必要があります。羽生さんは「行動シナリオ」の作成を薦めています。業務フローとの厳密な違いは正直良くわからなかったのですが、僕の理解では下記の情報が整理された実際のお仕事の流れをまとめたものです。

  • その仕事を行う人(役割)
  • その仕事の判断・完了基準
  • その仕事の受け渡し先

特に自分の仕事が終わった!と判断できる基準が最も大切。知りたいのは行動を決めるための判断基準。その基準を満たせない場合は例外処理やバリデーション対象になる。要件定義の時点でそこまで見ていく必要があります。また、下記の2つも考慮ポイントです。

  • 差し戻される場合はどういう時か
  • やり直したい・中止したい場合はどうしているのか

この2つも重要なので考慮して下さい。前者は例外処理やバリデーション、後者はCRUDが発生した場合に仕様として足りていないものがないかを確認できます。バリデーションが通っても次の作業に渡せないってこと、あり得ますからね。キャンセル発生とか。受注取って在庫引き当てたけど訂正入ったんで引当を戻して再度引くとか。

この設計したシナリオを元にユースケースが生まれて要件が見え、要件を満たすための仕様を考えるフェーズに移っていく、と。

システム仕様検討はUIファーストで

僕もこのアプローチに大賛成。まずはUIをスケッチしないと。UIが先、データが次。そのUIからこのデータになるには何の処理が必要だっけってのが、プログラム。それは最後。

UIを作りながら作業に必要なデータを洗い出して構成をまとめ、仕事に必要な情報を定義してまとめていきます。一語多義にご注意を。最終的に、必要なのはレイアウトとアクションと生み出されるデータ。これが定義されていないとシステムの機能が正しいかどうか、ユーザーが判断できない。

レイアウト UI部品。タブ、コンボボックス、テキストボックス、ボタン、表など。
アクション クリック、スワイプ、キーダウンetcのUIのイベント。
データ その画面で最終的に作られる or 表示されるデータ。

どの作業中に何をして欲しいかを明確にして、ユーザーが何を判断してどんな仕事を完了したいかを詰めていくのが良いと思います。これがこう出来ていればあなたのお仕事は完了できますよね〜っていうアプローチ。

UI設計は入力系の画面から。まずは何を入れるかを先に決めないと。マスタメンテじゃなくて、行動シナリオの中で受け渡して流れていく情報を作って保存するための画面のUI設計からはじめて下さい。いきなり帳票設計とかやめてくださいね。インプットが決まらないのに検索項目の話とかしないでね。

UIを決める→データを決める→そのデータを作り出すためのプロセスを決める、という流れで僕はいつも考えています。

要件定義は困難だけど楽しい

読み進めていく内に、僕自身の要件定義のアプローチを再考したことで、書評の半分が「オレはこうやって要件定義を進めている」話になってしまいました。要件定義は困難な作業だってことを改めて思い知らされましたが、楽しい工程です。

要望から最終的にシステムに落とすためにはこれだけのことを考えないといけないってのを最大限コンパクトにまとめてあり、UIもデータも定義していなければエンジニアに実装の依頼が出せないよねって「しっかりと」書いてあるのが誠実で良いと感じました。

エンジニアの方には「この要件定義は出来損ないだ、何も作れねぇよ」と間違った要件定義をガツン!と是正して欲しい。ユーザーの方には、エンジニアがシステムを作るに何が必要なのかを知って欲しい。共通言語がないと善し悪しが伝わらないので。そのために、本書をあたってもらいたいと思います。

はじめよう!  要件定義 ~ビギナーからベテランまで

はじめよう! 要件定義 ~ビギナーからベテランまで

皆さんのプログラムが最大の効果を発揮するために、良い要件定義が出来ますように。

エンジニアにはお馴染みの「こあくま」のLINEスタンプが発売されました

小悪魔女子大生のサーバエンジニア日記の著者、aicoさんが「こあくま スタンプ」を作られました。こあくまがOK返したり、Forbidden返したり、SSHしたりしてますw かわいいです。


coakuma sticker - LINE Creators' Stickers

スクショ(一部)

f:id:gothedistance:20150310201701p:plain

僕のお気に入りはこれ。カシャカシャターン!のドヤ顔スタンプ! エンジニアでなくてもブロガーさんでも原稿書いたあとにでも使えますよー「進捗どうですか」のリプライにお使い下さい。直リンごめんなさい。

https://sdl-stickershop.line.naver.jp/products/0/0/1//1100300/LINEStorePC/main.png

金額は100円です

買ってあげて下さい。僕には1円にも入らないのでご安心下さい(何を


coakuma sticker - LINE Creators' Stickers