調達 Qi 無線充電

itDEAL モバイルバッテリー Qi ワイヤレス充電 無接点充電 大容量 10000mAh Quick Charge 3.0対応 急速充電 (ホワイト)

【国内正規品】 MATECH 置くだけ充電パッド (シングルコイル Qi ワイヤレス充電器) iPhone 8 / iPhone 8 Plus / iPhone X / Galaxy S6 / S7 / S6 Edge / S7 Edge,Nexus 4 / 5 / 6 / 7 (第2世代 2013) / LG G3 / その他Qi対応機種 (1年保証) [日本メーカー] MQIP/CIRWH

調達 iPhone8 iPhoneX 保護フィルム

iPhone 8 3D フルスクリーンナノフィルム・PRO GUARD 3D forming nano film (iPhone 8, AFP white border・光沢)

3D フルスクリーンフィルム・PRO GUARD 3D forming nano film (iPhone X, HDAG white border・マット)

iPhoneX 背面保護フィルム ガラスフィルム 9H硬度の液晶保護 LANYI 日本旭硝子素材採用 高透過率 3D 0.3mm 超薄型 耐指紋 撥油性 ラウンドエッジ加工 (1pack, クリア)

iPhone X PRO GUARD CRYSTAL GLASS 3D NANO COATING (iPhone X, GLOSSY black border)

スクラムガイドの更新のまとめを読んで思い出したこと

 後から出てくるものは過去の埋もれて誰もが忘れていた手法やアセットにもう一度スポットライトを当てたり、忘却の彼方に追いやってしまった当時はその意味に気づかなかった仕組みを思い出させてくれることがあるのです。

スクラムガイドの更新

次のようにスクラムガイドが更新されたとのことで、変更点をまとめていただいているので感謝しつつ見させていただいた。

2017年11月7日(現地時間)にスクラムのルールブックであるスクラムガイドが更新されましたので、Webinarの資料をもとに変更点をご紹介します。

www.ryuzee.com

引用先の冒頭でも気になる点として取り上げられているのですが、 気になったのは↓これです。

レトロスペクティブ（ふりかえり）で出た項目を、次のスプリントのスプリントバックログに含めること

 どうして気になったのか

 ですけれど。これを読んで思い出したことがありまして。

このふりかえりで出た項目を次のスプリントのバックログに入れなさい、ということは、今回実施した作業工程で学んだことの中からtryをactionに繋げることを確実にするために入れておきなさいね、ということなのだと思ったのです。

これはさらに連想が2つのことに繋がりまして。

tryをやるかはクリティカルか否か

色々とエンジニアと話していると、ふりかえりを導入しているチームは増えています。これはいい傾向だと思っていますが、一方、当事者のチームが自ら気づきを得られるという観点から様子見とした方が良さそうなので経過観察しようと思っていますが、tryに出たことをどこまでチームが拾うかと言えば、実態は、クリティカルなtryしか拾わない、拾えないという状況が見受けられるのです。

まあ、tryにあげたら全部やらないといけないかと言えば、これまでは運用的にも次の工程で当初から予定しているテーマがあるのでそこにtryをどこまで入れるのかというシーソーゲームをするときにやはり、当初のテーマが優先されると、いわゆる負債が積み上がっていくので悩ましいところです。解は、tryの中で落ち葉拾い的なものも一定量やるだけの道幅を持っておきなさい、なのですが。

次のバックログに入れるということ

 もう一つは、この工程で得られた知見を次の工程に再投入しなさい、という考え方です。

これを読んで、思い出したのは、2000年頃のプロジェクトの品質管理の工程内レビューのポリシです。どんな内容だったかというと、

• 工程内レビューを行いなさい
• 品質分析をして、工程内で改善しなさい

というものです。つまり、今週レビューをしたら、その場で品質状況を分析して、次週の作業工程に反映しなさい、という考え方です。

まあ、1週間かどうかはレビュー計画によるのですが、最後にまとめてレビューをするようなことは作業量の平準化からそんなことはせず、順次レビューに投入する計画を建てるとき、工程内で品質不良の傾向をみて、残りのアウトプットを作るときに品質の確保を計るようにしておきなさい、と。

