GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

当事者意識を持てという言葉の向こう側

エモい資料が上がっていた。こういうのは大好きだ。一筆くれてやるしか無い。

speakerdeck.com

この資料のあるページに引用された岩田さんの以下の内容が、Xで色々出回っていた。

誰かのお役にたったり、
誰かがよろこんでくれたり、
お客さんがうれしいと思ったり、
それはなんでもいいんですが、
当事者になれるチャンスがあるのに
それを見過ごして
「手を出せば状況がよくできるし、
 なにかを足してあげられるけど、
 たいへんになるからやめておこう」
と当事者にならないままでいるのは
わたしは嫌いというか、
そうしないで生きてきたんです。
https://www.1101.com/president/iwata-index.html

知っててやらないのは、知らないよりタチが悪いかナ

知っててやらないは、知らないより悪い。当事者意識を最も単純に表現しているのはこの一文でしょう。私はそのように教わった。

手が出ないままだと塩漬けすることになる。改修が出来ないので、濃淡はあるにせよ組織のケイパビリティは下がるから、働きにくくなる。それが度を超えると人災を生み出す。もっとひどくなると、負の連鎖が巻き起こり大きな経営上の判断ミスが生まれて、倒産に向かうような気がする。誰が悪いんだろう。

何打でホールアウトできるかわからないゴルフ

ほとんどの組織運営上の問題は、放置しても倒産に直結するようなものではない。この問題を放置したらサービスが売れない・モノが売れないことに直結すれば対策が自明になるから、問題にならない。

対策が自明じゃないから問題になるように思う。例えると、何打でホールアウトできるかわからないゴルフ。「最終的に、どこまで」を手を出せば良くなるか、わかんない。未来から逆算して考えられるわけなくて、ピンが何ヤード先にあるかわかんねーけど、方向はあっちだからティーショットを打つ。そんな感覚。ゴルフは結局一人でやるしか無いので、それも似てる。キャディはドライバーに変わることはないから。

「手を出せば状況がよくできるし、なにかを足してあげられるけど、たいへんになるからやめておこう」という状況は、そういうものに見える。

やらないと出来ないことを、取り入れよう

当事者として逃げられぬ局面、多かれ少なかれあると思います。

そんな時に支えになるかもしれない、湾岸ミッドナイトの一コマをご紹介します。超一流のチューナーである、山本和彦の言葉。

これはいつもオレ自身に言い聞かせていることなんだが、
やらなければできないが大事なんだ。
でも人は知恵がつくと、「できるからやる」になるらしい。
それは結局、「できないことはやらない」だ。
それではその先の走りは引き出せない。
湾岸MIDNIGHT 第37巻

コンフォートゾーンなんて言葉使わなくても、これだけで表現されている。とてもいい言葉。やらなければできないことを行ってリスキリングしないと先細りするという示唆。

本を読んでも、できるようにならない。漢字は書き取らないと書けないのと一緒。それ以上でも以下でもないので、書き取れるものからトレースして、自分のやり方をどこかでつかめば。躊躇しないで。その結果としてハードワークになっちゃうかもしれないけど、甘受するしか無いかなーと思う。心理的安全性という言葉がコンフォートゾーンの免罪符になっているケースもある気がして、逆だろ逆って思う。そこから抜け出す為のものでしょう。

誰かと協調してやらないといけない、方針を決めないといけない。いきなりドンと渡されてもまず失敗する。だから、自分で片がつく範囲で、やらなければできないことをやる。そうすれば自分で見つけた何かが残る。見つけるに至った過程が、明文化は難しい経験値として。

自分で片がつく範囲で、やらなければできないことを片付けていくと、だんだんそれらがつながって、ゴルフじゃないけどコースの攻略法を自分の手数からはじき出せるようになる気がする。でかいIssueをひとりで倒せってではなく、でかいってわかってるなら細かくしろだし、細かくできるなら座組を組むために相談できる人を探せになる。そうやってアクションが取れる単位までに分解していけば良い。でも、やらなければできないアクションを取ったことがないと、それもできない。

組織のケイパビリティを左右する経験

この種の経験、フリーランスだと積みにくい。立場上与えられないと言うか。フリーランスを揶揄して「ワーカーとしての経験しかない」っていう話の向こう側は、組織のケイパビリティを左右するような意思決定を下してリードしたことがないのに、どうやって組織の中でバリューを出すのかという問いだと思ってます。そこにはステークホルダーという地雷原を歩いてどう捌くか、そういう明文化しにくい過程も入っている。私は初手がエンプラだったので、その種の議論をする同僚・先輩・上司・外注先がたくさんいあった。ペーペーから役員層まで全員と何かしら関わって仕事ができた。その時のコミュニケーションの節々が活きている。

社員と外注ではタッチできる情報や会議体に差がある。発注して頂いている組織の抱えている課題を共有できるような環境に、なかなかフリーランスの立場だとタッチさせてもらえない。求められていないことも多い。

そうはいっても、社員100%で構成されている現場って、絶滅しているような。人材斡旋ビジネスが盛んなITでは特に。社員が採れないし、採っても辞める。外注は契約がある限り辞めないので、調達して品質が良ければ困らないけど、プロパーがマネジメントして云々という話も。それでプロパーがやりがいを無くして辞めちゃう気もするけど。

組織のケイパビリティを左右する意思決定は、様々な所属先を含めたチームでやる時代になったと思う。最も必要なのはファシリテーター(旗振り役)かな。「手を出せば状況がよくできるし、なにかを足してあげられるけど、たいへんになるからやめておこう」とワルツを踊るための議論をファシリテートしたい。それが40代のワイの個人的テーマ。

問題意識を共有する会ってイベントを、何回かやった。そろそろ再開しないとな。

note.com

息を吐くようにブログを書いていたあの頃

インターネット老人会 Advent Calendar 2023」12日目の記事です。

adventar.org

インターネットとの出会いは iBook G3と共に

自分のPCデビューは、1999年。当時仲の良かった友人で唯一ネットについて色々教えてくれたY山が、「だれもマカーがいねぇ」と呪詛を唱えるもんだから、何も考えずにMacを買った。これだ・・・懐かしい・・・!

https://auctions.c.yimg.jp/images.auctions.yahoo.co.jp/image/dr000/auc0401/users/03435bbf8509ecd760721e18ad125366f5650be7/i-img1200x798-1674494399rrjmrh484507.jpg

最初のプロバイダーに選んだのは、AOLでした。マカーの友人が入ってた過疎ってる英会話サークルに自分も顔を出していて、プロバイダーを聞いたら「AOLがいいぞ、チャットで外人とお話できて面白いぞ」と聞いた。やってみた。タイピングが遅すぎて、helloしか打てんことに嫌気が差した。brbだけは覚えた。実際問題、何を聞いて良いかもわからんしうまいこと話せねぇわ!たまに夢に出てくる。

次の思い出は「ご近所さんをさがせ!」というサービスに登録して、麻雀友達が当時できたこと。自分は当時20歳そこそこだったけど、30歳近いT桑さん。ギターと麻雀というキーワードがあって、家がアホほど近かった。卒業しちゃったら全然会わなくなってしまった。

