組織人事を見てみよう。IT部門のミッションは何かをもう一度読んでみよう。ここはIT企画の醍醐味ではないか。それはIT部門の手からはなしてはいけない。・3つ目から学べること。選択しようとしているテクノロジは、経営上の、事業上の、業務上の課題を解決できると判断したIT部門が意思決定したもののはずだ。可能性で話すそうとするから話がおかしくなる。PoCをIT企画の段階でやろう。可能性などと曖昧な話はなくなるはずだ。・4つ目から学べること。新しいしい方法論を選びたいのなら、それこそIT企画の段階でPoCをしてその方法論のポテンシャルを見極めるなければ、企画自体ポシャってしまう。それも自分でやらないと予算組めないし、確保も、精査もできなくなってしまうだろう。・5つ目から学べること。IT企画はプロジェクトだ。プロジェクトは唯一無二のものである。誰も試したものはいない。似て非なるプロジェクトが過去にあった、という事実しかない。プロジェクトのオーナが意思決定するものだ。意思決定できないなら、IT企画の段階でプロトタイプなり、プレプロジェクトをやって意思決定出来る情報を集めればいい。アドバンテージ若いエンジニアから「最近新しいことを始められたと聞いてすごいとおもいました。失敗は怖くないですか」と聞かれた。以前、メンバのエンジニアにコンピテンシを広げるとき、「それ役に立ちますか」と問われたことがあった(そのエピソードについては過去に書いた)。役に立たない、失敗はしたくないという気持ちはわかる。役に立つこと、成功につながることをしたいのはよくわかる。それは年齢に関係なく、同じことを思う。やってみることに失敗はつきものであることもわかっている。失敗をしたくないというか、失敗にデメリットか、マイナスのイメージを持っているのだろう。やったことのがないことは、例えそのやり方が手順化されていたり、明確だったとしても、自分で成功して繰り返しても成功する経験がなければ、失敗する自信はある。その若者に引き合わせた知人もそうだが、新しいことに手を出して結果を出している人は失敗をする。それも上手に失敗する。別に失敗するためになんでも試すわけではない。上手くいくといいな、くらいか、これで行けると思いながらやってみる。「もし『こう』すれば、結果は『こう』なるだろう」とやる前に考える。その結果はどうかと言えば、『こう』ならない。「こう」すればを仮定するときに、仮定の条件を押さえているから、次の「もし『こう』すれば」につながる。そのうち、期待していた「結果は『こう』なる」に到達して、その時点で一旦ヨシとする。「一旦」」というと、それを評価出来る人かそれを作ったターゲットの人に見せて反応知って、フィードバックするつもり満々だからだ。それで反応が上々であればそのままGOにする。年齢の30歳の違いは「失敗の仕方というアドバンテージ」なのだと思っている。いえ、モニターの買い替えでは失敗したくないからどれがいいか迷いに迷ってなかなか決められない。おすすめが有れば教えて欲しい。csvタイトルを見て、エンジニアに出さずに内製化したのかって早合点していたのだが、読んでみたら、人ってバイアスを掛けて情報をみているのだな、と自分で自分を諌めるなどしている。note.comエンジニアになって数年した頃、知り合いの知人の建設関連の人で『こんなのをPCで実現したいんだけどいくらくらい』と聞かれ、何も話を聞いていないから『100万くらいですかね』と言ったことがあった。要件わからないで規模を言うのもアレだし、それが自分で作れるかもアレなのに、随分と適当だったなと冷や汗ものではある。あと、世間を知らなすぎな感じはある。今なら話を聞いて、誰でも持っているものでできないか、そもそもいるのか的な方向に持っていくだろう。ITにポンと100万出すほどの規模ではないからと察しがつくためだ。数ヶ月した後、知り合いからその話があって、結局、知人の方はexcelで自分で作ったと聞いた。引用の記事のタイトルをみて、それを思い出して、引っ張られた。今の自分は、外に出すよりはエンジニアのチームを抱える指向性を持っているので、そうしたこともバイアスの1つになっていると思われる。自分のことであるが、意思決定は自分の過去の成功体験などの積み重ねで捻じ曲げられるから、思われるとしか言いようがない。言え、何が何でも内製かと言えば、そうでもない。全部SaaSでいいとも思っているが、属する組織の実現したいことがSaaSで実現できないものもある。いったものやSaaSに置き換えられないものは内製化になる。SaaSを使い始めると、引用記事のように情報が分散する。目的に応じてSaaSを選び、業務を行うから、結果的に情報は業務別のSaaSに収容される。SaaSの乱立は手作業を生じさせる。どんな手作業かと言うと、転記やデータを手動で出し入れである。これはオンプレと言うかシステム間インタフェース(連携)の話だ。インタフェースを決め、csvファイルをHULFTを使ったり、指定のディレクトリにファイルを置いて、決めたサイクルでファイルを読みに行き、スクリプトで取り込むなどよくやるものだ。令和になり、2020年にもなろうと言うのに、平成なことを今度はクラウドでやろうとしているのである。codeだZapierなどで業務担当が繋いだり、codeならAPIでエンジニアが繋ぐことになる。話は脱線するのだが、microserviceの本をサラリと斜め読みして、『あー、大規模システム内のサブシステムの開発をリリースはときどき合わせて、あとはサブシステム毎に業務都合の裁量で開発しているようなものか」と解釈していた。組織内の業務アプリがSaaSへ移行すると、業務システムのmicroservice化が起きる。SaaSだから勝手に機能もインタフェースも変わる。利用者やエンジニアへの配慮はない。プロダクトの都合で進んでいく。繋ぐ仕組みが必要で、microserviceならAPIなのだがZapierなどで繋ぐのでもいいのではと思うようになった。Zapierを使ったり設定したりするのが業務担当なら、SaaSのバージョンが勝手に上がって、インタフェースのサポートが切れようなものなら、すぐにわかる。使えなくなったら自分で直せるからエンジニアに頼まなくていい。エンジニアはAPIでゴリゴリ繋ぐ方か内製化の組織内向けのサービスプロダクトに集中すればいい。そのことを事象として語っているのが、引用の記事なのだと思う。それが事業会社のエンジニアリングの進む方向なのだろう。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。