言わば、親心のようなものですね。

それを思い出したんですね。実際の現場でそれができていたかどうか、出来ていれば以降のプロジェクトに採用され、広がったはずだろうと穿った物の見方はできるけれどそれはあまり意味がないような気もするので。

ただ、そういった標準の仕組みの意図を理解して、実利があることを認めて理解者を増やすのは気づいた人だけというところがアレな訳ですが。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

調達

水作 フロートボックス

ジレット プロシールド 髭剃り 本体+替刃9コ付

スーパーエンジニアやエバンジェリストはロクロで何を捏ねているのか

システム開発でデスマになった後に行われるプロジェクト報告会は実質、戦犯を探すために行われているようなものだ。その目的が果たれようとするとメンバ同士がそのプロジェクトで自分が被害を受けた些細な出来事を論い、言い合いになりそうになると大人なんだからと割り込まれて、落とし所はコミュニケーションをもっと取るべきだったとかシステム開発方法論が合わなかったとか、と情緒的な、全くもって再発防止に結びつかない的外れな、どこかの失敗プロジェクトでも出てきた要因にすり替えられて本当の原因は会議室の片隅で置き去りにされてしまうのだ。

システム開発方法論

システム開発方法論は必要であるが、その構造を理解し、適用するプロジェクトにテーラリングする能力がなければ、全くもって機能しない。

使ったことがなく、どうなるかわからないけれどとでも他のシステム開発方法論では思うように結果を出せるほど使えているからと方法論の使い方を知っていて、新しい方法論を全部なのか一部分なのか加減をしながら使おうとするくらいであればその方法論が期待するような結果が得られるかどうかという意味合いで使えるかどうかの判断はできるだろう。

なんでもそうなのだけれど、論とついたら器なのだと思えるかどうかである。中身は使う料理人たるエンジニアが使い方を考え、思うように使わなければならないのだ。ウォーターフォールもアジャイル開発も、要は、見通して仕事をするために作業をどうするかの考え方なのである。

そのシステム開発方法論の上に乗るのは、ツール＆テクニックつまり生産性向上ツールである。それは選り好みで使えばいいし、使わない、対価を払わないのなら人件費が安いとバジェットを握っているマネージャがそう思っているだけの話である。

マインドセット

システム開発方法論は器で、その上に生産性向上ツールを乗せた。あとは、エンジニアがプロジェクトでは色々と起きるけれど、

「でもやるんだよ」

と思う環境を作れるかどうかである。カンバンなどの可視化だって常時エンジニアの視界に入るようにして刷り込んでいるわけだし、カンバンで使ったポストイットをシースルーのゴミ箱に入れて捨てないで置いておくのは頑張ってるよねと自己満足を充足しているだけのことだ、と見ることもできる。

チームの他のメンバの作業を止めてまで話しかけることは気がひけるし、自分が集中しているときには話しかけられたくないからslackやchatworkを使ったりするのは、生産性向上ツールというよりは、環境を構成するツールに当たるのでマインドセットに近い。ツールの分類はどうでもよくて、気にしておきたいのはトラブらないように、考えているようにプロジェクトを進捗させるために何をしなければならないか、そのために何を働きかけていかなければならないのかという仕事の本質をどう捉えているかである。

おおざっぱすぎてあれだけど、物理的な製品や部品を作っているなら、その日の生産目標分だけを出荷できるように操作すればいい。

ところが、ソフトウェア開発をするエンジニアは、仕様書やコードの型を持っていない。全部、エンジニアの個人が持っている経験値と形式知の危うい知識で捏ねて作るのだ。

その捏ねる作業のほとんどは、自分の仕事が捗るように思考をまとめる作業なのだ。そのために必要な情報をくれ、こう作っちゃうけどいいかなという情報伝達が仕事の大部分なのであることを誰一人として気づいていない。だから自分だけ頑張っていると思うのだ。