www.gokinjo.net

自分の時代は、ちょうど東京めたりっくがADSLをやり始めた頃。「ブロードバンド」という言葉が踊るミレニアム世代で、ろじぱら侍魂を初めとしたテキストサイトを巡回しつつ、最強のアングラリンクみたいなサイトをめぐりながら、エロと職人FLASHまとめサイトばっかり見てた気がする。健全な男子学生である。

社会人になってブログを書くようになった

自分にとってのインターネットの99%はブログなので、ブログの話をしたいと思います〜。

2005年だと思う。当時はライブドアがGoGoしてた時で、ブログと言えばライブドアだった。何人かの同期でブログを立ち上げて、書き始めた。自分が文章を書くのが好きだって自覚はなかったんだけど、1ヶ月経っても何かしら書いてるのが自分だけだったので、書くことが得意なんだなと知った。2005年は間違いない。当時の僕はデスマ案件で400時間働いていて、日々の残業時間を日記に書いていた。(゜∀。)ワヒャヒャヒャヒャヒャヒャ みたいな絵文字使っていた。

ライブドアのブログは当時の会社にバレちゃったので、消した。「渋谷で働く社長のブログ」のタイトルをオマージュしたのが運の尽き、案件のちょっとした愚痴と地名で身元が割れたという。特に減俸もなかったです。コンプライアンス〜。秒速でアメブロに移り、きっかけは忘れたけど、はてなに移動した。

これがはじまり。

なんだこの xusersってやつは

だらだら備忘録を書いていて、1年ぐらい経ったある日。ブログのパーマリンクの右側に、赤い文字で xxusersって出た。これが、はてなブックマークとの出会い。この記事だったと思う。

gothedistance.hatenadiary.jp

インターネット老人の皆さんはNiftyServe等でネットコミュニケーションをされていたと思いますが、自分にとってのネットコミュニケーションのデビュー戦はホッテントリに入ったブコメの数々であった。

興奮が最初に来たけど、次に来るのは「どうしたらいいんだこれ」でした。

「あ、はい、そうっすね、でも、そこで話の腰折られても。そんな事言うて無いと思うんやけど、どう伝わったんだこれ」みたいな、どうにも処理できない気持ちは出ます。20代で若かったので。AさんがBさんに告白して付き合えたやったね!という話に、フラれたCさんの気持ちにもなってくださいみたいなこと言われると、萎えちゃう。どこ見てんだお前はって。1:Nのコミュニケーションで反論できる場がないし、反論記事をあげようもんなら「うぷぷぷ、こいつなんなんw」みたいな反応をされてしまう。

ヨッピーさんとは比較にならないけど、自分がいない所でぐだぐだうるせーなー!とは思ってました。ちょっとだけよ。

yoppymodel.hatenablog.com

当時の僕の心の支えは、まなめはうすでしたね。まなめはうす。まなめはうすは推し度に対して★の大きさが違ったんだけど、なにかの記事ですげーでかい★がついたんよ。まなめがいい感じに言及してくれてたんで、読み取ってくれる人もおる〜ってなったんよね。そこから、段々と自分の書いた記事が読みたいっていう人がいるんだなって思えてきて、楽しくなってきた。

ブロガーとして最も気が合うなと感じてるのは、id:takerunba っすね。波長が合う。意見は違っても。字面の向こう側が飛び込んでくる感じ。たけちゃんならこのネタの意味を汲み取ってくれるよな〜という安心感があった。当時、よく引用させてもらった。押上のレバ刺しの店、最高だったな。もう食えないけどさ。

2007〜2008年の頃に出会った人たちは今でもずっとなにかしらつながっていて、交流させてもらっていて、自分の財産になっている。そうなったのは、自分がブログで本音を書いてきたからだと思う。

インターネットで本音を言う若さ

本音が書いてある文章は読み手に届く。言葉じゃなくて、想いが届く。自分はそう思ってる。人の本音ってすごい力があると思う。インターネットで発信すると、特に感じる。読んでて面白いなーって思う文章は、どこかしら本音が見え隠れしてるもん。コンビニ店長(G.A.W)さんとか、理知と本音のバランスが最高だった。また文章書いてほしいなー、インターネットで。

自分はインターネットで本音を書いた文章を公開して、後悔もしましたが、概ね良好です。はてなのおかげです!僕のインターネットの恩人は、Googleはてなです。

1979年生まれなので、44歳になった。信じられん。28歳のブログ反射神経はもう無い。というか、あの頃一緒にブログ書いていた人たち、みんな書かなくなったな。体力がないだけなのか、反発しても消化できる大人になったのか、未成年の主張よろしくエモさが最前列に来なくなったのか。それはわかんね。

今年の6月に、すごく好きだった上岡龍太郎さんが鬼籍に入られた。重厚さと軽快さを併せ持ったトークと、プライベートで会うと面倒くさ・・そうじゃないやんほんま人懐っこいおっさんでしょーっていう感じの愛嬌があって、すごく好き。

来年はそろそろ、上岡龍太郎モードでブログを書き始めますわ。本音をインターネットで言ってこそ、パイセンの冠つけられるってもんよ

フロントエンドの開発スタイルの変遷とFlutterというお話をさせて頂きました

毎度おなじみBPStudy。治夫さん、ありがとうございました!

bpstudy.connpass.com

108枚のスライドはこっちです。50分で話すボリュームではないですね... 煩悩が多くて、申し訳ありません。

speakerdeck.com

GUI→テキスト→全部コードへの流れ

前半部分は、僕なりのGUI実装考古学みたいな感じの話です。Webブラウザが業務システムで使われる前はWindowsしかない時代で、Windowsデスクトップアプリケーションが作られていました。その時使われていたのが Windows Formで、GUIでテキストボックスとかボタン等をペタペタとドラッグして貼り付けるというスタイルです。このスタイルは一見簡単そうに見えますが、ロジックの再利用性は低く、テキストじゃないのでデザインの再利用性も低いです。IDEのプロパティウインドウでスタイルとイベントハンドラの有無を見るみたいな世界なので、今だと考えられないっすよね。

iOSも、UIKitの時代はGUIベースでした。Interface Builderにパーツを貼り付けて、IBOutletで紐付けてロジックを書くのは同じです。UIKit用語が多くて癖があるのでぱっと見て何のコードか分かる人は少ないと思います。昔はStoryboardもなかったので画面遷移は全部コードで表現したので、画面遷移の全体像を追うことが難しかった。Storyboardで少しは良くなかったと思いますけど、もう戻りたくはないです!ごめんな!

GUIだと再利用性が低く、画面の動的な動きもUIでは一切表現できない。可読性が高いようで低いので、この縛りプレイの中で秩序あるフロントエンドのコードを書くのは相当な習熟が必要だと思います。

テキストでUIを書き、ViewModelとバインドする

