フロントエンドの開発スタイルの変遷とFlutterというお話をさせて頂きました
毎度おなじみBPStudy。治夫さん、ありがとうございました！
108枚のスライドはこっちです。50分で話すボリュームではないですね... 煩悩が多くて、申し訳ありません。
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そのものはよくできていて、Androidのxmlファイルのスキーマよりずっと直感的でした。AndroidのXMLスキーマ中途半端。
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して読むといいです！！！
自分は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の存在が非常に気になりました。というわけで、実践的な入門書と各所で話題になった「りあクト！」３部作を全部買いました。
TypeScriptの入門書及びReactに限らずフロントエンドエンジニアの入門書として、この三部作を超えるのは現状どこにもないでしょう。
普通の技術書で組版した日には、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やれてよかったよｗ
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倍界王拳した本作ですが、ほんとにここまで書ききって頂いてありがとうございます以外の感想がない。
三部作の学習メモをとるのにNotionを使っていますが、こんな感じです。改行入れて4.3万文字近くありました。入門書でこんだけのメモ取ったことないわ。コスパすごいですよ。5000円だもん全部で。この本の先生役の雪菜さんクラスの単価を考えるとね、すごいことです。
つらくないReact開発ってあるけど、Reactの辛みの9割はモダンJS＋TypeScriptの基礎体力のなさだと思います。ReactというSDKの理解はそこまで重くないと言うか。iOS SDKの理解に比べたらだいぶ楽な気がする。
著者の大岡さんに最大級の感謝を込めて、書評書きました。I ♡ React, can't thank you enough!!
Flutterに出会ったことで脳汁プシャーになった話
Flutterに出会ってしまったせいで、Flutterを中心に生きていこうと考えている私のポエムでございます。
エンジニアとしての頭打ち感
2016年に35で独立した時はエンジニアとして頭打ちを感じていて、エンジニアとして独立することはあまり考えていなかった。初心者ではないけど、上級者になれないなと感じていた。
エンジニア一本じゃ難しいと考えた時、その隙間を埋める役割はありかなと思った。業務系のシステム導入なら、コンサル〜要件定義の上流工程をやり、開発系なら開発寄りのディレクター。その時々で研修講師。この辺を組み合わせて、今までやってきた。
コードは細々と書いていた。JavaやPython、メンテナンスしてるシステム(WPF)やアプリ(iOS / Android)なり、kintoneでjs書いたりWordPressのプラグイン開発みたいなやつをチラホラやってた。小規模な受託なら受けていた。個人開発と大差ない。できることをやる関係上、技術スタック・規模・ビジネス対象が似通ってくるので、頭打ち感は残ったままでした。
Flutter…ほう、そんなものが？！
Flutterを知ったのは、この記事だったと思う。
2019年10月だから、本番導入した国内事例で、かなり初期ではないでしょうか。もし本当にワンソースで生きていけるなら、こんなに素晴らしいことはない。本番導入した会社があることが強く印象に残った。自分もやってみよ、と。
コロナ禍で2020年の春頃に暇があったので、以前納品した社内向けモバイルアプリをflutterで焼き直すことで、検証してみた。本を1冊買ってあとは公式ドキュメントを写経。
結果は、iOSとAndroidを両方作るのに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で画面開発をするのに比べると「あれ、こんな簡単に作れてええんか？何か間違ってないか？」と、拍子抜けするぐらいスムースに実装することができた。
AndroidとiOSは、原則として手続き型で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開発をやったことがある方なら、２週間でそれなりのものが作れる所を目指してる。
旧知の仲のYOUたちには、主にFBメッセンジャーでポツポツご連絡をさせて頂いており、Flutterに興味がある人いたらつないで！と自重せずお願いしています。
このエントリをここまで読んでくれて、私と面識がなくてFlutterにご関心がある方、最近流行りのカジュアル面談でもしましょう。面識ある人は飯でも行こう。1年弱やってますので、多少はお話できると思います。
2022年はFlutterを軸に生きていくことになります。
まふゆのだいぼうけん、はじまりだ！
炎上プロジェクトでスキルを会得する前にお前は死ぬ
最短でイッセンマンITエンジニアを目指すなら大炎上プロジェクトがオススメ！！経験浅でも採用の可能性が上がるし、週最大7日間1日15時間以上、プロに揉まれながらスキルを磨けるので面倒な家での積み上げは不要！やり遂げた際の経験値はヤバいし、活躍によってはPMが次のPJに引っ張ってくれるよ！
— 代表取締役 岩元仁＠株式会社ロックシステム (@iwa3nen) 2021年8月28日
経験の浅いエンジニアが1千万の年収を得る最短ルートが、炎上案件に飛び込んですげぇ修行して界王拳をマスターしろなのか... 社員にそれを言えるのがすごいな。(いわもと様から社員向けではないとコメントを頂いたので、打ち消します)
炎上プロジェクトで心を病んだ人を多かれ少なかれ見てきて、人づてに色んな哀しみを聞いている身としては、危険としか言いようがない。
僕が若い頃にやった、月稼働400時間が2ヶ月続いたプロジェクトは炎上プロジェクトの類に入るだろう。24〜5ぐらいの時。10時〜24時が平日で、休日も同じぐらい潰すと、それぐらいになる。良かった点は１つだけあって、自分の限界がわかったこと。2日てっぺんまでやれば終わる的なKKDに正確性が出ました。自分で仕事を組み立てないと炎上プロジェクトで生きてこれないし、多少の無茶振りでは動じなくなりました。当たり前だよね、限界まで働いているんだから。いい話でもないわ。
炎上プロジェクトをおすすめしてる理由が「すげー働けるからスキルつくし、やり遂げたときの達成感やばい」なんですけど、その前にお前が死ぬ。
炎上プロジェクトは終わらない夏休みの宿題だよ
働ける環境が劣悪だと、やり遂げるもクソもないんだ。やり遂げるっていうより、終わらない夏休みの宿題をずっとやってる感じ。8月31日がループされる感じ。自分のやったことが無駄になるのが一回ならいいけど、2度3度続くと平静を保つのが難しくなる。仕様が変わる or 追加されるのが炎上プロジェクトの常だからね。日々生み出されるうんこを掃除しても、またうん(ry
炎上プロジェクトでは誰もお前を助けない
経験の浅い人間が炎上案件に入っても、何も出来ないの。炎上してる時は各々が自分のタスクが溢れてしまう状態なので、経験の浅い人の教育に裂くコストなんて取れない。だから、誰もキミを助けることはしない。しないっていうか、出来ないよね。自分が泳ぐのが精一杯だから。そういう状況下で、経験の浅い人間がやれることは、手戻りが起きないように縮こまって目の前のことだけやるしかなくなるよ。何を改善できるの？
炎上プロジェクトで身につくのは力技だけ
問われるのは質ではなく、動くこと。あーこれバカロジックだなーって変更入ったら書き直しかもなーっていう予感があっても、とにかく書くの。書いて動かしてテスト回して先に進むことしか求められない。リファクタリングに時間を割く時間はない。もっと良い設計や書き方を感じる時間があったかもしれないけど、それをこの炎上案件に適用する時間は、無いんだ。動いているものを書き直す機会は与えられないし、動いているものが変わっちゃう可能性も高いから。
それに、経験が浅いってことは、誰かが考えた仕様を実装するタスクが多くなると思う。この種の仕事をやりきっても、ほとんど成長しない。実体験だよ。要望をまとめて自分で仕様を考えて実装してバグ出して直すから知見が得られるのであって、与えられた仕様をなぞって書いても漢字の書き取りと変わらない。文章を書かないとね、表現ができない。少なくとも、エンジニアはコードで表現できないと先に進めない。
悪い状況を悪いやり方でやっつけることを学んでも、あなたの開発者としての引き出しが増えるわけじゃないんだ。プロに揉まれるってのは幻想だと思っていいよ。失敗したプロジェクトで自分が沢山手を動かすことで成長できる、なんて言われるかもしれない。稼働すればするほど成長できる理論、バカとしか言いようがない。
終わってるところに入っても、何も残らないよ。炎上プロジェクトは、トライアンドエラー(PDCA)をする場じゃないから。DoDoDoDoDoDoCheckDoDoDoDoDoみたいな感じ。こういう状況だと、やっつけ仕事にならざるを得ない。振り返っている時間がないんだから。
橋が対岸にかかっていて、みんなが渡り始めていると、後ろから火の手が上がる状況なんだって。振り返る余裕ある？ 対岸に進むのが先だよね？ 対岸に着いたらなにか残るかな〜 橋は燃えているんだけどね〜。 ま、そういう話。
プロジェクトに入って、概ね計画通りに進めて成果物の整合性取って意見調整して進める一連の過程が「成功」するからノウハウがたまり資産が増える。その積み重ねで視座が変わるわけ。視座が変われば発想が変わる。発想が変わらないとレベルアップにならない。成功体験が重要じゃん。火消し体験って成功体験かって言われると、クエスチョンだ。スキルアップって耳障りの良い言葉に囚われちゃダメ。目指すのはレベルアップだよ。
もしかしたら、あの案件きつかったけどやりきったよな俺たち良かったよな〜なんて新橋で戦友と飲めるなんて美談を想像しているかもしれない。バカだな〜。うまく行ってなくて、ずっとうんこ片付けた話で酒がうまいとでも思います？ あの案件すげーうんこ降ってきたよな〜 楽しかったな〜って？
炎上プロジェクトにいるだけで落ち着かない
SESで下請けとして入る場合、炎上しようがあなたたちに非は無い。SESだから稼働すれば良く、プロジェクトが成功しようが失敗しようが、お金がもらえるならどうでもいい。でも、プロジェクトがうまく行ってないことはわかるじゃん、普通は。最低でも肌感で。進んでないんだから。糠に釘を打ち続けていると、真綿で首を絞められるような居心地の悪さがすごいんだ。
こういう立場のときにやれることは、自分の被害を最小化しつつ、焦げ臭いと感じてもやぶ蛇にならないよう、決められた稼働時間で指示通りに働いて作業報告書を出すだけ。オレがそう立ち回ってこいってブチョーに言われたからね。ハハハ。もし、あなたが当時の私と同じで炎上プロジェクトの下でSESで入ったとしたら、やることは「このプロジェクト自体が燃えています、こんな兆候があります。我々を早く引き上げて下さい。」と上に伝えること。これで私はちょっと早く生還できた。運もあったけど。
炎上プロジェクトで生き抜ぬいても、貧乏くじが待っている
上の立場からすると、心を病まれちゃ困るじゃん。キツめの案件で。そういうとこだけはディフェンシブなんだよね、他はガバガバなのに。乗り越えちゃうと、多少きつくてもあいつならってなりがちなのよね。よくやりきった！次はもっと良い条件で新しい技術のあるこれだ！なんて話につながらず、その後も焦げ臭い案件に入れられやすくなる。バカみたいだよね〜 やりきったら次にやってくるのが貧乏くじ〜。コレで辞める人多かったな〜。
炎上プロジェクトはステップアップの場ではない
ここまで読んでも、僕は炎上プロジェクトという超神水を飲んで40連勤上等で生き残ってパワーアップしてみせると申されるのであれば、どうぞご自由に。
経験がある人は多かれ少なかれ炎上の匂いを知ってるから、立ち回りもある程度できると思うし、身の処し方もわかってる。でも、経験が浅いヤングな人は、単純に知らないからね、流れ弾に打たれて当たっても、それを自己責任にするのはかわいそうだ。だからこの記事を書いている。
少なくとも、オレの周りにいる炎上経験者の生き残りは、誰も炎上プロジェクトで力がついてよかったとは言ってないよ。
オーバーワークからの立ち直りについては、こちらの記事が詳しいので、あわせて読もう。
逃げるは恥だが、役に立つ。
2021.08.30 14時43分 追記 いわもと様よりコメントを頂きました
最短で（フリーランスになって）イッセンマンITエンジニアを目指している人たちへのネタメッセージで、社員に向けて言っているなど書いてないので訂正をお願いします。
大変失礼しました。元ツイには対社員とはどこにも書かれていません。企業の代表が率先してオススメしてるぐらいだから、社員にも同様の主張を行っているものだと私が拡大解釈してしまいました。取り消し線を打って、修正しました。
・・・ネタメッセージってなんなのよ？？
ネタメッセージという日本語の意味がわからない。ネタってことはギャグや冗談ってことですよね。ホントの話じゃないと。あの、どこがネタなの・・・？
炎上案件がオススメという主張そのもの？ 炎上案件はオススメだけど、１千万稼ぐ最短ルートではないという話？ 炎上案件はおすすめしないっていうのがマジで、オススメするのはネタなの？ １千万稼ぐには炎上案件に入れという主張がネタだとしても、オチがないやん。これ。オチはどこなの。
あと、タレコミで「炎上結果から得た学びを社員に還元して労働時間減らした」という趣旨の発言もあったそうです。じゃ、炎上案件オススメしたのなんで？ なんでなの？
開いた口が塞がらないわ。
ブログで「言うだけ言うわ」という感覚を無くしてた
久しぶりに「わかるううううう」という脳内麻薬が出て、慌ててブログ作成の画面を開いた。
特に、ここが響いた。
これはかなりつまらないことで、自分でも「こいつ毎回似たようなこと書いてるな」と思うのはうんざりする。もちろん寄稿など求められて書く文章で似たようなことを書くぶんには違和感はない。でもここのブログはわたしの現住所のようなもので、過去の履歴も見ることができ、何よりそれを1番知っているのは自分なのだ。自分で自分の書くものに飽きている。長く住んだ家のようなもので、あれもこれもわたしが自分で探して選び、置いたものだらけだ。心地よいし安心するが、新鮮な刺激はない。これがわたしが書く頻度を落としてしまった理由なのではないかと思う。
とても良くわかる。同じ感覚持ってて、ブログを書けなかった。
はせさんも書いていたけど「自分の芯の部分って変わらないんだな」っていう気づきがあってから、ブログに書くという熱が冷めていった。「自分の中で煮詰めた考えを文章にする」ことって、書き終わると自分の頭もスッキリするし、自分で読み返すと糧になる部分があった。煮詰まっている過程で得られる何かは、確かにあった。
僕は累計で４万弱のはてなブックマークを頂いており、何十回と１対Ｎの意見交換をやってきて、みなさんのおかげで自分の考えが煮詰まったので、書くことがなくなったという帰結を迎えた気がしている。
昔はよくSIerとかアジャイルとか内製回帰とか、色々書いていた。多くは「まだ見えていないけど届きそうな理想」みたいなのも感じて書いていたが、それなりにプロジェクトをやってきて、ある程度煮詰まった考え/やり方を確立し、色々話ができる友だちや仕事仲間もできて、着地しちゃった感覚もあった。熱気球が燃料切れて着地するような感じ。
今、個人的に大好きなネタは「DX」だ。これを書かずしてどうするのよって最初は思っていた。自分も色んな会社のDXに貢献するぞという勢いで独立した。DXをやるのは正しい。どんどんやれ。いつやるのじゃねーよ、今だよ。できないのは企画が立てられないからで、企画が立たないの(ry
多少なりともDXコンサルをやっていたら、DXは組織問題が8〜9で、技術が1ぐらいという肌感を得るようになった。特にITがコアじゃない会社にとっては。DXをやるには、自社にとってのDXは何かを定義した上で、事業運営のメスを入れる箇所を決めて、どのような体制を組んでサイクルを回せるのかに注力する以外の道筋が見えなかった。地味すぎる。自分の中である程度煮詰まったので、煮詰まったものを蒸し返して書くことができない(慣れていない)ので、アウトプットできていなかった。
が・・・DXのアプローチを丁寧に展開してくれるすごい人がいた。ガーンと横っ面を叩かれた感じ。まだまだ、自分はしょぼい。
一緒に仕事できたら楽しそうって正直感じたので、言うだけ言う。
言うだけ言うわ、あとはヨ・ロ・シ・ク
このテンションを忘れていた。
ノリで文章かけなくなるなんて。このブログのアイデンティティが崩壊しているわ。思い返せば、言うだけ言うたけど、YOUたちどう思うって感じでノリで書くことで、それを枕にしていい感じに使ってくれる人がたくさんいるから、こんだけブックマークしてもらえたんだよな。
1ヶ月に1回ぐらいはノリで文章を書こう。
文章を書くのは大好きなんだから。
【書評】「業務システム開発モダナイゼーションガイド」を手に取ろう
非効率な日本のSIと聞いては私も反応してしまうので、読みました。結論から言うと、グレートでした。
業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス
- 作者:赤間 信幸
- 発売日: 2018/02/16
- メディア: 単行本
本書の主題
「はじめに」で書かれている内容を、私なりに要約します。
日本のエンプラ系SIの商慣習(多重請負構造)における『上流』の仕事のやり方が、ほとんど進化していない。多重請負構造におけるエンドユーザーやIT部門、SI関連会社、SIerが近代化しているソフトウェア開発技術の活用を『妨げる』ようなことをしていては、いつまでたってもその恩恵を「エンジニア」が享受できない。変えるべきは開発の現場だ。
上流工程と下流工程という工程の分断は、そこに属する技術者に対してデメリットが非常に強いのは事実です。自分もSIer時代に、プライムで請けた案件と2次請けのSES案件に入った時では、圧倒的に前者のほうが身になりました。エンドユーザーと同じ目的に向かい、ITプロジェクトを近代化したソフトウェア開発技術や手法で成功させてほしいという筆者の思いが、ビンビンに伝わります。
また、「開発」と名を打ってあるように、要件定義〜テストまで幅広く網羅され、「ここだけは抑えておけ、知っておけ」とポイントをまとめたTipsが列挙されており、新人教育にはこの1冊があれば充分ではないかと思います。Microsoftの方が書いた本なので、大人の事情で要素技術についてはMicrosoftテクノロジーを中心に解説されていますが、この本で学ぶべきでは要素技術ではなく開発手法や考え方なので、問題ありません。
本書に書かれている内容を実践している会社はまだまだ少ないと思いますが、「この開発の進め方はどうなの」と疑問を持った若い方に、是非手にとって欲しい本でした。
人月見積が効率化を阻害するのかも
エンドユーザーに対して人月見積をして売値を決めているので、期間短縮すると売上が落ちます。当社はめっちゃ近代化した開発プロセスになったので、今までより30%速く出来るようになりました。なので、30%引かせて頂きます！とはね、なかなか。効率化を促進すれば生産原価が下がるはずので利幅が大きくなるように思いますが、そういうビジネスモデルをエンプラ系SI関連会社が採用していないのではないでしょうか。
「エンド⇔SIer⇔協力(下請)会社」という商慣習も、極端に言えばエンドユーザーが「この技術を使ってこっちで要件出してプロジェクト管理すれば、SIer挟む必要ないね」となれば良いですが、エンド側にITプロジェクトを運営する体制がない気がします。自分の業務があるので、兼務ですよね。兼務だと手を動かすことが少ないので、ノウハウ残らない印象が強い。我々のようにプロジェクトワークだけに100%のリソースを当てられないので、だったら内製すればってなるんですけどね。
製造原価が人件費である以上、人月をやめるのはかなり難しい。顧客企業の課題を個別のシステムを作って解決するのが受託開発なので、サブスクのように「ちゃりんちゃりん」とお金が降りてくるモデルは極めて難しい。効率化するのであれば「要件からリリースまでの デリバリ・プロセス」しか無いのでしょう。
なので、本書が提起してるように、非効率を解消する鍵は開発プロセスにあるだろうなと感じた次第です。DXを推進するには、この本に書かれているように、要件定義〜リリースまでの一つ一つの工程を見直して、チューンナップすることが「急がば回れ」の解決策かもしれませんね。
業務システム開発モダナイゼーションガイド 非効率な日本のSIを変革する実践的ベストプラクティス
- 作者:赤間 信幸
- 発売日: 2018/02/16
- メディア: 単行本
日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について
先日、アジャイル開発を推進するために大変有意義な資料が公開されています。ESMの木下さんといえば、アジャイル開発の現場にずっと携わってきた著名な方です。
でも、令和2年にこちらの記事が何百もはてブされるのも、おいおいマジかよって思う所がありまして。今までどうやってたのだろうか...。準委任(時間単位のチャージ)以外の選択肢がないやり方だと思っていたので。請負でアジャイルを取りに入れるわけないですよね。一般的なSIerさんでは、どういう理解をされて、どう取り組んで来たのだろう。
アジャイルと受託開発の相性は最悪では
ムービング・ターゲットを請負で追いかける自傷行為を誰がやるんだって話と、要件固めて下請けに出せないから誰もやりたがらないよねという話を書き散らしています。
10年前に書いた記事の内容がまだ通用してしまうのも、自分でも少し寂しい気持ちがあります。
日本の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プロジェクトの成功の是非は価値をデザインするロールの人たちの動き方で決まってしまいますよ。
人類に要件定義は速すぎたのかもしれない
業務設計・要件定義等の支援を生業としている中で間違いなく言えるのは、「いきなり！要件定義！」は死に至りやすいこと。ビジネス要件整理してないのにITの話をしても虚無だよねっていう話ですが、「ビジネス要件を整理できる」というこの一文に至るまでの断崖絶壁を感じました。
その背景について掘り下げていきたいと思います。
コーポレートITの本質は情報共有
営業/製造/生産/研究開発/受発注/出荷/人事/経理/総務/法務/情シス... 企業組織にはとっても多くの業務が存在します。業務単位で皆さんが異なる仕事をしているけど、連携は取らねばなりません。その連携を行うためにITシステムがある。メールやOfficeソフトから、業務特化型のシステムやSaaS、グループウェア、古き良き最高のツールである紙媒体。
自分以外の誰かと情報共有しないと仕事が回らないという必然性があるから、使うわけですよね。一人だけでSlack使う必然性は限りなくゼロ。自分だけなら使わないITシステムはたくさんあるはず。なので、コーポレートITの存在意義は情報共有です。
その情報のレベル感や質は、別の議論になります。要件定義の壁だな〜と感じるのは「自分が行っている仕事を分解することが出来ない」という点です。
業務改善＝「自分の時間の使い方を変える」
話を単純化します。
出社して「今日のToDoは...よし、何の依頼も一切ない！今日は自由にやりたいことをやろう！」というケースは、基本ない。メールを打つ、資料を作る、会議に出る、お客様先にいく、色んなToDoがありますけれど、誰かの依頼を起点としているという共通点があります。もう1つあるのが、皆さんのお仕事の結果を待ってくれる人がいる点。誰かに動いて貰う必要がある事が多い。
皆さんお一人お一人が日々業務で使ってる時間は、皆さんの自由意思で決まるものではなく、「誰かに依頼され、終わらせて、引き渡す」という一連の流れで決定されます。まずこれが、大前提。
業務改善を一言で言えば「自分の時間の使い方を変える」になります。先程の「誰かに依頼され、終わらせて、引き渡す」という流れ(プロセス)を変えないと、時間の使い方を変えるのはかなり難しい。自分の自由意思で使える時間は少ないし、自分だけやり方変えるのも難しい。
自分の時間の使い方を振り返って一連の流れで仕事が生まれてくることが見えてくると「ここで良くないことが起きてる」「こんな時間の使い方をしたらアカン」等の「想い」が出てくるはず。PCはだるい、スマホでサクサクやりたいとかでも、全然OKです。多分、わんさかでてくるはずです。
時間の使い方を変えたいという想いがないと、業務改善のコンセプトが決まらないのです。それを最近、痛感しています。
で、時間の使い方を変えるシステム企画を生み出すには、自分の時間の使い方を振り返ることで、ここの道順が良くないのか〜という問題意識がクリアになって、問題の解像度が一定レベルまで上がらないと、ダメなんです。
要件定義？まだ速すぎるのでは？
要件定義という工程は、業務改善のコンセプトが決まり、時間の使い方を変えるオペレーションが設計できて、その上で初めて行うものです。前段の内容が全く煮詰まっていないと、要件定義やっても死ぬ確率は高い。目的と手段が乖離するから。
人類に要件定義はまだまだ速い、だが、やりきりたい。そう思います。
バックオフィスや業務系の話を主眼にしましたが、UXも同じじゃないですか。時間の使い方を変えるおもてなしを提供するもんだと思ってました。
SQL学習オンラインサービス「Start-SQL」をリリースしました
こんな感じで、ブラウザでSQLを書いて環境構築一切不要でSQLを学べるというWebサービスです。
今北産業
- SQL言語のみをサポートしています。
- 環境構築一切不要で、無料でお試し出来ます。
- コンテンツには無料と有料の2つがあり、有料版は”買い切り”で、5000円です。全てのコンテンツがお楽しみ頂けます。
圧倒的にアカウントを買うニーズが強かった
2019年8月頃に「研修サービスのプラットフォームとして」告知をしたのですが、結論から言うと「講師や研修は別にいらん、アカウントだけ売ってくれ」が個人 / 法人共に、圧倒的に多かったため、会員登録/ログイン/マイページ/コンテンツ購入/パスワードリマインダなどの機能を別途付与して、Webサービスとしてリリースしました。
買い切りにした理由
コンテンツを定期的に追加する予定が全く無いためです。月額制にするならほっといてもコンテンツが増えていかねばなりませんが、SQL言語に新しい標準構文等が出てくる気配がありません。このサービスを作るにあたりSQLの入門書はあらかた目を通しましたが、初版10年前の本と今年に出た本で書いてある内容、ほとんど変わっていないですしね...
Merry Chrismas!!
年末年始の自学自習に間に合うよう、12月25日のリリースを目指して準備して参りました。SQLは学習コストが低いのに応用の効く言語ですし、みなさんがお使い or 運営に携わっているWebサービスや業務システムへの理解も深まると思います。SQLを学べば、システムから好きなデータを取得できるようになります。
サービス案内ページはこちら
突撃! 隣のコーポレート・エンジニアリングっていう連載企画、どうでしょう。
あるWebメディアさんに「色んな会社がどうやって組織を円滑回すためのITを組んで会社を回しているのか、総務的かつ技術的な視点で刺激を与えるシブ知な連載どうですか」と持ちかけたんですが、まずは取材先や読者層がどれだけいてくれるのかってのが知りたくて、このブログで取材先を公募をすることにしました。
コーポレート・エンジニアリング is 何
非常に簡単に言えば、会社の運営上の問題をITを使ってどうやって解決して、組織の運営を最適化していくのか、それを支えるエンジニアリング組織をどう作るか、という活動です。私は、そのように定義しています。プロダクト開発のあり方を考えるのではなく、組織運営のオペレーション設計やあり方を考えるのが主眼です。
で、まぁ結局すべきことって1つしか無くて「オペレーションの改善と改革」です。自分達がやっているタスクを、正しいやり方に再定義して、みんなが働きやすい環境を作り、会社の運営をヘルシーにする。こういう流れというかサイクルを作って回す仕組みを、ITで用意する。そのITがハックする対象が、コーポレート(会社組織)になるわけです。
「IT技術を使って、人に依存することなく働き方を変えて、会社を変える・良くする仕組みを考えて、実行に移すこと」
自分がずっとご業務システム畑にいたこともあってか、こういうITの使い方をもっとやりたいな、知りたいなっていう思いが、とても強いです。
業務のDXと事業のDX
ITを手の内に入れる(企画から運用改善までのサイクルを、自社で管理できるような体制をつくる)のが、DXなるものを実現するための骨子。これは及川さんの著書「ソフトウェア・ファースト」で書かれていた定義です。
ただ、私の中では「事業やプロダクトを開発するDX」と「業務やオペレーションを改善し、組織運営のインフラを開発するDX」の2つがあると思っています。前者と後者は、どこかで融合するといいますか、結節するポイントがあると思ってて。ラグビーでいうとフォワードとバックスのような、そんなイメージを持っています。バックスがトライを上げるために、コーポレートが前でスクラムを組むわけですわ。プロダクトが生み出す価値と、組織改革として生み出す価値が交差する議論をしていく中で、エンジニアリングの幅を広げていける刺激を提供したい、そんな風に思っています。
取材先の会社さんを募集します
取材させて頂きたい内容としては、以下の通りです。
- 事業内容
- 総務部門の体制
- コーポレート系のエンジニアの主な業務内容・キャリアパス
- 会社運営上、特にITで解決したいと思っているエリア
- バックオフィス運営のやりがい
- 業務運営でウチはここを工夫しているぜ！っていうアピールポイント
- コーポレート・エンジニアリングに期待すること
- 今後の抱負
これがテンプレになっていて、これをベースに1時間〜1.5時間枠程度で、いろんな議論が取り交わせればと思っています。私が話し手となって、ショーンKのごとく色んな話を引き出させて頂ければと思います。コーポレート部門でエンジニアを活用している会社さんが最も関心が高いと思いつつも、ウチの創意工夫を聞いてもらって手伝ってくれる人を探したい方、一緒にこの企画を運営したい方からのお声がけをお待ち申し上げております。
来週以降、私から個別にDMが飛ぶこともあるかと思いますので、引き続きよろしくおねがいします...!!
掲載先
企業メディアさんが当該企画にJOINしていただけるのであれば、そちらに掲載しようと思っています。特にいらっしゃらない場合は、私が運営しているnoteに掲載します。