エンジニアは頑張っていることを気にするより、経験知と形式知を捏ねるのではなく情報をロクロに乗せて両手で捏ね捏ねすることが必要なのだ。

それができているからスーパーエンジニアやエバンジェリストの写真はいつもロクロを回すのである。

• メディア:
• この商品を含むブログを見る

 

自分でなんとかしよう症候群のエンジニアへの緩和ケア

SIビジネスのシステム開発手法にどっぷりと浸かった上で飼い慣らされてしまうと、業務量を調整しようという発想ができずに、自分でなんとかしよう症候群に侵されてしまいます。お気をつけください。

特に、年末進行となると、無能な上からあれこれと一方的にタスクを口に突っ込まれるだけ突っ込まれて息も絶え絶えにアップアップして今にも溺れそうなエンジニアが累々とするので。

この症候群は、どちらかといえば年齢層が高いエンジニアが罹りやすい症状です。20年、30年と頼まれたらそのままやらなければならないんだ、という思い込みも症候群に拍車を掛けるのでわまりで見かけたら、徐々にそうした負担を下げていくようにしてあげてください。急にタスクを剥がしたりすると年齢的に高いことからエンジニアとして必要とされていないと勘違いしたり、単純に拗ねたりするので面倒です。

症状に罹りやすいエンジニア

 自分でなんとかしよう症候群のエンジニアに特に年齢的な特徴はありませんが、中堅層からシニアにかけて罹りやすいです。

原因としては、前述したとおり頼まれたら言われたとおりやるものだと思い込んでいることが挙げられます。

また、年齢が上がると新しい技術を覚えたり、手法を試したりすることへの心理的な抵抗が増え、現状にしがみつきたいというエンジニアとしては有るまじき心構えが一層強くなって拗らせてしまう、という症例もありますので日常からのエンジニアライフの注意が必要です。

症状の緩和策のたて方

愛用しすぎたぬいぐるみの汚れと同じように、自分でなんとかしようとする思考がエンジニアの心身に染みついているので変えようと思っても変わりませんし、急に対処するとパニックを起こしかねませんので緩和した対処が求められます。

緩和策の例

緩和策には次のようなものがありますのでご参考にしてください。

ワークロードの可視化

自分でなんとかしようと症候群の症状の疑いがある若しくは罹ってしまったエンジニアには、まず、本人の法定労働時間は週40時間であることを可視化しましょう。

可視化の際も、罹患しているエンジニアに対してではなく、チーム全員が週40時間が法定労働時間であることを確かめ合い、お互いに作業を助け合おうという方針を確認することで間接的に認識させましょう。

前段取りで迷子にしない

自分でなんとかしよう症候群のエンジニアは作業見積もりの精度が甘々です。甘い作業見積もりを責めてはいけませんし、それで症状は改善しません。

作業の担当をアサインするときに、前提条件、必要な情報のリスト、作業のマイルストーンを尋ねる側が知りたい、知っておかないと顧客に尋ねられて困りそうだ、と他者を起因として知る必要があると伝えながら、雑談するように前段取りをしてしまいましょう。

つまり、前段取りで準備作業を可視化し、進めて問題ない状態から作業させると純粋に作業だけになりますから、作業をしながら迷子になることを防止します。

それではお大事に。

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

中小企業のシステム内製化にはアジャイルが良く似合う

まあ、多分、タイトルには後ろに隠れている前提があるんだろうなぁ、と思いながら読み進めるのが問題提起型のブログの読み手としては、一つの対処方法なのだろうと思うのです。

quality-start.in

例えば、

ITは費用ではない、投資である

という標題から始まります。過去に「内製回帰を訴えた時に考えていた」ときのことですから、今は違うのでしょう。

これ、間違いといえば間違いですし、正解といえば正解にできなくもない。両方なんですよ。ITも今はエンプラ向けにもサブスクリプションがそこそこ浸透し始めています。導入して勘定科目を費用にできるものは費用です。まあ固定費でいいのでしょうけれど。office365や社内ポータルなどを思い浮かべるといいかもしれません。