GUIはさすがにない!ということで、WindowsForm→WPFに進化したのが最初だと思います。WPFになると、XAMLというXML拡張セットでビューを書くことができます。TextBox Value="{BInding UserName,UpdateSourceTrigger=PropertyChanged"} HorizontalAlignment="center" みたいな感じのXMLがズラズラ続きます。XAMLそのものはよくできていて、Androidxmlファイルのスキーマよりずっと直感的でした。AndroidXMLスキーマ中途半端。

XAMLで定義したビュー情報に差し込むデータとロジックはどーするのって話ですが、ここでViewModelが登場します。TextBoxに差し込む値や、TextBoxのChangeイベントを受け付けるためのモデルクラスが登場して、ビューと紐付けます。WPFではこれらの仕組みを「データバインディング」と表現しています。テキストボックスの値が変わると、ViewModelのプロパティのSetterが自動的に呼び出されます。そのためのお作法がちょっと複雑なんだけどね。

ViewModelと特定のビューのイベントハンドラが紐付いてしまうと密結合になって再利用性がないので、UIが特定のイベントを実行したい場合には「Command」というインターフェイスを1枚挟みます。Commandを挟むことで、Commandを実装するViewModelのインスタンスが隠蔽されますので、ViewとViewModelが差し替え可能になります。GUI開発では、イベントは同じだけどコールバックだけ差し替えたいケースがメニーメニーなので、Commandインターフェイスで1枚挟む設計はワンダホーです。

UIがテキストで表現できたのはいいんですけど、今度はデータバインディングに必要な規約が重く感じます。素のWPFでMVVMやると即カオスになりますので、Prism/LivetのようなMVVMフレームワークも学ぶ必要があると思います。簡単なことをやってるのに結構なコードを書かねばならないので、重苦しい感じを受けるかもしれません。Webだと、サーバーサイドのテンプレートエンジンで吐き出したHTMLをjQueryでDOM操作して状態管理するみたいなコードを書いてしまうとカオスになって辛い、という経験をされている方は多いと思います。

やった!全部コードでかけるぞ!

React, SwiftUI, Jetpack Compose, Flutter。コードでUIを表現できコンパイルできるようになりました。Flutterで言うと、TextFieldというクラスのキーワード引数に、フォントの太さや下線などのデザインの設定、changeイベントなどのイベントハンドラ、入力チェック等のバリデーションロジックを全部書くことができます。見通しメッチャ良くなるのと、ロジックが書けるのでコンポーネントとして切り出して再利用することが容易です。表現力の高さは正義なのである。

これらのフレームワークに共通している、宣言的UIという考え方があります。 UI = f(state) という公式があって、UIは、その画面が持っている状態(state)によってその都度ビルドされ、ビルドされたUIを可変にしないということ。つまり、textBox.text = "aaa" みたいなコードは1度書いたら終わり。なので、FlutterのWidgetが持ってる変数は(多分)全部finalです。finalになってるので、stateの変化によって何が変わるのかViewに書かないといけないので、UIで担保する動きが把握しやすく、見通しが良くなります。やっぱこうだよな〜。

UI = f(state) を考えると、キーとなるのは state です。状態をどうやって管理するのかで、アーキテクチャがだいたい決まります。画面ローカルの状態とサービス全体で管理する状態の2つがあると思いますが、それらをいい感じに管理する方法を考えないといけなくて、Flutterも色々な流派が生まれました。2023年1月時点で最も勢いがあるのは、おそらくRiverpodです。Flutter界のロックスター、Remiさんの傑作でございます。

2022年にアーカイブとなりましたが、私がFlutterを始めた時にバイブルとして愛読していたのが、こちらのレポジトリです。Flutterでアプリを作るために必要な考え方や主要なライブラリのサンプルがいっぱいあるので、是非Forkして読むといいです!!!

github.com

自分はUIKit→Flutterにジャンプしたので、宣言的UIと全部コードで書けることの嬉しみ、上記レポジトリで教えてもらったコードの書き方や設計思想の違いにぶったまげてしまい、この2年ぐらいFlutterにハマってしまいました、というわけでございました。

全部コードでUIを書くスタイルは関数に関数を取る関数型プログラミングの書き方に慣れないと何もできないので、苦手意識のある方はそこに慣れることから始めると良いと思います。map/filter/reduce/extendみたいなリスト操作が関数型の書き方をしてます。これに慣れると、ロジックが全て式で表現できるので見通しが良くなります。

後半のFirebaseとか使ったライブラリの実装などは特に捕捉することはないです。Flutter関係ないけど、Cloud Firestoreってホンマに使うのが難しいプロダクトだなと思います。クエリの制約がいつか牙を向いてしまうリスクがずっとあるので。当初は必要ないと思ってたけど、Havingに近いことやらないといけなくなっても、未来のことはわからないもの。RDBのようにクエリの表現力が無限大であればプロダクトの価値にデータストアが後追いできるけど、KVSでは厳しい。Firestoreのデータモデリングは奥が深いです。

GUIってプログラミング教育に良いなと思った

発表内容とは関係ないですが、GUIオブジェクト指向を学ぶのにメッチャ良いと思います。自分が作ってるオブジェクトがUIとして表現できて、結果を目で見ることができる。視覚から入れますから。たい焼きの型がクラスで、たい焼きがインスタンスなのだという寓話より、2つTextFieldがあって、ひとつはフォントサイズが違う、ひとつは文字色が違う、でも元は同じTextFieldで、属性が個別に定義されているだけを例に取るほうがピンと来てくれるんじゃないかと。こういうのを目の前にすれば、オブジェクト指向のイメージが広がると思う。

次はたぶん3月です

RDBのデータモデリングについて、野球を絡めて資料を作って発表する予定です。BPStudyのBPは、BeProudでもあり、BaseBall Playでもあります。野球というドメインRDBに落とし込む、マニアにはたまらない構成にしたいと思いますので、どうぞよろしくお願い致します。

「りあクト! 第3.1版」三部作は間違いなくスゴ本です

Flutterを書き始めると、始祖であるReactの存在が非常に気になりました。というわけで、実践的な入門書と各所で話題になった「りあクト!」3部作を全部買いました。

TypeScriptの入門書及びReactに限らずフロントエンドエンジニアの入門書として、この三部作を超えるのは現状どこにもないでしょう。

oukayuka.booth.pm

普通の技術書で組版した日には、1000pは余裕で超え1500pも見えてくるかというボリュームです。第3部のあとがきで初版と2版時に「もっと丁寧に説明してほしい」という声が多かったので、紙に製本する事情を取っ払って本気出したよ?みたいなことが書かれていますが、ここで本気を出すのがどれだけ大変か。。。数年前にPythonの入門書を書いた私は理解できるつもりです。まーよくここまで歴史的背景を調べて書いてくれたものだと思います。

大いに助けられました点について、まとめました。ご査収ください。

Reactを読み解く基礎体力がついた

三部作の第1部は「言語」に関することがメインです。ES2015以降のJavaScript及びTypeScriptの言語仕様の解説です。

非常にクリアになったのが「文」と「式」の違い。関数型の書き方なんとなく気分ええわぐらいでしたけど、値を返す式の組み合わせが左から右へ評価され最終的な値へ到達する形が「シンプル」やな〜と感じさせてくれました。宣言的な関数定義は正義だ。

あやふやだったTypeScriptの型の理解もグンと促進されました。第4章の「TypeScriptで型をご安全に」で基礎体力が上がったと思います。

変数・関数・オブジェクトに任意の型を設定でき、型の演算・共用・交差・条件・推論・型ガードなど、型をHackして安全性を高めるTypeScriptの基本を学べました。

コードリーディングの補足説明が丁寧で、引っかかりがちなポイントを教えてくれる。<T, A extends any[], E extends Error> 的な宣言を見ると「ちょっとまって・・・」ってなりがちだったので、大変助かりました。

この本で書かれている(事実上と言っていいのかな)Reactのコードの大半は、関数型のコード with TypeSafeなので、その基礎体力が無いとReact辛いになると思う。でも、それが見えてきたので、ググってでてきたReactのコードの大半はスラスラ読めるようになったので、嬉しみ〜!

JSXは慣れの問題

気持ち悪いのはJSXのせいじゃなくてHTMLのせいだと思うのよね。Webブラウザがクライアントである以上、HTMLから逃げられないじゃん。JSXのほうがアウトプットイメージが湧きやすいのは僕だけですかね。

FlutterだとHTMLに当たる構文がないので大変気分が良いし、items.map((e) => ListTile(child: Text(e.name)) っていう書き方でUI書けて気分が良い。Vueだと難しいみたいだけど、Reactだとできる。コードでUIを表現できる気持ちよさを感じたので、本でも書かれているけど、JSファーストでやりきるReactのあり方は好き。

「Container Component」と「Presentational Component」

分割単位の指針として、「Container Component」と「Presentational Component」という考え方を明文化してくれたのは、自分にとって大きかった。

FlutterのWidgetの設計は基本これですよね。この指針は重要で「ロジックを除外した静的に動作するUIを作り、必要な状態を定義してType化して、外から与えられるようにする」に留意すれば、まぁひどいコンポーネントにはならないはず。外の定義が、Hooks/Propsの違いはあるけれど。

自分はFlutterから入ったので、この本で書かれている「Mixins」「Higher Order Components」「Render Props」に共通している「ロジックを追加がするとWidgetツリーが汚染され、追加するロジックの分だけ階層が深くなる」歴史的辛みを知らなかった。Hooks によって始めてReactはコンポーネントシステムの外に状態やロジックを持つ手段を手に入れたとしたら、それは辛いわ。Hooks後にReactやれてよかったよw

Reactはコンポーネント、Flutterはウィジェットだけど、UIをコードに落とす設計思想は大変参考になるので、Flutter力もこの本を熟読すると間違いなく上がる。フォルダ分けでガタガタ言ってるぐらいならこの本読んだほうがいい。

Redux + Effect Hook

React自体は関数型でUIを表現するシンプルなものだとしてもちゃんとした Web アプリを作るためにReduxや非同期処理ミドルウェアの組み合わせが前提になったのは辛いね〜。本にもあるけど「牛刀をもって鶏を割く」ってやつは、技術者が嫌いなアプローチだろう。State Hook+useEffectで各コンポーネントは書けるから、コンポーネント間で取得したデータを共有したいときは Redux を併用するのは凄くシンプルに見えた。

Recoil 気になります

本にも紹介があったけど、Recoilというフレームワークを使ってみたいな〜。

FlutterのRiverpodとコンセプトが同じに見える。state hookを各自グローバルに定義できるし、familyで引数取れるのも同じ。Suspenseを使って宣言的な非同期UIコンポーネント(RiverpodだとAsyncValueが近い)が作れるのも良さそう。Selectorのオプションの豊富さは、RiverpodのProviderの使い分けになんか似てる。

フロントエンド力をつけるなら「りあクト!」で決まり

Reactを読み解く為の基礎体力をつけるなら、この3部作しか無いでしょう。基礎体力には、なぜそう書くのか、及び、なんでそういう書き方はあかんのかも同時に知る必要がある。その説明がとんでもないので3版で分量が3倍界王拳した本作ですが、ほんとにここまで書ききって頂いてありがとうございます以外の感想がない。

三部作の学習メモをとるのにNotionを使っていますが、こんな感じです。改行入れて4.3万文字近くありました。入門書でこんだけのメモ取ったことないわ。コスパすごいですよ。5000円だもん全部で。この本の先生役の雪菜さんクラスの単価を考えるとね、すごいことです。

つらくないReact開発ってあるけど、Reactの辛みの9割はモダンJS+TypeScriptの基礎体力のなさだと思います。ReactというSDKの理解はそこまで重くないと言うか。iOS SDKの理解に比べたらだいぶ楽な気がする。

f:id:gothedistance:20220307172715p:plain
りあクト!学習記録

著者の大岡さんに最大級の感謝を込めて、書評書きました。I ♡ React, can't thank you enough!!

oukayuka.booth.pm

Flutterに出会ったことで脳汁プシャーになった話

Flutterに出会ってしまったせいで、Flutterを中心に生きていこうと考えている私のポエムでございます。

エンジニアとしての頭打ち感

2016年に35で独立した時はエンジニアとして頭打ちを感じていて、エンジニアとして独立することはあまり考えていなかった。初心者ではないけど、上級者になれないなと感じていた。

エンジニア一本じゃ難しいと考えた時、その隙間を埋める役割はありかなと思った。業務系のシステム導入なら、コンサル〜要件定義の上流工程をやり、開発系なら開発寄りのディレクター。その時々で研修講師。この辺を組み合わせて、今までやってきた。

コードは細々と書いていた。JavaPython、メンテナンスしてるシステム(WPF)やアプリ(iOS / Android)なり、kintoneでjs書いたりWordPressプラグイン開発みたいなやつをチラホラやってた。小規模な受託なら受けていた。個人開発と大差ない。できることをやる関係上、技術スタック・規模・ビジネス対象が似通ってくるので、頭打ち感は残ったままでした。

Flutter…ほう、そんなものが?!

Flutterを知ったのは、この記事だったと思う。

note.com

2019年10月だから、本番導入した国内事例で、かなり初期ではないでしょうか。もし本当にワンソースで生きていけるなら、こんなに素晴らしいことはない。本番導入した会社があることが強く印象に残った。自分もやってみよ、と。

コロナ禍で2020年の春頃に暇があったので、以前納品した社内向けモバイルアプリをflutterで焼き直すことで、検証してみた。本を1冊買ってあとは公式ドキュメントを写経。

結果は、iOSAndroidを両方作るのに3ヶ月弱(iOS2ヶ月、Android1ヶ月)。Flutterは2週間でした。

iOSに苦戦したのは、Storyboard/AutoLayout/Delegate/ARC等に始まるiOS特有の考え方や仕組みが多く、コードを書くよりiOS SDKの癖を掴むまでに時間を要し、最初はやっつけで、書き慣れた所でやっつけを書き直すなどをしたため。 ViewControllerはクセがすごい。iOSに比べるとAndroidはシンプルに感じた。Windowsのデスクトップアプリを作ってるのと大きな差異を感じなかった。画面数は12。

検証を終えて「はい、Flutterはレベチ。やっていき」に変わり、今年の2月に商品カタログ+注文アプリをリリースした。

Flutterの開発体験がレベチだった

3ヶ月と2週間の速度差が生まれる背景は「Flutterの開発体験の完成度」によるものだと思う。

  • ワンソースでマルチプラットフォームに対応できること
  • 提供されるWidgetが豊富にあること
  • DartコードのみでUIレイアウト・スタイルが完結し、可読性が高いこと
  • レイアウトが組みやすく、宣言的UI採用により再利用性が高いこと
  • Hot Reload によって修正点がすぐに確認できること
  • 状態管理の優れたライブラリがあること
  • Dart言語に癖がないこと

Flutterの優れた点は「プラットフォームのSDKの持つだるい部分に触れることなく、アプリケーションのコードに専念できる」に集約できる。

iOS(UIKit)を槍玉に上げてしまうけど、IB+Storyboard+Xibで画面開発をするのに比べると「あれ、こんな簡単に作れてええんか?何か間違ってないか?」と、拍子抜けするぐらいスムースに実装することができた。

AndroidiOSは、原則として手続き型でViewを更新する(ライブラリやSwiftUIなどがあるにせよ)。Viewを構成するパーツはミュータブルで、スタイルや表示内容をプロパティやメソッドを経由して変える方式。

Flutterは宣言的UIを採用しており、Viewはコンストラクタで初期化するのみ。イミュータブルになる。TextWidget(iOSにおけるUILabel)に対してsetTextとかやって、テキストの表示内容を変えることはできない。その代わり、Stateという状態そのものを管理する機構があり、Stateを操作するとViewの更新が走り、Viewが再構築され最新化される。

宣言的UIを採用すると、ViewとStateが分離できる。それが意味することは、状態管理の仕組みによってプロジェクトのアーキテクチャが規定されるってこと。

Flutterは状態管理のライブラリが色々あり、2021年も終わりになってこれでよくねっていうライブラリに落ち着いた感がある。個人的にはRiverpodが好き。色んなデータ保持の仕組みがあり、任意のタイミングでUIが更新でき、Viewの持つライフサイクルに当て込んでUIを更新しなくて良い。人類に必要なものだ。

ワンソースになれば利用するライブラリの数も少なくできる。内部的にはCocoaPodsやGradleで各プラットフォームのライブラリを取得しているけど、そこまでお世話して頂けることにジャンピング土下座。

あと、Dart言語が読みやすい。正確には癖がない。スッと頭に入る。運営元のGoogleも本腰入れて普及活動しているので、プロジェクトが途中で終わる可能性が極めて低そうなのもプラス材料。GoogleWa..いや何でもありません。

Flutterはモバイルアプリを書くのに最もモダンでかつ必要最低限のコードで実装できるフレームワークだと感じ、Flutterが切り開く未来を見てみたいというお気持ちが、すごく強くなった。

サービスデザインやりたいなぁ

Flutterに出会うまでは、データモデリングが好きだと思っていた。他人の書いたER図を見るのが大好き。みなさんが関わるビジネスはER図に全部出てくるし、その人が何を思ってこの設計にしたのか、感想戦をするのも好き。

細かい案件をこなすため、データモデリングができればローコードで秒殺狙いでkintoneやFileMakerに中途半端に手を出した時期もあった。ツールとしてはありだが、パートナーじゃないという結論になった。

Flutterでアプリ開発をやってみると、自分はデータモデリングよりもフロントエンド(もう少し大きく言うとサービスデザイン)が脳汁が出ることを実感した。サービスブループリント的なのを思い描きつつ、ここでこんな人がこんな判断でこんなムーブを決めると意味があるから、それに即したアクションってなにがあってどれがベストかな?を考えて進めていくのは、とてもよい。

プログラミングをそれなりにやっていて、久し振りにフレッシュな感動と共に「これ、面白いな〜!!」と思えたのが、Flutterでした!

Flutterを軸に会社を拡大する…かも

Flutterがマッチする案件や、Flutterでリプレイスする案件は絶対増えます。Flutterで作ったら戻れない。Googleちゃぶ台返して終了するのが最大のリスクではあるが、飲み込む価値がある。オンプレをクラウドに切り替えたら戻れないと同じで、ネィティブアプリ開発で解決しているペインがピンズド。

自分が「これ、面白いやん!」って思うことをやっていきたいし、その面白さを自分以外の人たちと共有して、なおかつ仕事になるなら、すげーいいな。今までひとり法人でぷらぷらしてたけど、Flutterを軸に会社を拡大しようかと思い始めてる。また、それに対応すべく、Flutter BootCamp的なメニューを作り始めてる。UI開発をやったことがある方なら、2週間でそれなりのものが作れる所を目指してる。

旧知の仲のYOUたちには、主にFBメッセンジャーでポツポツご連絡をさせて頂いており、Flutterに興味がある人いたらつないで!と自重せずお願いしています。

このエントリをここまで読んでくれて、私と面識がなくてFlutterにご関心がある方、最近流行りのカジュアル面談でもしましょう。面識ある人は飯でも行こう。1年弱やってますので、多少はお話できると思います。

2022年はFlutterを軸に生きていくことになります。

まふゆのだいぼうけん、はじまりだ!

カジュアル面談とTwitter

twitter.com

meety.net

炎上プロジェクトでスキルを会得する前にお前は死ぬ

経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します)

炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。

僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上プロジェクトの類に入るだろう。24〜5ぐらいの時。10時〜24時が平日で、休日も同じぐらい潰すと、それぐらいになる。良かった点は1つだけあって、自分の限界がわかったこと。2日てっぺんまでやれば終わる的なKKDに正確性が出ました。自分で仕事を組み立てないと炎上プロジェクトで生きてこれないし、多少の無茶振りでは動じなくなりました。当たり前だよね、限界まで働いているんだから。いい話でもないわ。

炎上プロジェクトをおすすめしてる理由が「すげー働けるからスキルつくし、やり遂げたときの達成感やばい」なんですけど、その前にお前が死ぬ。

炎上プロジェクトは終わらない夏休みの宿題だよ

働ける環境が劣悪だと、やり遂げるもクソもないんだ。やり遂げるっていうより、終わらない夏休みの宿題をずっとやってる感じ。8月31日がループされる感じ。自分のやったことが無駄になるのが一回ならいいけど、2度3度続くと平静を保つのが難しくなる。仕様が変わる or 追加されるのが炎上プロジェクトの常だからね。日々生み出されるうんこを掃除しても、またうん(ry

炎上プロジェクトでは誰もお前を助けない

経験の浅い人間が炎上案件に入っても、何も出来ないの。炎上してる時は各々が自分のタスクが溢れてしまう状態なので、経験の浅い人の教育に裂くコストなんて取れない。だから、誰もキミを助けることはしない。しないっていうか、出来ないよね。自分が泳ぐのが精一杯だから。そういう状況下で、経験の浅い人間がやれることは、手戻りが起きないように縮こまって目の前のことだけやるしかなくなるよ。何を改善できるの?

炎上プロジェクトで身につくのは力技だけ

問われるのは質ではなく、動くこと。あーこれバカロジックだなーって変更入ったら書き直しかもなーっていう予感があっても、とにかく書くの。書いて動かしてテスト回して先に進むことしか求められない。リファクタリングに時間を割く時間はない。もっと良い設計や書き方を感じる時間があったかもしれないけど、それをこの炎上案件に適用する時間は、無いんだ。動いているものを書き直す機会は与えられないし、動いているものが変わっちゃう可能性も高いから。

それに、経験が浅いってことは、誰かが考えた仕様を実装するタスクが多くなると思う。この種の仕事をやりきっても、ほとんど成長しない。実体験だよ。要望をまとめて自分で仕様を考えて実装してバグ出して直すから知見が得られるのであって、与えられた仕様をなぞって書いても漢字の書き取りと変わらない。文章を書かないとね、表現ができない。少なくとも、エンジニアはコードで表現できないと先に進めない。

悪い状況を悪いやり方でやっつけることを学んでも、あなたの開発者としての引き出しが増えるわけじゃないんだ。プロに揉まれるってのは幻想だと思っていいよ。失敗したプロジェクトで自分が沢山手を動かすことで成長できる、なんて言われるかもしれない。稼働すればするほど成長できる理論、バカとしか言いようがない。

終わってるところに入っても、何も残らないよ。炎上プロジェクトは、トライアンドエラー(PDCA)をする場じゃないから。DoDoDoDoDoDoCheckDoDoDoDoDoみたいな感じ。こういう状況だと、やっつけ仕事にならざるを得ない。振り返っている時間がないんだから。

橋が対岸にかかっていて、みんなが渡り始めていると、後ろから火の手が上がる状況なんだって。振り返る余裕ある? 対岸に進むのが先だよね? 対岸に着いたらなにか残るかな〜 橋は燃えているんだけどね〜。 ま、そういう話。

プロジェクトに入って、概ね計画通りに進めて成果物の整合性取って意見調整して進める一連の過程が「成功」するからノウハウがたまり資産が増える。その積み重ねで視座が変わるわけ。視座が変われば発想が変わる。発想が変わらないとレベルアップにならない。成功体験が重要じゃん。火消し体験って成功体験かって言われると、クエスチョンだ。スキルアップって耳障りの良い言葉に囚われちゃダメ。目指すのはレベルアップだよ。

もしかしたら、あの案件きつかったけどやりきったよな俺たち良かったよな〜なんて新橋で戦友と飲めるなんて美談を想像しているかもしれない。バカだな〜。うまく行ってなくて、ずっとうんこ片付けた話で酒がうまいとでも思います? あの案件すげーうんこ降ってきたよな〜 楽しかったな〜って?

炎上プロジェクトにいるだけで落ち着かない

SESで下請けとして入る場合、炎上しようがあなたたちに非は無い。SESだから稼働すれば良く、プロジェクトが成功しようが失敗しようが、お金がもらえるならどうでもいい。でも、プロジェクトがうまく行ってないことはわかるじゃん、普通は。最低でも肌感で。進んでないんだから。糠に釘を打ち続けていると、真綿で首を絞められるような居心地の悪さがすごいんだ。

こういう立場のときにやれることは、自分の被害を最小化しつつ、焦げ臭いと感じてもやぶ蛇にならないよう、決められた稼働時間で指示通りに働いて作業報告書を出すだけ。オレがそう立ち回ってこいってブチョーに言われたからね。ハハハ。もし、あなたが当時の私と同じで炎上プロジェクトの下でSESで入ったとしたら、やることは「このプロジェクト自体が燃えています、こんな兆候があります。我々を早く引き上げて下さい。」と上に伝えること。これで私はちょっと早く生還できた。運もあったけど。

炎上プロジェクトで生き抜ぬいても、貧乏くじが待っている

上の立場からすると、心を病まれちゃ困るじゃん。キツめの案件で。そういうとこだけはディフェンシブなんだよね、他はガバガバなのに。乗り越えちゃうと、多少きつくてもあいつならってなりがちなのよね。よくやりきった!次はもっと良い条件で新しい技術のあるこれだ!なんて話につながらず、その後も焦げ臭い案件に入れられやすくなる。バカみたいだよね〜 やりきったら次にやってくるのが貧乏くじ〜。コレで辞める人多かったな〜。

炎上プロジェクトはステップアップの場ではない

ここまで読んでも、僕は炎上プロジェクトという超神水を飲んで40連勤上等で生き残ってパワーアップしてみせると申されるのであれば、どうぞご自由に。

経験がある人は多かれ少なかれ炎上の匂いを知ってるから、立ち回りもある程度できると思うし、身の処し方もわかってる。でも、経験が浅いヤングな人は、単純に知らないからね、流れ弾に打たれて当たっても、それを自己責任にするのはかわいそうだ。だからこの記事を書いている。

少なくとも、オレの周りにいる炎上経験者の生き残りは、誰も炎上プロジェクトで力がついてよかったとは言ってないよ。

オーバーワークからの立ち直りについては、こちらの記事が詳しいので、あわせて読もう。

逃げるは恥だが、役に立つ。

hase0831.hatenablog.jp

kumalife-log.com

2021.08.30 14時43分 追記 いわもと様よりコメントを頂きました

最短で(フリーランスになって)イッセンマンITエンジニアを目指している人たちへのネタメッセージで、社員に向けて言っているなど書いてないので訂正をお願いします。

大変失礼しました。元ツイには対社員とはどこにも書かれていません。企業の代表が率先してオススメしてるぐらいだから、社員にも同様の主張を行っているものだと私が拡大解釈してしまいました。取り消し線を打って、修正しました。

・・・ネタメッセージってなんなのよ??

ネタメッセージという日本語の意味がわからない。ネタってことはギャグや冗談ってことですよね。ホントの話じゃないと。あの、どこがネタなの・・・?

炎上案件がオススメという主張そのもの? 炎上案件はオススメだけど、1千万稼ぐ最短ルートではないという話? 炎上案件はおすすめしないっていうのがマジで、オススメするのはネタなの? 1千万稼ぐには炎上案件に入れという主張がネタだとしても、オチがないやん。これ。オチはどこなの。

あと、タレコミで「炎上結果から得た学びを社員に還元して労働時間減らした」という趣旨の発言もあったそうです。じゃ、炎上案件オススメしたのなんで? なんでなの?

開いた口が塞がらないわ。

ブログで「言うだけ言うわ」という感覚を無くしてた

久しぶりに「わかるううううう」という脳内麻薬が出て、慌ててブログ作成の画面を開いた。

hase0831.hatenablog.jp

特に、ここが響いた。

これはかなりつまらないことで、自分でも「こいつ毎回似たようなこと書いてるな」と思うのはうんざりする。もちろん寄稿など求められて書く文章で似たようなことを書くぶんには違和感はない。でもここのブログはわたしの現住所のようなもので、過去の履歴も見ることができ、何よりそれを1番知っているのは自分なのだ。自分で自分の書くものに飽きている。長く住んだ家のようなもので、あれもこれもわたしが自分で探して選び、置いたものだらけだ。心地よいし安心するが、新鮮な刺激はない。これがわたしが書く頻度を落としてしまった理由なのではないかと思う。

とても良くわかる。同じ感覚持ってて、ブログを書けなかった。

はせさんも書いていたけど「自分の芯の部分って変わらないんだな」っていう気づきがあってから、ブログに書くという熱が冷めていった。「自分の中で煮詰めた考えを文章にする」ことって、書き終わると自分の頭もスッキリするし、自分で読み返すと糧になる部分があった。煮詰まっている過程で得られる何かは、確かにあった。

僕は累計で4万弱のはてなブックマークを頂いており、何十回と1対Nの意見交換をやってきて、みなさんのおかげで自分の考えが煮詰まったので、書くことがなくなったという帰結を迎えた気がしている。

昔はよくSIerとかアジャイルとか内製回帰とか、色々書いていた。多くは「まだ見えていないけど届きそうな理想」みたいなのも感じて書いていたが、それなりにプロジェクトをやってきて、ある程度煮詰まった考え/やり方を確立し、色々話ができる友だちや仕事仲間もできて、着地しちゃった感覚もあった。熱気球が燃料切れて着地するような感じ。

今、個人的に大好きなネタは「DX」だ。これを書かずしてどうするのよって最初は思っていた。自分も色んな会社のDXに貢献するぞという勢いで独立した。DXをやるのは正しい。どんどんやれ。いつやるのじゃねーよ、今だよ。できないのは企画が立てられないからで、企画が立たないの(ry

多少なりともDXコンサルをやっていたら、DXは組織問題が8〜9で、技術が1ぐらいという肌感を得るようになった。特にITがコアじゃない会社にとっては。DXをやるには、自社にとってのDXは何かを定義した上で、事業運営のメスを入れる箇所を決めて、どのような体制を組んでサイクルを回せるのかに注力する以外の道筋が見えなかった。地味すぎる。自分の中である程度煮詰まったので、煮詰まったものを蒸し返して書くことができない(慣れていない)ので、アウトプットできていなかった。

が・・・DXのアプローチを丁寧に展開してくれるすごい人がいた。ガーンと横っ面を叩かれた感じ。まだまだ、自分はしょぼい。

note.com

一緒に仕事できたら楽しそうって正直感じたので、言うだけ言う。

言うだけ言うわ、あとはヨ・ロ・シ・ク

このテンションを忘れていた。

ノリで文章かけなくなるなんて。このブログのアイデンティティが崩壊しているわ。思い返せば、言うだけ言うたけど、YOUたちどう思うって感じでノリで書くことで、それを枕にしていい感じに使ってくれる人がたくさんいるから、こんだけブックマークしてもらえたんだよな。

1ヶ月に1回ぐらいはノリで文章を書こう。

文章を書くのは大好きなんだから。

【書評】「業務システム開発モダナイゼーションガイド」を手に取ろう

非効率な日本のSIと聞いては私も反応してしまうので、読みました。結論から言うと、グレートでした。

本書の主題

「はじめに」で書かれている内容を、私なりに要約します。

日本のエンプラ系SIの商慣習(多重請負構造)における『上流』の仕事のやり方が、ほとんど進化していない。多重請負構造におけるエンドユーザーやIT部門、SI関連会社、SIerが近代化しているソフトウェア開発技術の活用を『妨げる』ようなことをしていては、いつまでたってもその恩恵を「エンジニア」が享受できない。変えるべきは開発の現場だ。

上流工程と下流工程という工程の分断は、そこに属する技術者に対してデメリットが非常に強いのは事実です。自分もSIer時代に、プライムで請けた案件と2次請けのSES案件に入った時では、圧倒的に前者のほうが身になりました。エンドユーザーと同じ目的に向かい、ITプロジェクトを近代化したソフトウェア開発技術や手法で成功させてほしいという筆者の思いが、ビンビンに伝わります。

また、「開発」と名を打ってあるように、要件定義〜テストまで幅広く網羅され、「ここだけは抑えておけ、知っておけ」とポイントをまとめたTipsが列挙されており、新人教育にはこの1冊があれば充分ではないかと思います。Microsoftの方が書いた本なので、大人の事情で要素技術についてはMicrosoftテクノロジーを中心に解説されていますが、この本で学ぶべきでは要素技術ではなく開発手法や考え方なので、問題ありません。

本書に書かれている内容を実践している会社はまだまだ少ないと思いますが、「この開発の進め方はどうなの」と疑問を持った若い方に、是非手にとって欲しい本でした。

人月見積が効率化を阻害するのかも

エンドユーザーに対して人月見積をして売値を決めているので、期間短縮すると売上が落ちます。当社はめっちゃ近代化した開発プロセスになったので、今までより30%速く出来るようになりました。なので、30%引かせて頂きます!とはね、なかなか。効率化を促進すれば生産原価が下がるはずので利幅が大きくなるように思いますが、そういうビジネスモデルをエンプラ系SI関連会社が採用していないのではないでしょうか。

「エンド⇔SIer⇔協力(下請)会社」という商慣習も、極端に言えばエンドユーザーが「この技術を使ってこっちで要件出してプロジェクト管理すれば、SIer挟む必要ないね」となれば良いですが、エンド側にITプロジェクトを運営する体制がない気がします。自分の業務があるので、兼務ですよね。兼務だと手を動かすことが少ないので、ノウハウ残らない印象が強い。我々のようにプロジェクトワークだけに100%のリソースを当てられないので、だったら内製すればってなるんですけどね。

製造原価が人件費である以上、人月をやめるのはかなり難しい。顧客企業の課題を個別のシステムを作って解決するのが受託開発なので、サブスクのように「ちゃりんちゃりん」とお金が降りてくるモデルは極めて難しい。効率化するのであれば「要件からリリースまでの デリバリ・プロセス」しか無いのでしょう。

なので、本書が提起してるように、非効率を解消する鍵は開発プロセスにあるだろうなと感じた次第です。DXを推進するには、この本に書かれているように、要件定義〜リリースまでの一つ一つの工程を見直して、チューンナップすることが「急がば回れ」の解決策かもしれませんね。

日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について

先日、アジャイル開発を推進するために大変有意義な資料が公開されています。ESMの木下さんといえば、アジャイル開発の現場にずっと携わってきた著名な方です。

note.com

でも、令和2年にこちらの記事が何百もはてブされるのも、おいおいマジかよって思う所がありまして。今までどうやってたのだろうか...。準委任(時間単位のチャージ)以外の選択肢がないやり方だと思っていたので。請負でアジャイルを取りに入れるわけないですよね。一般的なSIerさんでは、どういう理解をされて、どう取り組んで来たのだろう。

アジャイルと受託開発の相性は最悪では

ムービング・ターゲットを請負で追いかける自傷行為を誰がやるんだって話と、要件固めて下請けに出せないから誰もやりたがらないよねという話を書き散らしています。

10年前に書いた記事の内容がまだ通用してしまうのも、自分でも少し寂しい気持ちがあります。

gothedistance.hatenadiary.jp

日本のIT業界の未来はSESが切り開くのである

ガイドラインによれば、ビジネスモデルとしてはSESですよね。内訳が個人単位・サービス単位なのかは知りませんが、単価と工数を見積を出して作業委託という体になりますし。レベニューシェア的なモデルは絶対無理だと思います。仮説検証段階で何のレベニューが見込めるのかという単純な話で。DXの実現にアジャイルのプラクティスが必須で、そのための契約スキームは準委任がベストって話を大きく言うと、SESが正義であると聞こえます。

「SESは死ね」派の皆さんはこの動きをどう考えるんでしょうか。「人月商売のIT業界ははっきり言って、まともな産業ではない。」「日本のIT業界のためにSESは消滅するべき」という意見ありました。良いSESと悪いSESがあるのです、みたいな話になるのかなぁ。ダブスタ感が。

ITで達成できる選択肢が格段に増えたことでビジネスゴールを設定する事自体が高度化するので、「双方が同じコンテキストを共有して要件定義をしないと成果出せません、そして、価値を決めるのはユーザー側!イニシアチブを取ろう!」は100%同意です。それがいかに難しいかは、受託開発の現場で奮闘される皆さんにはお分かり頂けると思います。

POを立てられる会社がどれだけいるのだろう

DX実現のための仮説検証型アジャイル的な取り組みで最も難しいのが、ユーザー企業にPOが立てられるかどうかだと感じました。ハイスペックな人材がPOとして立ち回らないと成果出せませんよね、これ。ビジネス要件もシステム要件もどっちも策定・判断・意思決定できるような人材が、失礼ながらITが本業でないユーザー企業に潤沢にいるだろうか? ITプロジェクトを切り盛りした経験がない・要件定義をやったことがない人が大多数だと思います。

エンジニアを育てることには皆さんやっきになってますけど、POを育てるみたいな話ってアジャイルに造形が深い方々の間でどんな議論をされているだろう。PdM(プロダクト・マネージャ)に集約されるのかな。

自分の理解ではボトルネックになるのはITエンジニアじゃなくてPOだという理解なのですが、違うのだろうか?違ってたら追記して直すので、こっそり教えて。 ガイドラインの策定に貢献された木下さんのnoteにも以下のような記述があったので、自分はそう感じました。

ユーザ企業の担当者が忙しくPOを立てられない場合があるのではないかというような意見もあがったが、そもそもそういったケースではアジャイル開発をスタートしてはいけないのではないかというところに落ち着いた。
IPA の アジャイル開発版「情報システム・モデル取引・契約書」|木下史彦|note

このガイドラインを是として推進をされる現場の方には、「正しくプロジェクトを切り盛りするPOを俺たちが育成する、そういうロールを作る」という方向での議論を盛り上げて欲しいです。エンジニアがいくら頑張っても、ITプロジェクトの成功の是非は価値をデザインするロールの人たちの動き方で決まってしまいますよ。

イケてるPOを目指すあなたへ

僕が魂込めて作った資料を置いておきます。

speakerdeck.com

人類に要件定義は速すぎたのかもしれない

業務設計・要件定義等の支援を生業としている中で間違いなく言えるのは、「いきなり!要件定義!」は死に至りやすいこと。ビジネス要件整理してないのにITの話をしても虚無だよねっていう話ですが、「ビジネス要件を整理できる」というこの一文に至るまでの断崖絶壁を感じました。

その背景について掘り下げていきたいと思います。

コーポレートITの本質は情報共有

営業/製造/生産/研究開発/受発注/出荷/人事/経理/総務/法務/情シス... 企業組織にはとっても多くの業務が存在します。業務単位で皆さんが異なる仕事をしているけど、連携は取らねばなりません。その連携を行うためにITシステムがある。メールやOfficeソフトから、業務特化型のシステムやSaaSグループウェア、古き良き最高のツールである紙媒体。

自分以外の誰かと情報共有しないと仕事が回らないという必然性があるから、使うわけですよね。一人だけでSlack使う必然性は限りなくゼロ。自分だけなら使わないITシステムはたくさんあるはず。なので、コーポレートITの存在意義は情報共有です。

その情報のレベル感や質は、別の議論になります。要件定義の壁だな〜と感じるのは「自分が行っている仕事を分解することが出来ない」という点です。

業務改善=「自分の時間の使い方を変える」

話を単純化します。

出社して「今日のToDoは...よし、何の依頼も一切ない!今日は自由にやりたいことをやろう!」というケースは、基本ない。メールを打つ、資料を作る、会議に出る、お客様先にいく、色んなToDoがありますけれど、誰かの依頼を起点としているという共通点があります。もう1つあるのが、皆さんのお仕事の結果を待ってくれる人がいる点。誰かに動いて貰う必要がある事が多い。

皆さんお一人お一人が日々業務で使ってる時間は、皆さんの自由意思で決まるものではなく、「誰かに依頼され、終わらせて、引き渡す」という一連の流れで決定されます。まずこれが、大前提。

業務改善を一言で言えば「自分の時間の使い方を変える」になります。先程の「誰かに依頼され、終わらせて、引き渡す」という流れ(プロセス)を変えないと、時間の使い方を変えるのはかなり難しい。自分の自由意思で使える時間は少ないし、自分だけやり方変えるのも難しい。

自分の時間の使い方を振り返って一連の流れで仕事が生まれてくることが見えてくると「ここで良くないことが起きてる」「こんな時間の使い方をしたらアカン」等の「想い」が出てくるはず。PCはだるい、スマホでサクサクやりたいとかでも、全然OKです。多分、わんさかでてくるはずです。

時間の使い方を変えたいという想いがないと、業務改善のコンセプトが決まらないのです。それを最近、痛感しています。

で、時間の使い方を変えるシステム企画を生み出すには、自分の時間の使い方を振り返ることで、ここの道順が良くないのか〜という問題意識がクリアになって、問題の解像度が一定レベルまで上がらないと、ダメなんです。

要件定義?まだ速すぎるのでは?

要件定義という工程は、業務改善のコンセプトが決まり、時間の使い方を変えるオペレーションが設計できて、その上で初めて行うものです。前段の内容が全く煮詰まっていないと、要件定義やっても死ぬ確率は高い。目的と手段が乖離するから。

人類に要件定義はまだまだ速い、だが、やりきりたい。そう思います。

バックオフィスや業務系の話を主眼にしましたが、UXも同じじゃないですか。時間の使い方を変えるおもてなしを提供するもんだと思ってました。

時間の使い方を変えたいのだが、どうすべきか

問題意識を共有して、解像度を上げる支援しかやりませんが、吐き出したい!!という方はこのフォームからどうぞ。

forms.gle

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

SQLを学習できるWebサービスを作りました。