じゃあ、これまでそういった契約がなかったのかといえば、保守だってライセンスと技術サポートのサブスクリプションと言えるのではないかと思うのですが。

一方、IT投資はIT化することでコストメリットや生産性向上を狙いとして資金を充当する行為です。投資だから投資した分は投資したコストを回収しなければならないのです。

どっちもあるよ。企業規模に関わらず、ということです。まあ、小さな企業なら特例などを駆使して、費用で処理して節税効果を得たいでしょうが。

社員をおくこと自体が投資なのでは

元記事の順序が逆転するのは勘弁願うとして。

いろいろ書かれていますが、

内製する対象に限界があり、定期的に仕事を生み出せない

とあります。

中小の社長が考えることは、人を雇う前に何をやらせるのか、です。雇ってから仕事を作る経営者も中にはいるようですが。

ただ、中小企業だからこそ、コストに敏感だし、うるさいです。そこに専任でIT担当をおくということは、年間数百万のコスト負担が出るということを真っ先に意識します。

特に、事業の受注残やキャッシュフローが頭に入っている経営者は。

そういったこともあって、中小企業でのIT担当者は、通常はIT専任ではないということです。兼務者、です。多くが、総務と兼務か営業と兼務です。10人とか20人とかしかいないので。

そこを専任で内製化をするとなると、兼務が5対５だったとしたら、兼務でIT担当以外の仕事をITに振り戻すので、もう、これだけで投資です。月のコストが20万の社員なら毎月10万、年間120万が投資です。

"内製が正しいのか不安になった"

標題が長いので前半は切りました。理由はそれだけです。

さて、その先にこんなことがアンダーラインまで引いて書かれています。

エンジニアが仮に入社したとしても、ビジネスサイドに技術がわかる方(エンジニアと仕様策定・要件定義のコミュニケーションが取れる方）がいなければ、宝の持ち腐れになってしまいます。

うーん、例えば10人規模の会社、別に20人でもいいのですが、所謂、中小企業でITを担当する方のお仕事にどんなものがあるかといえば、OAサポートです。PCの設定とトラブル対応と、もしあればNASのお守りとインターネットに繋げるためのオフィス内のネットワーク設定とトラブル対応くらい。ああ、人事給与のパッケージを使っていたら設定関連でお仕事があるかもしれません。あとは、IT機器の設定と管理ですね。

事業上、販売管理システムや生産管理システムがある場合は、そこも対象に入ってきます。

そこに内製化の担当業務を渡すわけです。内製化するぞ、と。

ところで、内製化するぞと経営者が判断したあと、どうして不安になるのでしょうか。それまでは、何かをITで解決したいという経営上の課題は、自己解決してきたか、スポット契約で地場のIT会社に依頼して解決するケースが多いです。中小企業なので。

そこにエンジニアが入ってきたら、アウトソースして解決していた経営上の課題を自己解決できるようになるのです。固定費以上はお買い物がなければキャッシュアウトしなくなるのです。

では不安はどこにあるか。

 エンジニアの技術力がシングルスキルだと暗黙で思っていませんかね、と。中小企業だからこそ、それこそフルスタックエンジニアではないけれどマルチで技術を使えないと、でも全部ではなく、その課題ごとに必要な技術を覚えながらやればいいのだけれど、という感じでいいのです。

何せ、内製化でコストは固定費ですから。あと、請け負っているわけではないので、納期なんてあるようでないようなものです。ここ大事。

何より、経営者はエンジニアも事業と同じように育てさせればいいのです。1人しかいない貴重なエンジニアに事業のネタを考えてトライさせればいい。そのための0.5人月を専任化に回すのですから。

中小企業です。中小企業にほどアジャイルは合うと思うのですよね。ひとりアジャイルだろうけど。

あと、内製化したら属人化するか。いいえ、SIerでも属人化ばかりです。そんなことを心配するくらいならSIerはもっと心配しないといけない。

リーン・スタートアップ

ジョイ・インク 役職も部署もない全員主役のマネジメント